VPN d’entreprise MTU/MSS : pourquoi les gros fichiers se bloquent (SMB/RDP) et comment réparer

Le mode d’échec : pourquoi les « gros fichiers » exposent les bugs MTU/MSS

Quand quelqu’un dit « le VPN se connecte mais la copie de gros fichiers se bloque », il décrit un problème classique de path MTU qui ressemble à un souci de performances, de pare-feu ou de stockage — jusqu’à ce que vous le mesuriez.

Voici ce qui se passe typiquement :

• Vos points de terminaison croient pouvoir envoyer des paquets jusqu’à une certaine taille (souvent 1500 octets sur Ethernet).
• Le VPN ajoute une surcharge (encapsulation, chiffrement, authentification). L’MTU effective à l’intérieur du tunnel devient plus petite que 1500.
• Un équipement sur le chemin ne peut pas transmettre ces paquets plus grands et tente de le signaler via ICMP « Fragmentation needed » (ou l’équivalent IPv6).
• Ce message ICMP est bloqué ou ne revient jamais (bonjour, « durcissement de la sécurité »).
• TCP continue de retransmettre des segments qui ne traversent jamais le chemin. Les petits flux survivent parce qu’ils tiennent ; les gros flux se bloquent parce qu’ils ne tiennent pas.

Ceci est la définition d’un trou noir PMTUD : Path MTU Discovery tente de faire son travail, mais le canal de retour est cassé.

SMB et RDP ne tombent pas forcément en panne instantanément. Ils échouent de la façon la plus agaçante possible : partiellement. Les premiers mégaoctets peuvent se transférer, puis vous rencontrez un paquet qui doit être plus grand que ce que le chemin autorise, et la session passe de « ok » à « hantée ».

Règle pratique : si les petits paquets passent mais que les grands se bloquent, arrêtez de blâmer le stockage, arrêtez de blâmer DNS, et commencez à tester l’MTU.

Faits intéressants et contexte historique

1. 1500 octets est devenu « le défaut » surtout à cause d’Ethernet, pas parce que 1500 est optimal — juste pratique et largement interopérable.
2. PPPoE réduit famosamente l’MTU à 1492 (8 octets de surcharge), d’où le rôle récurrent de « 1492 » dans les enquêtes VPN.
3. La surcharge IPsec ESP n’est pas un nombre fixe ; elle dépend du mode tunnel vs transport, NAT‑T, chiffrement, intégrité, bourrage et alignement.
4. PMTUD date de la fin des années 1980/début 1990, créé pour réduire la fragmentation et améliorer l’efficacité — bonne idée, fragile face au filtrage ICMP.
5. « ICMP est bloqué pour la sécurité » casse les réseaux depuis des décennies ; c’est l’équivalent opérationnel de scotcher vos voyants d’alerte sur le tableau de bord.
6. IPv6 tente de rendre la fragmentation plus logique en déléguant la responsabilité aux points de terminaison — pourtant, les trous noirs PMTUD surviennent toujours quand ICMPv6 est mal géré.
7. Le clamp MSS est devenu courant parce que PMTUD échoue souvent dans le monde réel ; c’est un contournement pragmatique quand vous ne pouvez pas faire confiance au chemin pour signaler correctement l’MTU.
8. Les jumbo frames (MTU 9000) ont augmenté les incompatibilités MTU dans des environnements mixtes : super dans un data center, désordonné quand on le laisse fuir vers le WAN.

MTU, MSS, PMTUD : ce qui compte en production

MTU : la plus grande trame que vous pouvez faire passer sur un lien

MTU (Maximum Transmission Unit) est la plus grande taille de paquet IP qui peut traverser une interface sans fragmentation à ce niveau. Sur Ethernet, 1500 est courant. Les VPN encapsulent votre paquet dans un autre paquet. Cette enveloppe coûte des octets.

Si votre paquet interne fait 1500 octets et que le VPN ajoute 60–100+ octets de surcharge, le paquet externe peut atteindre 1560–1600 octets. Si un saut du chemin n’autorise que 1500, quelque chose doit céder.

MSS : la plus grande charge utile TCP par segment

MSS (Maximum Segment Size) est la taille de la charge utile TCP, hors en-têtes IP et TCP. Quand vous voyez MSS 1460, c’est 1500 MTU moins 20 octets d’en‑tête IPv4 moins 20 octets d’en‑tête TCP.

Quand l’MTU diminue (à cause de la surcharge VPN), la MSS sûre diminue aussi. Si vous n’ajustez pas la MSS et que PMTUD échoue, TCP tentera d’envoyer des segments trop grands pour le chemin, et vous aurez des blocages sous charge.

