Windows IKEv2 : déconnexions courantes et solutions fiables

Comment IKEv2 sur Windows échoue réellement (pour arrêter de deviner)

« Déconnexion IKEv2 » n’est pas un seul problème. C’est une famille de problèmes qui ressemblent tous à « le VPN s’est déconnecté » au niveau utilisateur.
Votre travail est de séparer : échecs de négociation (impossible d’établir le tunnel), échecs de vivacité (tunnel établi puis meurt),
problèmes de routage/MTU (tunnel up, le trafic meurt), et échecs d’identité/certificat (tunnel établi jusqu’à ce qu’il faille renouveler).

Les pièces mobiles qui comptent sur Windows

• RasClient : la couche client VPN de Windows. Les codes d’erreur proviennent souvent d’ici.
• IKEEXT : service IKE et AuthIP IPsec Keying Modules. Si celui-ci est mécontent, rien de bon ne se passe.
• Politique IPsec : propositions (chiffrement/intégrité/groupe DH), durées de vie, et quels sélecteurs de trafic sont autorisés.
• Certificats : EKU, validation de chaîne, accessibilité CRL/OCSP, et identité correcte (SAN vs CN).
• NAT-T : si vous êtes derrière un NAT (presque toujours), vous êtes probablement en UDP 4500. Le blocage de ce port est classique.
• Rekey + DPD : le monde des « keepalive » où les tunnels meurent quand un côté décide que l’autre a disparu.
• Changements de profil réseau : le roaming Windows du Wi‑Fi vers la 4G est un vrai test de résistance pour le tunnel.

Ce que « déconnexion » signifie habituellement en pratique

La plupart des vraies déconnexions sur Windows IKEv2 se rangent dans quelques catégories :

1. UDP 500/4500 est bloqué ou altéré en cours de session (Wi‑Fi d’hôtel, portails captifs, pare‑feu « sécurisés »).
2. Mismatch de rekey (lifetimes, propositions, PFS, ou mappings NAT expirant) provoquant des coupures toutes les N minutes.
3. Échecs de chaîne/identité de certificat qui n’apparaissent qu’après une rotation, un changement de CA, ou une panne de CRL.
4. MTU/fragmentation où IKE fonctionne, le tunnel est « connecté », mais le trafic réel cale ou se réinitialise.
5. Routage/DNS en split‑brain où le tunnel reste up, mais l’utilisateur pense qu’il est « down » parce que rien ne se résout.

La solution n’est pas de « essayer différents suites de chiffrement jusqu’à ce que ça marche ». C’est comme ça que vous finissez avec un VPN qui se connecte,
mais qui échoue dans chaque café avec un NAT différent. Nous allons le traiter comme n’importe quel autre incident de production :
obtenir du signal, réduire le périmètre, et appliquer la plus petite correction qui tient.

Une citation à garder : L’espoir n’est pas une stratégie. — Vince Lombardi.
Les équipes d’exploitation l’ont adoptée parce qu’elle est douloureusement exacte.

Petite blague n°1 : si votre tunnel IKEv2 se coupe toutes les 60 minutes, bravo — votre VPN a appris à faire la pause déjeuner.

Plan de diagnostic rapide

C’est le plan « j’ai besoin d’une direction en cinq minutes ». Il suppose un client Windows + un serveur IKEv2 conforme aux standards
(RRAS, strongSwan, Libreswan, Palo Alto, FortiGate, ASA, Azure VPN Gateway, etc.). Les noms de réglages changent ; les modes de panne non.

Première étape : décider si c’est « impossible de se connecter » ou « se connecte puis se déconnecte »

• Impossible de se connecter : concentrez‑vous sur les propositions, certificats, ports et identité.
• Se connecte puis se déconnecte : concentrez‑vous sur DPD, mappings NAT, rekey, roaming, MTU et middleboxes.

Deuxième étape : récupérer le journal qui dit la vérité

Sur Windows, le premier arrêt utile est le journal RasClient operational plus les événements IKEEXT.
Si vous ne regardez que l’erreur GUI, vous dépannez les yeux bandés.

Troisième étape : confirmer la santé du chemin UDP 500/4500

Beaucoup de déconnexions « aléatoires » sont juste la réalité NAT‑T. Si UDP 4500 est bloqué ou remappé agressivement,
le tunnel semblera correct jusqu’à ce qu’il ne le soit plus soudainement. Validez depuis le réseau client qui vous importe.

Quatrième étape : vérifier le timing de rekey et les lifetimes

Les déconnexions à intervalles réguliers hurlent « mismatch de lifetime » ou « rekey échoué ». Si c’est exactement 30/60/120 minutes,
ne débattez pas, mesurez et alignez avec vos lifetimes de Phase 1 / Phase 2.

Cinquième étape : tester un chemin « gros paquet » pour détecter les problèmes MTU

Le trafic de contrôle IKE est petit. Votre vrai trafic applicatif ne l’est pas. Si les gros paquets se fragmentent ou sont perdus, les utilisateurs appelleront ça une déconnexion VPN.
Ce n’est pas. C’est un problème de path MTU déguisé.

Sixième étape : si ça n’arrive qu’au roaming, cessez d’accuser la crypto

Le roaming est un changement d’état : nouvelle IP, nouveau NAT, nouveau pare‑feu, nouveau DNS. IKEv2 peut gérer la mobilité (MOBIKE) sur certaines piles,
mais le support Windows dépend du scénario et des capacités du serveur. Traitez les échecs de roaming comme une catégorie séparée.

