Routage VPN site-à-site : pourquoi le tunnel est actif mais rien ne fonctionne (et comment réparer)

décembre 17, 2025 • février 3, 2026 • Lecture : 29 min • Views: 8

Cet article vous a aidé ?

Le tunnel est « actif ». Votre tableau de bord est vert. La phase 1 est établie, la phase 2 est installée, le pair est « connecté ».
Et pourtant : pas de ping, pas de SSH, pas de connexions base de données, pas de trafic applicatif. Vous avez atteint le jalon classique en entreprise :
la cryptographie fonctionne, le réseau non.

Ce mode d’échec est si fréquent qu’il mérite son propre runbook. Le fait que le tunnel soit actif signifie seulement que les appareils se sont mis d’accord
sur la manière de chiffrer. Cela ne dit presque rien sur la capacité des paquets à trouver le tunnel, à survivre à l’encapsulation et à émerger
de l’autre côté d’une manière que la destination acceptera et à laquelle elle répondra.

Ce que « le tunnel est actif » signifie réellement (et ce que cela ne signifie pas)

La plupart des VPN site-à-site ont deux notions distinctes d’« actif » :

Plan de contrôle actif : IKE/handshake terminé, clés négociées, SA établie. C’est ce que les tableaux de bord aiment afficher.
Plan de données opérationnel : les paquets sont routés dans le tunnel, correspondent aux sélecteurs, franchissent pare-feu/NAT, survivent au MTU, et le trafic de retour suit le même chemin inverse.

Votre problème se situe presque toujours dans le plan de données. Plus précisément :

Routage : les paquets n’entrent jamais dans le tunnel (routes erronées, routes manquantes, policy routing incorrect, VRF incorrecte).
Sélecteurs / politique : les paquets atteignent la box mais ne correspondent pas aux sélecteurs du VPN (IPsec basé sur la politique) ou aux AllowedIPs (WireGuard).
NAT / pare-feu : les paquets correspondent au tunnel mais sont NATés en quelque chose que l’autre côté n’attend pas, ou sont bloqués par des règles états-pleines.
Chemin/MTU : les paquets disparaissent à cause de la fragmentation, de blackholes PMTUD, ou d’un MSS non bridé.
Asymétrie : les paquets sortent via le VPN et reviennent par l’internet (ou un autre WAN), déclenchant les pare-feu, rp_filter, ou simplement « pas de route de retour ».

Le seul test fiable est simple : envoyez un paquet depuis un hôte derrière le Site A vers un hôte derrière le Site B, puis prouvez — à l’aide
de captures et de compteurs — où il s’arrête.

Faits intéressants et contexte historique (qui vous mordent encore aujourd’hui)

Un peu d’histoire explique pourquoi le routage VPN moderne ressemble à de l’archéologie : différentes ères du réseau ont laissé
des hypothèses variées, et votre configuration actuelle est un mashup fossile.

IPsec précède le « cloud networking » : les spécifications centrales ont été formées à une époque où la plupart des réseaux étaient statiques et privés. Aujourd’hui on le greffe sur NAT, overlays et routage dynamique.
Les VPN basés sur la politique sont apparus tôt dans de nombreux pare-feu : plutôt que « router le trafic vers une interface », les conceptions initiales comparaient les paquets à des sélecteurs et les chiffraient. Simple pour des petits déploiements, pénible à grande échelle.
NAT-Traversal (NAT‑T) existe parce que le NAT a cassé IPsec : ESP ne survivait pas aux équipements NAT typiques, donc l’encapsulation UDP sur le port 4500 est devenue une échappatoire standard.
Les blackholes PMTUD sont plus vieux que la plupart des équipes : ICMP « Fragmentation Needed » a été bloqué par des équipes de « sécurité » depuis toujours, et l’encapsulation VPN aggrave le problème.
« Split tunnel » était autrefois un débat pour VPN client : désormais le même concept apparaît en site-à-site comme routage sélectif, tunnels multiples et politiques d’orientation du trafic.
BGP sur IPsec est populaire parce que les humains se trompent : les routes statiques vont très bien jusqu’au troisième site, puis vous êtes à un tableur d’une panne.
Reverse path filtering (rp_filter) est une réponse Linux au spoofing : c’est bien… jusqu’à ce que votre routage soit asymétrique, alors il commence à jeter du trafic VPN légitime.
WireGuard est volontairement minimal : il vous donne un tunnel et des clés, pas un cadre politique. Des AllowedIPs mal configurés sont l’équivalent moderne d’une non‑correspondance de sélecteurs.
Les espaces RFC1918 chevauchants sont une tradition d’entreprise : 10.0.0.0/8 était censé être privé, pas universel. Les fusions l’ont rendu universel malgré tout.

