Réglage MTU VPN : pourquoi les gros fichiers se bloquent alors que le web fonctionne (et comment choisir le bon MTU)

Modèle mental : pourquoi « le web fonctionne » mais les gros fichiers non

MTU (Maximum Transmission Unit) est la plus grande charge utile de paquet IP que votre interface accepte d’envoyer sans fragmentation.
Le MTU classique d’Ethernet est 1500 octets. Beaucoup de VPN circulent sur Ethernet. Nombreux sont ceux qui supposent que le VPN hérite de ces 1500. Cette supposition a fait plus de dégâts professionnels que n’importe quel bug unique d’un service.

Les VPN ajoutent des en-têtes. Parfois beaucoup d’en-têtes.
Votre paquet « interne » (celui que votre application croit envoyer) est enveloppé dans un paquet « externe » (celui que l’Internet transporte réellement).
Si le chemin externe ne peut pas gérer la taille, le paquet doit être fragmenté ou l’émetteur doit réduire la taille du paquet.

Voici d’où vient l’illusion « le web fonctionne » :

• Le trafic interactif est petit. Les frappes SSH et les appels d’API tiennent typiquement dans quelques centaines d’octets. Même si le MTU est incorrect, beaucoup de ces paquets passent.
• Le trafic web est résilient. Les navigateurs retentent. Les CDN tolèrent la perte. Certains sites utilisent une fenêtre de congestion initiale plus petite. Et beaucoup de chemins recadrent silencieusement MSS TCP ou ont simplement suffisamment de marge.
• Les gros transferts heurtent constamment le plafond MTU. SCP, rsync, SMB, NFS sur TCP — ces outils essaient de remplir le tuyau. Cela signifie beaucoup de segments TCP pleine taille. Si ces segments sont mis en boîte noire, le débit s’effondre.
• La PMTUD est fragile dans les réseaux d’entreprise. Elle repose sur les messages ICMP « Fragmentation Needed » retournant à l’émetteur. Les pare-feux aiment filtrer ICMP parce que ça « a l’air dangereux ».

Quand la PMTUD est cassée, vous obtenez le classique « trou noir MTU » : les gros paquets disparaissent, personne n’informe l’émetteur, TCP retransmet le même segment condamné et le transfert « bloque ».

Blague n°1 : les problèmes MTU sont comme les chaises de bureau — personne n’y pense jusqu’à ce que son dos lâche en plein trimestre.

Faits intéressants et contexte historique (édition MTU)

1. 1500 octets n’était pas une loi de la physique. C’est un choix de conception issu des compromis initiaux d’Ethernet : efficacité vs domaine de collision et contraintes matérielles.
2. La fragmentation IP existe parce que l’Internet a été assemblé à partir de nombreux réseaux. L’IP d’origine devait traverser des liens avec des tailles de trame maximales différentes, la fragmentation était un artifice de compatibilité.
3. IPv6 a changé les règles : les routeurs ne fragmentent pas. En IPv6, la fragmentation est réalisée uniquement par l’émetteur, ce qui rend la PMTUD encore plus critique.
4. Le MTU PPPoE de 1492 est un piège classique. Huit octets d’overhead PPPoE signifient que 1500 ne passe pas, et les VPN empilés deviennent encore plus serrés.
5. Les « jumbo frames » sont courantes dans les centres de données. Des MTU à 9000 octets améliorent l’efficacité, mais des MTU mixtes à travers des overlays (VXLAN/Geneve) créent des modes de défaillance qui ressemblent exactement à des problèmes MTU de VPN.
6. La PMTUD peut échouer depuis les années 1990. Le problème du « trou noir » est ancien : le filtrage d’ICMP casse la boucle de rétroaction.
7. Le clamp du MSS TCP est devenu populaire parce que les gens ont abandonné la PMTUD. Pas élégant, mais pragmatique quand vous ne contrôlez pas tous les pare-feux sur le chemin.
8. IPsec peut ajouter plus d’overhead que prévu. Selon le mode (tunnel vs transport), la traversée NAT et les algorithmes, l’overhead varie — et votre MTU sûr change.

À quoi ressemble une douleur MTU en production

Les problèmes MTU n’apparaissent que rarement sous la forme « paquet trop grand ». Ils se manifestent par des anomalies : échecs sélectifs, comportements incohérents entre applications et performances dignes d’une mauvaise journée chez un FAI.
Les symptômes qui doivent vous faire suspecter le MTU en premier :

