Qu'est-ce que l'IPsec ? Quand faut-il l'utiliser ?

L'IPsec est un ensemble de protocoles standard, indépendant de tout fournisseur, utilisé

pour relier deux réseaux locaux physiquement distincts. Les réseaux locaux sont reliés
comme s'il s'agissait d'un seul réseau logique, bien qu'ils soient séparés par l'Internet.
En théorie, IPsec prend en charge le cryptage nul, c'est-à-dire que vous pouvez créer des
VPN qui ne cryptent pas le trafic. IPsec prend également en charge l'intégrité des données
nulle. Mais cela présente-t-il des avantages par rapport au trafic ordinaire ? Non. Personne
ne peut faire confiance à un trafic dans lequel une attaque a pu être injectée par un pirate. Il
est rare que les gens veuillent des données envoyées par une source inconnue. La plupart
des gens souhaitent également que les données du réseau privé, telles que les transactions
par carte de crédit et les dossiers médicaux, restent privées.
Quel que soit le fournisseur, les VPN IPsec ont presque toujours des paramètres qui leur
permettent d'offrir trois avantages importants :
- L'authentification : pour vérifier l'identité des deux extrémités.
- L'intégrité des données (ou HMAC) : pour prouver que les données encapsulées n'ont pas
été altérées lors de leur passage sur un
réseau potentiellement hostile
- la confidentialité (ou le cryptage) : pour s'assurer que seul le destinataire prévu peut lire le
message.

Si vous faites passer votre VPN à travers des pare-feu, il est utile de savoir quels protocoles
autoriser.
IPsec est une suite de protocoles distincts. Elle comprend :
- Internet Key Exchange (IKE) : IKE est utilisé pour authentifier les pairs, échanger des clés et
négocier le cryptage et les sommes de contrôle qui seront utilisés; il s'agit essentiellement
du canal de contrôle.
- AH contient l'en-tête d'authentification - les sommes de contrôle qui vérifient l'intégrité
des données.
- Encapsulation Security Payload (ESP) : ESP est la charge utile de sécurité encapsulée - la
charge utile chiffrée,
essentiellement, le canal de données.
Donc, si vous devez faire passer le trafic IPsec à travers un pare-feu, rappelez-vous : autoriser
un seul protocole ou numéro de port n'est généralement pas suffisant.
Notez que la RFC IPsec mentionne AH ; cependant, AH n'offre pas de cryptage, un avantage
important. AH n'est donc pas utilisé par FortiGate. Par conséquent, vous n'avez pas besoin
d'autoriser le protocole IP AH (51).
Pour créer un VPN, vous devez configurer des paramètres correspondants aux deux
extrémités, que le VPN soit entre deux dispositifs FortiGate, FortiGate et FortiClient, ou un
dispositif tiers et FortiGate. Si les paramètres ne correspondent pas, la configuration du
tunnel échoue.
Certains FAI bloquent le port UDP 500, ce qui empêche l'établissement d'un VPN IPsec. Vous
pouvez utiliser la commande CLI présentée sur la diapositive pour configurer des ports
personnalisés pour IKE et IKE NAT-T.
Le port UDP par défaut pour le trafic IKE est 500, mais vous pouvez sélectionner un port
personnalisé dans la plage de ports 1024 à 65535. Le port par défaut pour le trafic IKE en
mode NAT-T est 4500, mais vous pouvez le changer pour un port personnalisé de la plage de
ports 1024 à 65535.
IKE négocie les clés privées, les authentifications et le chiffrement que FortiGate utilise pour
créer un tunnel IPsec. Les associations de sécurité (SA) constituent la base de l'intégration
des fonctions de sécurité dans IPsec. IKE utilise deux phases distinctes : la phase 1 utilise une
seule SA bidirectionnelle, et la phase 2 utilise deux SA IPsec, une pour chaque direction de
trafic.

