IKEv2/IPsec : Quand c’est un meilleur choix que WireGuard ou OpenVPN

Le cadre décisionnel : ce que vous choisissez réellement

«VPN» n’est pas une seule décision. C’est un ensemble de décisions :

• Surface client : Voulez-vous un client natif du système d’exploitation avec des commandes MDM, ou une application tierce que vous devez déployer, mettre à jour et dépanner ?
• Modèle d’identité : Voulez-vous des certificats, EAP (avec RADIUS/AD), une identité de périphérique, des politiques par utilisateur et une révocation propre ? Ou une clé partagée et une prière ?
• Tolérance à l’hostilité réseau : Pouvez-vous survivre au NAT, aux portails captifs, au carrier-grade NAT et au roaming Wi‑Fi sans voir vos tunnels osciller ?
• Visibilité opérationnelle : Pouvez-vous capturer, interpréter et auditer ce qui s’est passé à 3h du matin ?
• Écosystème fournisseur : Votre pile inclut-elle des pare-feux, des équilibrages de charge et du matériel d’identité qui «parlent IPsec» couramment ?

WireGuard l’emporte pour la simplicité et les performances. OpenVPN gagne pour «ça tourne partout et on le connaît déjà». IKEv2/IPsec l’emporte lorsque vous tenez à l’intégration entreprise, la stabilité en mobilité, la politique et la prévisibilité opérationnelle de niveau conformité.

Voici l’heuristique franche que j’utilise en production :

• Si vous construisez une superposition conviviale pour développeurs entre points connus et que vous pouvez gérer proprement les clés, commencez par WireGuard.
• Si vous avez besoin d’une compatibilité maximale avec des clients anciens et des environnements tiers, OpenVPN fait encore son travail.
• Si vous avez besoin de clients natifs, de configurations pilotées par MDM, d’une intégration forte de l’identité et de tunnels qui survivent au roaming, choisissez IKEv2/IPsec et ne vous excusez pas.

Faits et histoire qui comptent en production

Quelques éléments de contexte qui expliquent pourquoi IKEv2/IPsec se comporte comme il le fait aujourd’hui — et pourquoi il est souvent le «par défaut entreprise».

1. IKEv2 a été conçu pour remplacer la complexité et la fragilité d’IKEv1 (moins d’échanges de messages, machine d’état plus claire). Vous le ressentez en débogage : moins de «phase 1/phase 2 folklore», et une négociation plus structurée.
2. MOBIKE (Mobility and Multihoming) est une fonctionnalité de première classe dans IKEv2. Il est conçu pour des clients passant d’un réseau à l’autre sans démanteler le tunnel.
3. La traversée de NAT (NAT-T) a standardisé l’encapsulation UDP pour IPsec, le rendant praticable à travers la plupart des NAT grand public. Ce n’est pas parfait, mais ce n’est pas une rustine collée sur le côté.
4. De nombreux fournisseurs d’OS ont livré IKEv2 comme le chemin VPN «natif» tout en traitant OpenVPN/WireGuard comme tiers. Cela change tout en gestion de flotte : distribution de politiques, magasins de certificats et application des postures de sécurité.
5. IPsec est ancré dans les appliances réseau (pare-feux, routeurs, boîtiers SD‑WAN). Même si l’interface est pénible, l’histoire d’interopérabilité est mature.
6. L’agilité cryptographique est un vrai sujet opérationnel : les suites IPsec supportent depuis longtemps plusieurs algorithmes et négociations, utile quand la conformité change plus vite que le déploiement des endpoints.
7. IKEv2 prend en charge les méthodes EAP (comme EAP‑TLS, EAP‑MSCHAPv2) pour l’authentification utilisateur ; c’est pourquoi il est un pilier dans les entreprises avec RADIUS.
8. La confidentialité persistante (PFS) est un comportement normal dans les profils IPsec modernes, et les auditeurs apprécient qu’elle soit explicite et standard plutôt que «faites-nous confiance».

Une citation que je garde sur le tableau mental chaque fois que quelqu’un propose une configuration VPN «astucieuse» :

Idée paraphrasée — Werner Vogels : vous devriez concevoir pour la défaillance parce que tout finit par tomber en panne, et le système doit continuer à fonctionner malgré tout.

Où IKEv2/IPsec bat WireGuard et OpenVPN

1) Clients natifs et contrôle par MDM (le super-pouvoir sous-estimé)

Dans le monde réel, «déployer un VPN» signifie : ordinateurs portables gérés par MDM, smartphones soumis à l’accès conditionnel, et une équipe sécurité qui veut des vérifications de posture et une identité basée sur certificats. Les clients IKEv2 natifs sont intégrés à Windows, macOS, iOS et de nombreuses distributions Android. Cela compte parce que :

• Vous pouvez pousser des profils via MDM sans livrer un client tiers.
• Vous pouvez tirer parti des magasins de certificats OS et des clés protégées par keychain/TPM.
• Vous pouvez utiliser des fonctionnalités plateforme comme Always On VPN (Windows) avec IKEv2.
• Vous réduisez le cycle de mise à jour des clients et les incidents «l’appli VPN a cassé après une mise à jour OS».

WireGuard est compact et propre, mais sur des endpoints gérés vous déployez toujours un logiciel (ou vous comptez sur un support intégré qui n’est pas universel). OpenVPN implique presque toujours de déployer un client et un bundle de configuration, puis gérer «quelle version cet utilisateur exécute?» pendant les cinq années suivantes.