• Les transferts SCP/rsync/SMB se bloquent après l’envoi d’une partie des données, souvent à un offset répétable.
• HTTPS fonctionne, mais l’envoi d’un artefact volumineux expire.
• SSH fonctionne, mais réaliser un git clone sur le VPN est extrêmement lent ou se bloque.
• Certaines sites fonctionnent, d’autres pas, notamment ceux qui envoient de gros cookies/en-têtes ou utilisent de grands enregistrements TLS.
• Le VPN fonctionne depuis un réseau mais pas un autre (fibre à domicile vs café vs Wi‑Fi invité d’entreprise).
• Les choses se cassent seulement si vous activez le « full tunnel » ou redirigez des sous-réseaux supplémentaires.

Sous ces symptômes se cachent généralement une de ces causes mécaniques :
paquets surdimensionnés + DF activé (ne pas fragmenter) + PMTUD cassée = trou noir.
Ou bien la fragmentation a lieu, mais mal (fragments perdus, problèmes de réassemblage, surcharge CPU, problèmes avec des pare-feux stateful).

PMTUD et les messages ICMP que tout le monde bloque

La découverte du MTU du chemin (Path MTU Discovery) est censée être simple : envoyer un paquet avec DF activé, et si un routeur ne peut pas le transmettre, il répond par un message ICMP indiquant le MTU du saut suivant.
L’émetteur réduit la taille et réessaie. Tout le monde est content.

En pratique, la PMTUD est une négociation conduite par deux hôtes à travers une chaîne d’équipements qui peuvent :
bloquer ICMP, réécrire des en-têtes, encapsuler des paquets ou normaliser le trafic « pour aider ».
Si le message ICMP « Fragmentation Needed » (IPv4) ou « Packet Too Big » (IPv6) est filtré, l’émetteur continue d’envoyer des paquets surdimensionnés et ne reçoit aucun retour.

Voilà toute l’histoire du trou noir. Une seule règle de sécurité écrite en 2014 (« drop all ICMP ») peut mettre à genoux un VPN moderne en 2025.

Opinion tranchée : ne résolvez pas une PMTUD cassée en espérant que la PMTUD recommence à fonctionner.
Dans la réalité d’entreprise, vous devez supposer qu’un middlebox va bloquer ICMP à l’endroit le plus problématique.
Votre travail consiste à choisir un MTU sûr ou à clamer le MSS afin que TCP n’envoie jamais de paquets nécessitant la PMTUD en premier lieu.

Surcoût d’encapsulation VPN : les octets que vous ne voyez pas

L’encapsulation n’est pas gratuite. Chaque protocole VPN ajoute des en-têtes (et parfois du padding) qui consomment de l’espace à l’intérieur du MTU externe.
Si votre MTU physique est 1500 et que votre VPN ajoute 80 octets d’overhead, votre paquet interne ne peut plus être de 1500.

L’overhead varie. Il varie selon le protocole, le mode, l’utilisation ou non de la traversée NAT et selon que vous êtes en IPv4 ou IPv6 sur le transport externe.
Voici des ordres de grandeur avec lesquels vous pouvez raisonner (pas des garanties, juste des estimations pratiques) :

• WireGuard sur IPv4/UDP : souvent ~60 octets d’overhead ; MTU sûr réel communément 1420.
• WireGuard sur IPv6/UDP : un peu plus d’overhead ; MTU sûr souvent légèrement inférieur.
• IPsec ESP en mode tunnel : typiquement 50–80+ octets ; NAT-T ajoute davantage (encapsulation UDP).
• OpenVPN sur UDP : l’overhead dépend du chiffrement et des réglages ; 1500→ typiquement 1400–1472 selon le tuning.
• GRE/VXLAN overlays : ajoutent leur propre overhead ; empilé avec un VPN, on peut rapidement perdre 100+ octets.

La bonne façon de raisonner : vous avez un MTU de chemin externe, et vous devez choisir un MTU interne qui rentre toujours après ajout de l’overhead.
Si vous ne connaissez pas le MTU du chemin, vous le mesurez. Si vous ne pouvez pas mesurer de manière fiable, vous choisissez de façon conservative et vous clamez.

Blague n°2 : l’overhead d’encapsulation, c’est comme les réunions — personne ne le budgète, et pourtant ça dévore l’après-midi.

Comment choisir le « bon » MTU pour le VPN

Il n’y a pas un MTU magique. Il existe un MTU sûr pour votre chemin externe et votre pile d’encapsulation.
Le choisir est un exercice d’ingénierie : mesurer le chemin, soustraire l’overhead et vérifier avec du trafic réel.

Étape 1 : déterminer le plus petit MTU externe que vous rencontrerez

Si vous contrôlez l’underlay (un WAN privé), vous savez peut‑être qu’il est 1500 de bout en bout ou 9000 de bout en bout.
Si votre VPN circule sur l’Internet public, supposez que vous ne le contrôlez pas.
Les FAI grand public, PPPoE, LTE et les Wi‑Fi d’hôtel peuvent réduire le MTU de façons qui varient selon la localisation.

