Qu’est-ce qu’IPsec ? Architecture, limites et cas d’usage réels

IPsec (Internet Protocol Security) n’est pas un protocole unique, mais une suite de mécanismes de sécurité opérant directement au niveau IP (couche 3). Là où OpenVPN et WireGuard® encapsulent leur trafic dans UDP ou TCP, IPsec modifie le fonctionnement du réseau lui-même. Cette approche explique son statut paradoxal : massivement déployé dans les infrastructures professionnelles et intégré nativement à iOS/macOS, mais rarement optimal pour l’utilisateur grand public en raison de sa complexité, de sa sensibilité au NAT, et de la fragmentation de ses implémentations.

Qu'est-ce que l'IPsec ?

IPsec a été conçu pour un Internet moins mobile, moins soumis au NAT, et plus homogène qu’aujourd’hui ; l’écart entre ce modèle d’origine et la réalité actuelle explique une grande partie de ses limites. Comprendre IPsec, c’est comprendre pourquoi les VPN modernes se sont détournés de cette architecture… et pourquoi elle subsiste malgré tout, non par supériorité technique, mais par nécessité d’écosystème.

Qu'est-ce que IPsec ? : Sommaire

Architecture IPsec : modes, composants et implications

IPsec repose sur plusieurs blocs indépendants dont la combinaison offre une grande flexibilité au prix d’une grande complexité.

Mode tunnel vs mode transport

Le mode transport chiffre uniquement la charge utile du paquet, laissant l’en-tête IP d’origine visible. Les adresses source et destination restent exposées, rendant ce mode inadapté aux VPN commerciaux qui doivent masquer l’adresse IP de l’utilisateur. Le mode transport est réservé aux communications host-to-host dans des environnements contrôlés (serveur ↔ serveur, VM ↔ VM).
Le mode tunnel encapsule le paquet IP entier (en-tête + payload) dans un nouveau paquet IP. Il garantit la confidentialité des adresses et du contenu, mais au prix d’un overhead plus élevé : un en-tête IP externe supplémentaire s’ajoute aux en-têtes IPsec eux-mêmes, et la MTU devient plus délicate à gérer. C’est le standard pour les VPN et les connexions site-to-site.

AH vs ESP : une brique morte, une brique dominante

IPsec définit deux protocoles de sécurisation.

Authentication Header (AH) garantit l’intégrité via HMAC, mais n’offre aucun chiffrement et ne survit pas au NAT : toute modification de l’en-tête IP par un routeur NAT invalide l’authentification, rendant le protocole inopérant sur l’Internet moderne. AH est devenu quasiment inutilisable hors environnements très contrôlés.

Encapsulating Security Payload (ESP) chiffre la charge utile et authentifie le paquet sans dépendre de l’en-tête IP externe. ESP ajoute son propre en-tête (avec un SPI et un numéro de séquence anti-rejeu), chiffre le contenu, puis ajoute un bloc final contenant notamment le padding d’alignement et le code d’intégrité. ESP est l’unique composant réellement utilisé par les VPN modernes.

NAT-T : la contrainte fondamentale

ESP utilise le protocole IP 50, distinct de TCP et UDP. Les routeurs NAT grand public gèrent essentiellement TCP et UDP, mais ne savent pas translater correctement les paquets ESP. Sans adaptation, les paquets ESP se heurtent au NAT. IPsec contourne cette limitation via NAT Traversal (NAT-T) : encapsuler ESP dans UDP sur le port 4500.

NAT-T introduit un overhead supplémentaire (8 octets UDP) et une dépendance aux keepalive pour maintenir le mapping NAT actif, ce qui impacte autonomie et stabilité sur mobile. L’overhead total est en pratique de l’ordre de 60 à 90 octets par paquet selon la configuration. Le debugging devient complexe : identifier si le problème vient d’IKE, d’ESP, du NAT ou du firewall nécessite des outils réseau avancés. C’est cette sensibilité au NAT qui rend WireGuard nettement plus adapté aux usages actuels, puisqu’il a été conçu dès le départ pour être NAT-friendly.

IKEv1 vs IKEv2 : héritage cassant, correction partielle

