L2TP/IPsec connecté mais pas d’internet : pourquoi et comment réparer

Ce que « connecté » signifie vraiment pour L2TP/IPsec

L2TP/IPsec est en fait deux protocoles déguisés :

• IPsec fournit le chiffrement et le transport des paquets, utilise typiquement IKEv1 (souvent affiché « L2TP/IPsec PSK » dans les interfaces clients). Il négocie les clés et établit des SA (Security Associations). Si cela fonctionne, vous pouvez dire honnêtement « le tunnel est établi ».
• L2TP fonctionne à l’intérieur d’IPsec et met en place une session PPP. C’est PPP qui attribue une adresse IP, des serveurs DNS et parfois une route par défaut ou d’autres routes poussées.

Donc « connecté » peut vouloir dire :

1. IKE a réussi ; des SA IPsec existent ; L2TP n’a jamais démarré. L’interface peut néanmoins indiquer le succès selon le client.
2. L2TP est monté ; PPP s’est authentifié ; le client a reçu une IP ; mais les routes n’ont pas changé comme vous le croyez.
3. Les routes ont changé ; les paquets circulent ; mais le NAT/pare-feu sur le serveur bloque le trafic de retour.
4. Tout est « correct » sauf que le DNS pointe vers un résolveur inaccessible via le VPN.
5. Tout semble « correct » jusqu’à ce que le MTU/la fragmentation tue les gros paquets et que la navigation web devienne une danse interprétative.

Règle numéro un : considérez « connecté » comme un indice, pas comme un diagnostic.

Blague n°1 : Un VPN qui dit « connecté » mais qui ne transmet aucun trafic, c’est comme une réunion qui aurait pu être un e‑mail — techniquement tenue, fonctionnellement inutile.

Faits et contexte intéressants (pourquoi cette pile se comporte ainsi)

Un peu de contexte rend les bizarreries moins mystérieuses et les corrections plus prévisibles. Voici quelques faits concrets et historiquement pertinents :

1. L2TP a des racines L2F + PPTP. Il a été standardisé à la fin des années 1990 pour encapsuler PPP sur des réseaux IP. Les hypothèses de PPP fuient encore partout.
2. L2TP n’apporte pas de chiffrement. C’est pourquoi « L2TP/IPsec » est l’association usuelle. L2TP est la couche session ; IPsec est la couche sécurité.
3. La plupart des clients utilisent IKEv1 pour L2TP/IPsec. Les déploiements IPsec modernes préfèrent IKEv2, mais les piles L2TP restent souvent en IKEv1 pour compatibilité.
4. La NAT‑Traversal est devenue la réalité par défaut. IPsec n’aimait pas à l’origine la NAT. NAT‑T encapsule ESP dans UDP/4500 pour survivre aux routeurs grand public.
5. L2TP utilise UDP/1701. Dans L2TP/IPsec, UDP/1701 est généralement protégé par IPsec ; si vous le voyez en clair sur Internet, il s’agit probablement d’une mauvaise configuration.
6. Windows « connecté » ne garantit pas un changement de route par défaut. Selon les paramètres (split tunneling, métriques, « use default gateway on remote network »), votre route internet peut rester locale.
7. Les options PPP comptent toujours. Des éléments comme MRU/MTU, l’attribution DNS et « defaultroute » peuvent faire ou défaire l’utilisabilité.
8. Beaucoup de serveurs L2TP sont construits à partir de composants anciens. Piles Linux courantes : strongSwan/Libreswan + xl2tpd + pppd — chacun ayant ses logs, timers et modes de défaillance.
9. ESP est le protocole IP 50, pas TCP/UDP. Les pare‑feu qui « autorisent IPsec » mais oublient le protocole 50 créent des situations où tout marche à moitié (ou forcent NAT‑T de manière inattendue).

Playbook de diagnostic rapide (vérifier 1, 2, 3)

Si vous êtes d’astreinte, vous n’avez pas le temps de redécouvrir le réseau. Voici le chemin le plus rapide vers le goulet d’étranglement.

1) Est‑ce le routage ou le DNS ?

• Testez la reachabilité IP brute (pinguez une IP publique comme 1.1.1.1 ou votre point de terminaison public d’entreprise).
• Testez le DNS séparément (résolvez un nom en utilisant les serveurs DNS que vous pensez avoir).

Si l’IP fonctionne et que le DNS ne fonctionne pas : ne touchez plus à IPsec. Corrigez l’attribution du DNS ou la reachabilité.

2) Le trafic quitte‑t‑il le client via le tunnel ?

• Inspectez la table de routage sur le client. Cherchez une route par défaut via l’interface PPP/tunnel (full tunnel) ou des routes spécifiques (split tunnel).
• Vérifiez les métriques d’interface : « bonne route, mauvaise priorité » est un classique.

3) Le trafic revient‑il ?

• Sur le serveur, capturez les paquets sur l’interface VPN et sur la liaison montante. Si vous voyez des paquets venant des clients sortir mais pas de traduction de retour, c’est NAT/pare‑feu.
• Vérifiez le forwarding IP et les règles NAT/MASQUERADE.

