IPsec/IKEv2 : le piège du NAT‑Traversal qui casse les VPN site‑à‑site

NAT‑T en une phrase (et pourquoi ça fait mal)

La traversée NAT permet à IPsec de continuer à fonctionner quand l’un des pairs est derrière un NAT en encapsulant ESP dans UDP/4500, mais le moindre décalage dans la détection, les ports, les timers ou le filtrage transforme un « transport sécurisé » en « silence sécurisé ».

Voici le point douloureux : l’ESP pur (protocole 50) n’est pas ami avec le NAT parce que le NAT a besoin de ports au niveau transport pour suivre les flux. ESP n’en a pas. NAT‑T résout cela en enveloppant ESP dans UDP, ce qui donne au NAT quelque chose pour se noncer (IP source/destination + port source/destination). L’enveloppe est simple. L’écosystème autour, non.

Quand NAT‑T casse, ça casse souvent de manières qui vous font perdre du temps :

• La SA IKE se lève (UDP/500 fonctionne), mais les CHILD SAs transportent zéro octet.
• Ça marche un moment, puis ça meurt après des périodes d’inactivité (expiration du mapping NAT).
• Ça n’échoue que dans une direction (filtrage asymétrique, routage ou politique mal appariés).
• Ça n’échoue que pour le trafic volumineux (PMTUD/fragmentation/MTU).

Règle empirique pertinente : si vous voyez « tunnel up, no traffic », arrêtez d’examiner les propositions cryptographiques et commencez par vérifier NAT‑T et la reachabilité du plan de données.

Blague #1 : Le NAT, c’est comme un chat : il ignore les standards, fait ce qu’il veut, et vous devez quand même le supporter.

Ce qui se passe réellement sur le fil : IKEv2 + détection NAT + encapsulation UDP

Phases IKEv2 qui comptent pour NAT‑T

IKEv2 est plus propre qu’IKEv1, mais les pièces NAT restent subtiles. Le flux global :

1. IKE_SA_INIT : négocie les algorithmes, réalise le Diffie‑Hellman, échange des nonces et effectue la détection NAT.
2. IKE_AUTH : authentifie les pairs (PSK/certificats), établit la SA IKE et met en place la(les) première(s) CHILD SA(s).
3. CHILD SA rekeys : rekeying périodique des SAs du plan de données.

La détection NAT se fait via des payloads NAT‑D. Chaque côté hash ce qu’il pense être le 4‑tuple (adresses et ports). Si les hashes ne correspondent pas à ce que le pair voit, les pairs concluent qu’il y a un NAT en chemin et basculent en comportement NAT‑T.

Ports : UDP/500, UDP/4500, et la partie que les gens oublient

IKEv2 de base utilise UDP/500. Si un NAT est détecté, le tunnel passe typiquement sur UDP/4500 pour IKE et pour l’ESP encapsulé. Cela signifie :

• UDP/500 doit fonctionner (au moins pour la négociation initiale).
• UDP/4500 doit fonctionner pour les messages IKE en cours et pour le plan de données quand NAT‑T est utilisé.
• Certaines appliances démarrent sur UDP/500, détectent le NAT, puis continuent sur UDP/4500. Si votre pare‑feu autorise 500 mais pas 4500, vous obtenez le classique « handshake OK, trafic mort ».

ESP vs encapsulation NAT‑T

Sans NAT‑T, le plan de données est ESP (protocole IP 50). Avec NAT‑T, le plan de données devient UDP/4500 transportant ESP. Cela change ce que voient les middleboxes :

• Les pare‑feux stateful ont maintenant besoin d’un état UDP pour le flux.
• Les timers conntrack deviennent importants (UDP est « sans connexion », mais le NAT stateful fait comme si).
• Certains dispositifs de sécurité inspectent mal UDP/4500 ou le limitent en débit agressivement.

Le tueur silencieux : timers de mapping NAT et keepalives

Les NAT oublient rapidement les mappings UDP. Trente secondes est courant. Certains sont encore plus courts sous charge. Les tunnels IPsec, eux, peuvent rester inactifs pendant des minutes—en particulier les liens site‑à‑site « de secours » ou « seulement gestion ». Résultat : le mapping s’évapore, le pair continue d’envoyer des paquets chiffrés UDP/4500 dans le vide, et personne ne vous prévient jusqu’au paquet important suivant.

La correction est généralement un keepalive ou un réglage DPD/heartbeat. Pas « renforcez la crypto ». Pas « rekey toutes les 5 minutes ». Gardez le mapping NAT vivant, ou acceptez que le premier paquet après une inactivité soit sacrifié.