2) Stabilité en mobilité avec MOBIKE

Si vous prenez en charge des utilisateurs mobiles, votre VPN doit survivre : du Wi‑Fi bureau à la 4G, du Wi‑Fi d’hôtel au tethering, changements d’adresse IP, rebinding NAT et réseaux qui abandonnent silencieusement les mappings UDP inactifs. IKEv2 avec MOBIKE a été conçu exactement pour cela. Il peut mettre à jour les points de terminaison et garder la SA vivante sans renégocier tout depuis le départ.

WireGuard gère aussi bien le roaming (il est à la base conçu pour cela), mais IKEv2 vous offre ce comportement dans des cadres de politique entreprise et des appliances fournisseurs que les équipes sécurité connaissent déjà et en qui elles ont confiance.

3) Modèles d’authentification entreprise : EAP + RADIUS + certificats

Le modèle d’identité de WireGuard repose sur des clés publiques. C’est un avantage, pas un bug — jusqu’à ce que vous ayez besoin d’identité utilisateur, d’adhésion à des groupes, d’intégrations MFA et d’une désactivation propre liée au offboarding RH.

IKEv2 brille lorsque vous avez besoin de :

• EAP-TLS (le plus solide : certificats des deux côtés, pas de mots de passe en clair)
• Authentification RADIUS avec politique centralisée et comptabilité
• Contrôle d’accès par utilisateur/appareil via attributs, groupes et profils de certificats

OpenVPN peut aussi s’intégrer à ces fonctions, mais vous assemblez souvent des plugins, des scripts et un «s’il vous plaît ne mettez pas à jour OpenVPN avant qu’on reteste la pile d’auth». Les piles IPsec tendent à avoir ces intégrations en natif.

4) Posture conformité et audit

Certaines organisations doivent répondre à des questions comme : «Quelles suites de chiffrement sont autorisées ?», «Appliquons-nous la PFS ?», «Pouvons-nous prouver l’identité de l’appareil ?», «Pouvons-nous consigner le début/fin de connexion et l’identité utilisateur ?»

IKEv2/IPsec s’intègre souvent bien dans les récits d’audit parce que le vocabulaire politique est standardisé, les implémentations sont matures et les écosystèmes appliance/OS exposent des journaux et contrôles de configuration reconnus par les auditeurs.

5) Interopérabilité avec le site-à-site et le matériel existant

Si vous exécutez déjà de l’IPsec site-à-site entre bureaux, ajouter un accès distant IKEv2 réutilise souvent :

• la même PKI,
• les mêmes fournisseurs de pare-feu,
• les mêmes runbooks opérationnels,
• la même base de politique crypto.

WireGuard peut faire du site-à-site magnifiquement, mais si votre périmètre est ancré sur des appliances et un contrôle des changements, IPsec est souvent le chemin de moindre résistance organisationnelle. Ce n’est pas de la «politique». C’est de la survie.

6) Ingénierie du trafic et QoS dans des réseaux qui en ont besoin

Dans les grands réseaux, vous voudrez éventuellement marquer le trafic, le façonner et l’observer sans approximations. Les implémentations IPsec s’intègrent couramment à la gestion DSCP, au routage basé sur politique et aux outils QoS d’entreprise. WireGuard est simple mais n’a pas le même écosystème où l’équipe réseau a déjà des boutons et des tableaux de bord.

Blague courte #1 : IPsec est comme un couteau suisse — utile, respecté, et étrangement toujours sans l’outil dont vous avez besoin à 2h du matin.

Quand ne pas utiliser IKEv2/IPsec

IKEv2/IPsec n’est pas «toujours meilleur». Il est meilleur quand vos contraintes correspondent à ses forces.

Ne choisissez pas IKEv2/IPsec si vous avez besoin d’extrême simplicité

Si l’équipe est réduite et que vous voulez un VPN qu’on peut expliquer sur un tableau blanc en cinq minutes, WireGuard est votre ami. IPsec comporte plus d’éléments mobiles : propositions, transforms, SAs, durées de vie, EAP, certificats, NAT-T. C’est gérable, mais ce n’est pas minimal.

Ne le choisissez pas si vous êtes derrière des réseaux hostiles qui bloquent UDP

Beaucoup de déploiements IPsec passent par UDP 500/4500. Certains réseaux bloquent ou altèrent ces ports. OpenVPN sur TCP/443 peut parfois percer là où IPsec ne peut pas. Ce n’est pas une recommandation de performance. C’est une recommandation de réalité.

Ne le choisissez pas si le support plateforme est inégal

Les clients natifs sont excellents — jusqu’à ce que vous deviez supporter des plateformes avec des implémentations IKEv2 étranges ou des méthodes EAP limitées. Si vous supportez des appareils embarqués niche, OpenVPN ou WireGuard peuvent être plus faciles à standardiser.

Ne le choisissez pas si vous ne pouvez pas vous engager à une hygiène PKI

IKEv2 avec EAP-TLS et certificats est excellent. Il exige également que vous gériez la PKI sérieusement : workflows d’émission, révocation, surveillance des expirations, plans de rotation. Si votre pratique actuelle des certificats est «on mettra un rappel au calendrier pour l’an prochain», vous allez passer un mauvais moment.

Choix d’architecture : road warrior, site-à-site et «toujours activé»

Accès distant (road warrior) IKEv2

Ceci est le modèle «les utilisateurs se connectent depuis n’importe où». Choix typiques :

