Checklist de routage VPN site-à-site pour « impossible d’atteindre l’autre côté »

Un modèle mental pratique : paquets, pas tunnels

« VPN site-à-site » sonne comme un pont magique entre deux sites. En production, c’est moins poétique et plus plomberie :
les paquets quittent un hôte, subissent une décision de routage, sont peut‑être NATés, peut‑être filtrés, peut‑être encapsulés, traversent l’Internet,
puis sont décapsulés, filtrés à nouveau, routés à nouveau et finalement livrés (ou pas).

Quand quelqu’un dit « le VPN est up », traduisez cela par : « l’échange de clés a réussi, et il y a peut‑être des sélecteurs de Phase 2. »
Cette affirmation ne garantit pas que le plan de données transmet le trafic de bout en bout. Elle ne garantit pas l’existence des routes,
n’assure pas d’exemptions NAT, ne garantit pas que le trafic de retour suit le même chemin, et ne garantit surtout pas que le MTU ne vous sabote pas.

Deux modes VPN à ne pas confondre

La plupart des pannes de cette catégorie commencent par un malentendu caché dans les attentes. La différence clé :

• IPsec basé sur la politique : le chiffrement s’applique quand le trafic correspond aux sélecteurs d’« interesting traffic » (traffic selectors / proxy IDs).
  Le routage est souvent « normal », mais l’appareil VPN décide quoi chiffrer en fonction de paires de sous‑réseaux source/destination.
• IPsec basé sur le routage : vous avez une interface virtuelle (VTI / interface tunnel). Vous routez vers cette interface.
  Le chiffrement se produit parce que le paquet est routé dans l’interface tunnel, pas parce qu’il correspond à une liste de sélecteurs (même si des sélecteurs existent toujours en coulisse).

Si un côté pense être en mode policy-based et l’autre en mode route-based, vous pouvez obtenir un tunnel qui « se lève »
et un plan de données qui se comporte comme un poisson mort.

Règle opérationnelle : déboguez le chemin du paquet, pas le tunnel, côté par côté.
Ne déboguez pas le tunnel en premier. Le tunnel n’est qu’un seul saut au milieu.

Une citation à garder dans votre runbook provient de John Allspaw, souvent reprise dans les cercles fiabilité :
« idée paraphrasée » : l’erreur humaine est un symptôme de problèmes systémiques ; corrigez le système, pas la personne.
Appliquez-la ici : « mauvaise route » n’est rarement « quelqu’un a tapé une route incorrecte ». C’est généralement l’absence de garde‑fous, une visibilité insuffisante ou une propriété ambiguë.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Vous voulez trouver le goulot d’étranglement rapidement. Pas parfaitement. Rapidement. Voici l’ordre qui vous amène généralement à une réponse en quelques minutes.

Premier : prouver si le trafic entre dans le tunnel du tout

• Depuis un hôte du côté A, pingez ou testez TCP un hôte du côté B.
• Sur la passerelle VPN du côté A, vérifiez les compteurs SA IPsec (octets/paquets). S’ils ne bougent pas, vous ne faites pas correspondre les sélecteurs ou ne routez pas vers le tunnel.
• Capturez sur l’interface interne : voyez‑vous le paquet en clair arriver à la passerelle ?

Deuxième : prouver si le trafic sort du tunnel de l’autre côté

• Sur la passerelle VPN du côté B, vérifiez les compteurs SA. Si le côté A incrémente mais que le côté B ne le fait pas, vous avez probablement des problèmes d’ISP/ACL/NAT‑T ou de peer/PSK/ID incorrects (moins fréquent si le tunnel est « up »).
• Capturez sur l’interface interne du côté B : voyez‑vous le paquet décapsulé quittant la passerelle vers le sous‑réseau de destination ?

Troisième : prouver que le chemin de retour est suffisamment symétrique

• La plupart des problèmes « fonctionne dans un sens » sont des problèmes de routage de retour ou de NAT.
• Depuis le côté B, initiez du trafic vers le côté A. Ne supposez pas que l’état aide.
• Vérifiez les tables de routage sur l’hôte de destination ou sa passerelle par défaut : connaît‑il la route de retour vers le sous‑réseau distant via la passerelle VPN ?