Pourquoi les problèmes de fragmentation et MTU apparaissent davantage avec NAT‑T

NAT‑T ajoute de l’overhead UDP. IPsec ajoute de l’overhead ESP. Si vous étiez déjà serré sur le MTU (MPLS, PPPoE, GRE, VNets cloud, etc.), NAT‑T vous pousse au‑delà de la limite.

Quand PMTUD est bloqué (ICMP filtré), les gros paquets disparaissent. Les petits pings fonctionnent. SSH fonctionne. Les transferts de fichiers bloquent. Les connexions de base de données plantent sous charge. Voilà pourquoi « ça ping » signifie souvent « je n’ai testé que 56 octets ».

Blague #2 : La seule chose plus optimiste que « ça ping » est « ça ping, donc ce n’est pas le réseau ».

Une citation fiabiliste, parce que l’ops a des preuves

L’espoir n’est pas une stratégie. — Gen. Gordon R. Sullivan

En termes VPN : ne supposez pas que NAT‑T est correct parce que le tunnel indique ESTABLISHED. Mesurez le plan de données.

Guide rapide de diagnostic

Ceci est l’ordre qui trouve rapidement les vraies pannes. Il est biaisé vers ce qui casse le plus souvent en production : filtrage, état NAT, routage/politique et MTU.

Premier : confirmez quel transport le tunnel utilise réellement

• Est‑ce que l’IKE est sur UDP/500 uniquement, ou a‑t‑il basculé sur UDP/4500 ?
• Le plan de données est‑il ESP (proto 50) ou encapsulé en UDP/4500 ?

Si vous ne savez pas cela, vous dépannez à l’aveugle. « Autoriser IPsec » n’est pas une règle de pare‑feu ; c’est une phrase marketing.

Second : prouvez la reachabilité bidirectionnelle UDP/4500 (pas juste « ouvert »)

• Capture de paquets sur les deux pairs, en recherchant les paquets UDP/4500 sortants et entrants.
• Vérifiez que le dispositif NAT maintient le mapping assez longtemps (timers/keepalives).

Troisième : validez les sélecteurs/politiques et le routage pour les sous‑réseaux protégés

• Les traffic selectors (sous‑réseaux locaux/distants) correspondent‑ils sur les deux côtés ?
• Y a‑t‑il une route qui pointe les sous‑réseaux protégés vers l’interface/politique du tunnel ?
• Êtes‑vous en train d’encoder par erreur le trafic qui devrait être chiffré ?

Quatrième : si « certains trafics fonctionnent », allez directement au MTU/MSS et à la fragmentation

• Testez avec DF activé et des tailles de payload plus grandes.
• Recherchez des ICMP « fragmentation needed » bloqués.
• Clamp MSS pour TCP si nécessaire.

Cinquième : ce n’est qu’après que vous fouillez les propositions crypto et les timers de rekey

Oui, les incompatibilités de propositions existent. Mais les pannes NAT‑T sont souvent post‑négociation et ressemblent à « la crypto est OK, le plan de données est mort ». Traitez les symptômes honnêtement.

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

Voici les tâches que j’exécute réellement quand un tunnel IPsec site‑à‑site est « up » mais se comporte comme hanté. Chaque tâche inclut une commande réaliste, une sortie d’exemple, ce que ça signifie et la décision à prendre.

Task 1: Confirm IKEv2 SAs and whether NAT‑T is in use (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
IKE SAs:
corp-vpn[3]: ESTABLISHED 12 minutes ago, 203.0.113.10[gw-a]...198.51.100.20[gw-b]
corp-vpn[3]: IKEv2, rekeying in 46 minutes
corp-vpn[3]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
corp-vpn{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c3b8a9d2_i c9b6a331_o
corp-vpn{7}:  10.10.0.0/16 === 10.20.0.0/16

Ce que cela signifie : « ESP in UDP » confirme l’encapsulation NAT‑T sur UDP/4500 pour le plan de données.

Décision : Assurez‑vous que UDP/4500 est autorisé de bout en bout et que les timers de mapping NAT ne vont pas expirer. Si UDP/4500 n’est pas explicitement permis, corrigez cela avant de toucher aux propositions.

Task 2: Check for NAT detection messages in logs (strongSwan/charon)

cr0x@server:~$ sudo journalctl -u strongswan --since "30 min ago" | egrep -i "NAT|4500|encap|DPD" | tail -n 20
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] local host is behind NAT, sending keep alives
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] remote host is behind NAT
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] switching to NAT-T
Feb 04 09:12:41 gw-a charon[1123]: 11[IKE] sending keep alive to 198.51.100.20[4500]