PMTUD : la boucle de rétroaction facile à casser

Path MTU Discovery repose sur les routeurs qui disent à l’émetteur « ce paquet est trop grand ; voici l’MTU nécessaire ». Sur IPv4, c’est ICMP « Fragmentation needed » (type 3, code 4). Sur IPv6, c’est ICMPv6 « Packet Too Big ».

Bloquez ces messages, et PMTUD devient « deviner le Path MTU ». Devinez mal, et TCP perd du temps à retransmettre des segments qui n’arrivent jamais.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue ; concevez pour récupérer rapidement. » Les problèmes MTU en sont un exemple parfait — construisez pour le mode d’échec au lieu d’espérer que le chemin soit poli.

Vérité opérationnelle en une phrase : si vous ne pouvez pas garantir que PMTUD fonctionne de bout en bout, appliquez un clamp MSS à la bordure du tunnel.

Blague #1 (courte et pertinente) : les bugs MTU sont comme les imprimantes de bureau : elles ne bourrent que quand le PDG a besoin de quelque chose en cinq minutes.

Pourquoi SMB et RDP se plaignent en premier

SMB : bavard, avec état, et excellent pour révéler la perte de paquets

Les copies SMB sont des flux TCP longs avec des rafales de données. Ils font aussi beaucoup d’échanges de contrôle sensibles à la latence et aux retransmissions. Quand l’MTU est incorrect, les gros segments de données restent bloqués tandis que des petits messages de contrôle peuvent encore passer. Cela produit un symptôme exaspérant : le partage se parcourt, l’authentification marche, les listes de dossiers s’affichent, mais la copie de fichier se fige.

SMB3 ajoute des options de chiffrement et de signature qui peuvent modifier les tailles de paquets et le comportement. Ce n’est pas « la cause », mais cela peut être l’étincelle qui pousse un MTU limite vers l’échec.

RDP : la session reste connectée pendant que votre charge utile s’étouffe

RDP peut sembler connecté parce que les keepalives et les petites mises à jour d’écran passent. La redirection du presse‑papier, le mappage de lecteur, l’impression et la copie de fichiers sont les opérations où apparaissent des transferts plus volumineux et où le flux TCP commence à souffrir. Les utilisateurs décrivent cela comme un « gel RDP », mais c’est souvent le chemin I/O redirigé qui se bloque pendant que les threads de session conservent une connexion chancelante.

Pourquoi la navigation web semble souvent correcte

Le trafic web moderne est composé de nombreuses connexions courtes, avec un contrôle de congestion qui récupère rapidement, et beaucoup de contenu livré en morceaux qui ne demandent pas forcément des segments soutenus très grands. De plus, les navigateurs réessayent agressivement et cachent les échecs derrière des spinners. Les copies SMB sont honnêtes. Elles s’arrêtent et vous regardent.

Playbook de diagnostic rapide

Voici l’ordre qui vous amène rapidement à la vérité, sans passer un après‑midi à réécrire des configs VPN parce que « ça ressemble à l’MTU ».

Premier : confirmez que le symptôme est lié à la taille, pas à la résolution de noms ou à l’authentification

• Pouvez‑vous lister le partage SMB de façon fiable mais la copie de gros fichiers plante ?
• RDP se connecte instantanément mais la copie sur lecteur redirigé gèle ?
• Les petits pings fonctionnent mais les pings volumineux avec DF réglé échouent ?

Second : déterminez le MTU de chemin fonctionnel avec un test ping DF

• Testez depuis le client vers le serveur (et inversement si possible).
• Trouvez la plus grande charge utile qui réussit sans fragmentation.
• Si vous voyez « Frag needed » parfois, vous avez de la chance ; si vous entendez le silence, vous pourriez avoir un trou noir.

Troisième : vérifiez les hypothèses de surcharge du tunnel et clamppez la MSS à la bordure

• Identifiez si vous utilisez IPsec (ESP, NAT‑T), OpenVPN (UDP/TCP), WireGuard, ou appliances SSL VPN.
• Fixez l’MTU de l’interface tunnel de façon appropriée, et/ou appliquez un clamp MSS sur la passerelle VPN/pare‑feu.
• Retestez la copie de gros fichiers et les flux TCP longs.

Quatrième : vérifiez le traitement ICMP (ne faites pas d’hypothèses)

• Autorisez les types ICMP nécessaires à travers le tunnel et sur les bords WAN.
• Confirmez que PMTUD fonctionne, ou admettez qu’il ne fonctionne pas et basez‑vous sur le clamp MSS.

Cinquième : seulement alors poursuivez l’optimisation « performance »