Blague #1 : Si le tunnel est up mais que rien ne passe, félicitations — vous avez construit un destructeur de paquets très sécurisé.

Faits et contexte intéressants (parce que ça aide)

• IPsec a commencé dans les années 1990 comme partie de la sécurité d’IPv6, puis est devenu un add‑on pratique pour IPv4. Cette histoire explique pourquoi tant de concepts IPsec semblent « bricolés ».
• IKEv1 vs IKEv2 n’est pas que de la syntaxe. IKEv2 gère généralement mieux le rekey et la mobilité et réduit certains modes de défaillance, mais les vendeurs diffèrent encore dans les valeurs par défaut et les subtilités d’interopérabilité.
• Les sélecteurs de « Phase 2 » viennent de la pensée policy VPN. Même les tunnels route‑based négocient des traffic selectors en coulisse ; certains vendeurs utilisent 0.0.0.0/0 pour tout attraper, d’autres exigent des listes explicites.
• NAT‑Traversal (NAT‑T) existe parce que NAT a cassé ESP. ESP n’est pas TCP/UDP, donc les dispositifs NAT classiques ne savaient pas quoi en faire ; NAT‑T encapsule ESP dans UDP/4500 pour survivre.
• La découverte du MTU de chemin (PMTUD) est fragile sous encapsulation. Ajoutez l’overhead IPsec et soudain un chemin 1500 octets qui semblait sûr commence à noyer des fragments.
• Les « security associations » (SAs) ont des durées de vie et un comportement de rekey. Des bogues de rekey, des problèmes d’horloge ou des durées incompatibles peuvent causer des tickets périodiques « ça meurt toutes les heures ».
• Certaines implémentations route‑based cachent encore du policy VPN. Elles exposent une interface tunnel, mais s’appuient toujours sur des sélecteurs et règles de correspondance, ce qui compte quand vous ajoutez de nouveaux sous‑réseaux.
• BGP sur IPsec est devenu populaire avec les VPN cloud parce qu’il transforme la misère des routes statiques en routage dynamique — jusqu’à ce que vos timers BGP et l’état du pare‑feu se désaccordent.
• Le suivi d’état du pare‑feu est souvent le tiers invisible. Ce n’est pas suffisant que le routage soit correct ; l’inspection stateful peut abandonner le trafic de retour asymétrique même quand les routes existent.

Checklists / plan étape par étape

Checklist A : définir le problème en termes de paquets

• IP source (hôte, pas passerelle)
• IP de destination
• Protocole/port (ICMP vs TCP/443 importe)
• Directionnalité (A→B, B→A, ou les deux)
• Est‑ce « pas de route », « timeout », ou « connexion refusée » ?

Si vous ne pouvez pas nommer le 5‑tuple, vous dépannez à l’intuition.

Checklist B : confirmer le domaine d’encryptage / l’intention de routage

• Quels sous‑réseaux doivent traverser le VPN (local et distant) ? Listez‑les.
• Est‑ce des sélecteurs basés sur la politique, ou un VTI route‑based ?
• Y a‑t‑il des espaces d’adresses qui se chevauchent ? (Si oui, arrêtez‑vous et planifiez NAT ou renumérotation.)
• Le split tunneling est‑il attendu, ou tout le trafic doit‑il transiter ?

Checklist C : confirmer les trois plans de contrôle

• Plan de contrôle crypto : IKE établi, SAs IPsec installées, rekey stable.
• Plan de contrôle routage : routes des deux côtés pour les sous‑réseaux distants, next‑hop correct, pas de route plus spécifique qui s’échappe.
• Plan de contrôle politique : règles de pare‑feu permettant le trafic ; exemption NAT (ou NAT correct) en place ; security groups/NACLs alignés.

Checklist D : confirmer le plan de données de bout en bout

• Le paquet atteint la passerelle sur l’interface interne (capture).
• Le paquet incrémente les compteurs IPsec (octets SA).
• Le paquet apparaît sur l’interface interne du côté distant (capture).
• Le paquet de retour suit le chemin inverse (routage + NAT + état).

Checklist E : ne vous faites pas assassiner par le MTU