Ce que cela signifie : Un NAT a été détecté ; le démon est passé en NAT‑T et envoie des keepalives.

Décision : Si le trafic meurt encore, les keepalives peuvent être trop espacés, ou le pare‑feu/NAT n’autorise pas les réponses entrantes sur UDP/4500.

Task 3: Verify local listening sockets (is the daemon bound properly?)

cr0x@server:~$ sudo ss -ulnp | egrep ':500|:4500'
UNCONN 0      0            0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1123,fd=10))
UNCONN 0      0            0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1123,fd=11))

Ce que cela signifie : Le démon IKE écoute sur UDP/500 et UDP/4500.

Décision : Si 4500 n’écoute pas, NAT‑T ne peut pas fonctionner. Corrigez la configuration de la pile IPsec ou vérifiez les capacités/modules du noyau.

Task 4: Check firewall rules for UDP/500 and UDP/4500 (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '/table inet filter/,/}/p' | egrep -n "udp dport (500|4500)|ip protocol esp|drop"
24: udp dport { 500, 4500 } accept
31: ip protocol esp accept
78: counter drop

Ce que cela signifie : Le pare‑feu local autorise IKE et NAT‑T, plus ESP brut. Bien.

Décision : Si vous voyez UDP/500 autorisé mais pas UDP/4500, ajoutez 4500. Si vous voyez des drops augmenter, capturez et affinez les règles.

Task 5: Confirm packets are arriving on UDP/4500 (tcpdump)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:14:02.112233 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP, length 92
09:14:12.112998 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 92
09:14:22.113554 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP, length 300

Ce que cela signifie : Du trafic UDP/4500 bidirectionnel existe. Au moins le transport est vivant.

Décision : Si vous ne voyez que sortant ou que entrant, suspectez une asymétrie pare‑feu/NAT ou un filtrage en amont. Escaladez vers le bord réseau avec des captures comme preuve.

Task 6: Confirm that protected traffic is being encrypted (XFRM state)

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
	proto esp spi 0xc9b6a331 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x... 256 bits
	anti-replay context: seq 0x0000002a, oseq 0x0
	lifetime current: 780s, bytes 12480, packets 104
src 198.51.100.20 dst 203.0.113.10
	proto esp spi 0xc3b8a9d2 reqid 1 mode tunnel
	lifetime current: 780s, bytes 9800, packets 91

Ce que cela signifie : Les compteurs de paquets et d’octets augmentent. Le chiffrement a lieu dans le noyau.

Décision : Si les compteurs restent à zéro alors que vous générez du trafic, vos sélecteurs/routage/politique sont mauvais (le trafic ne correspond pas à la politique IPsec), ou les paquets sont bloqués avant d’atteindre XFRM.

Task 7: Verify policy selectors (XFRM policy)

cr0x@server:~$ sudo ip xfrm policy
src 10.10.0.0/16 dst 10.20.0.0/16
	dir out priority 3750 ptype main
	tmpl src 203.0.113.10 dst 198.51.100.20 proto esp reqid 1 mode tunnel
src 10.20.0.0/16 dst 10.10.0.0/16
	dir in priority 3750 ptype main
	tmpl src 198.51.100.20 dst 203.0.113.10 proto esp reqid 1 mode tunnel

Ce que cela signifie : Le noyau s’attend à ce que le trafic entre ces sous‑réseaux soit tunnellisé.

Décision : Si vos réseaux réels sont en /24 mais que la politique est en /16 (ou vice versa), vous aurez des échecs partiels étranges. Corrigez les sélecteurs pour qu’ils correspondent aux routes réelles et au domaine de chiffrement prévu.

Task 8: Confirm routing sends protected traffic to the right place

cr0x@server:~$ ip route get 10.20.5.10 from 10.10.5.10
10.20.5.10 from 10.10.5.10 dev eth0  src 203.0.113.10  uid 0
    cache

Ce que cela signifie : En IPsec basé sur la politique, le trafic continue souvent de « router normalement » (par ex. out eth0) et est intercepté par la politique XFRM. C’est acceptable.

Décision : Si la route pointe vers un endroit inattendu (mauvaise interface d’egress, mauvaise IP source), corrigez le routage/sélection de source. Une source incorrecte peut casser la détection NAT et la correspondance des sélecteurs.

Task 9: Generate traffic and watch counters move (ping + XFRM)

cr0x@server:~$ ping -c 3 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 56(84) bytes of data.
64 bytes from 10.20.5.10: icmp_seq=1 ttl=63 time=22.3 ms
64 bytes from 10.20.5.10: icmp_seq=2 ttl=63 time=21.9 ms
64 bytes from 10.20.5.10: icmp_seq=3 ttl=63 time=22.1 ms

--- 10.20.5.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.9/22.1/22.3/0.2 ms

Ce que cela signifie : Le plan de données fonctionne pour les petits paquets.

Décision : Testez immédiatement le MTU avec DF et des tailles plus grandes. « Le petit ping fonctionne » n’est pas un succès ; c’est un piège.

Task 10: Test MTU/fragmentation with DF set

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 1372(1400) bytes of data.
ping: local error: message too long, mtu=1392

--- 10.20.5.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2034ms

Ce que cela signifie : Votre MTU effectif est plus petit que prévu (ici 1392). L’overhead IPsec/NAT‑T l’a réduit. Si l’ICMP est bloqué ailleurs, vous pouvez voir des pertes silencieuses au lieu d’une erreur locale.

Décision : Clamppez le MSS TCP (pour les applications TCP intensives) et/ou réduisez le MTU d’interface sur le chemin du tunnel. Si vous ne contrôlez pas les réseaux intermédiaires, le clamp MSS est souvent la correction pragmatique.

Task 11: Check TCP MSS clamping rules (iptables example)

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

Ce que cela signifie : Le clamp MSS est activé sur les paquets SYN TCP forwardés.

Décision : Si vous avez des trous MTU et ne pouvez pas corriger l’ICMP, ajoutez le clamp MSS sur la passerelle et retestez les transferts de fichiers et les handshakes TLS.

Task 12: Validate that NAT is not being applied to protected subnets (iptables NAT table)

cr0x@server:~$ sudo iptables -t nat -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE

Ce que cela signifie : Ceci ferait du NAT pour tout le trafic de 10.10.0.0/16 sortant sur eth0, y compris le trafic qui devrait être chiffré vers 10.20.0.0/16.

Décision : Ajoutez une règle d’exemption NAT pour la destination VPN avant MASQUERADE, ou resserrez la règle MASQUERADE pour exclure le sous‑réseau distant protégé.

Task 13: Inspect conntrack timeouts for UDP/4500

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Ce que cela signifie : L’état « connexion » UDP expire vite (30s pour les flux non répondus). Cela peut tuer des tunnels NAT‑T inactifs si les keepalives sont trop espacés.

Décision : Préférez configurer les keepalives IKE/DPD ; ajuster les timeouts conntrack peut aider mais impacte toute la machine et peut avoir des conséquences inattendues.

Task 14: Verify rekey/DPD settings are not causing self-inflicted flaps (strongSwan status)

cr0x@server:~$ sudo swanctl --list-conns | sed -n '/corp-vpn/,/}/p'
corp-vpn: IKEv2, dpd_delay=30s, dpd_timeout=120s, rekey_time=1h
  local:  203.0.113.10
  remote: 198.51.100.20
  local_ts: 10.10.0.0/16
  remote_ts: 10.20.0.0/16

Ce que cela signifie : DPD est configuré. L’intervalle de rekey est raisonnable.

Décision : Si vous voyez un DPD ultra‑agressif (par ex. delay 5s, timeout 15s) sur un WAN bruyant, vous ferez flapper votre propre tunnel. Adaptez‑le au lien réel, pas au lien souhaité.

Task 15: Prove whether UDP/4500 is blocked upstream (nmap UDP scan with caution)

cr0x@server:~$ sudo nmap -sU -p 500,4500 198.51.100.20
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-04 09:22 UTC
Nmap scan report for 198.51.100.20
Host is up (0.021s latency).

PORT     STATE         SERVICE
500/udp  open|filtered isakmp
4500/udp open|filtered nat-t-ike

Nmap done: 1 IP address (1 host up) scanned in 2.49 seconds

Ce que cela signifie : Les résultats du scan UDP sont ambigus (« open|filtered » est courant). Cela ne prouve pas que c’est ouvert, mais indique que l’hôte est joignable et ne renvoie pas de ICMP port‑unreachable.

Décision : Utilisez tcpdump comme source de vérité. Si vous voyez vos paquets partir mais jamais de réponses, escaladez avec des captures.

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

1) « La SA IKE est établie, mais aucun trafic ne passe »

