IKEv2/IPsec et OpenVPN partagent un objectif identique (chiffrer un tunnel point à point) mais divergent sur à peu près tout le reste : pile protocolaire, surface d’attaque, comportement face au NAT, agilité cryptographique et capacité à traverser des réseaux restrictifs. Nous détaillons ici les points de friction réels entre ces deux protocoles VPN, ceux qui déterminent un choix en production.
Agilité cryptographique d’IKEv2 : les drafts IETF qui changent la donne
La plupart des comparatifs figent IKEv2 à son RFC 7296 de 2014. C’est ignorer les travaux récents de l’IETF qui élargissent sensiblement le périmètre cryptographique du protocole.
A découvrir également : Quelle est la plus grande source de logiciels malveillants ?
Un Internet-Draft introduit l’usage de fonctions pseudo-aléatoires à sortie variable (PRF+), mettant à jour les RFC 7296 et 7815. Concrètement, la dérivation de clés gagne en souplesse lorsque ces PRF sont employées.
Un second draft, portant sur KMAC et SHAKE, ajoute le support des primitives SHA-3 comme fonctions cryptographiques utilisables par IKEv2. Ces deux évolutions ouvrent la porte à des suites post-quantiques ou hybrides côté IKEv2, alors qu’OpenVPN reste tributaire de la bibliothèque OpenSSL (ou mbedTLS) sous-jacente pour sa propre agilité.
A voir aussi : Comment savoir si j’ai un ransomware ?
En pratique, cela signifie qu’un déploiement IKEv2 récent peut négocier des algorithmes que le stack TLS d’OpenVPN ne propose pas encore nativement. L’écart se creuse sur les environnements soumis à des exigences de conformité élevées, où la capacité à substituer rapidement une primitive compromise compte autant que le niveau de chiffrement nominal.
Kernel-space contre userspace : impact sur le débit et la latence du VPN
IKEv2/IPsec traite le chiffrement en kernel-space, sans context switching entre espace utilisateur et noyau. Le résultat est un overhead par paquet réduit et une latence plus stable sous charge.
OpenVPN fonctionne intégralement en userspace. Chaque paquet transite par le processus OpenVPN, subit un chiffrement TLS, puis redescend vers le noyau pour l’émission. Ce va-et-vient ajoute de la latence, surtout sur des machines à faible puissance (routeurs embarqués, Raspberry Pi, terminaux mobiles anciens).
Conséquences mesurables sur mobile
Sur un smartphone qui change de réseau (Wi-Fi vers cellulaire), IKEv2 exploite MOBIKE pour basculer sans renégocier le tunnel. La reconnexion prend moins de 200 ms dans la majorité des implémentations natives. OpenVPN, lui, doit rétablir la session TLS complète, ce qui prend plusieurs secondes selon la qualité du lien.
Nous observons aussi une différence de consommation énergétique : le traitement kernel-space d’IKEv2 sollicite moins le processeur applicatif, ce qui prolonge l’autonomie sur les appareils mobiles.
Traversée de pare-feu et résistance au DPI : avantage OpenVPN
IKEv2 utilise les ports UDP 500 et 4500, ainsi que le protocole IP 50 (ESP). Ces ports sont identifiables et fréquemment bloqués par les pare-feu d’entreprise ou les dispositifs de censure étatique. Un réseau qui filtre le protocole ESP coupe IKEv2 sans recours possible.
OpenVPN peut fonctionner sur n’importe quel port, TCP ou UDP, y compris le port 443 (HTTPS). Ce comportement le rend beaucoup plus difficile à bloquer par simple filtrage de port. Face au Deep Packet Inspection, OpenVPN sur TCP 443 peut être encapsulé dans un flux TLS standard, ce qui complique la détection.
- IKEv2 est bloqué dès qu’un pare-feu refuse ESP ou les ports 500/4500, sans contournement natif.
- OpenVPN en mode TCP 443 se confond avec du trafic HTTPS classique pour un filtrage basique.
- Contre un DPI avancé, OpenVPN peut être couplé à des techniques d’obfuscation (scramble, XOR patches) qu’IKEv2 ne supporte pas.
- Sur les réseaux d’hôtels, aéroports ou pays restrictifs, OpenVPN passe là où IKEv2 échoue régulièrement.
Failles d’implémentation et surface d’audit du protocole VPN
La sécurité d’un protocole se juge aussi à la qualité de ses implémentations. OpenVPN, projet open source audité par de multiples organismes, bénéficie d’une base de code unique et largement relue. OpenVPN 2.7.7, publié récemment, corrige plusieurs vulnérabilités et améliore la gestion des certificats.
IKEv2 repose sur des implémentations variées selon l’OS : strongSwan sous Linux, le stack natif sous Windows, celui d’Apple sous macOS/iOS. Cette fragmentation complique l’audit global.
Fuites de trafic sur macOS
L’implémentation IKEv2 intégrée à macOS présente des problèmes documentés de fuite de trafic susceptibles d’exposer l’adresse IP réelle de l’utilisateur. Ce type de faille ne relève pas du protocole lui-même mais de son intégration au système, un risque que les administrateurs réseau doivent prendre en compte lors du choix d’un client VPN.
À l’inverse, certains fournisseurs ont fait le choix inverse concernant OpenVPN : Mullvad a abandonné le support d’OpenVPN pour se concentrer sur WireGuard, estimant que la maintenance de la pile TLS d’OpenVPN devenait trop lourde par rapport au bénéfice.
IKEv2 ou OpenVPN : critères de choix selon le contexte réseau
Nous recommandons IKEv2 dans les scénarios suivants : flotte mobile avec changements de réseau fréquents, environnements où la latence doit rester basse, et infrastructures conformes aux recommandations ANSSI (qui préconise IKEv2/IPsec pour les environnements sensibles).
OpenVPN reste le choix pertinent quand le réseau cible applique du filtrage strict, quand l’obfuscation du trafic VPN est nécessaire, ou quand l’équipe IT exige un contrôle total sur la configuration (choix du port, du transport TCP/UDP, de la bibliothèque crypto).
- Mobilité et reconnexion rapide : IKEv2 avec MOBIKE.
- Réseaux restrictifs ou censurés : OpenVPN en TCP 443 avec obfuscation.
- Débit maximal sur serveur dédié : IKEv2 kernel-space ou, mieux, WireGuard.
- Audit de sécurité centralisé : OpenVPN, base de code unique et documentée.
- Conformité réglementaire (ANSSI, NIS2) : IKEv2/IPsec ou OpenVPN, selon le contexte de déploiement.
Le choix entre IKEv2 et OpenVPN n’est pas un arbitrage de chiffrement – les deux protocoles offrent un niveau de confidentialité comparable avec des suites modernes. La vraie différence se joue sur la couche réseau : traversée de pare-feu, comportement en mobilité, surface d’implémentation. Poser la question du contexte de déploiement avant celle du protocole évite la majorité des erreurs de dimensionnement.
