Analyser les problèmes de MTU et de fragmentation et les éviter via GRE/IPsec

Les problèmes de MTU et de fragmentation figurent en tête de la liste des erreurs de performance et d’atteignabilité inattendues sur les VPN site‑à‑site et les tunnels GRE. Je définis ici d’emblée le mot‑clé MTU‑ et fragmentation, car de nombreuses pannes y sont directement liées : des MTU effectives trop faibles dues à des en‑têtes supplémentaires (GRE, IPsec/ESP, NAT‑T) entraînent fragmentation ou rejet de paquets, et lorsque les erreurs ICMP sont bloquées, la découverte de la MTU de chemin (Path MTU Discovery, PMTUD) échoue. Cet article présente de manière pragmatique les causes, des séquences de vérification avec commandes claires, des mesures correctives concrètes et une stratégie de repli sûre pour l’exploitation en production.

Problèmes de MTU et de fragmentation : pourquoi GRE et IPsec provoquent des problèmes de MTU

Un bref aperçu technique : la MTU (Maximum Transmission Unit) est la taille maximale d’un paquet de couche 3 qu’un lien peut transporter sans fragmentation. GRE (Generic Routing Encapsulation) est un protocole de tunnel qui encapsule un paquet interne avec un en‑tête GRE supplémentaire ; l’en‑tête GRE de base fait 4 octets, des options supplémentaires (Key, Sequence) l’allongent. IPsec/ESP (Encapsulating Security Payload) chiffre et authentifie les données, ce qui génère d’autres en‑têtes (ESP Header, Initialization Vector, Padding, ICV/Authentication‑Tag). De plus, le NAT‑Traversal (NAT‑T) ajoute une encapsulation UDP (en‑tête UDP 8 octets). Pris ensemble, ces surcharges réduisent sensiblement la MTU effective pour le trafic interne.

Composants d’overhead typiques

• En‑tête IP externe (IPv4 : 20 octets, IPv6 : 40 octets)
• UDP (optionnel avec NAT‑T) : 8 octets
• ESP Header + Sequence : 8 octets (SPI 4 + Seq 4) + IV (p. ex. 16 octets pour AES) + ICV (p. ex. 12–16 octets) + padding
• En‑tête GRE de base : 4 octets (plus éventuellement 4 octets Key, 4 octets Seq)

Comme la taille exacte varie selon le mécanisme de chiffrement (p. ex. AES‑GCM vs. AES‑CBC + HMAC), le calcul approché n’est qu’indicatif. En pratique, un GRE sur IPsec avec NAT‑T peut facilement ajouter 60–100 octets — suffisamment pour forcer la fragmentation d’une charge utile de 1500 octets.

Pourquoi la PMTUD échoue et quels risques cela comporte

Path‑MTU‑Discovery (PMTUD) est un mécanisme par lequel un hôte tente de déterminer la plus grande taille de paquet utilisable le long d’un chemin. Les routeurs qui voient un paquet trop volumineux et empêchent la fragmentation (DF‑Bit = Don’t Fragment) renvoient un ICMP Type 3 Code 4 (Fragmentation Needed). Deux problèmes surviennent fréquemment en pratique :

• ICMP est bloqué par des pare‑feu ou des filtres, de sorte que le message Fragmentation‑Needed n’atteint jamais l’émetteur et la connexion se bloque. Cela est particulièrement courant avec des tunnels IPsec, car les réponses ICMP vers l’adresse interne ne sont pas toujours correctement renvoyées.
• L’encapsulation modifie les adresses ou ports source/destination (dans le cas de NAT‑T), de sorte que les messages ICMP ne peuvent pas être associés de manière fiable.

Résultat : les connexions TCP restent bloquées lors de l’établissement (fréquent avec TLS/HTTPS), le streaming UDP s’interrompt, ou les paquets sont fragmentés, augmentant la charge CPU et la perte de paquets.

Identifier : Quelles vérifications doivent figurer dans le diagnostic initial ?

Procédez de manière systématique et documentez chaque étape. L’objectif est d’identifier l’endroit où la MTU effective diminue ou où les erreurs ICMP sont supprimées.

1) Vérifier les MTU configurées

Vérifiez la MTU sur toutes les interfaces impliquées : physiques, tunnels et interfaces virtuelles.

ip link show dev eth0
ip link show dev gre1   # Beispiel für GRE-Interface
ip -4 route get 10.0.0.1   # zeigt u.a. die MTU-Informationen

2) Test PMTUD avec ping

Avec le flag DF (Don’t Fragment), testez la taille maximale d’un paquet non fragmenté. La taille de charge utile correcte pour IPv4 est typiquement MTU moins 28 octets (entête IP + ICMP).

# Beispiel: Test auf 1472 Bytes Payload ergibt 1500 Gesamt (IPv4: 20 + ICMP: 8)
ping -M do -s 1472 
# langsam verkleinern, bis ping erfolgreich ist

Si le ping échoue mais que des tailles plus petites fonctionnent, vous avez trouvé la limite. Si un ping à grande MTU échoue malgré une capacité apparente du chemin, il manque généralement le message ICMP Fragmentation Needed.