Symptôme : Le plan de contrôle est établi. Les compteurs du plan de données restent à zéro.

Cause racine : UDP/4500 bloqué (ou ESP bloqué quand NAT‑T est désactivé). Ou les sélecteurs ne correspondent pas, donc les paquets n’atteignent jamais XFRM.

Correction : Confirmez « ESP in UDP » (ou non) dans la sortie SA, puis autorisez UDP/4500 en bidirectionnel. Validez que les sélecteurs XFRM correspondent aux sous‑réseaux réels et que des exemptions NAT existent.

2) « Ça marche un moment, puis ça meurt après inactivité »

Symptôme : Après 5–30 minutes d’inactivité, le premier nouveau flux échoue ; le tunnel peut se rétablir plus tard.

Cause racine : Expiration du mapping NAT pour UDP/4500 ; keepalives/DPD trop lents ; état UDP en amont expirant.

Correction : Activez des keepalives NAT / liveness IKEv2 réglés plus fréquents que le timeout NAT le plus court sur le chemin. Si vous ne pouvez pas connaître le timeout, supposez 20–30 secondes et concevez en conséquence.

3) « Une direction fonctionne, l’autre pas »

Symptôme : Le site A atteint le site B, mais pas l’inverse (ou seulement certains sous‑réseaux fonctionnent).