IPsec ne définit pas comment les clés sont échangées. Cette responsabilité incombe au protocole IKE (Internet Key Exchange), qui négocie les algorithmes cryptographiques, génère les clés et établit les Security Associations (SA).

IKEv1 (1998) souffre de faiblesses structurelles. Le mode Aggressive envoie l’identité en clair et expose les PSK aux attaques par dictionnaire offline. La négociation nécessite 6 messages (main mode), introduisant une latence initiale significative. IKEv1 ne supporte pas nativement la mobilité : un changement d’adresse IP force une renégociation complète. Aujourd’hui, IKEv1 est un indicateur de retard technique.

IKEv2 (RFC 7296, 2014) simplifie l’architecture : négociation réduite à 4 messages, authentification mutuelle renforcée avec support des certificats et d’EAP, détection améliorée des pairs inactifs via Dead Peer Detection, et intégration du protocole MOBIKE permettant de maintenir une session IPsec malgré un changement d’adresse IP. Cette fonctionnalité est essentielle pour les usages mobiles où les bascules 4G ↔ WiFi sont fréquentes.

Cependant, IKEv2 reste moins réactif que WireGuard®. La reconnexion IKEv2 nécessite une renégociation partielle via MOBIKE, là où WireGuard, stateless par design, peut reprendre presque instantanément. En conditions réelles, IKEv2 montre une latence de reconnexion de quelques centaines de millisecondes, quand WireGuard® reste généralement sous la barre des 100 ms sur mobile.

Suite cryptographique : flexibilité vs sécurité par défaut

IPsec permet de choisir librement les algorithmes cryptographiques. Une configuration moderne s’appuie sur :

  • AES-256-GCM ou ChaCha20-Poly1305
  • SHA-256 pour l’intégrité si la suite n’utilise pas AEAD
  • un groupe Diffie-Hellman 14 minimum ou idéalement Curve25519
  • authentification par certificats X.509 ou PSK fort

Ces suites sont solides et largement auditées.

Le problème réside dans la flexibilité elle-même : rien n’empêche un administrateur de configurer 3DES, SHA-1, des groupes DH faibles, ou d’omettre la Perfect Forward Secrecy. C’est la différence fondamentale avec WireGuard®, où il est impossible de mal configurer le protocole car les choix cryptographiques sont imposés et modernes par défaut.

La PFS dans IPsec dépend de la politique de rekey : si chaque renégociation force un nouvel échange Diffie-Hellman, PFS est garantie. Sinon, elle est absente. WireGuard® applique nativement un rekey fréquent et imposé, éliminant ce risque de configuration.

Performance et stabilité : solide en théorie, fragile en pratique

IPsec peut atteindre d’excellents débits sur matériel moderne grâce à l’accélération AES-NI. Le chiffrement n’est pas le goulot.

Les limites viennent d’ailleurs : overhead réseau, fragmentation MTU et tolérance aux environnements instables.

En mode tunnel avec NAT-T, IPsec ajoute 60 à 90 octets par paquet, contre environ 60 octets pour WireGuard et 50 à 70 octets pour OpenVPN en UDP. L’overhead n’est pas catastrophique, mais IPsec n’est pas le plus efficace. Sur des connexions rapides ou des paquets de petite taille (IoT, VoIP), cet overhead relatif devient perceptible.

Le point réellement sensible est la fragmentation MTU. L’overhead combiné d’ESP, d’UDP (NAT-T) et de l’en-tête IP externe dépasse facilement le MTU standard de 1500 octets. Les paquets fragmentés nécessitent un réassemblage, ajoutant latence et charge CPU. Sur des connexions rapides, la fragmentation devient un goulot d’étranglement potentiel. Certains réseaux mal configurés bloquent ou droppent les fragments IP : si un fragment est perdu, le paquet entier est perdu et TCP doit le retransmettre intégralement.

La solution consiste à réduire le MTU de l’interface VPN à 1400 ou 1280 et activer Path MTU Discovery, mais cela nécessite une compétence réseau que l’utilisateur lambda n’a pas. WireGuard gère cela automatiquement avec un MTU réduit par défaut.