Une cible pragmatique pour des VPN Internet est souvent :
MTU 1420 pour WireGuard, ou
MTU 1400 comme valeur conservative « fonctionne dans la plupart des cas » quand vous avez des réseaux mixtes et des middleboxes inconnus.

Étape 2 : décider si vous comptez sur la PMTUD ou sur le clamp MSS

Si vous pouvez garantir qu’ICMP est autorisé de bout en bout et que vous avez visibilité sur les pare‑feux, la PMTUD peut fonctionner.
La plupart des organisations ne peuvent pas garantir cela à travers les réseaux partenaires, les travailleurs distants et le Wi‑Fi invité aléatoire.

Ma recommandation par défaut :
fixer un MTU tunnel sûr et clamer également le MSS TCP au bord du VPN pour une défense en profondeur.
C’est ennuyeux. Ça marche. C’est le genre d’ennuyeux qui garde votre canal d’incidents tranquille.

Étape 3 : valider avec des tests « do not fragment » et des transferts réels

Un test ping avec DF activé n’est pas toute l’histoire, mais c’est un moyen rapide de trouver la frontière d’échec.
Ensuite, validez avec un transfert réel en masse (iperf3, scp d’un gros fichier ou rsync) parce que certains chemins traitent ICMP différemment selon UDP/TCP.

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

Quand quelqu’un dit « le VPN est lent » et que vous suspectez le MTU, vous voulez un chemin court et déterministe vers la vérité.
Voici l’ordre le plus rapide qui capture la plupart des échecs du monde réel sans se transformer en fouille archéologique d’une semaine.

Premier : confirmer que le symptôme dépend de la taille

• Petites requêtes HTTP fonctionnent ; gros uploads échouent.
• SSH se connecte ; scp d’un fichier multi‑GB se bloque.
• Ping fonctionne avec petite charge ; échoue avec charge plus grosse + DF.

Deuxième : trouver le MTU effectif sur le tunnel et son underlay

• Vérifier le MTU de l’interface du tunnel.
• Vérifier le MTU de l’interface de sortie physique.
• Chercher PPPoE (1492), bizarrerie LTE, ou contraintes réseau cloud.

Troisième : détecter une défaillance PMTUD et décider clamp vs autoriser ICMP

• Lancer des pings DF pour rechercher binaire la taille max.
• Capturer le trafic pour voir retransmissions et ICMP manquants.
• Si ICMP est bloqué quelque part où vous ne pouvez pas intervenir : clamez le MSS et réduisez le MTU.

Quatrième : valider le correctif avec un transfert massif réel

• Utiliser iperf3 ou scp/rsync d’un fichier multi‑GB.
• Surveiller retransmissions, désordres et stabilité du débit.
• Confirmer que vous n’avez rien cassé d’autre (par exemple un réseau overlay).

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

L’objectif du dépannage MTU est d’arrêter de deviner.
Ci‑dessous des tâches concrètes à lancer sur des hôtes Linux et des passerelles VPN typiques.
Chaque tâche inclut : une commande, une sortie d’exemple, ce que cela signifie et la décision suivante.

Task 1: Check MTU on all interfaces (find the tunnel and the real egress)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
eth0             UP             0a:1b:2c:3d:4e:5f <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
wg0              UP             8a:9b:aa:bb:cc:dd <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Que cela signifie : Le tunnel (wg0) est réglé à 1420, l’underlay eth0 est à 1500. C’est un point de départ sain pour WireGuard.

Décision : Si le MTU du tunnel est 1500 alors que l’underlay est 1500, vous êtes presque certainement surdimensionné après l’overhead. Prévoir d’abaisser le MTU du tunnel ou de clamer le MSS.

Task 2: Inspect the route and learn which interface actually carries VPN traffic

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 203.0.113.1 dev eth0 src 203.0.113.10 uid 1000
    cache

Que cela signifie : Votre egress Internet est eth0. C’est l’underlay pour le VPN si vos pairs VPN sont sur Internet.

Décision : Si l’interface de sortie est un périphérique PPPoE (souvent ppp0) ou un VLAN avec MTU réduit, utilisez cette valeur comme borne supérieure pour la taille des paquets externes.

Task 3: Check for PPPoE or other reduced-MTU links

cr0x@server:~$ ip -d link show dev ppp0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp

Que cela signifie : Le MTU externe est 1492, pas 1500. Si vous supposiez 1500, votre MTU interne doit être réduit davantage.

Décision : Abaisser le MTU du tunnel et/ou clamer le MSS en conséquence. Ne « désoptimisez » pas cela sauf si vous contrôlez la méthode d’accès.

Task 4: Quick DF ping to detect fragmentation/black hole (IPv4)

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

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