Cause racine : Routage asymétrique, route de retour manquante, chevauchement de sous‑réseaux, mismatch de politique, ou NAT présent d’un seul côté sans autorisations symétriques.

Correction : Comparez les traffic selectors des deux côtés ; vérifiez les tables de routage ; assurez‑vous qu’il n’y a pas de chevauchement ; vérifiez les règles pare‑feu dans les deux sens ; confirmez que les paquets sont encapsulés et visibles sur les deux côtés avec tcpdump.

4) « Le ping fonctionne, SMB/HTTPS/transferts de fichiers bloquent »

Symptôme : Les petits paquets réussissent ; les gros payloads bloquent ou réinitialisent.

Cause racine : Trou noir MTU dû à l’overhead IPsec + NAT‑T ; PMTUD cassé ; ICMP filtré ; fragmentation mal gérée par le NAT.

Correction : Testez avec des pings DF, clamp MSS TCP et/ou réduisez le MTU sur les interfaces concernées. Autorisez aussi les types ICMP nécessaires si votre posture sécurité le permet.

5) « Le tunnel flappe lors des rekeys, surtout avec NAT »

Symptôme : Chutes périodiques alignées sur les timers de rekey ; les logs montrent des retransmissions et un churn des CHILD SA.

Cause racine : Collisions de rekey, stabilité NAT médiocre, pinholing pare‑feu strict, ou DPD agressif qui interagit mal avec la perte transitoire de paquets.

Correction : Échelonnez les temps de rekey, évitez les durées ultra‑courtes, ajustez DPD et assurez‑vous que UDP/4500 n’est pas limité en débit ni soumis à des timers conntrack courts.

6) « Tout casse après changement d’ISP/modem/routeur »

Symptôme : Même configuration, nouvel équipement d’accès, maintenant NAT‑T échoue.

Cause racine : Le nouvel équipement fait du NAT symétrique, le mapping endpoint‑independent a changé, ou il « optimise » UDP agressivement. Certains bloquent aussi UDP/4500 par défaut.

Correction : Placez la passerelle VPN sur une IP publique ou en mode bridge si possible ; sinon ajustez les keepalives et vérifiez explicitement le passthrough UDP/4500.

7) « Le cloud VPN dit connecté ; l’on‑premise ne voit rien entrant »

Symptôme : Le côté cloud est content ; l’on‑premise montre IKE up ; le plan de données entrant manque.

Cause racine : Le bord on‑prem autorise la sortie mais pas l’entrée UDP/4500 ; ou le NAT ne préserve pas les ports ; ou les security groups sont incomplets.

Correction : Validez des règles symétriques sur les deux côtés. Capturez sur l’interface WAN on‑prem pour prouver si le trafic encapsulé entrant arrive ou non.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise supposition

Ils avaient un VPN site‑à‑site entre un petit bureau et un DC central. Il fonctionnait depuis des années. Puis le bureau a changé d’étage et a eu un « rafraîchissement » réseau simple : nouveau circuit ISP, nouveau pare‑feu edge, et une refonte VLAN qui rendait les diagrammes propres comme dans un manuel.