Pourquoi les VPN commerciaux proposent IKEv2/IPsec

Les fournisseurs VPN proposent IKEv2/IPsec pour deux raisons principalement techniques et d’écosystème. Apple intègre nativement IKEv2/IPsec dans iOS et macOS avec une API stable et une gestion MDM complète. Un fournisseur peut déployer un profil VPN sans installer d’application tierce, garantissant une compatibilité durable avec les environnements professionnels Apple.

Parallèlement, IPsec reste l’option logique pour les entreprises utilisant des équipements Cisco, Juniper ou Fortinet depuis des décennies, disposant d’une PKI interne déjà déployée, et devant respecter des certifications strictes comme FIPS 140-2. Un VPN commercial propose donc IKEv2/IPsec par obligation de compatibilité et d’interopérabilité, pas par préférence technique.

Quand utiliser IPsec ?

IPsec reste pertinent dans trois scénarios :

  • les connexions site-to-site entre data centers ;
  • les environnements Apple ou MDM où aucune app tierce n’est autorisée ;
  • les infrastructures disposant déjà d’une PKI interne et de firewalls configurés pour IPsec.

Pour l’utilisateur VPN grand public, WireGuard offre de bien meilleurs résultats sur l’essentiel : vitesse, stabilité, mobilité, simplicité d’audit, résistance aux environnements NAT complexes. L’auditabilité d’IPsec est compromise par la fragmentation de ses implémentations (Windows, Apple, Android, strongSwan, Libreswan). Chaque implémentation peut avoir ses propres bugs ou faiblesses. Un audit de sécurité d’une implémentation ne garantit rien pour les autres.

Un fournisseur proposant uniquement IPsec sans WireGuard ni OpenVPN montre un retard technologique. La présence d’IKEv1, une authentification par PSK faible, l’absence de PFS documentée ou l’absence de paramètres de rekey clairs sont des signaux clairs d’une mauvaise maîtrise du protocole.

Controverses et perception post-Snowden

Les révélations Snowden de 2013 ont montré que la NSA avait tenté d’affaiblir certains standards cryptographiques, notamment Dual_EC_DRBG, un générateur de nombres aléatoires intégré à certaines implémentations IPsec. Les algorithmes IPsec actuels, AES-GCM, ChaCha20-Poly1305, SHA-256, sont solides et largement audités. Le risque historique concernait les générateurs aléatoires, pas les protocoles ESP ou IKE eux-mêmes. Les implémentations modernes ont abandonné Dual_EC_DRBG.

Le problème est principalement perceptionnel. IPsec est si complexe qu’un utilisateur non-expert ne peut pas vérifier si la configuration est saine. La multiplicité des choix cryptographiques et des implémentations alimente la méfiance. WireGuard® limite ce risque en réduisant la surface d’attaque et en imposant des choix modernes par défaut.

Conclusion

IPsec demeure un protocole robuste et cohérent dans les environnements pour lesquels il a été conçu : entreprises, interconnexions réseau, écosystèmes Apple et infrastructures nécessitant une conformité stricte. En IKEv2/ESP, il fournit une sécurité élevée lorsque la configuration est maîtrisée. Mais cette même flexibilité, indispensable aux déploiements professionnels, devient une faiblesse pour les usages grand public.

Pour un utilisateur informé, WireGuard® offre de meilleures garanties : simplicité, performance, résilience, auditabilité. OpenVPN reste une alternative fiable lorsqu’une compatibilité maximale est requise. IPsec est un choix par contrainte d’écosystème, rarement par préférence technique.

Les autres protocoles VPN

  • IKEv2 — excellent en mobilité et en reprise de session
  • L2TP — encapsulation ancienne reposant sur IPsec
  • SoftEther — suite VPN multi-protocoles orientée flexibilité
  • Comparatif : OpenVPN vs WireGuard
  • Comparatif : IKEv2 vs OpenVPN

  • Shadowsocks — proxy chiffré conçu pour la censure active, pas un VPN, pas d’anonymat

  • PPTP — protocole obsolète et compromis, à éviter
Share This