• Testez avec DF activé et tailles de charge utile variables.
• Clampez le MSS sur l’ingress du tunnel si vous ne pouvez pas faire confiance à PMTUD.
• Cherchez des motifs « ping fonctionne, HTTPS échoue ».

Tâches pratiques (commandes, sorties, décisions)

Ci‑dessous des tâches pratiques à lancer pendant un incident. Chaque tâche inclut : une commande, une sortie d’exemple, ce que ça signifie, et la décision à prendre.
Les commandes supposent des endpoints/passerelles Linux et strongSwan quand pertinent, mais la logique s’applique aux pare‑feux et routeurs cloud.

Task 1: verify the local host routes to the VPN gateway (not the internet)

cr0x@server:~$ ip route get 10.40.5.10
10.40.5.10 via 10.20.0.1 dev eth0 src 10.20.1.50 uid 1000
    cache

Signification : l’hôte enverra le trafic vers 10.40.5.10 via 10.20.0.1.
Si 10.20.0.1 n’est pas votre passerelle VPN (ou un routeur qui connaît le VPN), vous n’atteindrez jamais le tunnel.

Décision : si le next‑hop est incorrect, corrigez la route sur l’hôte ou le routeur amont (route statique ou routage dynamique).

Task 2: check the VPN gateway has a route for the remote subnet

cr0x@server:~$ ip route show 10.40.0.0/16
10.40.0.0/16 dev vti0 proto static scope link

Signification : tunnel route‑based : le sous‑réseau distant sort par vti0.
Si vous n’avez pas ceci, la passerelle peut envoyer le trafic vers la route par défaut (et vous vous demanderez pourquoi rien ne fonctionne).

Décision : ajoutez/réparez la route, ou corrigez la propagation de route (BGP, tables de routage cloud).