Lundi matin, le tunnel est monté. Leur monitoring voyait IKE établi et proclamait victoire. Mais le trafic client ERP était mort. La première réponse du vendor fut la classique : « On dirait votre pare‑feu. » La première réponse de l’équipe réseau fut aussi la classique : « Le tunnel est up, donc ce n’est pas nous. » Ce statu‑quo leur a bouffé une demi‑journée.

La mauvaise supposition était subtile : ils ont supposé que parce que UDP/500 était permis et que IKE avait négocié, NAT‑T allait « simplement marcher ». Sur le nouveau pare‑feu, UDP/4500 n’était pas autorisé en entrant par défaut. L’équipement permettait la sortie. Donc le bureau pouvait initier, mais le DC ne pouvait pas renvoyer de façon fiable le trafic encapsulé après rekeys et périodes d’inactivité.

Ce qui a réparé le problème n’a pas été héroïque. Ce furent deux captures de paquets et une réunion gênante. Un tcpdump sur le WAN du bureau montrait UDP/4500 sortant. Une capture sur le bord du DC ne montrait rien arriver. Une fois cette preuve en main, le débat a pris fin. Ils ont ajouté des règles UDP/4500 symétriques, activé les keepalives sur la passerelle bureau, et le tunnel a cessé de mentir.

Mini‑histoire 2 : L’« optimisation » qui a échoué

Une autre société avait un maillage mondial de VPN, et quelqu’un s’est senti ambitieux pour « réduire le bruit ». Ils notaient des keepalives NAT périodiques et des probes DPD et ont décidé d’allonger les timers—moins de chatter, moins de CPU, moins de logs. Ça ressemblait à une bonne idée. Ça a aussi cassé la réalité.

Leurs NAT edge, particulièrement sur les petits sites, avaient des timeouts UDP agressifs. Avec des intervalles de keepalive plus longs, les mappings NAT expiraient pendant les périodes calmes. La rafale de trafic suivante tombait sur un mapping mort. Le pair distant retransmettait. DPD finissait par déclarer le pair mort. Le rekeying dérivait. Du côté applicatif, cela ressemblait à des coupures aléatoires de 30–90 secondes quelques fois par jour.

Parce que le tunnel se réparait souvent seul, l’instinct initial était de blâmer l’ISP ou « le cloud ». Mais les captures montraient la passerelle distante envoyant des paquets UDP/4500 vers une adresse/port que le NAT ne forwardait plus. Rien à l’extérieur n’était « down ». L’état avait disparu.

La correction a été d’annuler l’optimisation et d’accepter un petit flux de keepalives comme le coût d’être derrière un NAT. Ils ont aussi mis en place une politique : si vous changez les timers de vivacité, vous devez valider contre le timeout NAT le plus court de la flotte, pas le meilleur. Le tunnel bruyant est devenu fiable. En ops, l’ennuyeux est une fonctionnalité.

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

Une organisation financière avait un contrôle de changement strict et une habitude agaçante : chaque modification réseau nécessitait une capture avant changement et une capture après changement pour les liens critiques. Les ingénieurs râlaient. Personne n’aime le théâtre processuel. Mais celui‑ci s’est avéré du vrai théâtre : le genre où vous attrapez le méchant avant le troisième acte.

Ils ont planifié une mise à jour du pare‑feu sur un site distant. Avant le changement, ils ont capturé 60 secondes de trafic sur l’interface WAN et l’ont sauvegardée avec le dossier de changement. Après la mise à jour, le tunnel est revenu—mais l’application du centre d’appel a commencé à échouer sur les grandes réponses. Les petits tests passaient. Le vendor disait « pas nous ». L’équipe applicative disait « réseau ». Vous connaissez la chanson.

Parce qu’ils avaient des pcaps avant/après, ils ont pu comparer. La capture post‑upgrade montrait des paquets UDP/4500 plus volumineux qu’avant, et une modification du comportement de fragmentation. Le nouveau pare‑feu dropait plus agressivement les fragments IP sur la liaison WAN. Ce n’est pas un problème IKE ; c’est une réalité du plan de données.

La correction fut aussi ennuyeuse : clamp MSS TCP et ajuster le MTU d’interface pour tenir compte de l’overhead IPsec/NAT‑T. Le tunnel ne s’est pas seulement rétabli—il a cessé de générer des pannes intermittentes et bizarres. Le processus que tout le monde moquait a produit le rapport d’incident le plus court du trimestre.

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

Construire correctement (nouveau site‑à‑site derrière NAT)