• SMB multichannel, window scaling, offloads — ce sont des optimisations secondaires une fois l’MTU correct.
• N’optimisez pas un chemin cassé. Vous ne ferez que créer un échec plus rapide.

Tâches pratiques avec commandes : prouver, puis réparer

Ci‑dessous des tâches réelles que vous pouvez exécuter. Chacune inclut : commande, exemple de sortie, ce que cela signifie, et la décision à prendre.

Task 1: Identify the VPN interface and its MTU (Linux)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
eth0             UP             52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420

Ce que cela signifie : L’interface tunnel (wg0) est déjà à 1420, un choix courant pour WireGuard. Si vous voyez 1500 sur une interface VPN, c’est un signal d’alerte dans la plupart des scénarios WAN.

Décision : Si l’MTU est 1500 sur le tunnel, prévoyez de le réduire ou d’appliquer un clamp MSS.

Task 2: Check route MTU hints (Linux)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 dev wg0 src 10.20.30.1 uid 1000
    cache

Ce que cela signifie : Le trafic vers l’hôte distant utilise wg0. S’il utilise de façon inattendue eth0, vos règles de split‑tunnel sont peut‑être erronées et vous dépannez le mauvais chemin.

Décision : Confirmez que vous testez réellement sur le chemin VPN.

Task 3: Find the real path MTU using ping with DF (Linux, IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2042ms

Ce que cela signifie : Un paquet de 1500 octets (1472 charge utile + 28 octets d’en‑têtes) n’est pas passé. Si vous avez reçu un « Frag needed » explicite, PMTUD fonctionne au moins partiellement. Le silence peut signifier un trou noir.

Décision : Réduisez la taille de la charge utile jusqu’à réussite ; notez la plus grande valeur fonctionnelle.

Task 4: Binary search MTU until it works (Linux)

cr0x@server:~$ ping -M do -s 1364 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1364(1392) bytes of data.
1372 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=31.2 ms
1372 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=30.9 ms
1372 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=31.0 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 30.9/31.0/31.2/0.1 ms

Ce que cela signifie : Votre path MTU est au moins de 1392 octets pour des paquets IPv4. Cela suggère une MSS autour de 1352 (1392 – 40 octets IP+TCP), et vous devriez clampper en dessous pour être sûr.

Décision : Définissez l’MTU du tunnel ou un clamp MSS sur une valeur conservatrice (souvent équivalente à 1360–1380 MTU pour le chemin interne, selon la surcharge et la variabilité).

Task 5: Observe TCP MSS in SYN packets with tcpdump (Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp[tcpflags] & (tcp-syn) != 0' -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:10:11.123456 IP 10.20.30.10.51123 > 10.20.30.40.445: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
12:10:12.234567 IP 10.20.30.10.51124 > 10.20.30.40.3389: Flags [S], seq 987654321, win 64240, options [mss 1460,sackOK,TS val 112 ecr 0,nop,wscale 7], length 0

Ce que cela signifie : MSS 1460 est annoncé sur un tunnel qui ne peut probablement pas supporter 1500 MTU interne de bout en bout. C’est là que les gros transferts vont mourir.

Décision : Mettez en place un clamp MSS sur le egress/ingress du VPN (ou corrigez l’MTU du tunnel pour que les endpoints annoncent la bonne MSS).

Task 6: Clamp MSS with iptables (Linux gateway)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

Ce que cela signifie : Les nouvelles connexions TCP transmises via wg0 verront leur MSS ajustée à 1360, empêchant des segments trop grands même si PMTUD échoue.

Décision : Choisissez la MSS basée sur le path MTU mesuré et la surcharge. Mieux vaut sous‑estimer d’environ 20–40 octets si le chemin change (LTE, Wi‑Fi domestique, bizarreries d’ISP).

Task 7: Verify MSS clamp is taking effect (Linux)

cr0x@server:~$ sudo tcpdump -ni wg0 'tcp[tcpflags] & (tcp-syn) != 0' -c 2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:12:44.111111 IP 10.20.30.10.51200 > 10.20.30.40.445: Flags [S], seq 11111111, win 64240, options [mss 1360,sackOK,TS val 210 ecr 0,nop,wscale 7], length 0
12:12:45.222222 IP 10.20.30.10.51201 > 10.20.30.40.3389: Flags [S], seq 22222222, win 64240, options [mss 1360,sackOK,TS val 211 ecr 0,nop,wscale 7], length 0

Ce que cela signifie : Le SYN annonce maintenant MSS 1360. Vous avez retiré le drame lié à la taille des paquets.

Décision : Retestez la copie SMB et le transfert de fichiers RDP. Si c’est encore mauvais, passez au diagnostic perte/latence.

Task 8: Check if ICMP “fragmentation needed” is being dropped (Linux firewall counters)

cr0x@server:~$ sudo iptables -L INPUT -v -n | head
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 120K  96M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  120  9600 ACCEPT     icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0            icmp type 3 code 4
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

Ce que cela signifie : Vous autorisez explicitement ICMP type 3 code 4 (frag needed). Si ces compteurs sont à zéro pendant que vous reproduisez le problème, le message peut être bloqué en amont ou ne pas être généré.

Décision : Assurez‑vous que ICMP « frag needed » et « packet too big » sont autorisés aux frontières. Si vous ne pouvez pas le garantir, maintenez le clamp MSS.

Task 9: Confirm WireGuard MTU setting (Linux)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
  private key: (hidden)
  listening port: 51820

peer: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.20.30.0/24
  latest handshake: 1 minute, 2 seconds ago
  transfer: 2.31 GiB received, 3.02 GiB sent
  persistent keepalive: every 25 seconds

Ce que cela signifie : WireGuard n’affiche pas l’MTU ici ; vous devez vérifier l’MTU de l’interface via ip link. Le handshake et les transferts confirment que le tunnel est vivant ; l’MTU peut toujours être erronée.

Décision : Si l’MTU de l’interface est trop élevé, réduisez‑le et gardez le clamp MSS pour la sécurité dans des réseaux clients mixtes.

Task 10: Set MTU on a Linux tunnel interface (WireGuard example)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380

Ce que cela signifie : Vous forcez la baisse de l’MTU du tunnel. Les endpoints choisiront généralement une MSS plus petite, réduisant la dépendance à PMTUD.

Décision : Préférez définir correctement l’MTU sur le tunnel et ajouter un clamp MSS à la bordure si vous servez des clients non gérés.

Task 11: Inspect MTU on Windows (client-side reality check)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 8 ifIndex,InterfaceAlias,AddressFamily,NlMtu,InterfaceMetric"
ifIndex InterfaceAlias            AddressFamily NlMtu InterfaceMetric
------ --------------            ------------- ----- ---------------
12     Wi-Fi                      IPv4         1500  25
19     VPN - Corp                  IPv4         1500  35
12     Wi-Fi                      IPv6         1500  25
19     VPN - Corp                  IPv6         1500  35

Ce que cela signifie : Windows croit que l’MTU de l’interface VPN est 1500. Si le chemin sous‑jacemment ne peut pas supporter cela à l’intérieur du tunnel, vous verrez des blocages sauf si PMTUD fonctionne parfaitement.

Décision : Corrigez l’MTU sur le profil d’adaptateur VPN quand c’est supporté, ou appliquez un clamp MSS sur la passerelle VPN pour que les clients n’aient pas à être parfaits.

Task 12: Test SMB throughput and stalls from Windows without guesswork

cr0x@server:~$ powershell -NoProfile -Command "robocopy \\10.20.30.40\share C:\Temp\mtu-test bigfile.bin /J /R:1 /W:1 /NP"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------
  Started : Sunday, December 28, 2025 12:20:01
   Source : \\10.20.30.40\share\
     Dest : C:\Temp\mtu-test\

    Files : bigfile.bin

  Options : /NP /R:1 /W:1 /J

------------------------------------------------------------------------------

         1    \\10.20.30.40\share\bigfile.bin
           0%        0.0 MB         0.0 MB/s        0:00:05

Ce que cela signifie : Si ceci reste bloqué à 0% ou s’arrête à un point constant, vous avez probablement un problème de transport (MTU/MSS, perte, inspection par pare‑feu), pas un problème d’autorisations. L’option /J utilise un I/O non mis en cache, réduisant les illusions côté client.

Décision : Relancez après clamp MSS / changement d’MTU. Si c’est stable immédiatement, vous avez prouvé la cause.

Task 13: Validate OpenVPN-style MSS fix on Linux client (if applicable)

cr0x@server:~$ grep -E 'mssfix|tun-mtu|fragment' -n /etc/openvpn/client.conf
41:mssfix 1360
42:tun-mtu 1400

Ce que cela signifie : OpenVPN peut imposer une plus petite encapsulation. Attention : fragment est généralement déconseillé ; mssfix est habituellement plus sûr.

Décision : Préférez les corrections MSS plutôt que les hacks de fragmentation. Si vous devez toucher l’MTU, faites‑le de façon cohérente aux deux extrémités.

Task 14: Spot retransmits that scream “black hole” (Linux)

cr0x@server:~$ ss -ti dst 10.20.30.40 | head -n 20
ESTAB 0 0 10.20.30.10:51200 10.20.30.40:445
	 cubic wscale:7,7 rto:204 retrans:8/12 lost:0 sacked:0 unacked:1
	 bytes_sent:10485760 bytes_retrans:5242880 bytes_acked:5242880

Ce que cela signifie : De nombreuses retransmissions et des octets retransmis pendant une session SMB sont cohérents avec des paquets perdus. Les trous noirs MTU produisent souvent des retransmissions répétées à un rythme régulier.

Décision : Si le clamp MSS réduit les retransmissions et restaure le débit, conservez‑le. Sinon, recherchez perte, shaping ou middleboxes défaillants.

Trois mini-histoires d’entreprise (anonymisées)

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

Ils avaient une configuration propre : un petit siège, quelques agences, et un VPN IPsec « moderne » entre sites. Le marketing du fournisseur de pare‑feu promettait « optimisation automatique du chemin », donc l’équipe a supposé que l’MTU était géré. Personne n’a mesuré parce que « ça marche ».

Le premier gros incident est survenu un matin de paie. La comptabilité ne pouvait pas ouvrir de grands tableaux stockés sur un partage SMB au siège. Les petits tableaux s’ouvraient instantanément. Les gros se chargeaient à moitié, puis Excel gelait suffisamment longtemps pour que les utilisateurs commencent à forcer la fermeture et à ouvrir des tickets. Les sessions RDP vers le serveur terminal financier restaient connectées mais devenaient lentes dès que quelqu’un copiait des fichiers via des lecteurs redirigés.

L’équipe stockage a été impliquée parce que « les fichiers sont lents ». Ils ont vérifié CPU serveur, latence disque et compteurs SMB. Tout semblait normal. Le réseau a déclaré « pas de perte de paquets » basé sur les erreurs d’interface et quelques pings. L’équipe VPN a insisté que le chiffrement était stable parce que le tunnel restait up.

La mauvaise hypothèse était simple : « si le tunnel est up, l’MTU doit être correct ». Un test ping DF à travers le tunnel a échoué au‑dessus d’une charge utile impliquant un MTU interne autour des hauts 1300. Les messages PMTUD étaient bloqués par un ACL upstream copié-collé des années auparavant. Une fois la MSS clampée sur le pare‑feu de l’agence, le problème a disparu instantanément — pas de changements côté stockage, pas d’optimisation serveur, pas de sorcellerie Excel.

Ils auraient gagné une journée en mesurant la taille des paquets d’abord. À la place, ils ont tenu trois réunions et blâmé un serveur de fichiers qui faisait simplement son travail.

2) L’optimisation qui s’est retournée contre eux

Une autre entreprise voulait « de meilleures performances » pour des ingénieurs distants. Quelqu’un a activé les jumbo frames dans un commutateur virtuel parce que l’équipe SAN avait obtenu de bons résultats avec MTU 9000 dans le data center. Puis ils ont étendu le même profil VLAN à un ensemble de VMs de terminaison VPN par souci de « cohérence ».

Localement, tout était excellent. Le trafic iSCSI s’est amélioré. Le trafic est‑ouest VM semblait super. Sur le VPN, c’était un désastre lent. Certains clients fonctionnaient bien, d’autres avaient des interruptions intermittentes. Les copies SMB sur le VPN démarraient vite, puis s’effondraient. RDP ressemblait à une connexion bas débit dès que quelqu’un déplaçait des fichiers.

Le mécanisme du retour de flamme n’était pas magique. C’était le pire des deux mondes : serveurs et VMs ont commencé à supposer qu’ils pouvaient envoyer des trames plus grandes, tandis que le WAN et les fournisseurs d’accès grand public ne le pouvaient absolument pas. PMTUD aurait dû les sauver, mais un jeu de règles IDS bloquait l’ICMP comme « bruit ». Résultat : un trou noir qui n’apparaissait que sous des tailles de segments plus grandes. Les flux interactifs plus petits restaient majoritairement corrects, ce qui rendait difficile de convaincre la direction qu’il s’agissait d’un problème réseau.

La correction a été d’arrêter de traiter « jumbo frames partout » comme un trait de personnalité. Ils ont rétabli un MTU sensé sur les interfaces face au VPN, activé le clamp MSS et autorisé explicitement ICMP « packet too big » à travers la pile de sécurité. Les performances se sont stabilisées, et le seul dommage durable a été la confiance de l’équipe dans « un MTU pour tous ».

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

Une équipe IT utilisant un mélange de WireGuard pour les développeurs et d’IPsec pour les sites a fait quelque chose d’impopulaire : elle a maintenu un « contrat de taille de paquet » sur une page. Il listait l’MTU attendu par type de tunnel, les hypothèses de surcharge et les valeurs MSS clamp standard qu’ils utilisaient à chaque bord.

Quand un nouveau circuit ISP a été ajouté dans une agence, un ingénieur junior a remarqué que de grosses copies SMB vers le siège se bloquaient, mais seulement depuis cette agence. Avant d’escalader, il a exécuté le test DF standard de leur checklist et documenté la charge utile maximale fonctionnelle. Elle était plus petite que prévu d’environ 60 octets.

Parce qu’ils avaient un contrat, ils n’ont pas débattu pour savoir s’il fallait « tuner SMB » ou « upgrader le serveur de fichiers ». Ils ont immédiatement vérifié le raccordement ISP et ont trouvé une couche d’encapsulation supplémentaire introduite par le CPE du fournisseur. Personne ne l’avait mentionnée ; personne n’a été surpris. Ils ont abaissé l’MTU du tunnel et gardé le clamp MSS cohérent.

Cette agence est passée en production selon le planning. Personne en dehors de l’IT n’a remarqué. Voilà ce à quoi ressemble une bonne exploitation : ennuyeuse, répétable et discrètement correcte.

Stratégies de correction qui tiennent la route

Stratégie A : définir correctement l’MTU de l’interface tunnel (meilleur quand vous contrôlez les deux extrémités)

Si vous gérez les deux extrémités du VPN (site‑à‑site, clients gérés), définir l’MTU sur l’interface tunnel est propre. Cela pousse les endpoints à choisir des tailles de paquets plus petites et réduit fragmentation et retransmissions.

À éviter : des nombres MTU tirés au hasard depuis des forums. Mesurez votre chemin et choisissez des valeurs avec marge.

Stratégie B : clamp MSS TCP à la bordure du VPN (meilleur quand les clients sont désordonnés)

Le clamp MSS est la solution de base. Il ne nécessite pas que chaque client se comporte correctement. Il ne dépend pas du succès de PMTUD. Il force simplement TCP à segmenter de manière conservatrice.

Où appliquer : sur le chemin de forwarding qui emmène le trafic client dans le tunnel (chaîne FORWARD sur passerelles Linux, règle de pare‑feu sur appliances, ou équivalent).

À éviter : clampper trop bas « juste pour être sûr ». Vous pouvez brider le débit si vous choisissez une MSS minuscule. Conservateur c’est bien ; paranoïaque, coûteux.

Stratégie C : corriger le traitement ICMP pour que PMTUD fonctionne (meilleur pour la correction, souvent politiquement difficile)

Si possible, autorisez les messages ICMP essentiels. Vous n’avez pas à autoriser tout l’ICMP. Il faut autoriser les types ICMP nécessaires au fonctionnement d’Internet.

Réalité opérationnelle : les équipes sécurité craignent souvent l’ICMP car il est visible et facile à mal interpréter. Votre travail est d’expliquer que PMTUD n’est pas un luxe optionnel. C’est de la plomberie.

Stratégie D : supprimer les couches d’encapsulation superflues (meilleur pour la santé à long terme)

Parfois l’MTU est erroné parce que vous avez des overlays empilés : GRE sur IPsec sur PPPoE sur LTE, avec une pincée de NAT. Chaque couche vole des octets et ajoute des modes d’échec.

Que faire : simplifiez. Si vous avez besoin à la fois de chiffrement et de routage, préférez un tunnel bien supporté plutôt que de l’imbrication.

Stratégie E : ne « corrigez » pas en forçant TCP‑sur‑TCP sauf si vous aimez la douleur

OpenVPN sur TCP peut masquer certains symptômes mais introduit des comportements catastrophiques sous perte (retransmissions TCP imbriquées). Cela peut rendre les blocages moins nets mais bien plus pénibles.

Recommandation : préférez les tunnels basés sur UDP pour le transport VPN, puis gérez MTU/MSS proprement.

Blague #2 (courte et pertinente) : bloquer l’ICMP pour « améliorer la sécurité » revient à enlever le témoin d’huile pour éviter les alertes moteur.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: SMB share browses, but copying a large file hangs at 0% or a few percent

Cause racine : MSS trop élevée ; les gros segments TCP ne traversent pas le tunnel ; le retour PMTUD est bloqué.

Fix : clamp MSS sur la passerelle VPN (par ex. 1360) et/ou abaisser l’MTU du tunnel ; autoriser ICMP frag‑needed/packet‑too‑big.

2) Symptom: RDP is fine until file copy or clipboard transfer, then the session “freezes”