• VPN basé sur le routage (préféré) : attribuer une IP virtuelle au client, router les réseaux via le tunnel.
• Split tunnel vs tunnel complet : le split réduit la bande passante et le rayon d’impact ; le tunnel complet simplifie les contrôles de sécurité mais augmente la dépendance à la disponibilité du VPN.

Avec IKEv2, les configurations basées sur le routage paraissent généralement plus propres opérationnellement que les configurations basées sur des politiques. Vous dépannerez moins de mystères du type «pourquoi seule cette sous-réseau casse ?».

Site-à-site IKEv2

C’est le territoire classique d’IPsec. Si votre organisation a déjà des tunnels site-à-site, standardiser sur IKEv2 apporte de la cohérence et parfois un meilleur comportement de basculement.

Dans des environnements multi-fournisseurs, consacrez du temps à la compatibilité des propositions. La plupart des tickets «IPsec est cassé» sont en réalité des «mismatch de proposition» avec une couche de déni par-dessus.

Cas d’usage «toujours activé» / tunnel appareil

IKEv2 est souvent le protocole derrière les stratégies VPN «toujours activé» en entreprise car il s’intègre au réseau au démarrage du système et à l’identité de l’appareil. Cela importe pour :

• des appareils joints au domaine qui doivent atteindre des contrôleurs avant la connexion utilisateur,
• des outils de gestion qui nécessitent une connectivité même quand aucun utilisateur n’est connecté,
• des politiques d’accès conditionnel basées sur la conformité de l’appareil.

Authentification et identité : EAP, certificats, PSK et les pièges

PSK : rapide, familier et généralement le mauvais choix par défaut

Les clés pré-partagées sont tentantes car elles sont faciles. Elles représentent aussi un problème d’échelle et de sécurité pour l’accès distant :

• La révocation est compliquée : vous faites tourner la PSK et cassez tout le monde en même temps.
• La distribution devient un problème de partage de secrets.
• L’audit «qui a utilisé la clé» est faible sauf si vous ajoutez d’autres contrôles d’identité.

Les PSK conviennent pour des tunnels site-à-site fortement contrôlés avec une discipline opérationnelle solide. Pour les utilisateurs, utilisez des certificats et/ou EAP.

EAP-MS-CHAPv2 : ça marche, mais traitez-le comme un pont legacy

EAP-MS-CHAPv2 est courant en entreprise car il s’intègre aux systèmes d’identité existants. Mais du point de vue sécurité, ce n’est pas le gold standard. Si vous pouvez faire EAP-TLS, faites-le.

EAP-TLS : l’option «oui, on a voulu la sécurité»

EAP-TLS vous donne une authentification mutuelle forte avec des certificats. Le gain opérationnel est une désapprovisionnement propre : révoquez le certificat, l’appareil/utilisateur est hors service. Le risque opérationnel est la gestion du cycle de vie des certificats. Vous devez surveiller les expirations et automatiser le renouvellement autant que possible.

Propositions cryptographiques : standardisez ou souffrez

Choisissez un petit ensemble d’algorithmes et de durées de vie approuvés. Publiez-les. Faites-les respecter. Si chaque environnement a une suite différente, vous finirez par déboguer un «ça marche sur mon laptop» au niveau cryptographique, qui est le type de misère le plus nerd.

Blague courte #2 : La façon la plus rapide d’apprendre l’IPsec est d’en malconfigurer une proposition ; la deuxième plus rapide est de le faire en production.

Réalité opérationnelle : supervision, débogage et gestion des changements

IKEv2/IPsec a la réputation d’être «difficile à dépanner». C’est en partie mérité. C’est aussi parce que beaucoup d’équipes essaient de l’exploiter sans observabilité. N’en faites pas partie.

Quoi superviser

• Nombre de tunnels up/down et taux de churn par ASN client / type de réseau (les motifs Wi‑Fi vs cellulaire révèlent vite les problèmes MTU et NAT).
• Échecs d’authentification ventilés par raison (certificat invalide, échec EAP, mismatch de proposition).
• Paquets abandonnés sur UDP 500/4500 et ESP, surtout aux pare-feux / dispositifs NAT.
• Baselines de latence et débit vers un endpoint interne connu.

Gestion des changements : l’IPsec punit les éditions occasionnelles

WireGuard est indulgent : changez un peer, rechargez, terminé. Les changements IPsec peuvent se répercuter :

• Les changements de proposition exigent l’accord des deux côtés.
• Des changements dans la chaîne de certificats peuvent casser des clients qui avaient mis en cache une ancienne CA.
• Les variations de comportement NAT-T peuvent exposer des problèmes de filtrage de chemin.

Utilisez des déploiements par étapes. Conservez des profils connus bons. Journalisez tout. Traitez le VPN comme un service de production, pas comme un projet annexe réseau.

Tâches pratiques avec commandes : quoi exécuter, ce que cela signifie, ce qu’il faut décider

Ci‑dessous des tâches concrètes à exécuter sur une passerelle IKEv2/IPsec basée sur Linux (strongSwan présumé) et l’infrastructure environnante. Chaque tâche inclut : commande, exemple de sortie, comment la lire et la décision à prendre.

Task 1: Confirm the IKE daemon is healthy