Que cela signifie : Votre système local connaît déjà une contrainte MTU (1420) sur le chemin/interface utilisée. Un paquet de 1500 octets ne passera pas.

Décision : N’envoyez pas de segments TCP nécessitant 1500 octets sur ce chemin. Réglez le MTU du tunnel pour coller à la réalité ou clamez le MSS.

Task 5: Binary search the maximum DF payload that works

cr0x@server:~$ ping -M do -s 1392 -c 2 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1392(1420) bytes of data.
1400 bytes from 198.51.100.20: icmp_seq=1 ttl=57 time=28.1 ms
1400 bytes from 198.51.100.20: icmp_seq=2 ttl=57 time=27.8 ms

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 27.825/27.948/28.071/0.123 ms

Que cela signifie : 1420 octets de paquet IP total passent (1392 payload + 28 octets d’en-têtes ICMP+IP). Cela suggère un MTU de chemin sûr proche de 1420 pour ce flux.

Décision : Choisir le MTU du tunnel au ou en dessous de cette frontière (tenez compte de l’overhead VPN). Pour WireGuard, 1420 est souvent correct ; pour des encapsulations plus lourdes, descendez.

Task 6: Detect PMTUD being blocked (classic black hole pattern)

cr0x@server:~$ ping -M do -s 1412 -c 2 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 1412(1440) bytes of data.

--- 198.51.100.20 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2038ms

Que cela signifie : Pas de réponse, et vous n’avez pas non plus reçu un ICMP « frag needed ». Cela peut être une perte pure, mais si des tailles plus petites fonctionnent de façon fiable, c’est suspect.

Décision : Supposer un trou noir MTU jusqu’à preuve du contraire. Préférer le clamp MSS et un MTU tunnel conservatif. Vérifier aussi les règles de pare‑feu pour ICMP type 3 code 4 (IPv4) et ICMPv6 type 2.

Task 7: Check TCP MSS and observed path behavior with ss

cr0x@server:~$ ss -ti dst 198.51.100.20
ESTAB 0 0 10.0.0.5:48216 198.51.100.20:443
	 cubic wscale:7,7 rto:204 rtt:32.4/4.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:10 bytes_sent:128734 bytes_acked:128734

Que cela signifie : La connexion utilise MSS 1360 et PMTU 1420. C’est cohérent : 1420 moins 40 octets d’en‑têtes TCP+IP = 1380 (les options peuvent réduire légèrement).

Décision : Si vous voyez MSS près de 1460 mais que votre MTU tunnel est plus bas, vous avez probablement un décalage et devez clamer ou corriger le MTU.

Task 8: Verify WireGuard’s configured MTU and peer path

cr0x@server:~$ wg show
interface: wg0
  public key: 8n3r...redacted...
  listening port: 51820

peer: pQ1k...redacted...
  endpoint: 198.51.100.20:51820
  allowed ips: 10.42.0.0/16
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.23 GiB received, 2.98 GiB sent

Que cela signifie : Le tunnel est actif et transfère des données. Les problèmes MTU n’empêcheront pas forcément les handshakes ; ils pénalisent les transferts en masse et certaines tailles de paquets.

Décision : Si les handshakes sont ok mais le débit est nul, concentrez‑vous sur MTU/MSS/PMTUD plutôt que sur les clés ou le routage.

Task 9: Check and set interface MTU (temporary change for testing)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Que cela signifie : Vous avez forcé un MTU plus petit sur le tunnel. Cela réduit le risque de fragmentation au prix d’un léger surcoût par paquet.

Décision : Si les gros transferts deviennent stables après réduction du MTU, vous avez confirmé que le MTU était le goulot. Calculez alors la valeur la plus élevée sûre et appliquez‑la de façon permanente via la gestion de configuration.

Task 10: Clamp TCP MSS on a Linux gateway with iptables

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

Que cela signifie : Pour les paquets SYN TCP sortants via wg0, MSS sera ajusté pour correspondre au PMTU découvert (ou au MTU de l’interface).

Décision : Utilisez ceci quand vous ne pouvez pas faire confiance à la PMTUD de bout en bout ou quand les clients ont des réglages MTU incohérents. Ensuite vérifiez avec ss -ti que le MSS est réduit.

Task 11: Do the same with nftables (common in modern distros)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft 'add chain inet mangle forward { type filter hook forward priority -150; }'
cr0x@server:~$ sudo nft add rule inet mangle forward oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
cr0x@server:~$ sudo nft list ruleset
table inet mangle {
	chain forward {
		type filter hook forward priority -150; policy accept;
		oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
	}
}

Que cela signifie : Le MSS est réglé en fonction du MTU de la route. C’est l’équivalent nftables du « clamp to PMTU ».

Décision : Préférez nftables si votre parc l’utilise. Rendez‑le persistant via le mécanisme de votre distribution (non montré ici) et testez après reboot.