Faits intéressants et un peu d’histoire

Un peu de contexte vous aide à prédire où sont les dragons. Voici des éléments concrets qui reviennent dans les vrais diagnostics.

1. IKEv2 a été normalisé en 2005 (RFC 4306). Il a remplacé la complexité d’IKEv1 par un modèle d’échange plus clair.
2. NAT traversal (NAT-T) existe depuis avant la plupart des runbooks VPN : l’approche pratique « IPsec à travers NAT » est devenue courante au début des années 2000, puis a été standardisée (RFC 3947/3948).
3. La pile VPN de Windows est stratifiée : RasClient gère les profils utilisateur pendant que IKEEXT fait IKE/IPsec. Dépanner uniquement RasClient, c’est comme réparer du stockage en regardant une lettre de lecteur dans la GUI.
4. EAP vs authentification par certificat change les modes de panne : EAP (comme EAP-MSCHAPv2) échoue souvent avec « credentials », l’auth par certificat échoue avec chaîne/identité/CRL. Même symptôme, univers différent.
5. UDP 4500 existe parce que NAT casse IPsec : ESP (protocole IP 50) ne s’entend pas bien avec NAT, donc NAT‑T encapsule ESP dans UDP.
6. Dead Peer Detection (DPD) est volontairement impatient : il est conçu pour nettoyer l’état rapidement quand les pairs disparaissent. Sur des réseaux instables, cette « fonctionnalité » devient votre panne.
7. Les codes d’erreur Windows sont souvent des abstractions : error 809 et 812 peuvent masquer plusieurs causes racines ; les logs événements révèlent les codes IPsec/IKE réels.
8. Les échecs de rekey sont fréquemment dus aux middleboxes : la crypto est correcte, mais le mapping NAT a expiré, le pare‑feu a effacé l’état, ou une DPI a décidé que UDP 4500 est suspect aujourd’hui.
9. La fragmentation IKEv2 existe, mais ce n’est pas magique : si le chemin perd des fragments ou bloque ICMP trop agressivement, vous aurez des blocages.

Erreurs courantes, ce qu’elles signifient et que faire

Les erreurs VPN Windows sont comme des alertes de stockage : le message est souvent le début de l’histoire, pas la fin.
Utilisez l’erreur GUI seulement pour classer le problème, puis plongez dans les journaux et le comportement des paquets.

Erreur 809 : « The network connection between your computer and the VPN server could not be established »

Ce que cela signifie généralement : les paquets IKE n’obtiennent pas de chemin de réponse fonctionnel. Souvent UDP 500/4500 bloqués, NAT-T cassé, ou serveur non à l’écoute.

Corrections fiables :

• Confirmer que UDP 500 et 4500 sont autorisés de bout en bout (réseau client, pare‑feu local, pare‑feu edge, security groups du serveur).
• Vérifier que le serveur est réellement bind/listening et non restreint par une politique (surtout sur RRAS/Windows Server).
• Rechercher un double NAT ou des timeouts NAT agressifs ; ajuster keepalive/DPD sur le serveur si possible.
• Si vous utilisez l’auth par certificat : confirmer que le client fait confiance à la chaîne serveur et que le serveur présente le bon certificat.

Erreur 812 : « The connection was prevented because of a policy configured on your RAS/VPN server »

Ce que cela signifie généralement : l’authentification a assez réussi pour parler politique, puis a été rejetée. Souvent politique NPS/RADIUS, appartenance à un groupe, mismatch EAP, ou restrictions sur le type de tunnel.

Corrections fiables :

• Valider la politique serveur pour l’utilisateur/groupe et le type de tunnel IKEv2.
• Confirmer que la méthode d’authentification (type EAP) correspond à la configuration client.
• Vérifier le mapping de certificat si vous utilisez des certificats machine/utilisateur et que le serveur attend un EKU ou un pattern de subject spécifique.

Erreur 13801 : « IKE authentication credentials are unacceptable »

Ce que cela signifie généralement : mismatch d’auth par certificat : mauvaise identité, mauvais EKU, clé privée manquante, chaîne non fiable, ou problèmes de CRL/OCSP. Parfois aussi PSK mismatch (si utilisé).

Corrections fiables :

• Vérifier que le certificat client a l’EKU Client Authentication et une clé privée, et que le serveur fait confiance à la CA émettrice.
• Vérifier que le certificat serveur a l’EKU Server Authentication et que son identité correspond à ce que le client attend (SAN est la réalité moderne).
• S’assurer que les points de distribution CRL sont atteignables depuis le client au moment de la connexion (cela mord sur les designs « VPN requis pour atteindre la PKI »).

Erreur 0x800B0109 / « A certificate chain processed, but terminated in a root certificate which is not trusted »

Ce que cela signifie généralement : le client ne fait pas confiance à la CA racine/intermédiaire, ou le serveur a présenté une chaîne incomplète.

Corrections fiables :

• Déployer les certificats racine et intermédiaires corrects dans le magasin de confiance du client.
• Corriger le serveur pour qu’il présente les intermédiaires (faute de configuration commune sur des appliances et certaines piles Linux).

Déconnexions toutes les 30/60/120 minutes