3) Capture de fragmentation avec tcpdump

Les paquets IPv4 fragmentés peuvent être capturés avec un simple filtre BPF. Ainsi vous repérez les paquets déjà fragmentés dans le trafic en direct :

tcpdump -n -i eth0 'ip[6:2] & 0x1fff != 0'
# Optional: nur Pakete zu/von einer bestimmten IP
tcpdump -n -i eth0 'host 10.0.0.1 and ip[6:2] & 0x1fff != 0'

Explication : dans l’en‑tête IPv4, les flags et l’offset de fragmentation se trouvent aux octets 6–7 ; le masque 0x1fff vérifie un offset > 0 (pas le premier fragment).

4) Vérifier si l’ICMP Fragmentation revient

Si PMTUD échoue, lancez tcpdump des deux côtés et recherchez les ICMP Type 3 Code 4 :

tcpdump -n -i eth0 icmp and 'icmp[0]=3 and icmp[1]=4'
# oder allgemein nach ICMP für Fehlermeldungen
tcpdump -n -i eth0 icmp

Si aucun ICMP « Fragmentation Needed » n’est observable, mais qu’une fragmentation se produit, il y a de fortes chances qu’un pare‑feu bloque l’ICMP ou que les messages ICMP ne soient pas routés correctement en retour.

Mesures concrètes : qu’est‑ce qui aide immédiatement et de façon durable ?

Il existe plusieurs stratégies éprouvées pour éviter les problèmes de MTU et de fragmentation. Choisissez une combinaison adaptée à l’infrastructure et documentez les modifications.

Option A: réduire la MTU du tunnel (rapide, sûr)

Fixez la MTU de l’interface tunnel de manière à prendre en compte l’encapsulation supplémentaire. C’est fiable et sûr, mais cela réduit la taille utile des données.

# Beispiel Linux GRE-Interface auf 1400 setzen
ip link set dev gre1 mtu 1400
# Beispiel für IPsec-Tunnel (veth/ifname) analog

Pourquoi cela fonctionne : en réduisant la taille maximale d’envoi, vous évitez complètement la fragmentation. Quand cela échoue : si des applications envoient des datagrammes UDP très volumineux (p. ex. flux vidéo), la limite reste perceptible.

Option B: MSS‑Clamping pour TCP (recommandé pour Web/SSH/SMB)

Le MSS (Maximum Segment Size) est la plus grande quantité de données TCP dans un segment. De nombreux stacks TCP respectent le MSS lors de l’établissement de la connexion ; le clamping permet aux NAT/routeurs d’ajuster le MSS sur les paquets SYN.

# Beispiel iptables für MSS-Clamping (Linux-Router/Firewall)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Pourquoi cela fonctionne : les nouvelles connexions TCP négocient des segments plus petits et évitent la fragmentation sans modifier la MTU des hôtes finaux. Quand cela échoue : le trafic UDP n’est pas affecté ; les connexions TCP qui réécrivent le MSS peuvent néanmoins poser problème.

Option C: planifier NAT‑T / encapsulation UDP en connaissance de cause

Si IPsec NAT‑Traversal (UDP/4500) est utilisé, 8 octets supplémentaires d’en‑tête UDP s’ajoutent. Intégrez‑les dans la MTU du tunnel ou évitez l’encapsulation UDP si aucune fonction de NAT n’est requise.

Option D: renforcer la robustesse du PMTUD

Assurez‑vous que tous les pare‑feu autorisent les ICMP Type 3 Code 4 (Fragmentation Needed). Si cela n’est pas possible, utilisez une combinaison de réduction de la MTU du tunnel et de MSS‑Clamping.

GRE sur IPsec : considérations particulières

GRE est souvent utilisé lorsque, en plus d’IPv4, d’autres protocoles (p. ex. multicast, IPv6 encapsulé dans IPv4) doivent être transportés via le VPN. En combinaison avec IPsec, les risques liés à la MTU augmentent toutefois :

• GRE ajoute un en‑tête supplémentaire (min. 4 octets), souvent plus en cas d’options.
• IPsec en mode tunnel encapsule en plus ; si un NAT se trouve entre les points de terminaison, s’ajoute NAT‑T UDP.
• L’ICMP interne peut être affecté par IPsec/couches extérieures, ce qui complique le PMTUD.

Recommandation : calculez la somme effective des overheads et réduisez la MTU du tunnel de manière conservatrice. Exemple de calcul pour IPv4 avec NAT‑T, GRE et AES‑GCM (présentation simplifiée) :

physische MTU: 1500
- äußeres IPv4-Header: 20
- UDP (NAT-T): 8
- ESP-Overhead (IV + ICV + ESP Header): z.B. 28
- GRE-Header: 4
= effektive MTU für innere Pakete: 1500 - 60 = 1440

Réglez la MTU du tunnel par exemple sur 1400 pour disposer d’une marge pour le padding/les variations.

Check‑list pratique : procéder étape par étape