Procédure de diagnostic rapide (trouver le goulot vite)

Quand quelqu’un dit « le VPN est actif mais rien ne fonctionne », ne commencez pas par modifier les paramètres crypto. C’est ainsi que vous transformez un bug de routage en une longue nuit.
Commencez par une boucle serrée : prouvez le chemin, prouvez la politique, prouvez le retour.

Première étape : prouver que le paquet entre dans la passerelle VPN

Depuis un hôte derrière le Site A, ping/traceroutez un hôte spécifique derrière le Site B (pas « le sous‑réseau »). Choisissez une IP que vous contrôlez.
Sur la passerelle VPN du Site A, capturez le trafic sur l’interface LAN pour confirmer que le paquet arrive.
Vérifiez la décision de routage de la passerelle : envoie‑t‑elle la destination vers l’interface de tunnel/VTI ou correspond‑elle à une politique ?

Deuxième étape : prouver que le paquet correspond à la politique/sélecteurs VPN

Sur IPsec, vérifiez que les SA installées incluent les sous‑réseaux source/destination exacts que vous testez.
Sur WireGuard, vérifiez que AllowedIPs inclut le sous‑réseau distant, et que le pair distant a une route de retour.
Regardez les compteurs d’octets des SA. S’ils restent à zéro pendant que vous générez du trafic, votre paquet n’entre pas dans la politique du tunnel.

Troisième étape : prouver le chemin de retour et l’état

Capturez sur l’interface LAN du site distant : le paquet émerge‑t‑il déchiffré ?
Si oui, capturez la réponse : est‑elle routée de retour dans le tunnel ?
Vérifiez l’état du pare‑feu et rp_filter des deux côtés.

Quatrième étape : vérifier MTU/MSS seulement après les bases routage/politique

Les problèmes MTU peuvent ressembler à « rien ne fonctionne », mais ils se présentent généralement comme « le ping marche, TCP bloque », ou « les petites requêtes passent, les grosses se figent ».
Ne blâmez pas prématurément le MTU parce que c’est à la mode.

Blague n°1 : un tableau de bord VPN qui dit « Actif » ressemble à une machine à café avec le voyant « Prêt ». Ça ne garantit pas que vous allez obtenir du café.

Modèle mental : les quatre portails que chaque paquet doit franchir

Voici le modèle que j’utilise en débogage. Chaque paquet qui tente de traverser un VPN site-à-site doit franchir quatre portails :

Portail 1 : L’hôte source peut‑il atteindre sa passerelle, et est‑ce la bonne ?

Un nombre surprenant de problèmes « VPN » sont en fait « mauvaise passerelle par défaut », « pare‑feu de l’hôte », ou « VLAN incorrect ». Si votre hôte n’envoie
pas le trafic vers la passerelle VPN (ou vers le routeur qui connaît le VPN), vous déboguez le mauvais appareil.

Portail 2 : La passerelle route‑t‑elle le paquet dans le tunnel ?

Les VPN basés sur les routes s’appuient sur les tables de routage (static, OSPF/BGP, policy routing). Les VPN basés sur la politique s’appuient sur des sélecteurs :
« si le paquet correspond à cet ACL, chiffrez‑le. » Les deux peuvent être incorrects de façon ennuyeuse.

Le classique « le tunnel est actif mais rien ne fonctionne » correspond souvent à l’absence d’une route vers le sous‑réseau distant sur le côté LAN, si bien que
les paquets partent sur l’internet et manquent la politique VPN.

Portail 3 : Le tunnel accepte‑t‑il le paquet ?

IPsec a des traffic selectors (sous‑réseaux locaux/distants). Si votre paquet ne correspond pas, il ne sera pas chiffré par la SA que vous croyez exister.
WireGuard a AllowedIPs, qui est à la fois une politique crypto et une politique de routage : il décide ce qui est chiffré et ce qui est accepté d’un pair.

Portail 4 : Le côté distant peut‑il livrer le paquet et le renvoyer de manière symétrique ?

Même si le côté distant reçoit le paquet, il doit le livrer à l’hôte de destination et obtenir une réponse qui emprunte le même chemin. Les réponses qui sortent par un autre chemin
sont l’ennemi des pare‑feu stateful, de conntrack, des attentes NAT et de rp_filter.

Tâches pratiques avec commandes : vérifier, décider, corriger

Les tâches suivantes sont destinées à être exécutées pendant un incident. Chacune comprend : une commande, ce que signifie la sortie, et la décision à prendre.
Les commandes sont montrées sur Linux parce que c’est courant pour les passerelles VPN, jump hosts et machines de test — même si votre appareil VPN est un appliance pare‑feu.