Ensuite, vous allez examiner les différences entre le mode agressif et le mode principal.
Cette diapositive montre le mode principal, où six paquets sont échangés :
1. Le client prend l'initiative en proposant les politiques de sécurité.
2. Le répondeur choisit la politique de sécurité qu'il accepte d'utiliser et répond.
3. L'initiateur envoie sa valeur publique Diffie Hellman.
4. Le répondeur répond avec sa propre valeur publique Diffie Hellman.
5. L'initiateur envoie son peer ID et son hash payloads.
6. Le répondeur répond avec son ID d'homologue et sa charge utile de hachage.

En comparaison, cette diapositive montre la négociation en mode agressif dans laquelle

seuls trois paquets sont échangés :
1. Le client commence en suggérant les politiques de sécurité et en fournissant sa valeur
publique Diffie Hellman et son ID de pair.
PAIR.
2. Le répondeur répond avec les mêmes informations, plus un hachage.
3. L'initiateur envoie sa charge utile de hachage.

L'authentification étendue (XAuth) peut être utilisée comme un niveau supplémentaire

d'authentification. Lorsque XAuth est utilisé, un côté doit fournir des informations
d'identification (nom d'utilisateur et mot de passe) afin de réussir l'authentification.
XAuth intervient après la phase 1 et avant toute négociation de la phase 2. C'est pourquoi
XAuth est parfois appelé phase 1.5.
Dans toute communication XAuth, il y a toujours un client et un serveur. Le serveur envoie
un paquet CFG_REQUEST, auquel le client doit répondre par un paquet CFG_REPLY. Le
paquet CFG_REPLY contient les informations d'identification de l'utilisateur. Si
l'authentification est correcte, le serveur envoie CFG_SET et le client répond par CFG-ACK.

Un FortiGate prend en charge trois méthodes différentes pour configurer automatiquement

les paramètres IP des clients IPsec : Configuration en mode IKE, DHCP sur IPsec et L2TP sur
IPsec.
Cette diapositive présente la configuration du mode IKE.
Après la phase 1 et avant la phase 2, le client envoie un message CFG_REQUEST énumérant
les paramètres IP requis (ou attributs). Le serveur répond par un message CFG_REPLY, qui
contient les valeurs attribuées pour chacun des attributs demandés.
Lorsque le premier paquet IPsec de phase 1 arrive, le FortiGate agissant en tant que
répondeur utilise la première configuration de phase 1 (par ordre alphabétique) qui
correspond à ce qui suit :
- IP de la passerelle locale
- Mode (agressif ou principal)
- ID de l'homologue, si le mode agressif est utilisé. Comme expliqué, seul le mode agressif
inclut l'ID de l'homologue dans le premier paquet.
- Méthode d'authentification (pour les clés pré-partagées et les certificats)
- Informations sur le certificat numérique, si les certificats sont utilisés comme méthode
d'authentification.
- Proposition
- Groupe DH
Toutefois, dans certaines circonstances, FortiOS peut passer à une phase 1 différente, s'il
constate qu'il a initialement sélectionné la mauvaise phase 1. Cette opération est appelée
revalidation de la passerelle et s'applique uniquement aux cas suivants :
- IKEv1 avec authentification par certificat
- IKEv2 avec authentification par clé pré-partagée
- IKEv2 avec authentification par certificat
Pour isoler les problèmes IPsec, il est utile de comprendre qu'une connexion IPsec peut être
décrite comme un processus en plusieurs étapes :
1. Le trafic intéressant déclenche la négociation VPN. Le trafic est dit intéressant lorsqu'il
doit traverser un tunnel IPsec (crypté et encapsulé).
tunnel IPsec (crypté et encapsulé) pour atteindre un réseau distant.
2. La phase 1 est lancée.
3. Si une authentification étendue est requise, un côté s'authentifie.
4. Si un côté requiert des paramètres IP, l'autre côté envoie les paramètres requis via la
configuration du mode IKE.
5. Une ou plusieurs phases 2 sont lancées. Deux SA IPsec sont négociés pour chaque phase 2.
6. Le trafic traverse le tunnel.
Donc, si vous avez un problème IPsec, vous devez identifier dans laquelle de ces étapes le
problème s'est produit.