1. Documentez le chemin et les équipements impliqués (MTU physiques, pare‑feu, NAT).
2. Réalisez des tests PMTUD par ping avec DF et notez les tailles maximales de la charge utile.
3. Lancez tcpdump sur les deux extrémités du tunnel, recherchez des paquets fragmentés et des ICMP Type 3 Code 4.

Exemples concrets de dépannage

Symptôme : les sites web ne se chargent pas, SSH ne se connecte pas via le tunnel

Procédure :

1. Vérifier le ping avec DF : si de gros paquets ICMP ne passent pas, un problème de PMTUD est probable.
2. Vérifier tcpdump sur le point de terminaison du tunnel : paquets fragmentés ou ICMP manquants ?
3. Appliquer MSS‑Clamping et tester ; si cela résout, le problème TCP est réglé. Sinon, réduire la MTU du tunnel.

Symptôme : le streaming UDP se coupe sur certains flux

L’UDP n’est pas affecté par le MSS‑Clamping. Vérifiez la MTU du tunnel, réduisez‑la et vérifiez si le problème disparaît. Si le streaming envoie des paquets très volumineux, une configuration applicative peut être nécessaire pour émettre des datagrammes UDP plus petits.

Stratégie de rollback et de sécurité

Les modifications de MTU et de pare‑feu doivent être réversibles et s’effectuer dans des fenêtres de maintenance clairement planifiées. Recommandations :

• Avant modification : sauvegarde de la configuration et plan de test clair avec points de mesure (latence, perte de paquets, CPU).
• Procéder par étapes, d’abord sur un segment de test ou en heures creuses.
• Activer la supervision automatique (SNMP/Netflow/alertes IPS) pour détecter immédiatement les régressions.
• Plan de repli : restaurer les anciennes règles MTU/MSS et communiquer de façon documentée aux équipes concernées.

Quand une modification d’architecture est pertinente ?

Si vous subissez régulièrement des surcoûts liés à IPsec/GRE/NAT et de nombreux problèmes avec des applications UDP ou le multicast, évaluez la réduction de la superposition de tunnels (p. ex. utiliser seulement IPsec pour protéger des sous‑réseaux au lieu de GRE pour le multicast) ou l’adoption d’alternatives VPN natives (p. ex. VXLAN avec IPsec, solutions SD‑WAN modernes) si cela réduit le coût opérationnel à long terme. De telles modifications doivent toutefois faire l’objet de projets incluant phases de test et plans de migration.

Résumé et actions concrètes

Les problèmes de MTU et de fragmentation sont, dans les scénarios VPN avec GRE et IPsec, une cause récurrente de coupures de connexion et de baisses de performance difficiles à expliquer. L’ordre pragmatique en exploitation productive est :

1. Diagnostiquer (vérifications MTU, ping avec DF, tcpdump sur les fragments et l’ICMP).
2. Mesures rapides (MSS‑Clamping pour le TCP, réduction temporaire de la MTU du tunnel).
3. Configuration durable (MTU sur le tunnel, règles pare‑feu pour l’ICMP, plan de déploiement documenté).

Si vous suivez systématiquement ces étapes, la majorité des problèmes peut être résolue sans modifications d’architecture profondes. Une ré‑architecture n’est recommandée que si la fragmentation et le blocage de l’ICMP surviennent régulièrement et affectent des services critiques.

Extraits pratiques : commandes essentielles en un coup d’œil

Vérifier la MTU, définir la MTU du tunnel, MSS‑Clamping, filtres tcpdump :

# MTU anzeigen
ip link show dev eth0
ip link show dev gre1

# Tunnel-MTU setzen
ip link set dev gre1 mtu 1400

# MSS-Clamping (Linux Firewall/Router)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Fragmentierte Pakete finden
tcpdump -n -i eth0 'ip[6:2] & 0x1fff != 0'

# ICMP Fragmentation Needed suchen
tcpdump -n -i eth0 icmp and 'icmp[0]=3 and icmp[1]=4'

# PMTUD-Ping (IPv4)
ping -M do -s 1472 

Liens complémentaires et indications de liaison interne

Pour un dépannage plus approfondi, consultez des articles sur le dépannage IPsec avec tcpdump/IKE‑logs, la vérification des règles de pare‑feu et les baselines de monitoring. Prévoyez des liens vers vos runbooks internes : IKE‑log‑analyse, règles ICMP du pare‑feu, tableaux de bord de surveillance pour la fragmentation et alertes de pic CPU.

Conclusion

Les problèmes de MTU et de fragmentation sont évitables si vous planifiez consciemment les overheads de l’encapsulation, maintenez intacts les chemins de signalisation PMTUD ou, en alternative, appliquez le MSS‑clamping et une MTU de tunnel conservatrice. Des tests prudents, des mesures reproductibles avec tcpdump et ping ainsi que des modifications réversibles forment la base d’une exploitation stable. GRE sur IPsec offre des fonctionnalités mais exige une planification rigoureuse de la MTU — sinon vous en paierez le prix par des pertes de paquets, de la latence et des coûts opérationnels accrus.

Les tunnels GRE sont également importants pour ce sujet. Cet article remet ces aspects en perspective de manière claire et montre ce qui compte au quotidien.