Task 1: Verify the host is sending traffic to the correct gateway

cr0x@server:~$ ip route show default
default via 10.20.0.1 dev eth0 proto dhcp src 10.20.0.55 metric 100

Signification : L’hôte utilise 10.20.0.1 comme passerelle par défaut. Si votre passerelle/routeur VPN n’est pas 10.20.0.1 (ou ne connaît pas les routes vers le site distant),
votre paquet n’a même pas la chance d’atteindre le tunnel.

Décision : Si la passerelle par défaut est erronée, corrigez la configuration DHCP/statique ou ajoutez une route spécifique pour le sous‑réseau distant via le routeur correct.

Task 2: Confirm there is a route to the remote subnet (host perspective)

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

Signification : Le trafic vers 172.31.40.10 passe par 10.20.0.1. Ce routeur doit avoir une route vers le VPN, sinon vous fuyez par le mauvais chemin.

Décision : Si le next hop n’est pas le routeur attendu, ajoutez une route plus spécifique ou corrigez les annonces de routage.

Task 3: Check routing on the VPN gateway (route-based VPN)

cr0x@server:~$ ip route get 172.31.40.10
172.31.40.10 dev vti0 src 10.20.0.1 uid 0
    cache

Signification : La passerelle enverra cette destination vers vti0 (une interface de tunnel virtuelle). Bon signe : le routage pointe vers le tunnel.

Décision : Si elle route vers l’interface WAN à la place, vous avez besoin de routes (statiques/BGP) ou de policy routing pour diriger le trafic dans le tunnel.

Task 4: Identify policy routing or multiple tables (Linux gateways)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.20.0.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Signification : Le trafic source 10.20.0.0/24 utilise la table de routage 100. Si votre route VPN vit dans main mais que le trafic utilise la table 100,
le tunnel ne sera pas utilisé.

Décision : Mettez la route VPN dans la table correcte ou ajustez la règle. Traitez le policy routing comme du code en production : révisez, testez, documentez.

Task 5: Confirm IP forwarding is enabled on a Linux VPN gateway

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

Signification : Le forwarding est activé. S’il est à 0, la passerelle est décorative.

Décision : Si désactivé, activez‑le et persistez la valeur dans /etc/sysctl.conf ou un drop‑in. Puis retestez le trafic.

Task 6: Check rp_filter (asymmetry killer)

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

Signification : Le reverse path filtering strict est activé. Si le trafic de retour est asymétrique (commun avec dual‑WAN ou routes multiples),
Linux peut jeter des paquets comme « spoofés ».

Décision : Si vous attendez de l’asymétrie, réglez en mode loose (2) sur les interfaces concernées, ou corrigez la symétrie de routage (préféré).

Task 7: Verify WireGuard peer and AllowedIPs (tunnel up, traffic not)

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: v4bq6nFh1lEoC4QyM2u0n9bZ1gYpP7oGQf+XvYdW2mU=
  listening port: 51820

peer: q0P3sZtVd8l0Rk2m1yG1CwVf1mQf0Qx4lQw2uXn8G3E=
  endpoint: 198.51.100.20:51820
  allowed ips: 172.31.40.0/24
  latest handshake: 18 seconds ago
  transfer: 12.34 KiB received, 9.87 KiB sent

Signification : Le handshake est récent et les compteurs de transfert augmentent. allowed ips inclut 172.31.40.0/24, donc le chiffrement sortant pour ce sous‑réseau devrait avoir lieu.

Décision : Si les compteurs ne changent pas pendant le test, votre trafic ne correspond pas aux AllowedIPs, ou l’hôte route autour de wg0.

Task 8: Confirm routes created for WireGuard (Linux)

cr0x@server:~$ ip route show dev wg0
172.31.40.0/24 proto kernel scope link src 10.99.0.1

Signification : Le kernel a une route vers le sous‑réseau distant via wg0. Si elle manque, vous utilisez peut‑être Table = off ou un design de routage personnalisé.

Décision : Ajoutez la route explicitement, ou ajustez la configuration WireGuard pour qu’elle programme les routes comme prévu.