cr0x@server:~$ systemctl status strongswan-starter
● strongswan-starter.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
     Loaded: loaded (/lib/systemd/system/strongswan-starter.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 08:11:02 UTC; 2h 14min ago
   Main PID: 1187 (starter)
      Tasks: 18 (limit: 9381)
     Memory: 21.4M
     CGroup: /system.slice/strongswan-starter.service
             ├─1187 /usr/lib/ipsec/starter
             └─1214 /usr/lib/ipsec/charon

Sens : Si ce n’est pas active (running), arrêtez de déboguer le réseau et commencez par déboguer le service.

Décision : Si inactive/en crash, collectez les journaux (Task 2) et revenez sur le dernier changement de config avant de toucher aux règles de pare‑feu.

Task 2: Inspect recent IKE negotiation errors

cr0x@server:~$ journalctl -u strongswan-starter -n 80 --no-pager
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] received AUTHENTICATION_FAILED notify error
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] EAP method EAP_MSCHAPV2 failed
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] IKE_SA vpn-ra[12] state change: AUTHENTICATING => DESTROYING
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] no proposal chosen
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] peer supports: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] configured: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

Sens : Deux modes d’échec distincts : un échec d’authentification EAP et un mismatch de proposition crypto (no proposal chosen).

Décision : Corrigez les problèmes d’identité (RADIUS/EAP) séparément de la politique crypto. N’«ouvrez pas toutes les suites» par panique ; alignez explicitement les propositions.

Task 3: List established SAs and traffic counters

cr0x@server:~$ sudo swanctl --list-sas
vpn-ra: #14, ESTABLISHED, IKEv2, 8f3a1b9c1b2e3a2d_i* 21a9de88c0d3b1aa_r
  local  'vpn.example' @ 203.0.113.10[4500]
  remote 'user@corp' @ 198.51.100.77[51234]
  AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  established 612s ago, rekeying in 41m
  vpn-ra{27}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c1b2a3d4_i c9d8e7f6_o
  vpn-ra{27}:   10.10.50.21/32 === 10.0.0.0/16
  vpn-ra{27}:   in  1483920 bytes, 1240 packets
  vpn-ra{27}:   out 932481 bytes, 1102 packets

Sens : Le tunnel est up, et des paquets circulent dans les deux sens. Si les utilisateurs rapportent «connecté mais rien ne fonctionne», comparez ces compteurs avec les symptômes au niveau application.

Décision : Si les SAs sont établies mais que les compteurs n’augmentent pas, suspectez le routage/pare‑feu/NAT sur la passerelle ou les paramètres de split tunnel côté client.

Task 4: Verify UDP 500/4500 is listening

cr0x@server:~$ sudo ss -lunp | egrep ':(500|4500)\s'
UNCONN 0      0          0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1214,fd=12))
UNCONN 0      0          0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1214,fd=13))

Sens : Si vous ne voyez pas ces sockets, votre daemon n’est pas lié ou est bloqué par une politique locale.

Décision : Pas de listener → corrigez la config/bind du daemon avant de changer des pare‑feux en amont.

Task 5: Check firewall rules for IPsec ports

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport { 500, 4500 } accept
    ip protocol icmp accept
    tcp dport 22 accept
    counter drop
  }
}

Sens : UDP 500/4500 est autorisé. Si la politique est drop et que ces règles manquent, votre VPN aura l’air «mort» depuis l’extérieur.

Décision : Si elles manquent, ajoutez des règles explicites. Ne passez pas temporairement la politique en accept ; vous oublierez de revenir en arrière.

Task 6: Confirm kernel IP forwarding and rp_filter

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 1

Sens : Le forwarding est activé (bien). Mais le filtrage strict reverse-path (rp_filter=1) peut abandonner le trafic encapsulé dans des scénarios de routage asymétrique.

Décision : Si vous avez plusieurs uplinks, du routage par politique ou de la complexité NAT-T, envisagez rp_filter=2 (loose) sur les interfaces concernées et validez par capture de paquets.

Task 7: Check routes for VPN client pools

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.0.0.0/16 via 10.0.1.1 dev eth1
10.10.50.0/24 dev vti0 proto kernel scope link src 10.10.50.1

Sens : Le pool client est sur vti0. Si les réseaux internes ne savent pas comment renvoyer le trafic vers 10.10.50.0/24, les clients se connecteront mais ne recevront pas de réponses.

Décision : Assurez-vous que des routes de retour existent dans vos routeurs internes, ou effectuez du NAT (en tenant compte des implications audit/sécurité).

Task 8: Validate NAT rules when doing split/full tunnel

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.10.50.0/24 -o eth1 -j MASQUERADE

Sens : Le trafic client VPN destiné à l’interface interne eth1 est NATé. Cela peut «réparer» le routage mais masque l’identité client dans les journaux internes.

Décision : N’utilisez le NAT que si vous ne pouvez pas ajouter de routes de retour. Si vous tenez à l’audit par utilisateur en interne, routez correctement et évitez le NAT.

Task 9: Confirm ESP-in-UDP (NAT-T) packets are arriving

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:21:11.205931 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048a), length 148
10:21:11.306102 IP 203.0.113.10.4500 > 198.51.100.77.51234: UDP-encap: ESP(spi=0xc9d8e7f6,seq=0x000003f2), length 132
10:21:11.406245 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048b), length 148
10:21:11.506311 IP 203.0.113.10.4500 > 198.51.100.77.51234: UDP-encap: ESP(spi=0xc9d8e7f6,seq=0x000003f3), length 132
10:21:11.606478 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048c), length 148

Sens : ESP-in-UDP bidirectionnel circule. Si vous voyez l’entrée mais pas la sortie, suspectez un filtrage sortant ou un problème de routage sur la passerelle.