4) Ça plante seulement pour certains sites ou transferts larges ?

• C’est MTU/fragmentation jusqu’à preuve du contraire. Testez avec des ping « ne pas fragmenter » et clamp MSS.

5) C’est intermittent ?

• Vérifiez les timeouts des états UDP/NAT, les problèmes de rekeying, ou plusieurs clients derrière une même NAT avec des identifiants identiques.

Les vrais modes de défaillance : routage, NAT, DNS, MTU, pare‑feu et stratégie

Mode de défaillance A : Le client n’envoie jamais le trafic Internet dans le tunnel (routage/métriques)

L2TP/IPsec est souvent déployé en « full tunnel » (tout le trafic passe par le VPN), mais les clients sont fréquemment configurés en split tunnel par accident — ou par une vieille « optimisation » non documentée.

Schémas communs :

• La route par défaut pointe toujours vers la passerelle locale, pas vers PPP.
• Une route par défaut existe via le VPN, mais a une métrique plus élevée que la route locale.
• Seuls des sous‑réseaux d’entreprise sont routés dans le tunnel ; l’internet reste local. Les utilisateurs interprètent cela comme « pas d’internet » parce que le DNS d’entreprise force des chemins de résolution internes.

Décision : déterminez si vous voulez du split tunnel ou du full tunnel. Ensuite adaptez la table de routage à cette intention.

Mode de défaillance B : Le trafic entre dans le tunnel mais meurt sur le serveur (forwarding, NAT ou pare‑feu manquants)

Ceci est la cause la plus fréquente de « connecté mais pas d’internet » sur des concentrateurs L2TP Linux. La session PPP est active. Le client a une IP. Les paquets arrivent. Puis le serveur hausse les épaules et les jette parce que :

• net.ipv4.ip_forward est désactivé.
• La masquerade NAT n’est pas définie pour le pool clients VPN vers la liaison montante.
• Les règles de pare‑feu autorisent IKE/ESP/L2TP mais bloquent le forwarding.
• Le filtrage de chemin inverse (rp_filter) écarte les flux asymétriques.

Décision : décidez si ce VPN est un chemin de sortie vers Internet. Si oui, activez le forwarding et le NAT. Si non, ne faites pas semblant — poussez des routes en split tunnel et corrigez le DNS.

Mode de défaillance C : DNS incorrect (et tout semble « en panne »)

L’« internet » via VPN est souvent juste du DNS. Le navigateur a besoin du DNS pour transformer les noms en IP. Si PPP pousse des serveurs DNS qui ne sont accessibles que sur un réseau interne que vous n’avez pas routé, vous obtenez :

• Le ping vers 1.1.1.1 fonctionne.
• Le ping vers example.com échoue.
• Les applications qui codent des IP en dur fonctionnent ; tout le reste non.

Décision : alignez le DNS sur le routage. Le full tunnel peut utiliser des résolveurs internes ; le split tunnel doit utiliser des résolveurs accessibles (publics ou un forwarder DNS atteignable via les routes du split).

Mode de défaillance D : MTU et fragmentation (le classique « certains sites chargent, d’autres non »)

L2TP + IPsec ajoute de l’overhead. Ensuite NAT‑T ajoute encore. Ensuite PPP ajoute le sien. Si votre path MTU est serré (fréquent avec PPPoE, LTE, Wi‑Fi d’hôtel ou des middleboxes « aidants »), les gros paquets sont mis dans un trou noir.

Les symptômes incluent :

• SSH fonctionne, les pages web se chargent à moitié, les handshakes TLS échouent de façon intermittente.
• Les petits pings réussissent ; les plus grands échouent quand DF est activé.
• Les tests de débit démarrent puis s’effondrent.

Correction : clamperez le MSS TCP sur le serveur (et parfois sur les clients) et/ou réglez MTU/MRU PPP sur une valeur conservative (souvent autour de 1400, mais vérifiez).

Mode de défaillance E : Pare‑feu et cas limites NAT‑T (UDP 4500, ESP et « état »)

IPsec est sensible aux pare‑feu presque correctement configurés. Autoriser UDP/500 et UDP/4500 mais pas ESP (protocole 50) peut forcer NAT‑T ou casser les chemins non NATés. Certains environnements bloquent UDP/4500. D’autres l’autorisent mais suppriment les mappings UDP inactifs de longue durée, causant des « connexions qui fonctionnent puis plus de trafic après quelques minutes ».

Décision : décidez si vous exigez NAT‑T et assurez‑vous que keepalives/rekey timers correspondent aux timeouts NAT réels.

Mode de défaillance F : Sous‑réseaux qui se chevauchent (vous vous êtes routé dans un paradoxe)

Si le LAN local du client utilise le même sous‑réseau que le réseau d’entreprise (ex : les deux sont 192.168.1.0/24), le client enverra le trafic sur le LAN local au lieu du tunnel. Le VPN peut être parfait ; la décision de routage ne l’est pas.