Task 12: Confirm ICMP “fragmentation needed” isn’t being dropped locally

cr0x@server:~$ sudo iptables -S INPUT
-P INPUT DROP
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j DROP

Que cela signifie : Vous droppez tout ICMP au pare‑feu de l’hôte. Cela peut casser la PMTUD (même si les règles RELATED auraient pu aider dans certains cas).

Décision : Autorisez les types ICMP nécessaires, ou clamez le MSS pour ne pas dépendre d’ICMP. En IPv6, « drop all ICMPv6 » est une façon sûre de casser le réseau de manière créative.

Task 13: Capture evidence of black-holing (retransmits, no ICMP back)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp port 443 or icmp' -vv
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:15:01.102334 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360
12:15:01.304982 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360
12:15:01.708115 IP 10.42.0.10.48216 > 10.42.0.20.443: Flags [P.], seq 1:1361, ack 1, win 501, length 1360

Que cela signifie : Retransmissions du même segment sans progression. Si vous ne voyez jamais d’ICMP « too big » et que des MSS plus petits fonctionnent, vous avez un problème PMTUD/MTU.

Décision : Réduire le MTU du tunnel et clamer le MSS. Refaire un test et confirmer que les retransmissions disparaissent.

Task 14: Measure throughput and stability with iperf3 (TCP)

cr0x@server:~$ iperf3 -c 10.42.0.20 -t 15
Connecting to host 10.42.0.20, port 5201
[  5] local 10.42.0.10 port 46012 connected to 10.42.0.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.50 MBytes  54.5 Mbits/sec   12   34.0 KBytes
[  5]   1.00-2.00   sec  2.00 MBytes  16.8 Mbits/sec   31   19.8 KBytes
[  5]   2.00-3.00   sec  1.25 MBytes  10.5 Mbits/sec   45   14.1 KBytes
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec   60   10.0 KBytes

Que cela signifie : Les retransmissions augmentent et le débit s’effondre à zéro, cohérent avec des segments mis en boîte noire ou une perte sévère. Les problèmes MTU se manifestent souvent ainsi quand vous atteignez la « mauvaise » taille.

Décision : Baisser MTU / clamer MSS et relancer. Un bon résultat est un débit stable avec peu de retransmissions.

Task 15: Spot local offload features that can confuse captures (not usually the root cause)

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'tso|gso|gro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Que cela signifie : Les offloads peuvent rendre les captures de paquets étranges (grosses « super paquets » côté hôte). Ils ne causent généralement pas de trous noirs MTU, mais peuvent vous faire mal lire les preuves.

Décision : Si vous êtes profond dans l’analyse de paquets, désactivez temporairement les offloads pour clarifier (pas comme « fix »), puis réactivez pour éviter une régression de performance.

Task 16: Verify MTU on a remote client (because your gateway isn’t the only liar)

cr0x@server:~$ ssh user@client 'ip -br link show dev wg0'
wg0              UP             3a:44:55:66:77:88 <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500

Que cela signifie : Le client wg0 est à 1500. Ce client peut envoyer des paquets internes qui ne rentreront pas une fois encapsulés, selon le chemin.

Décision : Standardiser le MTU sur les clients via la gestion de configuration (ou pousser un profil si vous utilisez un client géré). La cohérence bat le dépannage héroïque.

Trois mini-histoires d’entreprise (parce que la production enseigne)

1) L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé un nouveau VPN site-à-site entre un VPC cloud et un bureau on‑prem.
Les tests de connectivité semblaient propres : les pings passaient, le DNS passait, les gens pouvaient SSH sur des bastions. Tout le monde a déclaré le déploiement réussi.
Deux jours plus tard, le système CI a commencé à échouer pour téléverser des artefacts de build vers un registre interne accessible uniquement via ce VPN.

Les logs de build montraient des timeouts et des retries. Les développeurs accusaient le registre. L’équipe registre accusait les runners CI. Le SRE a été appelé parce que le canal d’incident avait cette énergie spéciale « c’est urgent mais personne ne sait pourquoi ».
Quelqu’un a remarqué un motif : les petites images se poussaient bien. Les grosses couches se bloquaient indéfiniment.

La mauvaise hypothèse était simple et courante : « Le réseau est Ethernet, donc MTU est 1500 partout. »
L’uplink on‑prem utilisait PPPoE. Le MTU externe était 1492. Le VPN ajoutait de l’overhead par-dessus. La PMTUD était cassée parce qu’une ancienne politique de pare‑feu dropait ICMP type 3 code 4.
Donc de gros segments TCP disparaissaient dans le vide, et TCP faisait ce que TCP fait : retransmettre, reculer et souffrir en silence.

