MTU sans douleur : pourquoi la taille des paquets casse le VPN et comment le réparer rapidement

Introduction : qu’est-ce que le MTU et pourquoi c’est important

MTU expliqué simplement

Le MTU, c’est la taille maximale d’un paquet IP que votre interface peut transmettre sans fragmentation. En gros, c’est la largeur de la porte réseau : si le paquet est trop grand, il ne passe pas. La porte est fixe, et la « boîte » de données doit y rentrer entière. Quand on parle VPN, cette boîte devient plus volumineuse à cause de l’enveloppe du tunnel, et c’est là que les complications commencent.

La MTU standard pour Ethernet est de 1500 octets. Pour IPv6, la taille minimale garantie sur le chemin est de 1280 octets. En data centers on trouve des jumbo frames de 9000 octets, mais c’est un luxe local. Sur Internet, surtout en 4G/5G, CGNAT ou Wi‑Fi, le MTU disponible varie souvent : parfois 1500, parfois 1472, voire 1400. Nous voulons que notre VPN fonctionne sans surprises, non ?

Pourquoi le MTU est crucial pour un VPN

Tout VPN ajoute une surcharge. Le tunnel ajoute ses propres en-têtes au paquet original. Par exemple, WireGuard sur UDP via IPv4 : les en-têtes IP, UDP et WireGuard totalisent environ 60 octets. Sur 1500 octets de départ, il reste donc environ 1440 octets pour les données utiles dans le tunnel. Si on ne le prend pas en compte, les paquets sont fragmentés, ou pire, perdus car certains réseaux bloquent l’ICMP et votre Path MTU Discovery devient aveugle. Résultat ? Des ralentissements extrêmes, des sites qui bloquent, des images qui ne chargent pas, et des timeouts sur le RDP. Pas cool, hein ?

MTU vs MSS : ne confondez pas les deux

Le MTU concerne le niveau IP. Le MSS, lui, c’est du TCP. Le MSS (Maximum Segment Size) est la taille max des données TCP sans les en-têtes IP et TCP. Quand on parle de « MSS clamping », c’est de forcer la réduction du MSS à la frontière, pour que les flux TCP se segmentent bien d’emblée et n’atteignent pas la limite MTU. C’est un petit coup de pouce, une sécurité sur la route glissante : pas de réparation de la route, mais une baisse des risques d’accident.

Comment un MTU mal configuré casse les connexions VPN

Symptômes : reconnaître le problème à l’écoute

Une image ne charge pas complètement. Le site s’ouvre, mais la moitié des requêtes reste en attente. Le mail part seulement à la deuxième tentative. La vidéo saccade. Le RDP plante en transférant un fichier. Le ping répond, mais le navigateur rame. C’est le classique du « blackhole MTU » : les paquets avec le bit DF trop gros sont bloqués en chemin, le message ICMP « Fragmentation needed » ne revient pas, TCP fait des retransmissions et réduit sa fenêtre. Tout est lent, mais « ça marche à peu près ». Et c’est ça qui énerve le plus.

Cas concrets : WireGuard, OpenVPN, IPsec

WireGuard : souvent on conseille une MTU à 1420. Mais si le fournisseur limite à 1472, et qu’en plus vous ajoutez VLAN ou PPPoE, la MTU peut tomber à 1380-1400. La solution : recalculer et fixer explicitement la MTU de l’interface wg, par exemple 1380 ou 1360. Moins performant mais stable.

OpenVPN UDP : la surcharge est plus lourde, surtout avec le chiffrement TLS et options. Le template courant est tun-mtu 1500 et mssfix 1360, mais en mobile on préfère souvent 1400 en MTU tunnel avec mssfix à 1360 voire 1320. Pas de honte à commencer petit et monter doucement.