Task 9: Inspect IPsec SAs and traffic selectors (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
siteA-siteB: #3, ESTABLISHED, IKEv2, 4c2b1b3c3e5b2a6f_i* 6a8d9c0b2a1f4e3d_r
  local  '203.0.113.10' @ siteA
  remote '198.51.100.20' @ siteB
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 241s ago, rekeying in 53m
  siteA-siteB-child: #5, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
    local 10.20.0.0/24
    remote 172.31.40.0/24
    bytes_i 18240, bytes_o 16512, rekeying in 49m

Signification : Le child SA est installé avec les sélecteurs 10.20.0.0/24 ↔ 172.31.40.0/24. Les compteurs d’octets sont non nuls, donc du trafic traverse la SA.

Décision : Si les sélecteurs ne correspondent pas à ce que vous testez, corrigez les traffic selectors locaux/distants. Si les octets restent à 0, les paquets ne correspondent pas ou n’atteignent pas la passerelle.

Task 10: Check if firewall/NAT rules are interfering (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
    iifname "eth0" oifname "vti0" ip saddr 10.20.0.0/24 ip daddr 172.31.40.0/24 accept
    iifname "vti0" oifname "eth0" ip saddr 172.31.40.0/24 ip daddr 10.20.0.0/24 accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth1" masquerade
  }
}

Signification : La politique forward est drop ; seules des règles explicites permettent LAN↔VPN. Le NAT masquerade s’applique à eth1 uniquement (WAN), pas au tunnel.

Décision : Si le NAT s’applique accidentellement au trafic de tunnel (masquerade sur toutes les interfaces), corrigez‑le. Si les règles forward manquent, ajoutez des règles explicites pour les sous‑réseaux VPN.

Task 11: Look for NAT on the VPN path (iptables legacy setups)

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

Signification : Le NAT est seulement sur l’interface WAN eth1. Bien. Si vous voyez MASQUERADE sans -o eth1, vous NATez peut‑être le trafic VPN par erreur.

Décision : Serrez les règles NAT pour que les sous‑réseaux VPN en soient exemptés, ou scopez la masquerade au WAN uniquement.

Task 12: Prove where packets die using tcpdump (on both sides)

cr0x@server:~$ sudo tcpdump -ni eth0 host 172.31.40.10
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.102938 IP 10.20.0.55 > 172.31.40.10: ICMP echo request, id 3812, seq 1, length 64

Signification : La requête atteint l’interface LAN de la passerelle. Capture suivante sur l’interface de tunnel pour voir si elle est transmise/chiffrée.

Décision : Si elle apparaît sur le LAN mais pas sur le tunnel, c’est le routage/politique/pare‑feu sur la passerelle. Si elle apparaît sur le tunnel mais pas sur le LAN distant, c’est la politique du tunnel/MTU/pare‑feu distant.

Task 13: Check tunnel interface counters (route-based VPN)

cr0x@server:~$ ip -s link show dev vti0
7: vti0:  mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    RX:  bytes packets errors dropped  missed   mcast
       82912     612      0      0       0       0
    TX:  bytes packets errors dropped carrier collsns
       74488     581      0      0       0       0

Signification : Des compteurs qui augmentent indiquent que du trafic est envoyé/reçu sur le VTI. Si TX augmente mais RX reste plat, le trafic de retour manque ou est bloqué.

Décision : Si une seule direction bouge, concentrez‑vous sur la route de retour, le pare‑feu distant, les sélecteurs distants, ou le NAT.

Task 14: Diagnose MTU/PMTUD with ping and DF bit

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

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

Signification : Le MTU de votre interface locale (1436) ne peut pas envoyer des paquets de 1428 octets avec DF. C’est attendu si le MTU du tunnel est plus petit à cause de l’encapsulation.

Décision : Bridez le MSS pour TCP, réduisez le MTU sur l’interface de tunnel, ou assurez‑vous que les ICMP « frag needed » ne sont pas bloqués. Si les petits pings fonctionnent mais que TCP bloque, le MTU est probablement en cause.

Task 15: Check MSS clamping status (nftables example)

cr0x@server:~$ sudo nft list chain inet mangle forward
table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    oifname "vti0" tcp flags syn tcp option maxseg size set 1360
  }
}

Signification : Les paquets SYN sortant par le tunnel ont MSS réglé à 1360. Cela empêche TCP d’envoyer des segments trop grands pour le MTU du tunnel.

Décision : Si vous observez des problèmes PMTUD, implémentez le bridage MSS en bordure. Ce n’est pas élégant ; c’est efficace.

Task 16: Trace path and identify “wrong exit” routing

cr0x@server:~$ traceroute -n 172.31.40.10
traceroute to 172.31.40.10 (172.31.40.10), 30 hops max, 60 byte packets
 1  10.20.0.1  0.431 ms  0.382 ms  0.369 ms
 2  203.0.113.1  2.171 ms  2.133 ms  2.114 ms
 3  198.18.0.5  6.990 ms  6.945 ms  6.903 ms

Signification : Ce trafic sort sur le WAN (203.0.113.1) au lieu d’emprunter le tunnel. C’est l’odeur classique de « route manquante ».

Décision : Corrigez le routage pour diriger 172.31.40.0/24 dans le tunnel. Si vous comptez sur BGP, vérifiez que le préfixe est annoncé et accepté.