1. Décidez du modèle : Si vous pouvez éviter le NAT, évitez‑le. Placez au moins un pair sur une IP publique stable quand c’est possible.
2. Ouvrez le bon trafic : Autorisez UDP/500 et UDP/4500 en bidirectionnel. Si vous opérez parfois sans NAT‑T, autorisez aussi ESP (IP proto 50). Soyez explicite.
3. Choisissez des durées sensées : Ne rekeyez pas toutes les quelques minutes sauf si vous appréciez les pages d’alerte.
4. Activez la vivacité : Configurez DPD et les keepalives NAT. Ajustez‑les pour le pire timeout NAT attendu, pas le meilleur.
5. Planifiez le MTU : Supposez l’overhead. Validez avec des tests DF. Mettez en place le clamp MSS si vous ne contrôlez pas ICMP de bout en bout.
6. Notez les sélecteurs : Sous‑réseaux locaux/distants et vérifiez qu’ils ne chevauchent aucun autre site.
7. Implémentez des exemptions NAT : Le trafic à destination du VPN ne doit pas être source‑NATé avant chiffrement.
8. Ajoutez du monitoring qui mesure le plan de données : Pas seulement « tunnel up ». Mesurez des flux réussis, des compteurs d’octets et la latence/jitter.

Changer sans casser (mises à jour de pare‑feu, changement d’ISP, changements de sous‑réseau)

1. Capturez UDP/500 et UDP/4500 avant le changement (30–60 secondes durant du vrai trafic).
2. Enregistrez l’état SA courant, les sélecteurs et les réglages MTU/MSS.
3. Après le changement, confirmez d’abord les ports à l’écoute et les règles pare‑feu.
4. Retestez avec un ping court et un ping DF.
5. Vérifiez que les compteurs XFRM ou les compteurs équivalents vendor augmentent quand vous générez du trafic.
6. Ce n’est qu’alors que vous ajustez timers/propositions si la négociation échoue.

Quand c’est en feu (checklist réponse incident)

1. Négocie‑t‑il sur UDP/500 ? Bascule‑t‑il sur UDP/4500 ?
2. Les deux côtés voient‑ils UDP/4500 entrant dans une capture ?
3. Les compteurs d’octets augmentent‑ils sur les SAs ?
4. Les sélecteurs correspondent‑ils aux sous‑réseaux réels ? Y a‑t‑il chevauchement ?
5. Une exemption NAT est‑elle présente ? De nouvelles règles MASQUERADE ?
6. Des pings DF passent‑ils ? Sinon, clamp MSS maintenant et planifiez un travail MTU plus profond.
7. Y a‑t‑il des changements récents ISP/CPE qui ont introduit du double NAT ou un nouveau filtrage ?

Faits intéressants et historique à utiliser

• Le NAT n’était pas prévu dans le design initial de l’IP. Il est devenu populaire dans les années 1990 comme réponse pragmatique à l’épuisement IPv4 et aux politiques d’adressage.
• L’ESP classique n’a pas de ports. Les NAT suivent typiquement les flux avec des ports, ce qui explique pourquoi ESP (protocole IP 50) est intrinsèquement hostile au NAT.
• NAT‑T a standardisé l’approche « ESP dans UDP ». L’idée centrale est simple : envelopper ESP pour que le NAT puisse le suivre comme tout autre flux UDP.
• UDP/4500 est le port conventionnel pour NAT‑T. UDP/500 est utilisé pour IKE ; NAT‑T bascule communément sur UDP/4500 après détection NAT.
• IKEv2 a amélioré la structure des messages et la fiabilité. Comparé à IKEv1, IKEv2 est moins baroque et se comporte mieux en cas de perte de paquets—mais il dépend toujours du comportement du chemin réseau.
• Certaines NAT sont « symétriques », et ça compte. Le NAT symétrique peut casser les hypothèses sur la préservation des ports et la reachabilité entrante, surtout quand plusieurs tunnels ou peers partagent une adresse.
• Les échecs PMTUD sont antérieurs à NAT‑T. Mais NAT‑T augmente l’overhead, faisant remonter des problèmes MTU latents plus fréquemment et de manière plus douloureuse.
• DPD et les keepalives sont des outils opérationnels, pas des niceties optionnelles. Ils existent parce que les middleboxes expirent l’état et parce que l’« échec silencieux » est courant sur Internet.
• Les VPN cloud masquent souvent la complexité derrière un statut « connecté ». Ce statut reflète généralement la santé du plan de contrôle IKE, pas si vos sous‑réseaux et routes spécifiques transportent du vrai trafic.

FAQ

1) Si IKEv2 montre ESTABLISHED, pourquoi ne puis‑je pas faire passer du trafic ?