IPsec NAT-T : ESP en UDP avec en-têtes supplémentaires. PPPoE enlève encore 8 octets. On ajoute parfois des en-têtes de marquage et conteneurs. Une bonne valeur est entre 1400 et 1440 selon la route et le matériel. En frontière, on active MSS clamping à 1360-1380 pour éviter la fragmentation TCP.

Les points sensibles : mobile, CGNAT, Wi‑Fi

4G/5G et CGNAT ont tendance à réduire le MTU, et ICMP est souvent filtré en chemin. PMTUD casse et on balance les données un peu à l’aveugle. Sur les passerelles Wi‑Fi SOHO, certains fabricants activent une « protection » contre ICMP. De bonnes intentions, zéro résultat. En 2026, les fournisseurs poussent IPv6-only et transport sur QUIC/HTTP3, ce qui ajoute des couches d’encapsulation. On doit encore compter les octets, maintenant aussi pour UDP/QUIC sur TLS.

Fragmentation, PMTUD et bit DF : comprendre la mécanique réseau

Comment fonctionne la fragmentation en IPv4 et IPv6

IPv4 peut fragmenter en chemin : si le paquet est gros et que DF=0, le routeur le découpe et le destinataire le recompose. Sur le papier, c’est bien, mais en pratique les fragments sont plus perdus, les firewalls les bloquent et la perf chute. IPv6 est plus strict : la fragmentation se fait uniquement à l’émetteur, pas en route, et le MTU minimum est de 1280. Les erreurs MTU sont donc plus visibles et douloureuses sur IPv6.

Path MTU Discovery : pourquoi ça casse

PMTUD calcule la MTU minimale sur le chemin grâce aux messages ICMP « Fragmentation needed » ou « Packet too big ». Si ICMP est bloqué, PMTUD devient aveugle, les paquets heurtent le plafond et disparaissent. Voilà le blackhole MTU. En 2026, beaucoup activent PLPMTUD (Packetization Layer PMTUD) au niveau TCP : il teste différentes tailles sans ICMP. Mais les anciens dispositifs et stacks applicatives n’aiment pas toujours ça sur le terrain.

Bit DF, ICMP et règles de filtrage

Le bit DF interdit la fragmentation en chemin. Il est souvent activé, notamment avec VPN où la fragmentation « hors tunnel » est risquée. Si en plus ICMP est coupé, on arrive à une impasse : impossible de fragmenter ni de demander de réduire la taille. Résultat : sessions TCP bloquées. La règle d’or : laissez passer ICMP « Fragmentation needed » et IPv6 « Packet too big ». Toujours. Même si on rêve parfois de renforcer la sécurité au détriment de cette liberté.

MSS clamping : quand et comment ça sauve la mise

MSS vs MTU : clair et concis

Le MSS clamping consiste à modifier le MSS dans les SYN TCP à la frontière, pour empêcher l’envoi de segments trop gros. Ce n’est pas un substitut à une bonne MTU, mais ça sécurise le trafic TCP applicatif. Ça ne règle rien pour l’UDP, mais ça élimine instantanément 80% des problèmes web.

Où configurer le MSS clamping

Sur Linux, on utilise des règles firewall. Avec nftables ou iptables, on ajoute une action qui modifie le MSS dans les paquets SYN. Sur MikroTik, les modules mangle pour TCP. Sur Cisco et Juniper, des politiques firewall ou zone-policies avec tcp-mss. C’est crucial de l’appliquer à la frontière du tunnel, là où le trafic entre ou sort, pour que le MSS corresponde bien au MTU réel de l’encapsulation.

Les écueils

Un MSS trop petit dégrade l’efficacité TCP, trop grand et on bute encore sur le plafond. Si vous modifiez la MTU du tunnel, pensez à recalculer le MSS. Formule classique : MSS = MTU - 40 pour IPv4 (IP+TCP = 20+20), et pareil pour IPv6 (40 octets diffèrent dans la structure). Puis retranchez la surcharge VPN si le clamping est avant l’encapsulation finale.