Task 17: Verify BGP-learned routes and next-hop (FRR)

cr0x@server:~$ sudo vtysh -c "show ip route 172.31.40.0/24"
Routing entry for 172.31.40.0/24
  Known via "bgp", distance 20, metric 0, best
  Last update 00:03:12 ago
  * 10.255.255.2, via vti0

Signification : BGP fournit la route, next hop via vti0. C’est ce que vous souhaitez pour un VPN basé sur les routes avec routage dynamique.

Décision : Si la route est manquante ou pointe ailleurs, examinez l’état de la session BGP, les filtres de route et la reachabilité du next hop.

Task 18: Check conntrack for stateful firewall weirdness

cr0x@server:~$ sudo conntrack -L -p icmp | head
icmp     1 29 src=10.20.0.55 dst=172.31.40.10 type=8 code=0 id=3812 [UNREPLIED] src=172.31.40.10 dst=10.20.0.55 type=0 code=0 id=3812

Signification : La passerelle voit des requêtes echo sortantes mais pas de réponses. Si vous attendez des réponses, elles ne reviennent pas ou sont jetées avant que conntrack ne les voie.

Décision : Capturez côté distant, vérifiez la route de retour et le pare‑feu distant. Si les réponses reviennent sur une interface différente, c’est de l’asymétrie.

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

1) Le tunnel est « actif », mais les compteurs SA restent à zéro

Symptômes : IKE établi ; pings/timeouts ; compteurs immobiles.

Cause racine : Le trafic ne correspond jamais aux sélecteurs/AllowedIPs, ou n’atteint pas la passerelle à cause du routage.

Correction : Vérifiez les routes vers le sous‑réseau distant sur l’hôte source et la passerelle. Pour IPsec basé sur la politique, assurez‑vous que les sous‑réseaux source/destination exacts correspondent au child SA.
Pour WireGuard, assurez‑vous que AllowedIPs inclut la destination et que les routes du kernel pointent vers wg0.

2) Trafic unidirectionnel : A atteint B, B n’atteint pas A (ou les réponses n’arrivent jamais)

Symptômes : SYN TCP vu au distant, SYN‑ACK jamais retourné ; requête ICMP vue, réponse manquante ; VTI TX augmente mais RX plat.

Cause racine : Route de retour manquante sur le LAN/routeur distant ; routage asymétrique lié à des uplinks multiples ; NAT d’un côté modifie l’IP source de façon inattendue.

Correction : Ajoutez/annoncez la route de retour pour le sous‑réseau source via le VPN. Assurez l’exemption NAT pour les sous‑réseaux VPN. Si plusieurs sorties existent, imposez la symétrie via la politique de routage ou le design.

3) Le ping fonctionne, mais HTTPS/SSH bloque ou les gros transferts stagnent

Symptômes : Les petits paquets passent ; les connexions TCP s’établissent mais bloquent au transfert ; certaines applis échouent.

Cause racine : MTU/PMTUD à cause de l’overhead d’encapsulation ; ICMP bloqué ; MSS trop élevé.

Correction : Bridez le MSS TCP sur le trafic entrant dans le tunnel. Réglez le MTU de l’interface de tunnel de façon appropriée. Autorisez les ICMP « Fragmentation Needed » sur les chemins pertinents si votre posture de sécurité le permet.

4) Fonctionne pour un sous‑réseau, échoue pour un autre

Symptômes : Certains hôtes atteignent le distant ; d’autres non ; un VLAN marche, un autre non.

Cause racine : Les sélecteurs/AllowedIPs n’incluent qu’un sous‑réseau ; routes manquantes pour les sous‑réseaux additionnels ; règles pare‑feu trop restrictives.

Correction : Étendez les sélecteurs/AllowedIPs symétriquement sur les deux côtés. Ajoutez routes et règles pare‑feu pour chaque sous‑réseau. Pour IPsec, rappelez‑vous que les deux côtés doivent être d’accord sur les traffic selectors.

5) Le trafic marche jusqu’à une rékey, puis meurt

Symptômes : Stable pendant minutes/heures, puis trou noir soudain après rekey ; le tunnel reste affiché « actif ».

Cause racine : Mismatch de rekey, ré‑affectation NAT, timeouts de pare‑feu stateful, ou différences DPD qui désynchronisent les child SAs.

Correction : Alignez les lifetimes/marges de rekey ; assurez la stabilité NAT‑T ; confirmez les paramètres DPD. Surveillez les événements d’installation/suppression des SA, pas seulement l’état IKE.

6) Pertes aléatoires sous charge, surtout UDP ou VoIP