Décision : Utilisez ceci pour séparer «le client peut atteindre la passerelle» de «la passerelle peut répondre». Cela évite des heures de conjectures.

Task 10: Detect MTU/fragmentation pain early

cr0x@server:~$ ping -M do -s 1372 10.0.0.10 -c 3
PING 10.0.0.10 (10.0.0.10) 1372(1400) bytes of data.
1372 bytes from 10.0.0.10: icmp_seq=1 ttl=63 time=18.1 ms
1372 bytes from 10.0.0.10: icmp_seq=2 ttl=63 time=18.5 ms
1372 bytes from 10.0.0.10: icmp_seq=3 ttl=63 time=17.9 ms

--- 10.0.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Sens : Ce test utilise une taille de charge utile qui approximativement tient compte de l’overhead IPsec. Si cela échoue alors que des pings plus petits fonctionnent, vous avez un problème MTU/PMTUD.

Décision : Si ça échoue, réduisez le MSS (Task 11) ou ajustez le MTU des interfaces tunnel. Ne blâmez pas encore le DNS.

Task 11: Clamp TCP MSS to avoid black-holed PMTUD

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o vti0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 1
-A FORWARD -o vti0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sens : Le clamp MSS atténue souvent le filtrage ICMP cassé et les échecs PMTUD qui se manifestent par «les sites web bloquent, mais le ping fonctionne».

Décision : Si les apps utilisateur se bloquent sur de gros transferts, activez le clamp MSS et retestez. Puis planifiez une correction propre (autoriser ICMP fragmentation-needed, définir le MTU correct).

Task 12: Validate XFRM state and policy in the kernel

cr0x@server:~$ sudo ip xfrm state
src 203.0.113.10 dst 198.51.100.77
  proto esp spi 0xc9d8e7f6 reqid 7 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0x3b... 128
  enc cbc(aes) 0x9f...
src 198.51.100.77 dst 203.0.113.10
  proto esp spi 0xc1b2a3d4 reqid 7 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0xa1... 128
  enc cbc(aes) 0x11...

Sens : Le kernel a des SAs ESP actives. Si charon affirme «established» mais que l’état XFRM est absent, vous avez un mismatch plan de contrôle / plan de données.

Décision : Si absent, suspectez des modules kernel manquants, des échecs d’installation de politique ou des outils IPsec concurrents (par ex., plusieurs daemons).

Task 13: Check for proposal mismatch from the client side (captured on gateway)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 500 -vv -c 3
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 198.51.100.77.500 > 203.0.113.10.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload)
IP 203.0.113.10.500 > 198.51.100.77.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload) notify(NO_PROPOSAL_CHOSEN)
IP 198.51.100.77.500 > 203.0.113.10.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload)

Sens : La passerelle a rejeté la proposition (NO_PROPOSAL_CHOSEN). Ce n’est pas «réseau». C’est un mismatch de configuration.

Décision : Alignez les transforms IKE/ESP. Évitez les réponses larges «activez tout» ; définissez une baseline compatible et appliquez‑la.

Task 14: Confirm DNS behavior for VPN clients (a frequent “VPN is broken” impostor)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 5 (vti0)
      Current Scopes: DNS
           Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Sens : L’interface tunnel a des serveurs DNS et un domaine de recherche. Si les clients atteignent des IPs mais pas des noms, l’attribution DNS ou la politique split‑DNS est mauvaise.

Décision : Corrigez la distribution DNS en priorité. Les utilisateurs se moquent que le tunnel soit «up» si leur navigateur ne résout pas les noms internes.

Task 15: Confirm RADIUS reachability and response codes (when using EAP)

cr0x@server:~$ sudo radtest alice 'CorrectHorseBatteryStaple' 10.0.0.20 0 testing123
Sent Access-Request Id 164 from 0.0.0.0:51682 to 10.0.0.20:1812 length 76
		User-Name = "alice"
		User-Password = "CorrectHorseBatteryStaple"
		NAS-IP-Address = 10.0.0.1
		NAS-Port = 0
		Message-Authenticator = 0x00
Received Access-Accept Id 164 from 10.0.0.20:1812 to 10.0.0.1:51682 length 44

Sens : RADIUS accepte les identifiants et est joignable. Si l’auth VPN échoue mais que ceci réussit, la méthode EAP / le chemin de confiance des certificats peut être en cause.

Décision : Séparez la santé du backend d’identité de la négociation EAP du VPN. Si RADIUS est OK, concentrez‑vous sur la config EAP, la chaîne de certificats et les paramètres clients.

Playbook de diagnostic rapide

Quand quelqu’un dit «le VPN est lent» ou «le VPN est down», vous ne commencez pas par des débats philosophiques sur les protocoles. Vous démarrez une boucle serrée qui trouve vite le goulot d’étranglement.

Première étape : est‑ce le plan de contrôle ou le plan de données ?

• Vérification plan de contrôle : Les SAs IKE sont‑elles établies ? Utilisez swanctl --list-sas. S’il n’y a pas de SAs, vous êtes en territoire auth/proposition/pare‑feu.
• Vérification plan de données : Si des SAs existent, les compteurs augmentent‑ils ? Sinon, vous êtes en routage/NAT/pare‑feu/XFRM.

Deuxième étape : prouvez que les paquets traversent le périmètre