Ce que cela signifie généralement : mismatch de rekey ou de lifetime, ou timeout d’état NAT/pare‑feu aligné sur une frontière de lifetime.

Corrections fiables :

• Aligner les lifetimes IKE SA et Child SA des deux côtés (et les marges de rekey).
• Activer/reviser DPD et keepalives NAT ; s’assurer que le mapping NAT ne s’expire pas en session.
• Investiguer les middleboxes qui effacent l’état UDP trop agressivement.

Connecté, mais « certains sites ne fonctionnent pas » ou « Teams coupe »

Ce que cela signifie généralement : routes en split tunneling, DNS ou problèmes MTU. Le tunnel n’est pas tombé ; le trafic est mal routé ou black‑holé.

Corrections fiables :

• Confirmer que les routes installées par le profil VPN correspondent à ce que vous souhaitez.
• Confirmer que les serveurs DNS et le suffixe de recherche sont corrects, et que les règles NRPT (si utilisées) sont correctes.
• Tester le path MTU et ajuster le MTU de l’interface ou clamer le MSS sur la passerelle VPN si disponible.

Petite blague n°2 : le dépannage VPN n’est que du réseau, mais avec plus de certificats et moins de collègues prêts à rester sur l’appel.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches réelles que j’utilise quand quelqu’un dit « Windows IKEv2 se déconnecte sans arrêt ». Chacune inclut une commande,
une sortie représentative, ce que cela signifie et la décision suivante. Vous en exécuterez certaines sur Windows, d’autres sur le serveur VPN.
Les commandes sont montrées dans un format console cohérent ; adaptez les noms d’hôtes et d’interfaces à votre environnement.

Task 1: Confirm the VPN profile is actually IKEv2 and not something “helpful”

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'Corp-IKEv2' | Select-Object Name,TunnelType,AuthenticationMethod,SplitTunneling"
Name      TunnelType AuthenticationMethod SplitTunneling
----      ---------- -------------------- --------------
Corp-IKEv2 Ikev2      Eap                 True

Ce que cela signifie : Vous utilisez bien IKEv2. L’authentification est EAP, le split tunneling est activé.

Décision : Si TunnelType n’est pas Ikev2, arrêtez. Corrigez d’abord le profil. Si l’auth est EAP, focalisez‑vous sur NPS/RADIUS et la config EAP ; si Certificate, focalisez‑vous sur la PKI.

Task 2: Pull RasClient operational errors around the disconnect

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-RasClient/Operational' -MaxEvents 20 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Auto"
TimeCreated           Id  LevelDisplayName Message
-----------           --  ----------------  -------
12/27/2025 09:14:11  20227 Error            CoId={...}: The user SYSTEM dialed a connection named Corp-IKEv2 which has failed. The error code returned on failure is 809.
12/27/2025 09:14:10  20226 Information      CoId={...}: The user SYSTEM dialed a connection named Corp-IKEv2.

Ce que cela signifie : La déconnexion vue dans la GUI est soutenue par un code d’erreur RasClient concret et un timestamp.

Décision : Utiliser le timestamp pour corréler avec les logs IKEEXT et les journaux serveur. L’erreur 809 vous dirige vers des vérifications de chemin UDP/NAT‑T.

Task 3: Check IKEEXT events for negotiation or authentication failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-IKE/Operational' -MaxEvents 10 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Wrap"
TimeCreated           Id  LevelDisplayName Message
-----------           --  ----------------  -------
12/27/2025 09:14:11  4653 Error            IKE failed to find valid machine certificate. Error 0x800B0109

Ce que cela signifie : Ce n’est pas « réseau ». C’est de la confiance/chaîne de certificats.

Décision : Arrêtez de toucher aux règles de pare‑feu. Corrigez la confiance CA, les intermédiaires et la sélection de certificat.

Task 4: Validate the client certificate exists and has a private key

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path Cert:\CurrentUser\My | Select-Object Subject,HasPrivateKey,NotAfter,EnhancedKeyUsageList | Format-List"
Subject            : CN=alice, OU=Corp, O=Example
HasPrivateKey      : True
NotAfter           : 06/01/2026 12:00:00
EnhancedKeyUsageList : {Client Authentication (1.3.6.1.5.5.7.3.2)}

Ce que cela signifie : Le certificat est présent, utilisable, et possède le bon EKU.

Décision : Si HasPrivateKey est False ou si l’EKU est incorrect/manquant, réenregistrez ou corrigez le template/politique. Si tout semble bon, passez à la validation de la chaîne et à la correspondance d’identité.

Task 5: Confirm the root/intermediate chain is trusted on the client

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object {$_.Subject -like '*Example Root CA*'} | Select-Object Subject,Thumbprint,NotAfter"
Subject                 Thumbprint                                NotAfter
-------                 ----------                                --------
CN=Example Root CA      9A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B  01/01/2035 00:00:00

Ce que cela signifie : La CA racine est présente. Si des intermédiaires sont utilisés, assurez‑vous qu’ils sont aussi installés (magasin Intermediate Certification Authorities).

Décision : Si manquants, déployer via GPO/MDM. Si présents, vérifier que le serveur envoie correctement les intermédiaires.