Symptômes : Jitter, pertes, rafales de pertes ; ping stable mais trafic temps‑réel mauvais.

Cause racine : Pas de QoS à l’intérieur du tunnel ; CPU saturé sur le chiffrement ; mise en file et bufferbloat ; fragmentation des payloads UDP.

Correction : Profilez le CPU et les files d’interface. Shape/markez le trafic avant chiffrement si possible. Réduisez le MTU pour les applications UDP intensives. Envisagez l’offload matériel ou des instances plus puissantes.

7) Tout casse dans une seule direction après un « hardening » de sécurité

Symptômes : Après un changement de durcissement, le trafic VPN meurt ; le trafic local marche.

Cause racine : rp_filter mis strict, changement de politique par défaut du pare‑feu, ou ICMP bloqué globalement.

Correction : Réévaluez rp_filter et les règles de forwarding par rapport au design VPN. Mettez des règles explicites allow pour les sous‑réseaux VPN. Autorisez les ICMP nécessaires pour PMTUD, ou compensez avec un bridage MSS.

8) Réseaux chevauchants : les deux côtés utilisent 10.0.0.0/8

Symptômes : Le trafic va vers des ressources locales au lieu du tunnel ; les routes se battent ; résultats intermittents selon le préfixe le plus long et la politique locale.

Cause racine : Chevauchement d’adressage. Le routage VPN ne peut pas distinguer « leur 10.20.0.0/24 » de « notre 10.20.0.0/24 ».

Correction : Utilisez du NAT (avec précaution) ou renumérotez. Si vous devez NATer, faites‑le de façon cohérente et documentez les plages traduites ; mettez à jour les sélecteurs et les règles pare‑feu en conséquence.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne exploitait un VPN IPsec site‑à‑site « simple » entre le siège et un entrepôt. Le tunnel était actif. L’UI du pare‑feu souriait.
L’équipe de l’entrepôt a essayé d’atteindre une API d’inventaire au siège. Rien. Ils ont escaladé. Naturellement, la première réaction a été de faire tourner les clés et
relancer le débogage IKE, parce que c’est ce que font les gens quand ils sont inquiets.

La mauvaise hypothèse était : « Si le tunnel est actif, le pare‑feu va router le trafic à travers. » La configuration réelle était IPsec basé sur la politique.
Seul le trafic correspondant à une paire spécifique de sous‑réseaux était chiffré. Entre‑temps, la nouvelle API d’inventaire avait été déployée sur un
VLAN différent au siège, avec un sous‑réseau non inclus dans les sélecteurs phase 2.

Les hôtes de l’entrepôt atteignaient l’ancien sous‑réseau sans problème. Personne n’a remarqué parce que la checklist de test était « ping n’importe quel hôte du siège ».
Le nouveau sous‑réseau API ? Pas dans les sélecteurs, donc il a été routé vers la voie par défaut internet et perdu en amont. Les compteurs SA restaient près de zéro,
mais personne ne les regardait car l’UI ne les affichait pas en évidence.

La correction fut ennuyeuse : ajouter le sous‑réseau manquant au domaine de chiffrement local d’un côté et au domaine de chiffrement distant de l’autre,
puis refléter les règles pare‑feu. Après cela, les compteurs ont bougé, l’API a été atteinte, et tout le monde a fait comme si c’était un « problème ISP » pour
des raisons de moral.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une entreprise globale avait plusieurs tunnels site‑à‑site vers un hub central. La latence comptait. Quelqu’un a proposé une optimisation :
augmenter le MTU et laisser PMTUD « faire le boulot ». Le changement a été déployé sur plusieurs passerelles, et cela semblait correct sur des pings synthétiques.
Tout le monde est rentré tôt ce jour‑là.

Deux jours plus tard, une application financière a commencé à timeout uniquement sur les gros téléchargements de rapports. L’authentification fonctionnait.
Les petites pages se chargeaient. Les téléchargements se bloquaient. Le tunnel VPN était actif ; les compteurs bougeaient ; le CPU allait bien. Ça sentait le pire genre de problème : « intermittent ».

Le retour de bâton était classique : PMTUD reposait sur des messages ICMP qui étaient bloqués par une politique de sécurité quelque part entre les sites.
Avec les nouveaux réglages MTU, les paquets encapsulés dépassaient le vrai MTU du chemin. Le réseau ne pouvait pas signifier « fragmentation nécessaire », donc les paquets disparaissaient.
TCP réessayait jusqu’aux timeouts.