• Exécutez ss -lunp pour confirmer les écouteurs UDP 500/4500.
• Exécutez tcpdump sur l’interface WAN pour UDP 500/4500.
• Si l’entrée apparaît mais pas la sortie, vérifiez le pare‑feu local et le routage ; si aucune n’apparaît, vérifiez le pare‑feu/NAT en amont.

Troisième étape : chassez les tueurs silencieux (MTU, DNS, asymétrie)

• MTU : symptômes : «SSH marche mais les sites web bloquent», «gros téléchargements qui stagnent». Utilisez des pings DF et appliquez MSS clamp comme mitigation.
• DNS : «connecté mais rien ne fonctionne» est souvent «connecté mais impossible de résoudre». Confirmez les serveurs DNS et le comportement split‑DNS.
• Routage asymétrique : le trafic de tunnel sort par une interface et revient par une autre, puis est abandonné par rp_filter ou des pare‑feux en amont.

Quatrième étape : validez que la performance n’est pas un problème CPU/crypto

• Vérifiez la saturation CPU sur la passerelle sous charge.
• Confirmez que AES‑NI / accélération crypto est activée si applicable.
• Assurez‑vous de ne pas empiler des encapsulations inutiles (double NAT, double tunnel).

Erreurs courantes (symptôme → cause racine → correction)

1) «Connecté» mais aucun accès aux sous‑réseaux internes

Symptôme : Le client affiche connecté ; les services internes expirent ; la passerelle montre des SAs établies.

Cause racine : Routes de retour manquantes vers le pool client VPN, ou règles de pare‑feu n’autorisant pas le trafic forwardé.

Correction : Ajoutez des routes sur les routeurs internes pour le pool client via la passerelle VPN ; validez avec ip route et les compteurs dans swanctl --list-sas. N’utilisez le NAT qu’en dernier recours.

2) Reconnexions fréquentes quand les utilisateurs se déplacent (Wi‑Fi ↔ LTE)

Symptôme : Le tunnel se coupe dès que l’IP change ; les utilisateurs se plaignent sur réseaux mobiles.

Cause racine : MOBIKE désactivé ou non supporté dans le profil ; problèmes de rebinding NAT ; paramètres DPD agressifs.

Correction : Activez MOBIKE, affinez DPD/keepalives pour maintenir les mappings NAT, vérifiez dans les journaux que les adresses sont mises à jour plutôt qu’une réauthentification complète.

3) «No proposal chosen» après une mise à jour de politique de sécurité

Symptôme : Échec immédiat à IKE_SA_INIT ; les journaux montrent no proposal chosen.

Cause racine : Les suites gateway et client ont divergé — souvent après la désactivation de SHA1/groupes DH anciens sans mise à jour des clients.

Correction : Définissez une matrice de compatibilité par version OS. Déployez les changements de profil client avant de durcir la politique serveur. Conservez une suite transitoire temporaire avec une date de retrait.

4) Ça marche sur certains réseaux, échoue sur Wi‑Fi hôtel/guest

Symptôme : Les utilisateurs se connectent depuis le domicile/la 4G mais pas depuis certains réseaux Wi‑Fi.

Cause racine : UDP 500/4500 bloqués ou altérés ; interférence du portail captif ; cas limites de NAT symétrique.

Correction : Confirmez avec tcpdump si les paquets arrivent. Si bloqué, envisagez un repli (parfois OpenVPN/TCP est une échappatoire pragmatique) ou placez une passerelle VPN dans un chemin egress plus permissif.

5) Débit lent après «durcissement de la sécurité»

Symptôme : Les tunnels se connectent ; le débit est divisé par deux ; le CPU de la passerelle monte en flèche.

Cause racine : Choix d’algorithmes coûteux en CPU ou désactivation des chemins d’accélération matérielle ; rekeying excessif.

Correction : Privilégiez des suites AEAD modernes comme AES‑GCM quand supportées ; assurez‑vous que l’accélération crypto est activée ; augmentez raisonnablement les intervalles de rekey.

6) Bloquages aléatoires sur gros uploads/downloads

Symptôme : Les petits paquets passent ; les gros transferts se figent ; certaines apps fonctionnent, d’autres non.

Cause racine : Trou noir MTU/PMTUD — ICMP «fragmentation needed» bloqué quelque part.

Correction : Clampez MSS comme mitigation ; puis corrigez PMTUD en autorisant ICMP et en définissant le MTU correct sur les interfaces tunnel.

7) Les utilisateurs s’authentifient mais obtiennent le mauvais accès

Symptôme : Certains utilisateurs atteignent des réseaux restreints ; d’autres n’accèdent pas à ce qu’ils devraient.

Cause racine : Attributs/groupes RADIUS mal mappés ; politique par utilisateur incohérente sur la passerelle.

Correction : Normalisez le mapping des politiques. Journalisez les groupes/ACL appliqués par session. Traitez l’autorisation VPN comme l’autorisation d’une application : explicite, versionnée, revue.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré l’accès distant d’une appliance vieillissante vers une nouvelle passerelle Linux exécutant IKEv2. Les utilisateurs pilotes étaient satisfaits. Le débit était excellent. La fenêtre de changement a été fermée avec des high‑fives et une nouvelle vignette sur le tableau de bord.

Deux jours plus tard, le support a reçu une vague : «Le VPN se connecte, mais rien ne charge.» Pas tout le monde — seulement des utilisateurs dans un bureau particulier et quelques uns sur des FAI spécifiques. Le statut du tunnel semblait correct. Les SAs étaient établies. Des octets circulaient. L’équipe a supposé «c’est le DNS» parce que c’est toujours le DNS jusqu’à preuve du contraire.