La correction n’a pas été héroïque. Ils ont abaissé le MTU du tunnel à une valeur sûre et clamé le MSS sur la passerelle.
Les uploads sont redevenus ennuyeux. L’incident s’est terminé.
L’action postmortem a été plus nette : arrêter d’utiliser « ping fonctionne » comme proxy pour « le trafic en masse fonctionne », et arrêter de dropper tout ICMP par défaut.

2) L’optimisation qui a mal tourné

Une autre organisation avait une main‑d’œuvre distante et un client VPN qui utilisait par défaut MTU 1420.
Un ingénieur réseau, cherchant à extraire plus de débit sur les gros transferts, a poussé une politique pour régler le MTU à 1500 « pour correspondre à Ethernet ».
Ils ont aussi désactivé le clamp MSS parce que « ça ne devrait pas être nécessaire ».

Pendant une semaine, cela a semblé être un gain au bureau : transferts plus rapides vers certains services internes sur un lien ISP bien comporté.
Puis la file d’aide a explosé avec des utilisateurs distants : appels vidéo ok, mais l’envoi de rapports vers un portail interne échouait, et certaines applications web se chargeaient sans CSS.
Les échecs étaient incohérents selon les FAI et les lieux, ce qui correspond exactement à la façon dont se manifestent les problèmes MTU quand l’underlay varie.

L’optimisation a été contre‑productive dans le monde réel : certains utilisateurs étaient sur des hotspots LTE avec des MTU effectifs plus faibles ; certains étaient derrière des routeurs grand public faisant des choses bizarres avec ICMP ; d’autres avaient des chemins ISP qui ne laissaient simplement pas passer 1500+encapsulation de façon fiable.
La PMTUD aurait dû négocier des tailles plus petites, mais elle n’a pas pu, car les messages ICMP « too big » ne passaient pas de façon cohérente.

Le rollback vers 1420 a réparé la plupart des utilisateurs immédiatement. Ils ont réintroduit le clamp MSS au bord du VPN, puis mené une expérience contrôlée pour voir si un sous‑ensemble pouvait utiliser un MTU plus grand en toute sécurité.
La conclusion était malheureusement prévisible : un MTU plus élevé globalement ne valait pas le coût de support. Ils ont gardé 1420 et se sont concentrés sur le routage et la capacité pour améliorer le débit.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers utilisait plusieurs types de VPN : WireGuard pour les ingénieurs, tunnels IPsec pour les partenaires et un réseau overlay dans Kubernetes.
Ils avaient une règle : chaque nouveau tunnel devait être livré avec un test MTU et une politique MSS, plus un runbook d’une page incluant la procédure « DF ping binary search ».
Personne n’aimait cette règle. Tout le monde la suivait parce qu’elle évitait de détruire des week‑ends.

Un vendredi, un partenaire a changé sa posture de pare‑feu et a commencé à bloquer plus d’ICMP.
Leur tunnel IPsec est resté « up » mais de gros messages vers une API de règlement ont commencé à échouer sporadiquement. Les alertes ont déclenché, mais l’équipe n’a pas paniqué ; elle avait un playbook et une baseline connue.

Ils ont exécuté leurs vérifications standard : tests DF ping, tcpdump pour retransmissions et vérification du clamp MSS sur la bordure.
Résultat : le clamp empêchait déjà les segments TCP surdimensionnés, donc l’impact a été limité à un sous‑ensemble de trafic non‑TCP et à un service spécifique qui envoyait des payloads UDP plus grands que prévu.
Parce que le MTU du tunnel était déjà conservatif, la zone d’impact a été plus petite que ce qu’elle aurait pu être.

Ils ont ajusté la taille des payloads applicatifs pour ce chemin UDP et coordonné avec le partenaire pour permettre les types ICMP nécessaires.
La pratique « ennuyeuse » — paramètres MTU standard, clamp et tests répétables — a transformé ce qui aurait pu être une panne multi‑équipe en un ticket opérationnel contenu.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: SCP stalls; SSH interactive is fine

Cause racine : Des segments TCP dimensionnés pour un MTU 1500 sont mis en boîte noire après encapsulation VPN ; PMTUD/ICMP est bloqué.

Correction : Abaisser le MTU du tunnel (par ex. 1420→1380 si nécessaire) et clamer le MSS à la bordure VPN. Vérifier avec ss -ti et un transfert réel.

2) Symptom: Some websites load, others hang or lose assets (CSS/images)

Cause racine : Tailles de paquets mixtes en TLS/HTTP ; de plus grosses réponses déclenchent des problèmes de fragmentation. Souvent vu avec VPN full‑tunnel et mismatch MTU.

Correction : Clamer le MSS sur le TCP sortant depuis le client ou la passerelle VPN. Si vous gérez les clients, standardisez le MTU du tunnel.