Task 3: verify IKE/IPsec SAs exist (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-siteA-siteB: #12, ESTABLISHED, IKEv2, 3c2a9c1e0e3b1a2f_i* 6f1d2b7c8a9e0d1c_r
  local  'gw-siteA' @ 203.0.113.10[4500]
  remote 'gw-siteB' @ 198.51.100.20[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 214s ago
  vpn-siteA-siteB{27}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
  vpn-siteA-siteB{27}:   10.20.0.0/16 === 10.40.0.0/16
  vpn-siteA-siteB{27}:   bytes_i 0, packets_i 0, bytes_o 8420, packets_o 71

Signification : la SA est installée ; les traffic selectors sont 10.20/16 ↔ 10.40/16.
Les compteurs sortants augmentent, les entrants sont à zéro : le côté A envoie du trafic chiffré mais ne reçoit pas de réponses (ou elles ne correspondent pas aux sélecteurs).

Décision : concentrez‑vous sur le chemin de retour, le routage distant, les sélecteurs distants ou le pare‑feu distant qui bloque.

Task 4: check whether packets arrive at the gateway inside interface

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.40.5.10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.102334 IP 10.20.1.50.51124 > 10.40.5.10.443: Flags [S], seq 245112233, win 64240, options [mss 1460,sackOK,TS val 902211 ecr 0,nop,wscale 7], length 0

Signification : le paquet interne atteint la passerelle. Bien. Si vous ne le voyez pas, votre problème est en amont (route hôte, VLAN, ACL, mauvaise passerelle).

Décision : s’il est absent, cessez de toucher IPsec ; corrigez d’abord le routage/L2/L3 vers la passerelle.

Task 5: check whether encrypted packets leave the gateway to the peer

cr0x@server:~$ sudo tcpdump -ni eth0 host 198.51.100.20 and udp port 4500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.102901 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 116
14:02:11.103122 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 116

Signification : des paquets ESP encapsulés en NAT‑T sortent. Si vous voyez des paquets internes mais pas de UDP/4500, votre politique IPsec ne matche pas ou le pare‑feu bloque.

Décision : inspectez les sélecteurs/politiques et le pare‑feu local. Si les paquets sortent mais rien ne revient, allez regarder de l’autre côté et les ACL ISP.

Task 6: confirm packets decapsulate on the far side (capture on inside)

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.20.1.50
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.145009 IP 10.20.1.50.51124 > 10.40.5.10.443: Flags [S], seq 245112233, win 64240, options [mss 1360,sackOK,TS val 902211 ecr 0,nop,wscale 7], length 0

Signification : sur le côté B, vous voyez l’origine/destination après décapsulation. Cela prouve que le tunnel transporte le paquet.
Si vous ne le voyez pas mais voyez de l’UDP/4500 en dehors, les sélecteurs peuvent ne pas matcher, ou l’appareil VPN rejette à cause de la politique.

Décision : corrigez les traffic selectors/proxy IDs, ou les règles basées sur la politique qui définissent le « interesting traffic ».

Task 7: check Linux kernel IPsec policy and state (xfrm)

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
    proto esp spi 0xc4b3a2c1 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x0000000000000000000000000000000000000000000000000000000000000000 128
    enc cbc(aes) 0x0000000000000000000000000000000000000000000000000000000000000000
    anti-replay context: seq 0x0000002f, oseq 0x00000000, bitmap 0x00000000
    stats: replay-window 0 replay 0 failed 0 bytes 8452 packets 71
src 198.51.100.20 dst 203.0.113.10
    proto esp spi 0xc1a2b3c4 reqid 1 mode tunnel
    stats: replay-window 0 replay 0 failed 0 bytes 0 packets 0

Signification : l’ESP sortant fonctionne ; l’entrant non. Cela corrobore l’histoire des compteurs SA et vous pousse vers le routage/pare‑feu distant ou un blocage en amont.

Décision : arrêtez de débattre « le tunnel est‑il up ». Il l’est. Maintenant, corrigez pourquoi les réponses ne reviennent jamais.

Task 8: validate firewall rules for forwarded traffic (Linux nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iif "eth1" oif "vti0" ip saddr 10.20.0.0/16 ip daddr 10.40.0.0/16 accept
    iif "vti0" oif "eth1" ip saddr 10.40.0.0/16 ip daddr 10.20.0.0/16 accept
  }
}

Signification : la politique forward est drop, mais des permissions explicites existent dans les deux sens. Si vous n’autorisez qu’un sens, le suivi d’état peut ne pas couvrir tous les flux (surtout en cas d’asymétrie ou UDP).

Décision : assurez‑vous que les règles de forward permettent les deux sous‑réseaux dans les deux sens, et que les politiques s’appliquent aux bonnes interfaces.

Task 9: detect NAT that breaks the encryption domain

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

Signification : MASQUERADE NATera tout le trafic 10.20/16 sortant sur eth0. Si votre trafic VPN sort sur eth0 avant d’être capturé par la politique IPsec,
vous pouvez le NATer et il ne correspondra plus aux sélecteurs (ou le côté distant verra une source incorrecte et rejettera).

Décision : ajoutez une exemption NAT pour le trafic destiné à 10.40/16 (ou assurez‑vous que la politique s’applique avant le NAT sur votre plateforme).

Task 10: confirm the remote side knows how to return to the source subnet

cr0x@server:~$ ip route get 10.20.1.50
10.20.1.50 via 10.40.0.1 dev eth0 src 10.40.5.10 uid 1000
    cache

Signification : cet hôte (10.40.5.10) enverra le trafic de retour vers 10.40.0.1 (sa passerelle par défaut), pas vers la passerelle VPN.
Si 10.40.0.1 ne route pas 10.20/16 vers le VPN, les réponses partent ailleurs et s’évaporent.

Décision : ajoutez des routes sur le routeur central du réseau distant, ou ajustez le routage pour que la passerelle VPN soit sur le chemin pour le trafic de retour.

Task 11: detect asymmetric routing with traceroute (TCP to match real traffic)

cr0x@server:~$ traceroute -T -p 443 10.40.5.10
traceroute to 10.40.5.10 (10.40.5.10), 30 hops max, 60 byte packets
 1  10.20.0.1 (10.20.0.1)  0.324 ms  0.291 ms  0.276 ms
 2  * * *
 3  * * *
 4  10.40.5.10 (10.40.5.10)  9.812 ms  9.775 ms  9.741 ms

Signification : le saut 1 est votre passerelle interne, puis silence (probablement parce que les sauts du tunnel n’envoient pas de TTL exceeded), puis la destination.
Si vous voyez des sauts publics, vous n’utilisez pas le VPN. Si vous n’atteignez jamais la destination, passez aux captures/compteurs.

Décision : utilisez traceroute comme un contrôle de bon sens rapide, pas comme un verdict final. Passez ensuite aux captures/compteurs.

Task 12: test MTU/PMTUD with “do not fragment” pings

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

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

Signification : le MTU local est 1400 (ou le chemin le clamp), et votre charge choisie ne rentre pas avec les en‑têtes.
Dans le monde VPN, même un LAN à 1500 octets nécessite souvent un MTU effectif plus petit à cause de l’overhead d’encapsulation.

Décision : réduisez le MTU de l’interface/tunnel ou clamppez le MSS TCP. Si les ICMP fragmentation‑needed sont bloqués, vous devez compenser explicitement.

Task 13: check TCP MSS clamping (if you’re doing it, confirm it’s real)

cr0x@server:~$ sudo iptables -t mangle -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A FORWARD -o vti0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Signification : les SYN forwardés vers vti0 voient leur MSS ajusté au PMTU. Cela réduit les problèmes de « gros transferts qui bloquent ».

Décision : si vous avez des symptômes MTU, ajoutez ceci (ou l’équivalent) via un changement contrôlé ; si vous l’avez déjà, vérifiez que PMTU fonctionne.

Task 14: validate that forwarding is enabled (Linux gateway classic)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Signification : la machine ne routage pas les paquets entre interfaces. Votre tunnel peut être parfait et tout sera quand même rejeté.

Décision : activez le forwarding et persistez la configuration, puis retestez. Assurez‑vous aussi que la chaîne forward du pare‑feu le permet.

Task 15: confirm the peer is reachable and ports aren’t blocked (4500/500)

cr0x@server:~$ sudo nc -uvz 198.51.100.20 4500
Connection to 198.51.100.20 4500 port [udp/*] succeeded!

Signification : pas définitif pour UDP (car « succeeded » est best‑effort), mais si cela échoue complètement à cause du routage ou du pare‑feu local, c’est un indice.

Décision : si vous ne pouvez même pas tenter UDP/4500, corrigez les ACL en amont ou le filtrage de sortie local avant de toucher les réglages IKE.

Task 16: observe rekey/DPD flaps in logs (strongSwan)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" | tail -n 12
Dec 27 14:01:22 gw strongswan[1123]: 15[IKE] peer supports MOBIKE
Dec 27 14:01:22 gw strongswan[1123]: 15[IKE] IKE_SA vpn-siteA-siteB[12] established between 203.0.113.10[gw-siteA]...198.51.100.20[gw-siteB]
Dec 27 14:01:22 gw strongswan[1123]: 15[CHD] CHILD_SA vpn-siteA-siteB{27} established with SPIs c1a2b3c4_i c4b3a2c1_o and TS 10.20.0.0/16 === 10.40.0.0/16
Dec 27 14:03:01 gw strongswan[1123]: 07[IKE] sending DPD request
Dec 27 14:03:31 gw strongswan[1123]: 07[IKE] DPD response received
Dec 27 14:05:22 gw strongswan[1123]: 15[CHD] CHILD_SA vpn-siteA-siteB{27} rekeyed

Signification : réponses DPD stables et rekey réussi. Si vous voyez des timeouts DPD répétés ou des échecs de rekey, vous aurez des coupures intermittentes.

Décision : si ça flappe, regardez les NAT qui ont des temporisations de mapping UDP, les timeouts inactifs, le filtrage ISP, ou des durées/algorithmes incompatibles.

Erreurs courantes : symptôme → cause racine → correction

1) « Tunnel up, impossible de pinger quoi que ce soit »

• Symptôme : IKE établi, mais les compteurs d’octets SA restent à zéro.
• Cause racine : le routage n’envoie pas le trafic vers le tunnel, ou les sélecteurs de politique ne correspondent pas aux sous‑réseaux source/destination réels.
• Correction : vérifiez ip route get et les traffic selectors VPN ; ajoutez les routes manquantes ou mettez à jour les proxy IDs/paire TS.

2) « Fonctionne de Site A vers Site B, pas en retour »

• Symptôme : les octets SA sortants augmentent d’un côté ; les entrants restent plats. SYN TCP vus dans un sens ; pas de SYN‑ACK.
• Cause racine : route de retour manquante sur la passerelle par défaut du sous‑réseau distant ; routage asymétrique ; pare‑feu stateful qui rejette les réponses hors‑état.
• Correction : ajoutez la route distante pour le sous‑réseau source via la passerelle VPN ; assurez‑vous que le pare‑feu permet les deux sens ; évitez les conceptions « one‑arm » sans gestion d’état rigoureuse.

3) « Les pings fonctionnent, HTTPS bloque ou les transferts se figent »

• Symptôme : les petits paquets passent ; les charges plus grandes échouent ; les sessions TCP s’établissent puis se figent.
• Cause racine : MTU/PMTUD en blackhole dû à l’overhead IPsec et aux messages ICMP fragmentation‑needed bloqués.
• Correction : clamppez le MSS TCP à l’ingress du tunnel ; réduisez le MTU interface/tunnel ; autorisez les types ICMP pertinents quand c’est sûr.

4) « Un seul sous‑réseau fonctionne ; le nouveau sous‑réseau ne passe pas »

• Symptôme : les anciens réseaux passent ; le nouveau CIDR est mort.
• Cause racine : sélecteurs/proxy IDs non mis à jour sur les deux côtés ; tables de routage cloud non mises à jour ; exemption NAT manquante pour le nouveau sous‑réseau.
• Correction : mettez à jour les sélecteurs sur les deux pairs ; propagez les routes (statique/BGP/cloud) ; dupliquez les exemptions NAT et les règles de pare‑feu.

5) « Coupures intermittentes toutes les N minutes »

• Symptôme : le trafic fonctionne, puis meurt brièvement, puis revient ; les logs montrent des événements de rekey.
• Cause racine : timers de rekey mismatched, timeouts de mapping NAT, DPD agressif, ou interopérabilité crypto boguée.
• Correction : alignez les durées de vie ; définissez un DPD raisonnable ; maintenez NAT‑T actif ; mettez à jour le firmware ; envisagez IKEv2 si possible.

6) « Tout fonctionnait jusqu’à ce qu’on active le NAT »

• Symptôme : tunnel up, mais le distant voit du trafic depuis une IP source inattendue ; les politiques ne correspondent pas.
• Cause racine : le NAT s’est appliqué au trafic destiné au VPN avant le chiffrement (ou le NAT a changé la source hors des sélecteurs/proxy ID).
• Correction : configurez une exemption NAT ; ou concevez volontairement un « NAT inside the tunnel » et mettez à jour les sélecteurs et routes distantes en conséquence.

Blague #2 : Le NAT, c’est comme un programme de protection des témoins pour les paquets — parfait jusqu’à ce que la cour demande leur vraie identité.

Trois mini-histoires d’entreprise du terrain

Mini-histoire 1 : la panne causée par une mauvaise hypothèse

Une société acquiert un petit fournisseur et a besoin d’un VPN site‑à‑site rapide pour que la finance « accède juste à l’ERP ».
L’équipe réseau côté acquéreur met en place un tunnel route‑based avec un VTI et ajoute des routes pour le sous‑réseau du fournisseur.
L’UI du pare‑feu montre du vert. Tout le monde rentre chez soi en se sentant compétent.

Le lendemain matin : rien ne fonctionne. Ni SMB, ni HTTPS, pas même un ping. Le VPN est toujours « up ».
L’équipe applicative commence à accuser le DNS, ce qui est toujours un mauvais signe pour la durée de l’incident.
L’équipe réseau consulte les compteurs : octets sortants, zéro octets entrants.

L’hypothèse cachée : « Si de notre côté on route dans le tunnel, l’autre côté fera naturellement la route de retour. »
Du côté du fournisseur, la passerelle par défaut est un autre routeur, et ce routeur n’a aucune idée que 10.20.0.0/16 se trouve derrière le VPN.
Les paquets de retour partent vers Internet, sont supprimés par des protections anti‑spoofing, et disparaissent.

La correction fut ennuyeuse : une route statique sur le routeur central du fournisseur pointant 10.20.0.0/16 vers leur passerelle VPN, plus des règles de pare‑feu autorisant les flux.
Une fois le routage de retour correct, tout a fonctionné instantanément. Personne n’a touché aux réglages crypto.

La leçon : « Tunnel up » n’est pas un contrat de routage. Rendez le chemin de retour explicite, par écrit, avant de planifier la bascule.

Mini-histoire 2 : l’optimisation qui s’est retournée contre eux

Une autre organisation voulait « optimiser » le débit VPN pour les jobs de réplication nocturne.
Quelqu’un a remarqué que le MTU de l’interface tunnel était réglé bas « par sécurité » et a décidé de le pousser à 1500 parce que « le LAN est à 1500 et les jumbo frames, c’est moderne ».
Ils ont aussi désactivé le clamp MSS parce que « c’est du travail CPU en plus ».

Pendant quelques heures tout semblait bien. Les pings passaient. Les petites API fonctionnaient. Le job de réplication a démarré… puis plafonné.
Pas une panne nette. Le pire : à moitié fonctionnel, totale confusion.
Les sessions TCP s’établissaient puis se figeaient sous charge. Les retransmissions montaient. Les graphes de latence ressemblaient à des dents de scie.

Le vrai problème était un blackhole PMTUD. Le chemin Internet ne pouvait pas réellement porter des paquets internes de 1500 octets une fois l’encapsulation IPsec ajoutée.
Les messages ICMP fragmentation‑needed étaient filtrés en amont (personne ne pouvait prouver où, bien sûr).
Les gros paquets disparaissaient, et TCP persistait jusqu’à abandon.

L’« optimisation » a produit un système qui tombait en panne exactement dans les conditions qu’on voulait améliorer.
La correction : revenir sur le MTU, réactiver le clamp MSS, et ajouter une vérification de monitoring qui alerte sur la hausse des retransmissions pour les flux de réplication.
Le débit s’est stabilisé, et tout le monde a fait semblant que l’expérience fut un succès parce qu’elle leur a appris quelque chose.

La leçon : les changements MTU sont des changements en production. Traitez‑les comme une migration de schéma de base de données — planifiez, testez, rollbackez rapidement.

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

Une grande entreprise avait des dizaines de VPN site‑à‑site parce que le « hybrid » était devenu du « spaghetti » en une décennie.
L’équipe réseau était fatiguée des tickets de nuit, alors elle a adopté une pratique que personne ne trouvait excitante :
pour chaque tunnel, maintenir une « fiche de contrat de trafic » d’une page — sous‑réseaux locaux, sous‑réseaux distants, attentes NAT, méthode de routage, et commandes de test.

Un vendredi soir, une fenêtre de changement a introduit un nouveau sous‑réseau côté A.
Sans surprise, le nouveau sous‑réseau ne pouvait pas atteindre le côté B. Les anciens sous‑réseaux fonctionnaient toujours.
L’ingénieur d’astreinte n’a pas eu besoin du savoir tribal ; il a ouvert la fiche de contrat et a vu la liste des sélecteurs et les modèles d’exemption NAT requis.

Il a exécuté les tests dans le doc : les compteurs SA n’incrémentaient pas pour le nouveau sous‑réseau, mais oui pour l’ancien.
Cela a directement pointé les sélecteurs/proxy IDs. Ils ont mis à jour les deux côtés, poussé la config, et confirmé le mouvement des compteurs.
Temps total : moins d’une heure, sans tâtonnements ni « peut‑être c’est le DNS ».

La leçon : la documentation ennuyeuse et testable opérationnellement bat la débrouillardise. Surtout à 2 h du matin, quand votre débrouillardise dort.

FAQ

1) Si IKE est établi, cela ne prouve-t-il pas que le VPN fonctionne ?

Cela prouve que les pairs peuvent s’authentifier et négocier des clés. Cela ne prouve pas que le plan de données est routé correctement, autorisé par la politique, ou dimensionné pour le MTU.
Vérifiez toujours les compteurs d’octets SA et faites des captures.

2) Quelle est la façon la plus rapide de savoir si mon trafic correspond aux sélecteurs ?

Regardez les compteurs CHILD_SA/SA tout en générant du trafic depuis l’hôte source réel vers la destination réelle.
Si les compteurs ne bougent pas, votre trafic n’est pas chiffré (sélecteurs incorrects, routes incorrectes, ou interférence NAT).

3) Policy-based vs route-based : lequel privilégier ?

Privilégiez route‑based (VTI) quand vous le pouvez. Il s’aligne sur le routage normal, évolue mieux quand les sous‑réseaux changent, et fonctionne bien avec le routage dynamique comme BGP.
Le policy‑based convient aux petits environnements statiques, mais chaque nouveau sous‑réseau devient une négociation avec votre futur vous.

4) Pourquoi le ping fonctionne mais mon application pas ?

L’ICMP echo est petit et tolérant. Les applications utilisent souvent TCP avec des segments plus grands et sont sensibles à l’échec de PMTUD.
C’est du domaine classique MTU/MSS : testez avec des pings DF et clamppez le MSS si nécessaire.

5) Dois‑je autoriser l’ICMP à travers le VPN ?

Vous devez autoriser suffisamment d’ICMP pour des opérations saines, en particulier fragmentation‑needed (pour PMTUD) et pour le dépannage de base.
Si la politique l’interdit, compensez par un MTU conservateur et un clamp MSS, et acceptez une visibilité réduite.

6) Comment les sous‑réseaux qui se chevauchent cassent‑ils un VPN site‑à‑site ?

Le routage devient ambigu : le même préfixe existe localement et à distance, donc les paquets peuvent ne jamais entrer dans le tunnel, ou le trafic de retour va au mauvais endroit.
Corrigez par renumérotation (meilleur), ou par NAT à l’intérieur du tunnel (courant, mais ajoute complexité et surprises).

7) Qu’est‑ce qu’une « exemption NAT » et pourquoi m’importe‑t‑elle ?

C’est une règle qui dit « ne pas NATer le trafic entre ces sous‑réseaux privés ; conserver les adresses afin que les sélecteurs et les routes correspondent ».
Sans cela, votre VPN peut chiffrer la mauvaise chose ou le côté distant peut rejeter le trafic qui ne correspond pas aux adresses source attendues.

8) Quand devrais‑je utiliser BGP sur le VPN ?

Utilisez‑le lorsque vous avez de multiples sous‑réseaux, des changements fréquents, ou plusieurs tunnels/chemins.
Il réduit la dérive des routes statiques. Mais surveillez‑le : une session BGP up ne signifie pas que le plan de données est sain, et le réglage des timers peut créer des flaps.

9) Que signifie « routage asymétrique » dans ce contexte ?

La requête va A→B via le VPN, mais la réponse retourne B→A par un chemin différent (souvent Internet ou un autre tunnel).
Les pare‑feux stateful détestent ça, et même le routage stateless peut le rejeter à cause des protections anti‑spoofing.

10) Que devrais‑je standardiser entre les tunnels pour réduire les incidents ?

Standardisez : inventaire des domaines d’encryptage/sous‑réseaux, méthode de routage (préférez VTI), politique de clamp MSS, timers DPD/rekey, et une suite de tests opérationnels
(quelques pings/checks TCP + vérification des compteurs SA + un point de capture).

Conclusion : que faire la prochaine fois avant que ça casse

Quand vous « ne pouvez pas atteindre l’autre côté », résistez à la tentation de bidouiller la crypto en premier. La plupart des pannes sont liées au routage, NAT, politique de pare‑feu ou MTU.
Traitez le tunnel comme un saut ; dépannez le chemin du paquet.

Étapes pratiques que vous pouvez faire cette semaine :

• Rédigez une fiche de « contrat de trafic » d’une page pour chaque VPN site‑à‑site : sous‑réseaux, méthode de routage, attentes NAT, et commandes de test.
• Ajoutez un contrôle de monitoring qui alerte quand les compteurs d’octets SA ne bougent pas pendant des fenêtres de trafic connues (ou sur des pics de retransmissions pour les flux clés).
• Standardisez le clamp MSS (ou un MTU validé) entre les tunnels pour arrêter de redécouvrir le même blackhole.
• Pendant les changements, testez explicitement dans les deux sens. Un succès unilatéral est un pré‑incident, pas une victoire.

Faites cela, et votre prochain incident « le VPN est up mais rien ne marche » sera plus court, plus calme, et impliquera moins de discussions entre cinq équipes sur l’appartenance d’un paquet.