Parce que le plan de contrôle et le plan de données sont différents. IKE peut réussir sur UDP/500 alors que UDP/4500 ou ESP est bloqué, que les sélecteurs ne correspondent pas, que les routes sont erronées, ou que des trous MTU mangent vos paquets plus gros.

2) Dois‑je toujours ouvrir ESP (protocole IP 50) ?

Si vous utilisez toujours NAT‑T, le plan de données est UDP/4500, pas ESP brut. Mais de nombreux environnements peuvent basculer de mode selon la détection NAT ou la configuration, donc permettre ESP peut être utile. La vraie réponse : vérifiez ce que vos pairs utilisent réellement et écrivez les règles de pare‑feu en conséquence.

3) Puis‑je exécuter NAT‑T même s’il n’y a pas de NAT ?

Souvent oui, selon l’implémentation. Mais forcer NAT‑T partout ajoute de l’overhead et vous expose au filtrage/conntrack spécifique à UDP. Utilisez‑le quand vous en avez besoin ; ne l’activez pas par superstition.

4) Pourquoi le tunnel meurt‑il seulement après une période d’inactivité ?

Les NAT et les pare‑feux stateful expirent l’état UDP. Sans keepalives fréquents, le mapping disparaît. Le paquet suivant arrive sur un mapping qui n’existe plus.

5) Quel intervalle de keepalive devrais‑je utiliser ?

Moins que le plus court timeout NAT attendu sur le chemin. Dans des environnements d’entreprise mixtes, supposer ~20–30 secondes est courant. La « bonne » valeur garde les mappings vivants sans générer un churn inutile. Si vous devinez, partez conservateur et vérifiez par la mesure.

6) Pourquoi de petits pings fonctionnent mais les applications échouent ?

MTU/fragmentation. NAT‑T + IPsec réduisent le MTU effectif. Si PMTUD est cassé, les gros paquets disparaissent. Corrigez avec le clamp MSS et/ou l’ajustement MTU, et envisagez d’autoriser les types ICMP nécessaires.

7) Quelle est la façon la plus rapide de prouver que UDP/4500 est bloqué ?

Capturez sur les deux bouts. Si vous voyez UDP/4500 sortant d’un pair et rien arriver à l’autre, le chemin filtre ou route mal. Les captures de paquets écrasent les opinions.

8) Le double NAT a‑t‑il de l’importance ?

Oui. Il peut modifier les mappings de ports, raccourcir les timers et introduire un comportement de NAT symétrique. Si vous ne pouvez pas enlever le double NAT, vous aurez généralement besoin de keepalives plus agressifs et d’une symétrie stricte des règles pare‑feu.

9) Des timers de rekey agressifs sont‑ils bons pour la sécurité ?

La sécurité n’est pas améliorée en rendant le tunnel inutilisable. Des durées raisonnables avec un comportement stable valent mieux que des rekeys constants qui provoquent pertes, collisions et flaps—surtout derrière un NAT.

10) Comment dois‑je surveiller correctement un tunnel IPsec site‑à‑site ?

Surveillez le succès du plan de données : transactions synthétiques périodiques entre hôtes/sous‑réseaux réels, plus compteurs d’octets SA et événements retransmit/DPD. « IKE est up » est nécessaire, pas suffisante.

Étapes suivantes à exécuter réellement

1. Inventoriez vos tunnels et enregistrez pour chacun : s’il utilise NAT‑T (UDP/4500), quels sous‑réseaux sont protégés, et quels timers keepalive/DPD sont configurés.
2. Rendez explicites les règles UDP/4500 sur chaque pare‑feu entre pairs. « IPsec autorisé » n’est pas une affirmation exploitable en audit.
3. Ajoutez une vérification du plan de données par tunnel : un petit ping, un ping DF près du MTU, et une transaction TCP (HTTPS ou équivalent). Alertez sur l’échec, pas sur « SA manquante ».
4. Corrigez proactivement le MTU : implémentez le clamp MSS sur les passerelles où vous ne contrôlez pas ICMP et où les tunnels traversent des réseaux imprévisibles.
5. Arrêtez d’« optimiser » les keepalives sauf si vous avez mesuré les timeouts NAT de bout en bout. Si vous devez réduire le chatter, faites‑le avec des preuves et des plans de rollback.
6. Lors d’incidents, partez des captures. Un pcap de 30 secondes sur chaque interface WAN règle les débats plus vite que n’importe quelle convocation.

Si vous faites cela, NAT‑T redevient un détail ennuyeux—ce qui est exactement là où il doit être.