Cause racine : le canal bulk de RDP heurte un trou noir MTU ; keepalives et petites mises à jour passent toujours.

Fix : idem ci‑dessus ; vérifiez la MSS dans les SYN ; retestez avec un transfert de fichier contrôlé.

3) Symptom: Works from some home ISPs but not others

Cause racine : MTU WAN variable (PPPoE, LTE, bizarreries DOCSIS) plus une hypothèse MTU/MSS fixe sur le tunnel.

Fix : choisissez un MTU tunnel conservateur (ex. 1380–1420 selon la techno), clamp MSS, et ne comptez pas sur PMTUD via des équipements grand public.

4) Symptom: Small pings work; large DF pings fail with no error

Cause racine : trou noir PMTUD ; les messages ICMP sont droppés.

Fix : permettre les types ICMP requis ; si c’est une bataille politique, clamppez la MSS et avancez dans votre vie.

5) Symptom: “We lowered MTU and now everything is slower”

Cause racine : MTU trop faible ; overhead augmenté à cause de segments trop petits ; surcharge CPU en hausse.

Fix : mesurez le MTU maximal réel et fixez MTU/MSS avec une marge minimale. Ne coupez pas à 1200 sauf nécessité.

6) Symptom: Only SMB over VPN is bad; iperf looks okay