Task 6: Check whether Windows is attempting NAT-T (UDP 4500) and not stuck on UDP 500

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPsecMainModeSA | Select-Object -First 5 LocalAddress,RemoteAddress,LocalPort,RemotePort,AuthMethod,EncryptionAlgorithm,IntegrityAlgorithm | Format-Table -Auto"
LocalAddress RemoteAddress LocalPort RemotePort AuthMethod EncryptionAlgorithm IntegrityAlgorithm
------------ ------------- --------- ---------- --------- ------------------- -----------------
10.50.12.34  203.0.113.10  4500      4500       EAP      AESGCM256           None

Ce que cela signifie : L’IKE SA utilise UDP 4500 : NAT‑T en jeu, ce qui est normal sur la plupart des réseaux clients.

Décision : Si vous ne voyez jamais UDP 4500, suspectez un échec de détection NAT ou une politique forçant UDP 500 uniquement. Vérifiez aussi que UDP 4500 est permis par les pare‑feu locaux et périphériques.

Task 7: Verify the IPsec Child SAs are stable and not constantly rekeying

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPsecQuickModeSA | Select-Object -First 5 RemoteAddress,LocalSubnet,RemoteSubnet,KeyModule,EncryptionAlgorithm,IntegrityAlgorithm,SAIdleTime | Format-Table -Auto"
RemoteAddress LocalSubnet     RemoteSubnet      KeyModule EncryptionAlgorithm IntegrityAlgorithm SAIdleTime
------------- -----------     ------------      --------- ------------------- ----------------- ----------
203.0.113.10  10.50.12.34/32  10.0.0.0/8        IKEv2     AES256              SHA256            00:02:11

Ce que cela signifie : Quick Mode (Child SA) existe. Si vous voyez ces SA recréées constamment, vous faites face à des boucles de rekey ou des problèmes de traffic selector.

Décision : Boucles de rekey : alignez les lifetimes/propositions et vérifiez les logs serveur. Problèmes de selector : vérifiez quels sous‑réseaux sont poussés/autorisés des deux côtés.

Task 8: Check interface MTU and test PMTU with “do not fragment” pings

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like '*Corp-IKEv2*'} | Select-Object InterfaceAlias,NlMtu,ConnectionState | Format-Table -Auto"
InterfaceAlias        NlMtu ConnectionState
--------------        ----- ---------------
Corp-IKEv2            1400  Connected

cr0x@server:~$ powershell -NoProfile -Command "ping 10.0.10.10 -f -l 1360"
Pinging 10.0.10.10 with 1360 bytes of data:
Reply from 10.0.10.10: bytes=1360 time=21ms TTL=62

Ce que cela signifie : Le MTU est 1400 et une charge utile de 1360 octets fonctionne sans fragmentation. Si cela échoue, vous avez un problème de fragmentation/PMTU.

Décision : Si les pings DF échouent, réduire le MTU de l’interface VPN (ou clamer le MSS sur la passerelle). Si seules certaines destinations échouent, suspecter un pare‑feu intermédiaire qui jette les fragments ou les ICMP.

Task 9: Confirm DNS servers and suffix behavior during the VPN session

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto"
InterfaceAlias        ServerAddresses
--------------        ---------------
Ethernet              {192.168.1.1}
Corp-IKEv2            {10.0.0.53, 10.0.0.54}

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName internal-app.corp.example -Server 10.0.0.53 | Select-Object Name,IPAddress"
Name                     IPAddress
----                     ---------
internal-app.corp.example 10.0.20.15

Ce que cela signifie : L’interface VPN a des serveurs DNS corporate et la résolution fonctionne quand vous interrogez directement ces serveurs.

Décision : Si la résolution échoue via le résolveur par défaut mais fonctionne en ciblant les DNS corporate, il faut corriger les suffixes/NRPT ou les métriques pour que Windows utilise le bon DNS pour les noms corp.

Task 10: Check routing and whether split-tunnel routes are present and preferred

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -like '*Corp-IKEv2*'} | Sort-Object DestinationPrefix | Select-Object DestinationPrefix,NextHop,RouteMetric | Format-Table -Auto"
DestinationPrefix NextHop      RouteMetric
---------------- --------      -----------
10.0.0.0/8        0.0.0.0      5
172.16.0.0/12     0.0.0.0      5
192.168.0.0/16    0.0.0.0      5

Ce que cela signifie : Les routes split‑tunnel existent et sont rattachées à l’interface VPN.

Décision : Si les routes sont manquantes, le problème est la configuration du profil ou la politique/ push serveur. Si les métriques sont plus élevées que les routes locales, Windows peut préférer le mauvais chemin ; ajustez les métriques avec précaution.

Task 11: Packet capture on Windows to confirm UDP 500/4500 behavior during a drop

cr0x@server:~$ powershell -NoProfile -Command "netsh trace start capture=yes report=yes scenario=VPNClient maxsize=512 filemode=circular tracefile=C:\Temp\ikev2.etl"
Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Temp\ikev2.etl
Max Size:           512 MB
File Mode:          Circular

cr0x@server:~$ powershell -NoProfile -Command "netsh trace stop"
Merging traces ... done
Generating report ... done
Trace file and report:
C:\Temp\ikev2.etl
C:\Temp\ikev2.cab

Ce que cela signifie : Vous avez capturé le scénario VPNClient. C’est souvent suffisant pour voir si les paquets cessent de sortir, cessent de revenir, ou rencontrent des erreurs ICMP.