La correction : brider le MSS à la sortie du tunnel et réduire le MTU du tunnel à une valeur sûre qui fonctionnait sur tous les chemins.
Ils ont aussi ajusté la politique pare‑feu pour permettre les types ICMP nécessaires au PMTUD — quand c’était possible.
L’« optimisation » a été annulée, et la leçon est restée : le MTU est une vérité partagée, pas une préférence personnelle.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société SaaS exploitait des VPN basés sur les routes depuis leur datacenter principal vers plusieurs partenaires. Ils avaient l’habitude, qui paraissait fastidieuse :
chaque tunnel avait un « contrat » d’une page décrivant les préfixes locaux/distants, la politique NAT, le MTU du tunnel et le next‑hop attendu. Ils conservaient aussi
une recette de capture de paquets « known good » et la vérifiaient trimestriellement.

Un après‑midi, un partenaire a signalé qu’il ne pouvait pas atteindre un sous‑réseau spécifique. Le tunnel était actif. L’équipe partenaire insistait sur le fait que « rien n’a changé ».
L’on‑call SaaS a sorti le doc contrat, puis a fait un rapide lookup de route : le préfixe annoncé par le partenaire avait discrètement été réduit d’un /16 à un /24.
BGP était toujours up, mais l’ensemble de routes n’était pas ce que leurs règles pare‑feu attendaient.

Parce que la pratique était ennuyeusement cohérente, l’on‑call disposait d’une baseline pour comparer. Ils ont pu dire, avec des preuves, « le tunnel est OK,
mais votre côté n’annonce plus l’agrégat ; on apprend seulement ce préfixe plus spécifique. » Cette phrase a coupé court au jeu du blâme.

Ils ont mis en place une route statique temporaire pour la plage manquante (ciblée, limitée dans le temps), pendant que le partenaire corrigeait ses annonces.
Pas d’héroïsme. Pas de devinettes. Juste des attentes documentées et une vérification rapide.

Blague n°2 : BGP, c’est comme la politique de bureau — tout le monde prétend partager l’information, mais il faut quand même vérifier ce qu’ils ont réellement dit.

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

A. Checklist d’incident (15–30 minutes pour isoler)

Choisissez une paire de test : un hôte source et un hôte destination spécifiques, avec des IPs accessibles.
Confirmez le routage local de l’hôte : ip route get <dest> doit pointer vers le routeur/passerelle connaissant le VPN.
Confirmez que la passerelle voit le trafic sur le LAN : capture sur l’interface LAN.
Confirmez que la passerelle route dans le tunnel ou correspond à la politique : ip route get (route‑based) ou compteurs SA/sélecteurs (policy‑based).
Confirmez que les compteurs du tunnel augmentent : compteurs VTI, compteurs SA, compteurs de transfert WireGuard.
Confirmez que le côté distant reçoit le trafic déchiffré : capture sur le LAN distant.
Confirmez le chemin de retour : capture de la réponse quittant le côté distant et assurez‑vous qu’elle retourne dans le tunnel.
Vérifiez les règles pare‑feu dans les deux sens : forward/ACL et exemption NAT.
Vérifiez MTU/MSS seulement ensuite : si TCP bloque ou que les gros paquets échouent.
Documentez le point de défaillance : « meurt avant le tunnel », « meurt dans la politique du tunnel », « meurt après déchiffrement », ou « chemin de retour cassé ».

B. Checklist Build-it-right (avant mise en production)

Choisissez route‑based sauf raison contraire : cela scale mieux et rend le dépannage sensé.
Décidez routage dynamique ou statique : s’il y aura plus de quelques préfixes, préférez BGP avec filtres clairs.
Rédigez des contrats de préfixes : préfixes locaux et distants, y compris les attentes de croissance future.
Définissez la politique NAT explicitement : exemption NAT pour le trafic VPN, et plages traduites si chevauchements.
Fixez MTU/MSS intentionnellement : ne « laissez pas faire ». Mesurez, puis bridez.
Préparez l’asymétrie : une sortie unique est la plus simple ; si ce n’est pas possible, imposez la politique de routage et validez rp_filter.
Surveillez les signaux du plan de données : octets SA, compteurs d’interface VTI, drops de paquets, rekeys — les tableaux de bord doivent montrer le trafic, pas seulement « connecté ».
Créez une suite de tests : ping, connect TCP, requête HTTP, gros transfert, et DNS — exécutez après chaque changement.

C. Checklist de changement (pour ne pas saboter la production)

Avant le changement : capturez la baseline des sélecteurs SA, des routes et des valeurs MTU.
Faites un seul changement à la fois : routage, puis politique, puis pare‑feu, puis MTU.
Après le changement : vérifiez avec la même paire de test et comparez les compteurs avant/après.
Ayez un rollback : conservez les configs précédentes prêtes, et sachez comment rétablir routes et règles pare‑feu.

FAQ

1) Pourquoi le VPN indique « actif » s’il n’y a pas de trafic ?