Cause racine : test non comparable : iperf peut utiliser des flux différents, une MSS différente, ou tolérer les retransmissions différemment ; SMB révèle la douleur des retransmissions.

Fix : reproduisez avec ping DF et capture de paquets ; vérifiez la MSS ; testez avec un seul flux TCP long similaire à SMB.

7) Symptom: Problems started after “security hardening”

Cause racine : filtrage ICMP ou fonctionnalités d’inspection VPN interférant avec fragmentation/PMTUD ou options TCP.

Fix : autorisez explicitement les types ICMP ; désactivez les fonctionnalités « utiles » cassées (ex. réécriture MSS agressive sans comprendre).

8) Symptom: VPN works for months, then fails intermittently during peak hours

Cause racine : changements de chemin (nouvelle route ISP), variabilité MTU, ou un middlebox qui droppe l’ICMP sous charge.

Fix : clamp MSS (stabilité), puis investiguez le comportement ICMP et le path MTU dans le temps.

Listes de contrôle / plan pas à pas

Étape par étape : de « SMB plante » à transferts stables

1. Choisissez un flux en échec unique : un client, un serveur, un partage, un gros fichier.
2. Confirmez le routage : assurez‑vous que le trafic utilise vraiment l’interface VPN (Linux : ip route get).
3. Exécutez des tests ping DF pour trouver la charge utile maximale fonctionnelle (Linux : ping -M do -s). Documentez‑la.
4. Capturez les paquets SYN et notez la MSS annoncée (Linux : filtre tcpdump pour SYN).
5. Comparez MSS et path MTU mesuré : si la MSS implique 1500 MTU mais que vous mesurez ~1392 MTU, vous avez trouvé la discordance.
6. Implémentez un clamp MSS sur la bordure VPN pour le trafic forwardé ; notez la valeur et pourquoi.
7. Optionnel : baissez l’MTU du tunnel pour que les endpoints annoncent naturellement une MSS plus sûre.
8. Retestez la même copie de fichier. Ne changez pas trois choses à la fois ; gardez le test contrôlé.
9. Vérifiez la diminution des retransmissions (Linux : ss -ti, ou statistiques de capture).
10. Décidez si vous corrigez l’ICMP correctement : autorisez les types ICMP requis ou acceptez le clamp MSS comme contournement permanent.
11. Déployez par couches : pilotez une agence, puis étendez ; évitez des changements MTU massifs simultanés sur toute la flotte.
12. Rédigez un contrat de taille de paquet : MTU/MSS standard par type de VPN, et comment le mesurer. C’est la pratique ennuyeuse qui sauve les weekends.