Décision : Si UDP 4500 sortant continue mais que l’entrant s’arrête au moment de la déconnexion, suspectez un blocage en amont/expiration NAT. Si les paquets sortants s’arrêtent, suspectez un pare‑feu local/driver/service.

Task 12: Validate Windows services that must be alive (RasMan, IKEEXT)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service RasMan,IKEEXT | Format-Table Name,Status,StartType -Auto"
Name   Status Running StartType
----   ------ ------- ---------
RasMan Running         Manual
IKEEXT Running         Manual

Ce que cela signifie : Les services requis tournent. S’ils redémarrent ou plantent, vous aurez des déconnexions VPN « aléatoires » non liées au réseau.

Décision : Si l’un est arrêté ou instable, vérifiez les événements système, les mises à jour de drivers et l’interférence des logiciels de sécurité. Corrigez cela avant de toucher aux réglages IPsec.

Task 13: On a Linux VPN server, verify it’s listening and see IKE handshakes

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

Ce que cela signifie : le processus charon de strongSwan est bindé sur UDP 500/4500. Si ces ports ne sont pas ouverts, les clients échoueront avec des symptômes semblables à 809.

Décision : Si non à l’écoute, corriger le daemon/service, la syntaxe de config ou l’interface de binding. Si à l’écoute, passer aux logs de pare‑feu et aux logs de propositions/certificats.

Task 14: On the server, confirm firewall allows UDP 500/4500

cr0x@server:~$ sudo nft list ruleset | egrep -n 'udp dport (500|4500)'
42: udp dport 500 accept
43: udp dport 4500 accept

Ce que cela signifie : Le pare‑feu serveur autorise IKE/NAT‑T.

Décision : Si manquant, ajouter des règles. Si présent, suspecter des pare‑feu en amont ou des security groups. Si un seul port est ouvert, corriger les deux.

Task 15: On strongSwan, inspect live SAs and rekey timing

cr0x@server:~$ sudo swanctl --list-sas
ikev2-corp: #12, ESTABLISHED, IKEv2, 3b1c2d3e4f...
  local  'vpn.corp.example' @ 203.0.113.10[4500]
  remote 'alice' @ 198.51.100.27[52344]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, rekeying in 41 minutes
  child: corp-net, #25, INSTALLED, TUNNEL, ESP:AES_GCM_16_256, rekeying in 9 minutes

Ce que cela signifie : Les timers de rekey sont visibles. Si les déconnexions coïncident avec les moments « rekeying in … », vous avez trouvé le déclencheur.

Décision : Si le rekey échoue, alignez lifetimes/propositions, vérifiez la fragmentation/MTU et inspectez le comportement NAT. Si le rekey fonctionne mais que le tunnel tombe au roaming, concentrez‑vous sur le tuning MOBIKE/DPD.

Task 16: Watch live logs during a reconnect storm (server side)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" -f
Dec 27 09:14:11 vpn charon[1123]: 12[IKE] peer supports MOBIKE
Dec 27 09:14:41 vpn charon[1123]: 12[IKE] sending DPD request
Dec 27 09:14:46 vpn charon[1123]: 12[IKE] DPD response received
Dec 27 09:15:12 vpn charon[1123]: 12[IKE] retransmit 1 of request with message ID 7
Dec 27 09:15:27 vpn charon[1123]: 12[IKE] giving up after 5 retransmits
Dec 27 09:15:27 vpn charon[1123]: 12[IKE] deleting IKE_SA ikev2-corp[12] between 203.0.113.10[ vpn.corp.example ]...198.51.100.27[ alice ]

Ce que cela signifie : DPD a démarré, puis des retransmissions ont eu lieu, puis la SA a été supprimée. C’est un classique de rupture de chemin ou NAT.

Décision : Investiguer le timeout NAT, les changements de réseau client, ou le filtrage UDP 4500. Ajuster DPD/keepalive pour qu’ils soient moins agressifs, et valider le comportement de roaming.

Trois mini-récits issus du monde de l’entreprise

Incident 1 : La mauvaise hypothèse (« C’est IKEv2, donc il gère automatiquement le roaming »)

Une entreprise de taille moyenne a déployé IKEv2 pour remplacer SSTP pour le personnel distant. Le groupe pilote a adoré. Puis le déploiement a atteint l’équipe commerciale,
l’incarnation humaine du « toujours en mouvement ». Le motif des plaintes était constant : connexion sur le Wi‑Fi domestique, déplacement pour une réunion, basculement vers le hotspot du téléphone,
et le VPN mourait silencieusement. Les utilisateurs appelaient ça des « déconnexions aléatoires » parce que l’échec n’apparaissait pas immédiatement. Il survenait cinq minutes plus tard,
juste quand le mapping NAT expirait et que DPD décidait que le pair était mort.

L’équipe réseau supposait que IKEv2 signifiait MOBIKE et roaming transparent. L’hypothèse est compréhensible — et fausse dans suffisamment de cas réels pour vous faire mal. Windows IKEv2
plus la configuration de passerelle choisie ne se comportaient pas comme un client VPN mobile. Le tunnel montait bien, mais après un changement d’IP,
le serveur continuait d’envoyer vers l’ancien tuple jusqu’à la mort de la SA. Ensuite Windows tentait de rétablir, parfois avec succès, parfois coincé derrière un portail captif.