Diagnostic des problèmes MTU : approche pas à pas

Algorithme rapide

1. Vérifiez s’il y a des symptômes de blackhole : sites partiellement chargés, requêtes longues bloquées, RDP qui coupe.
2. Pinguez avec grosse taille et bit DF activé. Pour IPv4 : « ping -M do -s SIZE adresse ». Pour IPv6 : « ping -s SIZE -M do » varie selon OS. Le but : trouver la taille max sans fragmentation.
3. Lancez tracepath ou « traceroute --mtu » et repérez la baisse du MTU.
4. Contrôlez que les ICMP « Fragmentation needed » et IPv6 « Packet too big » passent. Sinon, configurez la politique réseau pour les autoriser.
5. Baissez la MTU tunnel et activez MSS clamping. Commencez avec une valeur sûre (1360-1380), puis montez progressivement.

Outils en pratique

Le ping avec DF/size : cherchez la taille « -s » maximale sans pertes. Sur Ethernet et WireGuard, la limite est souvent 1380-1420, mais vérifiez votre route. Tracepath donne une estimation du PMTU en chemin. Wireshark révèle les ICMP « Packet too big » reçus et l’ampleur du MTU nécessaire. Sous Linux, « ip link show dev wg0 » et « ip route get » montrent la config actuelle et PMTU.

Spécificités protocolaires

GRE et L2TP ajoutent une surcharge et souvent entrent en conflit avec PPPoE. IPsec ESP NAT-T rajoute UDP et en-têtes ESP — on peut perdre 60-80 octets. WireGuard est propre, mais sensible au blocage ICMP et MTU instable sur le mobile. OpenVPN UDP souffre surtout de la fragmentation à cause des grosses données envoyées et du TLS.

Déterminer le MTU minimal sur le chemin

Méthode simple : recherche binaire avec ping DF à partir de 1400-1500, ajustement fin par pas de 10 puis 2. Retirez ensuite 20-40 octets comme marge de sécurité pour fluctuations. Oui, les chemins changent dynamiquement : un opérateur le jour, un autre la nuit. Une marge raisonnable évite les mauvaises surprises.

Solutions et réglages MTU pour VPN en 2026

Valeurs recommandées selon les protocoles

• WireGuard sur IPv4/UDP : commencez entre 1380 et 1420. Sur 5G et CGNAT plutôt 1380-1400. Pour IPv6 — pas moins de 1280 dans le tunnel, mais à cause de l’encapsulation, visez 1280-1360.
• OpenVPN UDP : tun-mtu entre 1400 et 1500, mssfix à 1360 en point de départ. Sur mobile et Wi‑Fi, préférez 1400/1360 voire moins.
• IPsec ESP NAT-T : MTU tunnel entre 1400 et 1440, MSS entre 1360 et 1380. Avec PPPoE, réduisez encore de 8-12 octets.
• GRE/L2TP : testez la route, souvent 1400-1460, mais avec PPPoE préparez-vous à 1380 ou en dessous.

Automatisation et contrôle

Les scripts qui testent périodiquement le PMTU et ajustent la MTU sont devenus incontournables en 2026. Pour WireGuard, on utilise pre-up hooks dans wg-quick et systemd-networkd avec netlink pour lancer un test court au démarrage du tunnel, calculer la MTU sûre, puis l’appliquer. Une marge de 20 octets sous le test évite bien des heures de support.

Politiques à la frontière

Laissez passer les ICMP « Fragmentation needed » et IPv6 « Packet too big ». Ce n’est pas un trou de sécurité, c’est l’air pour PMTUD. Dans ACL et groupes de sécurité, mettez des exceptions pour ces types. Vérifiez aussi que DPI ou WAF ne bloquent pas ICMP par défaut. C’est une habitude d’anciens manuels, mais en 2026 c’est archaïque.

Tendances 2026 : QUIC, MASQUE, BBRv3, 5G SA