Checklist politique : quoi autoriser à travers les pare‑feu

• IPv4 : ICMP type 3 code 4 (« Fragmentation needed ») dans les bonnes directions.
• IPv6 : ICMPv6 « Packet Too Big » et découverte de voisinage associée (ne cassez pas les fondamentaux IPv6).
• Limitation de débit : une limitation raisonnable d’ICMP est acceptable ; les suppressions totales ne le sont pas.

Checklist opérationnelle : quoi enregistrer dans les tickets

• Type de réseau client (Wi‑Fi domestique, hotspot LTE, LAN bureau).
• Type de VPN et encapsulation (IPsec NAT‑T, WireGuard, SSL VPN).
• Plus grande charge utile DF ping qui réussit.
• MSS observée dans SYN avant et après modifications.
• Si des messages ICMP frag‑needed/packet‑too‑big ont été vus.
• Si le problème est symétrique (client→serveur et serveur→client).

FAQ

1) Pourquoi les petits fichiers se copient bien mais les gros se bloquent ?

Les transferts courts tiennent souvent dans des segments TCP plus petits ou se terminent avant que la connexion n’atteigne des tailles de paquets problématiques. Les gros transferts maintiennent des segments plus larges et finissent par atteindre la limite MTU réelle du chemin.

2) Si PMTUD existe, pourquoi a‑t‑on besoin du clamp MSS ?