La correction n’était pas une nouvelle suite de chiffrement. Ils ont ajouté deux changements opérationnels : (1) des intervalles DPD plus courts et raisonnables avec un peu de tolérance, et (2) des consignes explicites
dans le profil Always On VPN pour déclencher une reconnexion au changement de réseau. Ils ont aussi mis à jour les scripts helpdesk : « si vous venez de changer de réseau, déconnectez/reconnectez une fois »
est devenu un contournement délibéré plutôt que de la magie populaire. La stabilité s’est améliorée parce que le système a été conçu pour le roaming, pas simplement laissé à l’espoir.

La vraie leçon : traitez le roaming comme un cas de test de première classe. Faites un test contrôlé : connectez, changez de réseau, gardez du trafic, observez si les SA survivent.
Si ça échoue, c’est un problème de conception, pas un « problème utilisateur ».

Incident 2 : L’optimisation qui s’est retournée contre eux (« Réduisons les lifetimes pour améliorer la sécurité »)

Une autre organisation a décidé de « durcir » son VPN en réduisant agressivement les lifetimes IPsec. Des lifetimes plus courts peuvent être acceptables.
Mais ils sont allés trop loin, et de façon asymétrique : l’équipe passerelle a changé les lifetimes Child SA, le profil Windows est resté par défaut,
et personne n’a validé le comportement de rekey sous charge.

Ce qui s’est passé ensuite était prévisible. Les rekeys ont augmenté. Le CPU sur la passerelle a monté, sans déclencher d’alerte suffisante.
Ensuite le vrai problème est apparu : des utilisateurs se sont fait déconnecter à intervalles réguliers pendant la journée. Pas tout le monde en même temps — juste assez pour créer une file d’assistance permanente.
Le helpdesk accusait le Wi‑Fi. L’équipe Wi‑Fi accusait le VPN. L’équipe VPN accusait « Windows étant Windows ».

Les captures ont montré que l’échange de rekey commençait, puis un côté n’acceptait pas la proposition. Parfois ça marchait, parfois non, selon l’instance SA qui rencontrait le mismatch en premier.
Aussi, plus vous rekeyez fréquemment, plus vous dépendez d’un chemin stable, d’un état UDP frais, et d’une fragmentation qui se comporte. En d’autres termes : vous avez transformé un système robuste
en un système nécessitant des conditions parfaites.

La correction a été ennuyeuse et efficace : aligner les lifetimes, définir des marges de rekey raisonnables, et garder des suites crypto modernes sans être exotiques.
Ils ont restauré des lifetimes Child SA plus longs et adopté un planning de rekey qui ne surcharge pas le plan de contrôle. La sécurité ne s’est pas détériorée de façon significative ;
la fiabilité s’est nettement améliorée. En production, des contrôles de sécurité qui poussent les utilisateurs à contourner le VPN ne sont pas des contrôles de sécurité. Ce sont des vœux pieux.

Incident 3 : La pratique ennuyeuse qui a sauvé la mise (rotation de certificats disciplinée)

Une grande entreprise a fait tourner ses CA émettrices et ses certificats serveur dans le cadre d’une modernisation PKI. C’est d’habitude quand les VPN meurent.
Les certificats ne sont pas difficiles ; les écosystèmes de certificats le sont. Les CRL bougent. Les intermédiaires changent. Les clients legacy paniquent.
Quelqu’un oublie toujours un intermédiaire quelque part.

Cette équipe a fait une chose peu sexy : maintenir un anneau canari de profils VPN et de clients pointés sur une passerelle de test.
Le canari validait la confiance de chaîne, les EKU et la correspondance d’identité une semaine avant le basculement général.
Ils avaient aussi un rollback écrit : « restaurer le certificat serveur précédent + bundle intermédiaire », avec une fenêtre temporelle et une propriété claire.

Le jour du cutover, le canari a détecté une cassure : les clients sur le Wi‑Fi invité ne pouvaient pas atteindre les nouveaux points de distribution CRL.
Sans accès CRL, Windows refusait de faire confiance au certificat présenté, et l’erreur ressemblait à un échec d’auth IKE générique.
Le canari les a empêchés de déployer un certificat qui nécessitait le VPN pour valider le certificat requis pour utiliser le VPN. Oui, c’est aussi circulaire que ça en a l’air.

La correction a été tout aussi ennuyeuse : publier les CRL dans un emplacement atteignable de partout (ou ajuster la stratégie de révoquation avec soin).
La rotation s’est faite avec une chaîne stable. Les utilisateurs n’ont rien remarqué, ce qui est le plus grand compliment pour les opérations.

Erreurs fréquentes : symptôme → cause racine → fix

Cette section est volontairement directe. La plupart des incidents « Windows IKEv2 déconnexion » se répètent parce que les équipes marchent sur les mêmes râteaux.
Voici les plus courants, liés à des symptômes observables.

1) Symptom: Error 809 on some networks but not others

Cause racine : UDP 4500 bloqué ou modelé ; portail captif ; filtrage Wi‑Fi « sécurisé » ; ou expiration d’état NAT/pare‑feu en amont.

Fix : Assurer le passage de UDP 500/4500. Si vous ne contrôlez pas le réseau, augmenter la tolérance des keepalives/DPD et fournir un fallback (parfois SSTP est le recours pragmatique).

2) Symptom: Connects fine, then drops at a consistent interval

Cause racine : mismatch de lifetime ou rekey échoué ; expiration du mapping NAT ; DPD trop agressif ; pics CPU sur la passerelle durant des tempêtes de rekey.