QUIC et MASQUE font que les VPN sur HTTP/3 ne sont plus une curiosité, mais la norme. La surcharge est plus complexe, et PMTUD pour UDP devient doublement crucial. BBRv3 dans les noyaux récents améliore la gestion des pertes, mais ne sauve pas d’une fragmentation aveugle. En 5G SA et slicing réseau, les opérateurs optimisent beaucoup, modifiant le MTU disponible souvent à la volée. Une gestion dynamique avec auto-tuning et monitoring est indispensable.

Sécurité et performance : ne pas faire de mal

Risques de la fragmentation

Les attaques par fragments chevauchants, les classiques « teardrop » sont encore possibles faute de bonnes configs. Autoriser la fragmentation agrandit la surface d’attaque. Le VPN complique avec son encapsulation et le parcours complexe. Mieux vaut l’éviter complètement : réduisez MTU et activez MSS clamping.

QoS, ECN et TFO

Le MTU impacte la qualité QoS : des tailles mal calibrées cassent les classifications et files d’attente. ECN et TCP Fast Open peuvent améliorer la réactivité, mais avec un blackhole MTU ils ne sauvent rien et peuvent aggraver à cause de fausses retransmissions. Commencez par soigner la MTU avant de tuner le reste.

Monitoring SLO

Les indicateurs clés : SRT (temps de réponse serveur), RTT, pertes de paquets, ratio de retransmissions TCP, nombre d’ICMP « Packet too big ». Si RST et FIN augmentent avec des sessions courtes — regardez le MSS. Si un « time-wait storm » survient — réévaluez MTU et clamping. Un tableau simple corrélant « changement MTU – plaintes utilisateurs » révèle souvent tout instantanément.

Checklists et modèles prêts à l’emploi

Checklist rapide MTU pour VPN

1. Déterminez la vraie limite PMTU sur votre chemin, ne croyez pas au « 1500 par défaut ».
2. Fixez une MTU tunnel plus basse avec une marge de 20-40 octets.
3. Activez MSS clamping à la frontière pour TCP (start à 1360, ajustez ensuite).
4. Laissez passer les ICMP « Fragmentation needed » et « Packet too big ».
5. Faites un test A/B sur une partie du trafic, suivez plaintes et métriques.
6. Automatisez la détection PMTU au démarrage des interfaces.

Modèles de réglages : quoi et où ajuster

• WireGuard : fixez la MTU dans la config de l’interface. Commencez entre 1380 et 1420. Testez le ping DF. Baissez encore si PPPoE est présent.
• OpenVPN : utilisez tun-mtu et mssfix. Beaucoup de mobiles ? Démarrez à 1400/1360.
• IPsec : réduisez la MTU sur l’interface tunnel interne et configurez MSS clamping. Prenez en compte NAT-T et PPPoE.

Clouds et fournisseurs : subtilités

En 2026, beaucoup de clouds supportent jumbo frames dans le VPC, mais sur la sortie Internet c’est souvent 1500 ou moins. Soit vous gérez le end-to-end et ICMP, soit préparez-vous à des régressions aléatoires. Mention spéciale aux tunnels interrégionaux sur 5G : le MTU fluctue toute la journée. L’auto-tuning régulier ou un statique malin (1360) vous épargnent bien des soucis.

SOHO et routeurs mobiles

Les routeurs domestiques et semi-pro ont souvent des options cachées « Bloquer ICMP ». Désactivez-les. Activez MSS clamping dans les sections « Firewall » ou « Mangle ». Pour les clients OpenVPN, ne craignez pas de fixer le MTU à 1400 si les performances souffrent à 90% de charge.

Mythes fréquents sur le MTU

« Plus petit MTU = toujours mieux »

Non. Un MTU trop bas diminue l’efficacité : plus d’en-têtes pour la même charge utile, plus de paquets, plus d’interruptions. L’équilibre est clé. Commencez conservateur et montez si la route suit.