Parce que PMTUD dépend des messages ICMP survivant au trajet retour. Dans de nombreux réseaux d’entreprise et grand public, ces messages sont bloqués, limités en débit ou altérés. Le clamp MSS supprime cette dépendance.

3) Quelle valeur MSS devrais‑je clampper ?

Utilisez la mesure. Trouvez la taille IPv4 maximale fonctionnelle avec un ping DF (par ex. 1392). Soustrayez 40 octets pour les en‑têtes IP+TCP : MSS ≈ 1352. Puis choisissez un clamp légèrement inférieur (par ex. 1340–1352) pour tenir compte de la variabilité.

4) Est‑ce que baisser l’MTU du tunnel est mieux que clampper la MSS ?

Si vous contrôlez les deux extrémités du tunnel et que les clients sont cohérents, définir l’MTU du tunnel est propre. Dans des environnements clients mixtes (réseaux domestiques, portables en mobilité), le clamp MSS à la passerelle est plus robuste.

5) Le chiffrement ou la signature SMB peuvent‑ils provoquer ça ?

Ils peuvent modifier les tailles de paquets et le comportement de débit, ce qui peut exposer plus tôt un problème MTU existant. Mais la cause racine reste le transport : des paquets trop grands pour le chemin et pas de rétroaction fonctionnelle.