3) Symptom: VPN “connects” but throughput is terrible and retransmits are high

Cause racine : Fragmentation ou perte en trou noir à une frontière de taille spécifique ; parfois aggravé par un overlay sur overlay (VXLAN sur VPN, etc.).

Correction : Mesurer la taille DF max, réduire le MTU et éviter d’empiler des encapsulations sans budgéter le MTU. Si empilement nécessaire, intégrer le calcul MTU dans la conception.

4) Symptom: Works from office network, fails from home or LTE

Cause racine : Le MTU de l’underlay diffère (PPPoE/LTE), et votre MTU tunnel choisi est trop élevé pour certains chemins. PMTUD peut ne pas fonctionner à travers l’équipement grand public.

Correction : Utiliser un MTU conservatif pour les VPN d’accès distant et clamer le MSS. Cesser de traiter le bureau comme « l’Internet ».

5) Symptom: IPv6 traffic over VPN is flaky; IPv4 is okay

Cause racine : ICMPv6 filtré (notamment « Packet Too Big »), ce qui casse la PMTUD IPv6. De plus, les en‑têtes IPv6 sont plus grands, réduisant la charge utile effective.

Correction : Autoriser les types ICMPv6 requis ou clamer le MSS / réduire davantage le MTU pour IPv6. Ne pas dropper ICMPv6 en bloc.

6) Symptom: Kubernetes pods can reach services, but large responses fail

Cause racine : Mismatch MTU CNI vs node/tunnel MTU ; l’overlay ajoute de l’overhead ; MTU des pods trop grand ; PMTUD bloquée à l’intérieur des overlays.

Correction : Définir explicitement le MTU CNI pour tenir compte de l’underlay et de tout VPN. Puis clamer le MSS à l’egress des nœuds si besoin.

7) Symptom: UDP-based apps break (VoIP okay, but large UDP payloads fail)

Cause racine : UDP n’a pas de négociation MSS comme TCP ; datagrammes surdimensionnés sont fragmentés et les fragments sont perdus/dropés ; ou le comportement DF diffère.

Correction : Réduire la taille des payloads applicatifs ; éviter les gros datagrammes UDP sur le VPN ; s’assurer que la fragmentation n’est pas requise ou est gérée de façon fiable.

Listes de contrôle / plan étape par étape

Checklist A: When you’re on call and need a fix in under an hour

1. Confirmer la dépendance à la taille. Tester un gros scp/rsync/iperf3 ; comparer avec une petite requête HTTP.
2. Lire les valeurs MTU actuelles. ip -br link sur les deux extrémités ; identifier le tunnel et l’egress.
3. Lancer des tests ping DF. Rechercher binaire les tailles limites.
4. Abaisser temporairement le MTU du tunnel. Tester 1420 → 1380 → 1360 selon besoin.
5. Clamer le MSS à la bordure VPN. Utiliser iptables/nftables pour clamer sur PMTU.
6. Retester le transfert en masse. iperf3 + scp d’un fichier multi‑GB ; s’assurer que les retransmissions chutent.
7. Rendre persistant. Mettre à jour la config VPN et la gestion du pare‑feu ; ajouter un test de régression au runbook.

Checklist B: When you’re designing a VPN and want to avoid the incident entirely

1. Inventorier les couches d’encapsulation. VPN + overlay + VLAN + PPPoE n’est pas une vibe ; c’est un budget MTU.
2. Choisir un MTU de base conservatif. Pour l’accès Internet distant, partir autour de 1420 (WireGuard) ou 1400 si chemins mixtes.
3. Standardiser le MTU sur les clients. Ne laissez pas les endpoints deviner ; fournissez une config.
4. Clamer le MSS aux frontières. Surtout là où le trafic passe de « inside » au « tunnel ».
5. Autoriser l’ICMP essentiel. Permettre fragmentation‑needed/packet‑too‑big. Ne pas dropper tout ICMP parce qu’un scanner a crié.
6. Tester depuis des réseaux hostiles. LTE, Wi‑Fi d’hôtel, PPPoE à domicile et tout ce que votre équipe finance utilise en déplacement.
7. Rédiger le runbook. Inclure les commandes exactes, les sorties attendues et les procédures de rollback.

Checklist C: What to avoid (because you’ll regret it)

• Régler le MTU du tunnel à 1500 « parce qu’Ethernet ».
• Dropper tout ICMP/ICMPv6 sans comprendre la PMTUD.
• Supposer qu’un ping réussi signifie que le MTU est correct.
• Empiler tunnels/overlays sans calculer explicitement la marge.
• Déployer des changements MTU à l’échelle sans un réseau canari incluant des FAI grand public.

FAQ

1) Pourquoi les petits paquets fonctionnent mais les gros se bloquent ?