Fix : Aligner lifetimes et propositions ; ajuster DPD/keepalive ; vérifier la capacité de la passerelle ; éviter des lifetimes trop courts sans preuve opérationnelle.

3) Symptom: Error 13801 after certificate changes

Cause racine : mauvais EKU, clé privée manquante, chaîne non fiable, mismatch d’identité (SAN), ou échec des vérifications de révocation.

Fix : Valider EKU, chaîne et identité des deux côtés. S’assurer que les intermédiaires sont présentés. S’assurer que CRL/OCSP est atteignable sans le VPN.

4) Symptom: “Connected” but internal sites time out; small pings work, downloads fail

Cause racine : trou noir MTU, fragmentation bloquée, MSS trop élevé, ou PMTU brisé par ICMP bloqué.

Fix : Réduire le MTU sur l’interface VPN ; clamer MSS sur la passerelle ; autoriser l’ICMP nécessaire (au moins fragmentation‑needed) si possible.

5) Symptom: Only some subnets reachable, others dead

Cause racine : routes split tunnel manquantes/erronées ; traffic selectors n’incluent pas les sous‑réseaux nécessaires ; chevauchement d’adressage avec les réseaux domestiques.

Fix : Corriger les routes/TS poussées ; éviter les plages RFC1918 chevauchantes ; si inévitable, utiliser NAT sur le VPN ou repenser l’adressage.

6) Symptom: Disconnects correlate with sleep/hibernate or lid close

Cause racine : économie d’énergie NIC, mise en veille système cassant l’état UDP, ou client VPN ne reprenant pas proprement.

Fix : Ajuster les paramètres d’alimentation pour les appareils corporate ; s’assurer qu’Always On VPN déclenche une reconnexion ; envisager de désactiver la gestion d’énergie NIC agressive via politique.

7) Symptom: Works on Ethernet, fails on Wi‑Fi

Cause racine : le Wi‑Fi bloque UDP 4500, a des bizarreries d’isolation client, ou la pile de sécurité endpoint filtre différemment selon l’interface.

Fix : Valider par capture de paquets ; vérifier les profils de pare‑feu locaux (Public vs Private) ; ajuster les politiques endpoint pour UDP 500/4500.

8) Symptom: Server shows retransmits, client shows “authentication failed”

Cause racine : messages perdus en plein échange ; fragmentation des messages IKE ; MTU ou middlebox qui jette ; parfois de grandes chaînes de certificats gonflent les messages IKE.

Fix : Réduire la taille de la chaîne de certificats ; activer le support de fragmentation IKE sur le serveur ; corriger le MTU ; cesser de bloquer aveuglément fragments/ICMP.

9) Symptom: After enabling “stronger” crypto, some clients drop

Cause racine : mismatch de propositions ; anciennes builds Windows ou certains appliances ne supportent pas les suites choisies comme vous le pensez.

Fix : Utiliser une base moderne conservatrice (AES-GCM, PRF SHA2, DH group 14/19+ selon le besoin) et valider avec un anneau de test avant déploiement.

Listes de contrôle / plan pas à pas

Pas à pas : stabiliser un déploiement Windows IKEv2 instable

1. Collecter timestamps et symptômes. Obtenir l’heure exacte de la déconnexion, le type de réseau (Wi‑Fi domestique, LTE, bureau), et si c’est périodique.
2. Extraire d’abord RasClient + IKE logs. Si le log pointe vers cert/auth, restez sur cette piste. S’il pointe vers 809/transport, allez vers les vérifications de chemin.
3. Vérifier que les services (RasMan/IKEEXT) ne vacillent pas. S’ils vacillent, stabiliser l’endpoint avant d’ajuster le réseau.
4. Confirmer la reachabilité UDP 500/4500. Depuis les réseaux affectés. Ne supposez pas que parce que ça marche au bureau ça marche dans un hôtel.
5. Vérifier si NAT‑T est effectivement utilisé. Si les clients sont derrière NAT (ils le sont), vous voulez UDP 4500 fiable.
6. Aligner propositions et lifetimes. Faire correspondre les deux bouts. Rekey assez souvent pour la sécurité, pas assez pour créer un DDoS du plan de contrôle.
7. Tester le MTU tôt. Tests de ping DF et flux applicatifs réels. Corriger les trous noirs avant de discuter du routage.
8. Valider DNS et routes. Confirmer que les noms corporate se résolvent via les DNS corporate et que les sous‑réseaux voulus passent par le VPN.
9. Tests de roaming. Changer de réseau en gardant un ping/SSH/RDP continu et observer. Si ça casse, décider si vous supportez le roaming ou documenter les limites.
10. Introduire des canaris. Profils pilotes et changements de certificats avec un petit anneau avant le déploiement large.
11. Documenter la réalité des « réseaux mauvais connus ». Certains réseaux bloquent UDP 4500. Planifier un fallback ou accepter explicitement les limites.
12. Automatiser la collecte de logs pour le support. Une one‑liner qui exporte RasClient et IKE logs économise des heures par ticket.

Checklist opérationnelle : avant de changer quoi que ce soit sur la passerelle