« 1500, c’est la loi de la nature »

C’est un standard pratique Ethernet, pas une vérité absolue. Avec PPPoE, tunnels, mobile, c’est souvent moins. Acceptez-le et adaptez-vous aux faits de la route, pas aux mythes des manuels.

« IPv6 est toujours mieux côté MTU »

IPv6 est plus strict sur la fragmentation, donc les erreurs MTU se voient vite. C’est un avantage : la douleur est immédiate et non diluée en retransmissions. Mais « mieux » ne veut pas dire « sans réglages ». Activez PMTUD IPv6, suivez ICMPv6 et ne bloquez pas les « Packet too big ».

Conclusion : résumé et prochaines étapes

En bref

MTU, c’est la physique réseau et un peu de bon sens. Le VPN ajoute des octets, le monde du net du bruit et du filtrage. Soit on respecte PMTUD et on laisse passer ICMP, soit on joue à l’aveugle et on perd des heures au support. La bonne option pour dormir tranquille, non ?

Erreurs à éviter

• Bloquer ICMP « Fragmentation needed » et « Packet too big ».
• Se reposer sur le mythe du « 1500 par défaut » sans tester la route.
• Ne pas activer MSS clamping sur TCP.
• Ignorer les overheads PPPoE et NAT-T dans les calculs.

Que faire ensuite

1. Tester les chemins clés avec DF et tracepath.
2. Configurer la MTU tunnel avec marge et activer MSS clamping.
3. Automatiser la vérification au démarrage des interfaces.
4. Ajouter du monitoring sur les métriques liées au MTU.

FAQ : réponses courtes aux questions brûlantes

Comment savoir vite si c’est un problème de MTU ?

Si « Internet semble là, mais une partie du contenu ne charge pas », en particulier gros fichiers et chargements interrompus — c’est presque sûrement un souci MTU. Testez le ping avec DF et grandes tailles « -s », comparez avec tracepath. Si ICMP est bloqué, c’est quasi-certitude.

Quelle MTU choisir sur WireGuard en 5G ?

Démarrez à 1380. Si c’est stable, montez jusqu’à 1400-1420. Si vous constatez des suspensions étranges aux heures de pointe, retournez à 1380. N’oubliez pas le MSS clamping à 1360.

Peut-on juste activer MSS clamping sans toucher au MTU ?

Cela facilite la vie au TCP, mais ne sauve pas l’UDP et ne résout pas tout. Une bonne MTU + MSS clamping reste l’idéal. Oublier un des deux, c’est laisser traîner un peu de douleur pour les utilisateurs.

Pourquoi chez moi tout roule localement, mais à distance ça plante ?

Les chemins sont différents : la MTU minimale aussi. Au bureau, un seul fournisseur et des 1500 honnêtes, chez un télétravailleur c’est CGNAT, Wi-Fi et routeur « intelligent » coupant l’ICMP. Votre MTU parfaite « sur papier » n’a rien à voir avec la réalité.

IPv6 et VPN : quelle MTU minimale garder ?

Ne descendez pas sous 1280 dans le tunnel. Prenez en compte les overheads d’encapsulation. La majorité des usages roulent très bien entre 1280 et 1360. N’oubliez pas d’autoriser ICMPv6 « Packet too big ».

Est-il critique d’autoriser ICMP en production ?

Oui, c’est vital. C’est comme conduire sans phares sur autoroute. Il existe PLPMTUD et autres astuces, mais économiser sur ICMP coûte cher en support et satisfaction utilisateur.

Qu’en est-il de QUIC/HTTP3 et MTU ?

QUIC sur UDP est sensible à la perte de grosses datagrammes. Une MTU incorrecte provoque des lags et des variations de vitesse bizarres. Vérifiez le PMTU, choisissez une valeur prudente, et maintenez le MSS clamping pour TCP qui reste souvent à côté.