Parce que « actif » signifie généralement que le plan de contrôle IKE est établi. Le plan de données dépend du routage, des sélecteurs/AllowedIPs, du pare‑feu/NAT, et des chemins de retour.

2) Quelle est la preuve la plus rapide que le routage est le problème ?

Lancez ip route get <remote-host> sur la passerelle. Si cela pointe vers l’interface WAN au lieu du tunnel/VTI, vous avez trouvé le problème.
Aussi, un traceroute montrant des sauts internet au lieu du chemin du tunnel est révélateur.

3) Que sont les « traffic selectors » en IPsec, et comment posent‑ils problème ?

Les traffic selectors définissent quels sous‑réseaux source/destination le child SA va chiffrer. Si votre trafic réel utilise un sous‑réseau non listé dans les sélecteurs,
il ne correspondra pas et ne sera pas chiffré. Résultat : tunnel actif, trafic en échec.

4) WireGuard handshake mais je n’atteins pas le sous‑réseau distant. Quelle est la cause habituelle ?

AllowedIPs mal configurés ou routes kernel manquantes. WireGuard peut handshaker sans aucun routage utile. Vérifiez aussi que le côté distant a une route de retour vers votre sous‑réseau.

5) Comment savoir que le NAT casse mon VPN site‑à‑site ?

Si le côté distant voit du trafic provenant d’une IP source traduite (pas votre sous‑réseau réel), il peut ne pas correspondre aux sélecteurs ou aux règles pare‑feu.
Sur des passerelles Linux, inspectez les règles NAT et confirmez que les sous‑réseaux VPN sont exemptés du masquerade.

6) Pourquoi le ping marche mais TCP échoue ?

Généralement MTU/MSS. L’écho ICMP utilise par défaut des petits paquets ; TCP peut négocier de grands segments qui sont jetés à cause de l’overhead d’encapsulation et du PMTUD bloqué.
Bridez le MSS et réglez le MTU du tunnel de façon conservatrice.

7) Ai‑je besoin de BGP sur le VPN ?

Si vous avez plusieurs préfixes, plusieurs sites, des liens de basculement, ou que vous attendez une croissance, oui — BGP réduit l’erreur humaine. Si c’est vraiment un seul sous‑réseau de chaque côté et que ça ne changera jamais, des routes statiques peuvent suffire.

8) Quelle est la différence entre VPN basé sur la politique et VPN basé sur les routes pour le dépannage ?

Policy‑based : vous déboguez la correspondance des sélecteurs/ACL et les compteurs SA. Route‑based : vous déboguez les routes vers une interface de tunnel. Route‑based est généralement plus facile à raisonner et à faire évoluer.

9) Comment une routage asymétrique peut‑il se produire s’il n’y a qu’un seul tunnel VPN ?

Parce que le reste du réseau peut avoir plusieurs sorties. Le paquet sortant peut prendre le tunnel, tandis que la réponse prend un autre WAN ou un autre routeur ayant une vue différente des routes.
Les pare‑feu stateful et rp_filter détestent ça. Corrigez‑le par le design de routage, pas par l’espoir.

10) Que dois‑je surveiller pour éviter que ça devienne une surprise mensuelle ?

Surveillez les compteurs d’octets SA, les compteurs d’interface VTI, la fréquence de rekey, les drops de paquets et les symptômes liés au MTU (retransmissions TCP).
« Tunnel up » n’est pas une métrique ; c’est un état d’esprit.

Conclusion : prochaines étapes réalisables aujourd’hui

Si vous ne retenez qu’une chose : le fait qu’un tunnel VPN soit actif prouve que les deux points d’extrémité peuvent s’accorder sur le chiffrement. Cela ne prouve pas que vos paquets sont routés, sélectionnés, transférés et renvoyés.
Traitez le VPN comme un chemin réseau avec un plan de contrôle et un plan de données, et déboguez‑le comme n’importe quel autre chemin.

Étapes pratiques :

Créez une paire de test unique (hôte source et destination) et consignez‑la dans votre runbook.
Ajoutez la supervision du plan de données : octets SA et compteurs d’interface de tunnel avec alertes sur « actif mais inactif pendant les heures ouvrées ».
Standardisez sur des designs route‑based quand c’est possible, et documentez les contrats de préfixes et les règles NAT.
Définissez MTU/MSS volontairement, puis testez avec des gros transferts — pas seulement des pings.
Exécutez la procédure de diagnostic rapide la prochaine fois que quelqu’un dit « le VPN est actif mais rien ne fonctionne », et refusez de toucher à la crypto tant que le routage n’est pas prouvé.

“Everything fails, all the time.” — Werner Vogels