La mauvaise hypothèse était subtile : ils croyaient que le routage interne avait déjà une route de retour vers le nouveau pool client VPN parce que «c’est juste un autre sous‑réseau interne». Ce n’était pas le cas. L’ancienne appliance NATait le trafic client vers une plage source familière, donc le routage de retour n’importait pas. La nouvelle configuration était plus propre — routée, sans NAT — donc elle dépendait des routes de retour. Ces routes n’existaient pas partout.

Dès que quelqu’un a tracé un flux de bout en bout, le schéma s’est mis en évidence : les SYN arrivaient, les SYN‑ACK partaient vers la passerelle par défaut et mourraient ailleurs. Ils ont ajouté des routes dans le cœur, validé sur les routeurs d’edge, et l’incident a disparu.

La leçon n’était pas «le routage est difficile». La leçon était : sachez si votre prédécesseur a résolu un problème par du NAT, et ne supprimez pas ce comportement sans remplacer la dépendance.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre entreprise avait un déploiement IKEv2 propre avec EAP‑TLS et certificats gérés. Les performances étaient acceptables, mais on en voulait plus. Quelqu’un a remarqué des pics CPU sur la passerelle VPN et a décidé d’«optimiser» en ajustant les paramètres crypto et les timers de rekey.

Le changement était bien intentionné : durées plus courtes pour «meilleure sécurité», et un switch vers une proposition différente qui semblait plus forte sur le papier. Personne n’a mesuré le coût CPU. Personne n’a vérifié quels algorithmes utilisaient l’accélération matérielle. Le déploiement s’est fait un vendredi parce que «c’est juste de la config».

Le lundi matin, la passerelle tournait à plein régime. Des tempêtes de rekey ont commencé aux heures de pointe, et les clients mobiles — déjà sensibles à la perte de paquets — ont commencé à flapper. Les utilisateurs décrivaient le VPN comme «possédé», ce qui n’est pas une métrique, mais c’est une vibe à respecter.

Le rollback a corrigé immédiatement. Un test de suivi a montré que la suite «plus forte» coûtait plus de CPU par paquet et que l’intervalle de rekey multipliait le travail contrôle. La posture sécurité ne s’est pas améliorée de façon significative parce que la suite originale était déjà conforme, mais la disponibilité a empiré, ce qui est un problème de sécurité en soi.

La leçon : les réglages crypto sont aussi des réglages de performance. Changez‑les comme vous changez des index de base de données : avec des benchmarks, un déploiement progressif et un plan de rollback.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation utilisait IKEv2 pour accès distant et site‑à‑site, avec des certificats émis par une CA interne. Rien de fancy. La magie résidait dans les parties ennuyeuses : ils suivaient les expirations de certificats, avaient des alertes et forçaient le renouvellement via de l’automatisation sur les appareils gérés.

Six mois après, leur hiérarchie de CA a dû être tournée à cause d’un changement de politique de sécurité. Ce type de changement cause habituellement le chaos : les clients ne font pas confiance à la nouvelle chaîne, les passerelles présentent le mauvais intermédiaire, et tout le monde joue à «devine le magasin de confiance» pendant une semaine.

Ici, rien. Ils avaient un plan documenté de déploiement de la chaîne de confiance : pousser la nouvelle racine/intermédiaire sur les endpoints d’abord, vérifier la confiance via la conformité MDM, puis mettre à jour les passerelles pour présenter la nouvelle chaîne. Ce n’est qu’après que la télémétrie montrait que la plupart des appareils faisaient confiance à la nouvelle CA qu’ils ont révoqué l’ancien intermédiaire.

La rotation s’est terminée avec un bruit mineur. Pas de panne. Pas de ré-enrôlement massif. Le meilleur compliment a été le silence du support.

La leçon : la gestion du cycle de vie des certificats n’est pas de la paperasse ; c’est de l’ingénierie de disponibilité.

Listes de vérification / plan étape par étape

Choisir IKEv2/IPsec (checklist décisionnelle)

1. Avez‑vous besoin de clients natifs et d’une configuration pilotée par MDM ? Si oui, penchez vers IKEv2.
2. Avez‑vous besoin d’une identité par utilisateur avec politique centralisée (RADIUS/AD) et de bons audits ? Si oui, penchez vers IKEv2.
3. Avez‑vous une main‑d’œuvre très mobile et voulez‑vous des tunnels stables lors des changements réseau ? Si oui, exigez MOBIKE et testez‑le.
4. Votre environnement est‑il hostile au UDP 500/4500 ? Si oui, prévoyez une stratégie de secours (ou reconsidérez le protocole).
5. Pouvez‑vous gérer une PKI avec discipline (émission, renouvellement, révocation, alertes d’expiration) ? Si non, corrigez cela d’abord ou choisissez un modèle adapté à votre réalité.

Plan de déploiement en production (étape par étape)