6) Pourquoi échoue‑t‑il parfois dans un seul sens ?

Les chemins asymétriques sont courants : ISPs différents, NATs différents, règles de filtrage différentes. Une direction peut autoriser ICMP « packet too big » tandis que l’autre le bloque.

7) Est‑ce que cela s’applique à IPv6 aussi ?

Oui. IPv6 repose fortement sur ICMPv6 pour PMTUD. Si vous bloquez ICMPv6 « Packet Too Big », vous pouvez créer le même comportement de trou noir, souvent avec encore plus de confusion.

8) Puis‑je simplement autoriser la fragmentation et en finir ?

S’appuyer sur la fragmentation est généralement un dernier recours. Cela augmente l’overhead, rend le flux plus sensible à la perte et peut interagir mal avec pare‑feu et NAT. Préférez un MTU/MSS correct.

9) Pourquoi un test de vitesse peut sembler bon alors que SMB plante ?

Différents outils utilisent des motifs différents (multiples flux, tailles de segments différentes, UDP vs TCP). SMB est un flux TCP long et avec état qui est excellent pour exposer des conditions de retransmission.

10) Nous utilisons un appliance pare‑feu tout‑en‑un. Où appliquer le clamp MSS ?

Sur la règle de politique qui autorise le trafic de l’intérieur vers la zone/tunnel VPN, ou sur l’egress de l’interface VPN. Les fournisseurs ont des appellations différentes, mais l’objectif est le même : réécrire la MSS sur les paquets SYN traversant vers le tunnel.

Conclusion : prochaines étapes qui ne vous embarrasseront pas

Si votre VPN de bureau « marche la plupart du temps » mais que les copies SMB volumineuses se bloquent ou que les transferts de fichiers RDP gelent, traitez‑le comme un incident MTU/MSS jusqu’à preuve du contraire. Mesurez le path MTU avec des pings DF. Observez la MSS dans les paquets SYN. Clamppez la MSS à la bordure du VPN. Puis — seulement alors — discutez de l’optimisation SMB ou des performances du stockage.

Prochaines étapes que vous pouvez faire aujourd’hui :

1. Exécutez un test ping DF à travers le VPN et enregistrez la plus grande charge utile fonctionnelle.
2. Capturez un SYN et confirmez la MSS annoncée.
3. Mettez en place un clamp MSS sur la passerelle VPN pour le trafic destiné au tunnel.
4. Optionnel : ajustez l’MTU de l’interface tunnel pour refléter la réalité.
5. Notez vos valeurs MTU/MSS choisies et la mesure qui les justifie. Le vous du futur voudra des justificatifs.