• Avez‑vous un client de test et une passerelle canari ?
• Connaissez‑vous les lifetimes IKE/Child et les propositions des deux côtés ?
• Avez‑vous validé la reachabilité CRL/OCSP depuis l’extérieur du VPN ?
• Avez‑vous des captures de paquets d’un cas en échec ?
• Pouvez‑vous revenir en arrière rapidement (snapshot/export de config) ?

Checklist opérationnelle : après avoir appliqué un correctif

• Tester connexion, déconnexion, reconnexion.
• Tester trafic soutenu (10–30 minutes) et surveiller le comportement de rekey.
• Tester transferts volumineux et pings DF.
• Tester le roaming (Wi‑Fi ↔ LTE) si vous déclarez le supporter.
• Vérifier que le helpdesk connaît les nouvelles étapes « quoi collecter ».

FAQ

1) Why does Windows IKEv2 disconnect more on hotel or guest Wi‑Fi?

Ces réseaux bloquent souvent ou expirent agressivement les flux UDP, en particulier UDP 4500. IPsec NAT‑T ressemble à du « trafic UDP inconnu » pour certains équipements.
Les portails captifs provoquent aussi des changements de chemin silencieux qui cassent les mappings NAT existants. Confirmez avec les logs et une trace.

2) Is error 809 always a firewall issue?

C’est généralement un problème de connectivité, mais « connectivité » inclut le comportement NAT, le filtrage en amont, et même le filtrage de sécurité local sur l’endpoint.
Traitez 809 comme « IKE n’a pas établi un chemin fonctionnel », puis vérifiez UDP 500/4500 et l’état d’écoute du serveur.

3) What’s the fastest way to tell if it’s certificates?

Vérifier Microsoft-Windows-IKE/Operational pour des erreurs de chaîne et d’identifiants (comme 0x800B0109) autour du moment de l’échec.
Si celles‑ci apparaissent, arrêtez de bidouiller les ports et commencez à valider les EKU, la confiance de chaîne et l’accessibilité de la révocation.

4) Why does it drop exactly every hour?

C’est presque toujours lié au rekey/lifetime ou à l’alignement des timers d’expiration d’état. Alignez IKE SA et Child SA lifetimes,
et vérifiez si les mappings NAT expirent autour du même moment. Les logs serveur montrant des tentatives de rekey sont vos amis.

5) Should we lower IPsec lifetimes for “better security”?

Pas aveuglément. Des lifetimes très courts augmentent la fréquence des rekey et la sensibilité à la perte de paquets, à la fragmentation et aux middleboxes.
Choisissez une base sensée, validez le rekey sous charge, et ne resserrez que si vous avez un vrai modèle de menace et la capacité opérationnelle pour le soutenir.

6) Connected but internal DNS names don’t resolve—why does the tunnel look fine?

Parce que « connecté » ne signifie que le plan de contrôle est up. Si les serveurs DNS ne sont pas appliqués, le suffixe de recherche est incorrect,
ou les métriques de routage préfèrent la mauvaise interface, vous obtenez un tunnel fonctionnel mais pratiquement inutile. Vérifiez les DNS et les tables de routage par interface.

7) Do MTU issues really look like disconnects?

Oui. Les applis timeoutent, les sessions se réinitialisent, les appels vocaux se dégradent, et les utilisateurs disent « le VPN a sauté » parce que c’est le seul levier qu’ils connaissent.
Testez avec des pings DF et des transferts réels. Corriger MTU/MSS/ICMP vous fera « réparer des déconnexions » qui n’étaient pas des déconnexions.

8) Can endpoint security software cause IKEv2 drops?

Absolument. Pare‑feux locaux, « inspection réseau » et drivers qui interfèrent avec le VPN peuvent jeter ou retarder UDP 4500,
bloquer le trafic de validation de certificat, ou redémarrer des services. Si vous voyez des flaps de service ou seulement certaines machines affectées, inspectez la pile endpoint.

9) Is split tunneling more likely to cause instability?

Il est plus susceptible de causer la confusion « connecté mais ça ne marche pas » : routes manquantes, métriques incorrectes, ambiguïté DNS et adresses chevauchantes.
La stabilité du tunnel lui‑même est généralement fine, mais l’expérience utilisateur peut être pire si routes/DNS ne sont pas conçus avec soin.

Conclusion : prochaines étapes qui tiennent

Les déconnexions Windows IKEv2 cessent d’être mystérieuses lorsque vous les traitez comme tout incident de production :
classer la panne (bring‑up vs liveness vs trafic), extraire les bons journaux, et valider les fondamentaux ennuyeux
(UDP 500/4500, lifetimes/rekey, certificats, MTU, routage, DNS).

Prochaines étapes pratiques :

• Construire un bundle support en deux commandes : exporter RasClient + événements IKE opérationnels autour de la fenêtre d’échec.
• Exécuter un test axé sur le rekey : garder un tunnel up pendant au moins deux cycles de rekey tout en poussant du trafic réel.
• Mettre en place un plan de tests MTU et définir une stratégie MTU/MSS connue‑bonne pour votre parc.
• Adopter un anneau canari pour les profils VPN et les changements de certificats. C’est ennuyeux. Ça marche.
• Décider explicitement si vous supportez le roaming et les réseaux hostiles — et documenter le comportement attendu.

L’objectif n’est pas un VPN qui se connecte dans votre labo. C’est un VPN qui reste connecté dans le monde réel, où les NAT expirent, le Wi‑Fi ment,
et les certificats expirent au pire moment possible.