1. Définissez une matrice de compatibilité : versions OS supportées, méthodes EAP, suites de chiffrement et durées de vie.
2. Choisissez l’identité : EAP‑TLS si possible ; sinon EAP avec RADIUS et intégration MFA. Évitez PSK pour l’accès utilisateur.
3. Construisez une passerelle de référence : journaux activés, métriques exportées, accès capture de paquets contrôlé.
4. Implémentez le routage délibérément : décidez du trafic client routé vs NATé et documentez les routes de retour.
5. Plan MTU : définissez le MTU tunnel, autorisez ICMP fragmentation‑needed, et ajoutez le clamp MSS seulement en mitigation.
6. Déploiement client par étapes : pilote interne, puis un département, puis déploiement large. Conservez l’ancien VPN jusqu’à stabilisation du churn.
7. Tests chaos (légers) : passez du Wi‑Fi à la 4G, suspendez/reprenez des laptops, testez des réseaux portail captif.
8. Runbooks : documentez votre playbook de diagnostic rapide et qui possède quelle couche (réseau/sécurité/endpoint).
9. Exercices de rotation : répétez le renouvellement de certificats et le rollback de config passerelle.

Checklist opérations Day‑2

1. Supervisez le churn des tunnels, les échecs d’auth et les taux de succès de connexion par utilisateur.
2. Alertez sur les expirations de certificats (gateway et CA émettrices des clients).
3. Revue trimestrielle de la politique crypto vs capacités clients (évitez les incidents «no proposal chosen» surprises).
4. Testez depuis au moins deux réseaux hostiles (guest Wi‑Fi, hotspot mobile) pour détecter des problèmes d’egress filtering.
5. Gardez un profil client connu‑bon en réserve (pour récupération).

FAQ

Est‑ce que IKEv2/IPsec est «plus sûr» que WireGuard ?

Pas automatiquement. WireGuard a une surface d’attaque plus petite et des choix crypto modernes. IKEv2/IPsec peut être extrêmement sécurisé s’il est bien configuré. Le vrai différenciateur est souvent l’intégration identité et politique, pas la cryptographie brute.

Pourquoi IKEv2 semble plus fiable pour les laptops d’entreprise ?

Parce que le système d’exploitation possède la pile cliente : elle s’intègre aux magasins de certificats, aux transitions réseau et aux politiques de gestion des appareils. Moins de composants tiers signifie moins de cassures étranges après des mises à jour OS.

Quelle est la meilleure raison unique de choisir IKEv2 plutôt qu’OpenVPN ?

Le support client natif plus les modèles d’authentification entreprise (EAP/RADIUS/certificats) avec un contrôle de politique prévisible. OpenVPN peut faire beaucoup, mais vous payez une «taxe de gestion client».

Quelle est la meilleure raison unique de choisir IKEv2 plutôt que WireGuard ?

Quand vous avez besoin de l’identité utilisateur/appareil et d’une politique centralisée qui s’intègre aux workflows IAM d’entreprise, en plus du confort d’interopérabilité IPsec standard avec le matériel réseau existant.

Dois‑je utiliser PSK pour l’accès distant IKEv2 ?

Généralement non. La PSK est difficile à faire tourner à l’échelle et mauvaise pour l’audit par utilisateur. Utilisez EAP‑TLS ou EAP via RADIUS, idéalement avec MFA.

Dois‑je autoriser ESP (protocole IP 50) dans mon pare‑feu ?

Pas nécessairement. Beaucoup de déploiements s’appuient sur NAT‑T (UDP 4500) qui encapsule ESP dans UDP. Si vous contrôlez les deux extrémités et évitez le NAT, l’ESP natif peut être utilisé, mais UDP 4500 est le chemin pratique commun.

Pourquoi je vois «no proposal chosen» et comment l’éviter ?

Cela signifie que le client et le serveur ne peuvent pas s’accorder sur les algorithmes et paramètres IKE/ESP. Corrigez en standardisant les suites et en déployant les profils client avant de durcir la politique serveur.

Mon tunnel est up mais les apps web bloquent — quelle est la cause probable ?

Trou noir MTU/PMTUD. Les gros paquets sont abandonnés silencieusement. Validez avec des pings DF et atténuez en clampant le MSS pendant que vous corrigez l’ICMP/MTU.

IKEv2 est‑il adapté pour site‑à‑site et accès distant ensemble ?

Oui, et c’est un de ses avantages opérationnels. Vous pouvez unifier la politique crypto, la supervision et le modèle de support fournisseur entre les deux cas d’usage.

Que dois‑je journaliser pour la conformité sans être noyé par le bruit ?

Journalisez les événements d’auth (succès/échec avec raisons), les IP virtuelles assignées, les identifiants de politique/ACL appliqués et le début/fin de session. Évitez les journaux de paquets complets sauf pendant les fenêtres d’incident.

Étapes pratiques suivantes

Si vous hésitez entre IKEv2/IPsec, WireGuard et OpenVPN, arrêtez de discuter en abstrait. Prenez la décision avec les contraintes qui créent des incidents :

1. Inventoriez vos clients (versions OS, état de gestion, motifs de mobilité). Si vous avez besoin de natif + MDM, IKEv2 passe en tête.
2. Choisissez un modèle d’identité que vous pouvez exploiter pendant des années. Si vous pouvez exécuter EAP‑TLS avec une hygiène PKI décente, faites‑le.
3. Définissez et publiez des suites crypto et gardez‑les volontairement ennuyeuses. Puis testez sur toutes les plateformes clientes que vous supportez.
4. Décidez d’emblée du mode routed vs NATed pour l’accès distant, documentez les routes de retour et ne changez pas involontairement l’histoire sécurité/audit.
5. Adoptez le playbook de diagnostic rapide comme réflexe en on‑call : plan de contrôle vs plan de données, preuve périmètre, puis MTU/DNS/asymétrie.

Choisissez le protocole que vous pouvez exploiter proprement. Le meilleur VPN est celui qui ne transforme pas votre équipe réseau en détectives à temps partiel.