Correction : évitez, si possible, les plages RFC1918 courantes pour les réseaux d’entreprise. Si vous ne pouvez pas, utilisez du routing basé sur la stratégie, attribuez des pools non chevauchants, ou NATez côté client VPN (dernier recours, mais parfois la seule solution à l’échelle).

Blague n°2 : Les sous‑réseaux qui se chevauchent, c’est comme appeler deux collègues « Chris » puis blâmer le système de mail quand le mauvais répond.

Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, quelles décisions prendre

Ci‑dessous des tâches testées sur le terrain que vous pouvez exécuter pendant l’incident. Les commandes sont centrées Linux côté serveur (strongSwan/xl2tpd/pppd), mais la logique se transpose à d’autres plateformes.

Chaque tâche inclut : commande, sortie réaliste, ce que ça signifie, et la décision à prendre.

Task 1: Confirm IPsec SAs exist (server)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.5.0, x86_64):
  uptime: 2 hours, since Dec 27 08:12:41 2025
  worker threads: 16 of 16 idle
Connections:
    l2tp-psk:  %any...%any  IKEv1
Security Associations (1 up, 0 connecting):
    l2tp-psk[3]: ESTABLISHED 6 minutes ago, 203.0.113.44[203.0.113.44]...198.51.100.10[198.51.100.10]
    l2tp-psk{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c2a3d8c4_i c8a1aa9b_o

Signification : IPsec est monté. Si les utilisateurs n’ont toujours pas d’internet, le problème est probablement PPP/routage/NAT/DNS/MTU, pas la négociation IKE.

Décision : Passez à la vérification de la session PPP et du forwarding. Ne perdez pas de temps à faire pivoter les PSK « au cas où ».

Task 2: Verify xl2tpd is accepting sessions (server)

cr0x@server:~$ sudo journalctl -u xl2tpd -n 30 --no-pager
Dec 27 10:01:12 server xl2tpd[1290]: Connection established to 203.0.113.44, 1701, LNS session 4087
Dec 27 10:01:12 server xl2tpd[1290]: Call established with 203.0.113.44, Local: 53291, Remote: 22714, Serial: 1
Dec 27 10:01:13 server pppd[24410]: pppd 2.4.9 started by root, uid 0
Dec 27 10:01:13 server pppd[24410]: peer from calling number 203.0.113.44 authorized
Dec 27 10:01:13 server pppd[24410]: local  IP address 10.10.50.1
Dec 27 10:01:13 server pppd[24410]: remote IP address 10.10.50.101
Dec 27 10:01:13 server pppd[24410]: primary   DNS address 10.10.0.53

Signification : PPP est monté et un client a obtenu 10.10.50.101 avec DNS 10.10.0.53. Bien. Vérifiez maintenant les routes et la reachabilité vers 10.10.0.53 (et Internet) depuis le serveur.

Décision : Si le DNS est interne (10.10.0.53), assurez‑vous que le client peut router vers 10.10.0.0/16 via le VPN ou en full tunnel.

Task 3: Confirm the PPP interface exists and has addresses (server)

cr0x@server:~$ ip -br addr show | egrep 'ppp|eth0|ens'
ens3             UP             198.51.100.10/24
ppp0             UP             10.10.50.1/32

Signification : ppp0 est UP avec un /32 local. C’est normal pour PPP. Les clients sont de l’autre côté avec leurs propres /32.

Décision : Assurez‑vous d’avoir une route vers le pool client via les interfaces ppp ou que vos règles de pare‑feu correspondent à ppp+. Beaucoup de gens écrivent par erreur des règles pour « 10.10.50.0/24 via ppp0 » puis s’étonnent du bazar.

Task 4: Check IP forwarding (server)

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

Signification : Le serveur ne forwarde pas les paquets entre interfaces. Les clients VPN se connectent, mais n’atteignent rien au‑delà du serveur.

Décision : Activez‑le immédiatement et de façon persistante si cet hôte est destiné à router.

Task 5: Enable IP forwarding (server)

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

Signification : Forwarding activé maintenant. Il vous faut encore la correction pare‑feu/NAT.

Décision : Si cela résout le problème, rendez‑le persistant via /etc/sysctl.d/*.conf et continuez à lire : le forwarding sans règles de pare‑feu est source de surprises.

Task 6: Check NAT (MASQUERADE) for the VPN client pool (server)

cr0x@server:~$ sudo iptables -t nat -S | egrep 'MASQUERADE|10\.10\.50'
-A POSTROUTING -s 10.10.50.0/24 -o ens3 -j MASQUERADE

Signification : Le NAT sortant existe pour le pool client 10.10.50.0/24 vers ens3 (liaison montante). C’est généralement requis pour que « le VPN fournisse l’accès Internet ».

Décision : Si cette ligne manque, ajoutez‑la. Si elle est présente mais le trafic échoue encore, regardez les règles filter et rp_filter.

Task 7: Check FORWARD policy and counters (server)

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i ppp+ -o ens3 -j ACCEPT
-A FORWARD -i ens3 -o ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT

Signification : Politique FORWARD par défaut DROP (bon choix). Vous autorisez ppp→internet et le retour. Aussi correct.

Décision : Si vous avez DROP sans ces acceptations, ajoutez‑les. Si elles existent mais que le trafic ne passe pas, vérifiez que les noms d’interfaces correspondent à la réalité (ppp+ aide) et que nftables ne contrôle pas réellement le trafic.

Task 8: Identify whether nftables is the real firewall (server)

cr0x@server:~$ sudo nft list ruleset | head -n 25
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    udp dport {500, 4500, 1701} accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    iifname "ppp0" oifname "ens3" accept
    iifname "ens3" oifname "ppp0" ct state established,related accept
  }
}

Signification : nftables est actif et a des règles spécifiques pour ppp0 uniquement. Si des clients arrivent sur ppp1/ppp2, le forwarding peut échouer.

Décision : Remplacez les correspondances ppp0 par un style générique (iifname « ppp+ ») ou utilisez des sets. Sinon, le premier client fonctionne et le second vous appelle à 2 h du matin.

Task 9: Validate the server can reach the internet (server)

cr0x@server:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=12.1 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Signification : Le concentrateur a une connectivité basique. Si les clients VPN n’en bénéficient pas, ce n’est pas « Internet en panne ».

Décision : Concentrez‑vous sur le forwarding/NAT/sélection de route pour le trafic client.

Task 10: Observe whether client packets traverse the server (tcpdump)

cr0x@server:~$ sudo tcpdump -ni ppp0 icmp or udp port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type PPP, snapshot length 262144 bytes
10:04:21.112233 IP 10.10.50.101 > 1.1.1.1: ICMP echo request, id 4112, seq 1, length 64
10:04:22.114455 IP 10.10.50.101 > 1.1.1.1: ICMP echo request, id 4112, seq 2, length 64

Signification : Le client envoie du trafic via le tunnel vers le serveur. Si vous ne voyez pas de réponses, le problème est le chemin de retour : NAT, pare‑feu ou routage amont.

Décision : Capturez sur ens3 ensuite pour voir si les requêtes sortent et si les réponses reviennent.

Task 11: Confirm NAT translation occurs (server, capture on uplink)

cr0x@server:~$ sudo tcpdump -ni ens3 icmp and host 1.1.1.1
listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:04:21.112900 IP 198.51.100.10 > 1.1.1.1: ICMP echo request, id 4112, seq 1, length 64
10:04:21.125001 IP 1.1.1.1 > 198.51.100.10: ICMP echo reply, id 4112, seq 1, length 64

Signification : Le NAT fonctionne : la source du paquet est l’IP publique du serveur (198.51.100.10), et les réponses reviennent. Si les clients ne reçoivent pas encore les réponses, votre chaîne forward vers PPP peut bloquer, ou rp_filter peut les supprimer.

Décision : Vérifiez les règles de forwarding et rp_filter, puis vérifiez si les réponses atteignent ppp0.

Task 12: Check reverse path filtering (rp_filter) (server)

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

Signification : Un rp_filter strict peut supprimer des paquets quand le noyau juge que le chemin de retour est « incorrect », ce qui arrive avec des tunnels, du NAT, du policy routing, ou du routage asymétrique.

Décision : Mettez rp_filter à 0 (off) ou 2 (loose) sur les interfaces concernées. Pour des concentrateurs VPN, le mode loose est souvent un compromis sensé.

Task 13: Test DNS resolution via the pushed DNS server (server-side sanity check)

cr0x@server:~$ dig @10.10.0.53 example.com +short
93.184.216.34

Signification : Le résolveur interne répond. Cela ne prouve pas que le client peut y accéder, mais ça enlève une variable.

Décision : Si le DNS résout ici mais pas pour les clients, c’est du routage/pare‑feu entre le pool VPN et le réseau DNS, ou le client n’utilise pas réellement ce DNS.

Task 14: Check that PPP is pushing the intended DNS and routes (server config)

cr0x@server:~$ sudo sed -n '1,120p' /etc/ppp/options.xl2tpd
ipcp-accept-local
ipcp-accept-remote
ms-dns 10.10.0.53
ms-dns 10.10.0.54
noccp
auth
mtu 1400
mru 1400
proxyarp

Signification : Le DNS est poussé et le MTU est réglé. Si les utilisateurs rapportent « certains sites se chargent », le MTU ici est un bon indice. Si le MTU est par défaut (souvent 1500), vous devrez peut‑être l’ajuster.

Décision : Si vous ne contrôlez pas MTU/MRU ici, prévoyez de l’ajouter et clamperez le MSS au pare‑feu.

Task 15: Detect MTU blackhole with DF ping (from server toward a client path)

cr0x@server:~$ ping -M do -s 1472 -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1476
ping: local error: message too long, mtu=1476

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1024ms

Signification : Le path MTU est inférieur à 1500 (ici il suggère ~1476 à ce saut), et si les messages ICMP « fragmentation‑needed » sont bloqués quelque part, les clients vivront des échecs « aléatoires ».

Décision : Clamperez le MSS (par ex. 1360–1410 selon l’overhead) et/ou réglez MTU/MRU PPP plus bas. Vérifiez itérativement.

Task 16: Clamp TCP MSS for forwarded VPN traffic (server)

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

Signification : Les paquets SYN négocieront un MSS adapté au PMTU réel, réduisant les problèmes de fragmentation.

Décision : Si cela améliore immédiatement la fiabilité web/TLS, conservez‑le et rendez‑le persistant. Validez toujours que PMTUD (ICMP) n’est pas bloqué en amont.

Task 17: Verify client pool routes exist (server routing)

cr0x@server:~$ ip route show | egrep '10\.10\.50|default'
default via 198.51.100.1 dev ens3
10.10.50.101 dev ppp0 scope link

Signification : Pour PPP, les routes sont souvent des /32 par client. Si vous attendiez un /24, c’est votre mauvaise attente, pas le noyau.

Décision : Assurez‑vous que les règles de pare‑feu et la supervision tiennent compte de cela. Utilisez des correspondances d’interface ppp+ plutôt que de compter sur une belle route en /24.

Task 18: Confirm UDP/4500 and ESP are allowed on the perimeter (server)

cr0x@server:~$ sudo iptables -S INPUT | egrep 'udp.*(500|4500|1701)|esp'
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j ACCEPT
-A INPUT -p esp -j ACCEPT

Signification : Les ports communs et ESP sont autorisés. Si ESP manque et que NAT‑T n’est pas utilisé, vous aurez des « connexions parfois » selon les conditions NAT des clients.

Décision : Autorisez ESP quand c’est faisable. Sinon, imposez NAT‑T et assurez‑vous que 4500 est fiable bout‑en‑bout.

Trois mini‑récits d’entreprise venus du terrain

Mini‑récit 1 : Incident causé par une mauvaise hypothèse

L’entreprise avait un concentrateur L2TP/IPsec legacy qui « fonctionnait toujours ». Une petite migration l’a déplacé d’un hôte VM à un autre. Même IP. Mêmes règles de pare‑feu. Mêmes fichiers de configuration. La demande de changement était ennuyeuse, ce qui est généralement bon signe.

Lundi matin, le helpdesk a reçu un flot d’appels : VPN connecté, mais « internet mort ». Les gens pouvaient atteindre certains services internes mais pas d’autres, et la plupart des sites externes étaient inaccessibles. L’équipe réseau a immédiatement accusé le FAI en amont parce que tout le monde blâme cela quand le navigateur tourne en boucle.

La mauvaise hypothèse : « Si le tunnel est monté, le routage est correct. » En réalité, le nouveau hyperviseur utilisait un nom d’interface différent (ens192 au lieu de ens3). Les règles NAT faisaient encore référence à l’ancien device. Les paquets arrivaient sur ppp0, atteignaient POSTROUTING, et… rien ne correspondait. Pas de masquerade. Pas d’internet.

Cela s’est aggravé : quelques ingénieurs pouvaient atteindre des services internes parce que les routes en split tunnel fonctionnaient encore pour certains sous‑réseaux, donc les symptômes semblaient incohérents. Cette incohérence a fait perdre des heures. Ils cherchaient un réseau instable alors que le problème était une discordance déterministe.

La correction fut brutalement simple : changer la règle NAT pour correspondre au vrai nom d’interface uplink (ou mieux, matcher par table de routage / utiliser des sets nftables). Ensuite ils ont ajouté une vérification au démarrage qui affirme « si ppp+ existe, la règle NAT doit exister ». La leçon : ne jamais baser un comportement critique de routage/NAT sur un nom d’interface que vous ne contrôlez pas.

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

Une revue sécurité a signalé que les utilisateurs VPN faisaient du hairpinning de tout le trafic internet via le datacenter. Quelqu’un a proposé le split tunneling comme optimisation : « Routez seulement les sous‑réseaux d’entreprise via le VPN ; laissez le reste local. Moins de charge, meilleures performances. » Sur le papier, correct. En production, comédie.

Ils ont poussé des routes en split tunnel sans aligner le DNS. PPP continuait de pousser des résolveurs DNS internes parce que « c’est ce qu’on a toujours fait ». Maintenant, les laptops distants résolvaient des domaines publics via des résolveurs internes uniquement atteignables via le VPN, mais les requêtes allaient dans le tunnel tandis que les réponses revenaient par l’interface locale — ou ne revenaient pas du tout à cause du stateful firewalling et du routage asymétrique côté client.

Le symptôme était bruyant : « VPN connecté, pas d’internet ». La réalité était plus limitée : pas de résolution DNS, accès interne intermittent, et certaines applis (IP en dur) fonctionnaient encore. Les utilisateurs ne rapportent pas « échec de résolution DNS » ; ils disent « rien ne marche ». Juste.

Ils l’ont « réparé » temporairement en demandant aux utilisateurs de forcer des DNS publics. Cela a créé un autre souci : les noms internes ne se résolvaient plus, et la sécurité n’était pas contente des requêtes internes fuitées. Ils ont fini par faire la chose ennuyeuse mais correcte : fournir un forwarder DNS accessible via le VPN qui répond aux zones internes et récursive pour l’externe, et s’assurer que les requêtes DNS suivent la même politique de routage que le reste.

L’optimisation va bien. Mais le split tunneling est un changement de politique de routage, pas une mise à niveau CPU. Traitez‑le avec la même prudence que le changement d’isolation d’une base de données : vous découvrirez les cas limites à la dure.

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

Une autre organisation exploitait L2TP/IPsec pour une flotte d’ordinateurs industriels. Peu glamour. Mais l’équipe SRE avait l’habitude suivante : chaque changement VPN exigeait un test smoke scripté depuis un runner externe. Il faisait : connecter, vérifier l’IP assignée, pinguer une IP publique, résoudre un nom, récupérer une petite page HTTPS, et télécharger un fichier plus gros pour tester MTU/MSS.

Un vendredi, une opération de nettoyage des politiques de pare‑feu a supprimé des « règles legacy étranges ». Le pipeline de déploiement a exécuté le test smoke et a échoué à « récupérer la page HTTPS ». Le ping fonctionnait. Le DNS fonctionnait. HTTP fonctionnait parfois. HTTPS échouait. C’est le moment où la plupart des équipes commencent à redémarrer des services au hasard. Pas eux.

Le script incluait une sonde MTU et a signalé une défaillance de fragmentation. Le nettoyage du pare‑feu avait aussi supprimé l’autorisation ICMP « fragmentation‑needed » et une règle de clamp MSS. Sans clamp MSS, les paquets TLS étaient mis dans un trou noir sur certains chemins. Le test l’a détecté avant les humains.

Rollback immédiat. Ils ont réintroduit une règle MSS clamp contrôlée, documenté pourquoi elle existait, et ajouté un test unitaire pare‑feu : « les clients VPN doivent compléter le handshake TLS vers un endpoint public ». Ennuyant. Correct. Sauvé le weekend.

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

Cette section est opinionnée parce que la production a besoin d’opinions. Ce sont les schémas qui génèrent des tickets « connecté mais pas d’internet ».

1) Symptom : « Connecté » mais impossible de pinger n’importe quelle IP (même 1.1.1.1)

• Cause racine : Le trafic client n’est pas routé dans le tunnel ; ou la session PPP ne transporte pas réellement les données ; ou le serveur refuse le forwarding.
• Fix : Côté client, vérifiez la route par défaut et les métriques d’interface. Côté serveur, activez IP forwarding et autorisez le trafic FORWARD de ppp+ vers l’uplink, avec NAT si l’e‑gress Internet est prévu.

2) Symptom : Peut pinger des IP publiques mais les sites web ne chargent pas

• Cause racine : Mauvaise configuration DNS (serveurs DNS inaccessibles ou client n’utilise pas les DNS poussés).
• Fix : Poussez des DNS atteignables via les options PPP (ms-dns). Assurez‑vous que le routage permet l’accès à ces résolveurs. Pour le split tunnel, utilisez un forwarder DNS accessible via le tunnel.

3) Symptom : Seuls certains sites chargent ; HTTPS est instable ; gros téléchargements échouent

• Cause racine : MTU blackhole ou problèmes de fragmentation dus à l’overhead L2TP/IPsec et au blocage ICMP.
• Fix : Clamp MSS TCP sur le serveur pour le trafic VPN forwardé. Réglez MTU/MRU PPP (ex. 1400) et retestez. Autorisez les types ICMP nécessaires si vous maîtrisez les pare‑feu.

4) Symptom : Ressources internes fonctionnent ; internet non

• Cause racine : Split tunnel par conception ou accident ; NAT manquant pour l’e‑gress internet ; ou la politique interdit l’internet via VPN.
• Fix : Décidez de la politique. Si full tunnel est requis, poussez la route par défaut (paramètre client) et configurez NAT/forwarding. Si split tunnel est souhaité, poussez uniquement les préfixes internes et fournissez un DNS cohérent.

5) Symptom : Internet fonctionne, mais seulement pour le premier client connecté

• Cause racine : Règles de pare‑feu qui matchent une seule interface (ppp0) au lieu de toutes les interfaces PPP (ppp+), ou NAT lié à une interface spécifique qui change.
• Fix : Utilisez les wildcards ppp+ (iptables) ou des correspondances iifname/oifname (nftables). Évitez les hypothèses fragiles sur les noms d’interfaces.

6) Symptom : Connexion réussit sur certains réseaux mais pas d’autres (Wi‑Fi d’hôtel, LTE)

• Cause racine : UDP 4500 bloqué ou timeout agressif ; problèmes NAT‑T ; équipements intermédiaires qui altèrent ESP/UDP.
• Fix : Assurez‑vous que NAT‑T est activé et que les keepalives sont configurés. Si UDP est peu fiable, envisagez de migrer hors de L2TP/IPsec vers IKEv2 ou un VPN basé sur TLS quand c’est possible.

7) Symptom : « Connecté » mais impossible d’accéder à un sous‑réseau d’entreprise qui chevauche le réseau domicile

• Cause racine : Chevauchement d’adressage RFC1918 ; les routes client préfèrent le LAN local.
• Fix : Changez l’adressage d’entreprise (idéal), ou NATez les sous‑réseaux clients VPN sur le concentrateur, ou utilisez du policy routing par client. Au minimum, évitez 192.168.0.0/24 ou 192.168.1.0/24 pour des réseaux auxquels des clients itinérants doivent accéder.

8) Symptom : Ça marchait hier ; aujourd’hui ça se connecte mais plus de trafic après un changement de pare‑feu

• Cause racine : Autorisé IKE/L2TP mais bloqué le forwarding, le DNS, l’ICMP fragmentation‑needed ou le trafic de retour en état.
• Fix : Auditez les règles pour : UDP/500, UDP/4500, UDP/1701 (si besoin), ESP, plus FORWARD et NAT. Restaurez le clamp MSS et l’ICMP requis si des problèmes MTU apparaissent.

Checklists / plan étape par étape

Checklist 1 : Décidez de la politique (full tunnel vs split tunnel)

• Full tunnel : La route par défaut client passe par le VPN. Vous devez NATer et forwarder sur le serveur. Le DNS peut être interne.
• Split tunnel : Seuls les préfixes d’entreprise passent par le VPN. Vous devez pousser ces routes. Le DNS ne doit pas créer de dépendance à des résolveurs internes inaccessibles (utilisez un forwarder accessible via le tunnel).

Si vous ne prenez pas cette décision explicitement, votre système la prendra implicitement, et il choisira le chaos.

Checklist 2 : Essentiels côté serveur (concentrateur Linux L2TP/IPsec)

1. SA IPsec établies (strongSwan/libreswan status montre INSTALLED).
2. xl2tpd voit les sessions ; pppd authentifie ; attribue des IP clients ; pousse DNS si souhaité.
3. net.ipv4.ip_forward=1.
4. Masquerade NAT pour le pool client vers l’uplink (si full tunnel/e‑gress Internet).
5. FORWARD du pare‑feu autorise ppp+ vers l’uplink et le retour ESTABLISHED.
6. Clamp MSS pour les SYN TCP forwardés, ou MTU/MRU PPP conservative.
7. rp_filter en mode loose/off si nécessaire.
8. Logs : strongSwan, xl2tpd, pppd collectés et consultables.

Checklist 3 : Essentiels côté client (générique)

1. Confirmez que vous avez une IP sur l’interface VPN et une configuration DNS comprise.
2. Vérifiez la table de routage : avez‑vous une route par défaut via le VPN (full tunnel) ou des routes spécifiques (split tunnel) ?
3. Testez : ping IP publique, résolution nom, curl sur un endpoint HTTPS.
4. Si seul HTTPS échoue : suspectez MTU/MSS et des trous noirs de fragmentation.
5. Si les ressources d’entreprise échouent depuis le domicile : suspectez des sous‑réseaux qui se chevauchent.

Plan de récupération étape par étape pendant une panne

1. Confirmez l’étendue. Un utilisateur vs tout le monde ; réseaux spécifiques vs tous ; OS clients spécifiques vs tous.
2. Prouvez qu’IPsec est monté. Si IPsec n’est pas monté, corrigez IKE/PSK/certs/ports d’abord. Si c’est monté, arrêtez de blâmer IKE.
3. Prouvez que PPP est monté. Cherchez l’IP client et le DNS assigné dans les logs pppd.
4. Prouvez l’intention de routage. Full tunnel ou split tunnel ? Vérifiez que les routes clients correspondent à la politique.
5. Prouvez le forwarding/NAT serveur. tcpdump sur ppp+ et uplink ; vérifiez MASQUERADE et les règles FORWARD.
6. Prouvez le DNS. Résolvez via le serveur DNS poussé ; confirmez la reachabilité à travers les routes.
7. Prouvez le MTU. Si les symptômes sont « certains sites », activez le clamp MSS et réglez MTU/MRU PPP.
8. Stabilisez. Rendez les changements persistants, ajoutez de la supervision, et consignez ce que vous avez modifié et pourquoi.

Principe opérationnel (une citation)

« L’espoir n’est pas une stratégie. » — idée paraphrasée attribuée aux leaders opérations et fiabilité

Traduction : si votre VPN fonctionne uniquement quand « le réseau est gentil », il ne fonctionne pas. Rendez‑le déterministe.

FAQ

1) Pourquoi L2TP/IPsec indique « connecté » alors que rien ne fonctionne ?

Parce que « connecté » signifie souvent que IKE a réussi et que des SA sont installées. L’utilisabilité réelle dépend de PPP, routage, NAT, pare‑feu, DNS et MTU. Différentes couches peuvent réussir indépendamment.

2) Est‑ce généralement un problème côté client ou côté serveur ?

La plupart du temps c’est côté serveur : forwarding/NAT/pare‑feu, ou un décalage de politique (split vs full tunnel). Les métriques de routage côté client et la sélection du DNS sont les suivants les plus fréquents.

3) Si les ressources internes fonctionnent mais pas Internet, quelle est la cause la plus probable ?

Soit le split tunnel est actif (par conception ou accident), soit la masquerade NAT pour le pool client VPN manque. Décidez si le VPN doit fournir la sortie Internet. Mettez‑le en place explicitement ensuite.

4) Si le ping vers 1.1.1.1 fonctionne mais les sites web ne fonctionnent pas, que faire en premier ?

Vérifiez le DNS. Confirmez quels résolveurs le client utilise et si ces résolveurs sont atteignables via les routes du VPN. Les problèmes DNS sont l’illusion la plus rapide de « tout est en panne ».

5) Quel MTU utiliser pour L2TP/IPsec ?

Il n’y a pas de valeur universelle, mais 1400 est un point de départ courant pour MTU/MRU PPP en L2TP/IPsec avec NAT‑T. Mieux : clamperez le MSS sur le PMTU et validez avec des pings DF et des transferts HTTPS réels.

6) Dois‑je autoriser UDP/1701 via le pare‑feu ?

Pour L2TP/IPsec, UDP/1701 est utilisé pour le contrôle/données L2TP et est généralement protégé par IPsec. Pratiquement, vous autorisez souvent UDP/1701 vers le serveur VPN, plus UDP/500, UDP/4500 et ESP. Votre jeu de règles exact dépend du mode IPsec et de l’utilisation de NAT‑T.

7) Et les clients derrière la même NAT ? Cela peut‑il casser des choses ?

Oui. Plusieurs clients derrière une même NAT peuvent déclencher des cas limites NAT‑T, surtout avec IKEv1 et des identifiants identiques. Assurez‑vous que votre configuration IPsec supporte plusieurs peers et utilise des identifiants/nom d’utilisateur uniques, et ajustez les keepalives pour que les mappings UDP ne expirent pas.

8) Le chevauchement des sous‑réseaux peut‑il vraiment causer « pas d’internet » ?

Oui, indirectement. Si le DNS ou des proxys passent par un sous‑réseau d’entreprise qui chevauche un LAN domestique, le client enverra le trafic localement et cela échouera. Les utilisateurs interprètent cela comme « internet en panne » parce que navigateurs et apps dépendent de ces services internes.

9) Devons‑nous continuer d’utiliser L2TP/IPsec ?

Si vous avez besoin d’une compatibilité maximale avec les clients intégrés, vous continueriez à le voir. Si vous pouvez choisir, préférez IKEv2 ou un VPN moderne basé sur TLS, qui gère mieux la NAT et propose des outils clients plus propres. Mais si vous êtes coincé avec L2TP/IPsec, vous pouvez le rendre fiable — en étant explicite sur le routage, le DNS et le MTU.

10) Quel est le contrôle de supervision le plus efficace pour cela ?

Lancez un test synthétique externe qui établit une session VPN puis réalise : ping IP public, requête DNS, GET HTTPS d’une petite page plus un téléchargement plus important. Cela détecte rapidement régressions de routage, DNS et MTU.

Prochaines étapes (quoi changer pour ne pas revivre ça)

Résoudre l’incident d’aujourd’hui, c’est bien. Prévenir le prochain, c’est mieux, et honnêtement moins éprouvant.

1. Écrivez votre intention. Full tunnel ou split tunnel. Quel DNS. Quel pool client. Quels sous‑réseaux. Faites‑en un runbook d’une page qui reflète la réalité.
2. Rendez le forwarding/NAT déterministe. Activez ip_forward de façon persistante, utilisez des wildcards d’interface ou du matching basé sur la table de routage, et versionnez vos règles de pare‑feu.
3. Standardisez la gestion du MTU. Ajoutez un clamp MSS pour le trafic forwardé et réglez MTU/MRU PPP intentionnellement. Considérez les échecs PMTUD comme un risque connu.
4. Cessez de déboguer par le statut UI. Supervisez séparément les SA IPsec, les sessions PPP et les tests synthétiques end‑to‑end du plan de données.
5. Ajoutez un test smoke. Un script externe qui valide la connectivité comme l’expérimente un utilisateur. Exécutez‑le après chaque changement.
6. Planifiez une migration. Si L2TP/IPsec est une ancre legacy, définissez une trajectoire vers IKEv2 ou une solution moderne. Pas parce que c’est tendance — parce que la simplicité opérationnelle est une fonctionnalité.

Si vous ne faites qu’une chose : ajoutez des captures de paquets et un test synthétique VPN à votre workflow d’incident. « Connecté mais pas d’internet » cesse d’être un mystère et devient une case de checklist.