Parce que les petits paquets passent sous le MTU effectif même après overhead VPN. Les gros paquets le dépassent, sont dropés ou fragmentés, et la PMTUD peut être bloquée.
TCP retransmet ensuite et recule, ce qui ressemble à un « blocage ».

2) Quel est un bon MTU par défaut pour WireGuard ?

1420 est un défaut courant et pratique sur des underlays Ethernet à MTU 1500. Si vous observez des symptômes de trou noir sur certains réseaux, essayez 1380 ou 1360.
Puis validez avec des pings DF et des transferts réels.

3) Dois‑je compter sur la PMTUD plutôt que clamer le MSS ?

Si vous contrôlez tout le chemin et autorisez les messages ICMP requis, la PMTUD peut bien fonctionner.
Dans la réalité mixte entreprise/consommateur, clamer le MSS est souvent le choix opérationnel le plus sûr — surtout pour les VPN d’accès distant.

4) Baisser le MTU ne réduit‑t‑il pas les performances ?

Légèrement, oui : plus de paquets pour les mêmes données, plus d’overhead par paquet.
Mais la « performance » que vous obtenez d’un MTU trop grand est imaginaire si cela provoque retransmissions, fragmentation ou blocages. La stabilité vaut mieux que l’efficacité théorique.

5) Qu’en est‑il des jumbo frames (MTU 9000) ? Puis‑je utiliser un MTU de tunnel plus grand ?

Seulement si tout l’underlay le supporte de bout en bout et que chaque couche d’encapsulation est prise en compte.
Les MTU mixtes sont courants, et un seul saut à 1500 vous gâchera la journée. Mesurez ; ne supposez pas.

6) Si je clame le MSS, dois‑je toujours régler correctement le MTU du tunnel ?

Le clamp MSS protège les flux TCP. Il ne fait rien pour UDP ou les protocoles non‑TCP.
Un MTU de tunnel sain réduit le risque de fragmentation pour tous les protocoles, donc vous voulez généralement les deux : MTU tunnel sûr + clamp MSS.

7) Pourquoi IPv6 est‑il plus sensible à ça ?

Les routeurs ne fragmentent pas les paquets IPv6. L’émetteur doit s’adapter en fonction des messages ICMPv6 « Packet Too Big ».
Si ICMPv6 est filtré, la PMTUD échoue sévèrement, et vous obtenez des trous noirs plus souvent qu’avec IPv4.

8) Quelle est la différence entre MTU et MSS ?

Le MTU est la taille maximale de paquet IP sur un lien. Le MSS est la taille maximale de charge TCP dans un segment.
Le MSS est typiquement MTU moins les en‑têtes IP+TCP (et moins les options). Clamer le MSS empêche TCP de générer des paquets dépassant le MTU du chemin.

9) Puis‑je « corriger » ça en autorisant la fragmentation ?

Vous pouvez, mais c’est un compromis : la fragmentation augmente la sensibilité à la perte (perdre un fragment équivaut à perdre le paquet entier), surcharge les middleboxes et peut amplifier les problèmes de performance.
Préférez éviter la fragmentation en choisissant un MTU approprié et en clamant le MSS.

10) Quelle règle opérationnelle pour l’ICMP dans les pare‑feux ?

Autoriser les messages ICMP requis pour la PMTUD (fragmentation‑needed IPv4, packet‑too‑big IPv6) et le reporting d’erreurs de base.
Ne pas dropper ICMP en bloc. Cette politique est la cause des tickets « le VPN est hanté ».

Une citation à garder sur votre mur

Idée paraphrasée de Werner Vogels : « Tout échoue, tout le temps — concevez pour ça. » Appliqué ici : supposez que la PMTUD échoue quelque part et construisez quand même des garde‑fous (MTU/MSS).

Conclusion : prochaines étapes pratiques

Si les gros fichiers se bloquent via votre VPN alors que la navigation de base fonctionne, cessez de chasser des fantômes dans la couche applicative.
MTU et PMTUD sont les suspects habituels, et le correctif est généralement une combinaison d’un MTU tunnel conservatif et du clamp MSS.

Prochaines étapes que vous pouvez faire aujourd’hui :

1. Lancer des pings DF pour trouver la frontière de taille réelle.
2. Standardiser le MTU tunnel entre les endpoints (ne laissez pas les clients improviser).
3. Clamer le MSS TCP à la frontière VPN pour éviter de dépendre de la PMTUD.
4. Auditer les règles de pare‑feu : autoriser les messages ICMP/ICMPv6 essentiels.
5. Valider avec un transfert en masse réel et conserver les commandes dans un runbook.

Quand le MTU est correct, le VPN devient ennuyeux. C’est l’objectif. Les réseaux ennuyeux transfèrent des données et vous tiennent à l’écart des réunions.