MTU- und Fragmentierungsprobleme analysieren und über GRE/IPsec vermeiden

MTU- und Fragmentierungsprobleme stehen bei Site‑to‑Site‑VPNs und GRE‑Tunneln ganz oben auf der Liste unerwarteter Performance‑ und Erreichbarkeitsfehler. Das Fokus‑Keyword MTU- und Fragmentierungsprobleme erkläre ich hier gleich zu Beginn, weil viele Ausfälle direkt damit zusammenhängen: Zu kleine effektive MTUs durch zusätzliche Header (GRE, IPsec/ESP, NAT‑T) führen zu Fragmentierung oder verworfenen Paketen, und wenn ICMP‑Fehler blockiert sind, schlägt die Path‑MTU‑Discovery (PMTUD) fehl. Dieser Beitrag zeigt praxisnah Ursachen, Prüfsequenzen mit klaren Befehlen, konkrete Gegenmaßnahmen und eine sichere Rückfallstrategie für den produktiven Betrieb.

MTU- und Fragmentierungsprobleme: Warum GRE und IPsec MTU‑Probleme verursachen

Ein kurzer technischer Überblick: MTU (Maximum Transmission Unit) ist die maximale Größe eines Layer‑3‑Pakets, das ein Link ohne Fragmentierung transportieren kann. GRE (Generic Routing Encapsulation) ist ein Tunnelprotokoll, das ein inneres Paket mit einem zusätzlichen GRE‑Header kapselt; der Basis‑GRE‑Header ist 4 Bytes, zusätzliche Optionen (Key, Sequence) erweitern ihn. IPsec/ESP (Encapsulating Security Payload) verschlüsselt und authentifiziert Daten, dabei entstehen weitere Header (ESP Header, Initialization Vector, Padding, ICV/Authentifizierungs‑Tag). Zusätzlich erzeugt NAT‑Traversal (NAT‑T) eine UDP‑Kapselung (UDP‑Header 8 Bytes). Zusammengenommen reduzieren diese Overheads die effektive MTU für den inneren Datenverkehr spürbar.

Typische Overhead‑Komponenten

• Äußeres IP‑Header (IPv4: 20 Bytes, IPv6: 40 Bytes)
• UDP (optional bei NAT‑T): 8 Bytes
• ESP Header + Sequence: 8 Bytes (SPI 4 + Seq 4) + IV (z.B. 16 Bytes bei AES) + ICV (z.B. 12–16 Bytes) + Padding
• GRE Basis‑Header: 4 Bytes (plus ggf. 4 Bytes Key, 4 Bytes Seq)

Weil sich die genaue Größe je nach Verschlüsselungsmechanismus (z. B. AES‑GCM vs. AES‑CBC + HMAC) unterscheidet, bietet die pauschale Rechnung nur Orientierung. In der Praxis können bei GRE über IPsec mit NAT‑T leicht 60–100 Bytes zusätzlich anfallen – genug, um ein 1500‑Byte Payload in mehrere Fragmente zu zwingen.

Warum PMTUD scheitert und welche Risiken das birgt

Path‑MTU‑Discovery (PMTUD) ist ein Mechanismus, bei dem ein Host versucht, die größte nutzbare Paketgröße entlang des Pfads zu ermitteln. Router, die ein zu großes Paket sehen und Fragmentierung verhindern (DF‑Bit = Don’t Fragment), senden ein ICMP Type 3 Code 4 (Fragmentation Needed) zurück. Zwei Probleme treten in der Praxis häufig auf:

• ICMP wird durch Firewalls oder Filter blockiert, sodass die Fragmentation‑Needed‑Nachricht den Sender nie erreicht und die Verbindung effektiv abstürzt. Das ist besonders bei IPsec‑Tunnels verbreitet, weil die ICMP‑Antworten zur inneren Adresse nicht immer korrekt zurückgeschleust werden.
• Die Kapselung ändert die Absender/Empfänger‑Adressen oder Ports (bei NAT‑T), sodass ICMP‑Meldungen nicht sinnvoll zugeordnet werden können.

Das Resultat: TCP‑Verbindungen bleiben beim Verbindungsaufbau stecken (häufig bei TLS/HTTPS), UDP‑Streaming bricht ab oder Pakete werden fragmentiert und erhöhen CPU‑Last und Paketloss.

Erkennen: Welche Prüfungen gehören in die Erstdiagnose?

Starten Sie systematisch und dokumentieren Sie jeden Schritt. Ziel ist es, die Stelle zu finden, an der die effektive MTU kleiner wird oder ICMP‑Fehler unterdrückt werden.

1) Prüfen der konfigurierten MTUs

Überprüfen Sie die MTU auf allen beteiligten Interfaces: physisch, Tunnel und virtuelle Interfaces.

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) PMTUD‑Test mit ping

Mit dem DF‑Flag (Don’t Fragment) testen Sie, wie groß ein unfragmentiertes Paket sein darf. Die korrekte Nutzlastgröße für IPv4 ist typischerweise MTU minus 28 Bytes (IP + ICMP Header).

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

Wenn der Ping fehlschlägt, aber kleinere Werte funktionieren, haben Sie die Grenze gefunden. Gelingt kein hoher MTU‑Ping trotz offensichtlicher Pfadkapazität, fehlt meist das ICMP Fragmentation Needed.

3) Fragmentierungs‑Capture mit tcpdump

Fragmentierte IPv4‑Pakete lassen sich mit einem einfachen BPF‑Filter erfassen. So finden Sie bereits fragmentierte Pakete im Live‑Traffic:

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'

Erklärung: Im IPv4‑Header befinden sich Flags und Fragment‑Offset in Bytes 6–7; die Maske 0x1fff prüft auf einen Offset > 0 (Nicht‑Erstfragment).

4) Prüfen, ob ICMP‑Fragmentation zurückkommt

Wenn PMTUD scheitert, sollten Sie auf beiden Seiten tcpdump laufen lassen und nach ICMP Type 3 Code 4 suchen:

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

Wenn keine ICMP Fragmentation Needed zu sehen ist, aber Fragmentierung auftritt, ist die Wahrscheinlichkeit hoch, dass eine Firewall ICMP blockiert oder die ICMP‑Meldungen nicht korrekt zurückgeroutet werden.

Konkrete Gegenmaßnahmen: Was hilft sofort und dauerhaft?

Es gibt mehrere bewährte Strategien, um MTU‑ und Fragmentierungsprobleme zu vermeiden. Wählen Sie eine Kombination passend zur Infrastruktur und dokumentieren Sie die Änderungen.

Option A: Tunnel‑MTU reduzieren (schnell, sicher)

Setzen Sie die MTU am Tunnel‑Interface so, dass die zusätzliche Kapselung berücksichtigt ist. Das ist zuverlässig und sicher, beeinflusst aber die nutzbare Payload‑Größe.

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

Warum es funktioniert: Durch Reduktion der Sendefragmentgröße vermeiden Sie Fragmentierung vollständig. Wann es scheitert: Wenn Anwendungen sehr große UDP‑Datagramme senden (z. B. Videostreams), dann bleibt Limit spürbar.

Option B: MSS‑Clamping für TCP (empfohlen für Web/SSH/SMB)

MSS (Maximum Segment Size) ist die größte TCP‑Datenmenge in einem Segment. Viele TCP‑Stacks respektieren MSS beim Verbindungsaufbau; durch Clamping passen NAT/Router das MSS bei SYN‑Paketen an.

# 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

Warum es funktioniert: Neue TCP‑Verbindungen vereinbaren kleinere Segmente und vermeiden Fragmentierung ohne MTU‑Änderungen auf Endhosts. Wann es scheitert: UDP‑Traffic bleibt unberührt; TCP‑Verbindungen, die MSS überschreiben, können trotzdem Probleme verursachen.

Option C: NAT‑T / UDP‑Encapsulation bewusst planen

Wenn IPsec NAT‑Traversal (UDP/4500) verwendet, fallen zusätzliche 8 Bytes UDP‑Header an. Planen Sie diese in die Tunnel‑MTU ein oder vermeiden Sie UDP‑Encapsulation, wenn keine NAT‑Funktion benötigt wird.

Option D: PMTUD‑Robustheit erhöhen

Stellen Sie sicher, dass alle Firewalls ICMP Type 3 Code 4 zulassen (Fragmentation Needed). Wenn das nicht möglich ist, nutzen Sie eine Kombination aus Tunnel‑MTU‑Reduktion und MSS‑Clamping.

GRE über IPsec: Spezielle Erwägungen

GRE wird oft genutzt, wenn neben IPv4 auch andere Protokolle (z. B. Multicast, IPv6 innerhalb IPv4) über das VPN transportiert werden sollen. In Kombination mit IPsec erhöhen sich jedoch die MTU‑Risiken:

• GRE bringt zusätzlichen Header (mind. 4 Bytes), oft mehr bei Optionen.
• IPsec in Tunnel‑Mode kapselt zusätzlich; wenn NAT zwischen den Endpunkten sitzt, kommt UDP‑NAT‑T hinzu.
• Inneres ICMP kann von IPsec/Außenschichten beeinflusst werden, was PMTUD erschwert.

Empfehlung: Berechnen Sie die effektive Overhead‑Summe und reduzieren Sie die Tunnel‑MTU konservativ. Beispielrechnung für IPv4 mit NAT‑T, GRE und AES‑GCM (vereinfachte Darstellung):

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

Setzen Sie das Tunnel‑MTU auf z. B. 1400, um Puffer für Padding/Variationen zu haben.

Praxis‑Checkliste: Schritt für Schritt vorgehen

1. Dokumentieren Sie Pfad und beteiligte Geräte (physische MTUs, Firewalls, NATs).
2. Führen Sie PMTUD‑Ping‑Tests mit DF durch und notieren Sie die maximalen Payload‑Größen.
3. Starten Sie tcpdump auf beiden Tunnelenden, suchen Sie nach fragmentierten Paketen und ICMP Type 3 Code 4.
4. Wenn ICMP fehlt: erlauben Sie gezielt Fragmentation Needed in Firewalls; wenn das nicht möglich ist, fahren Sie mit Schritt 5 fort.
5. Setzen Sie temporär MSS‑Clamping auf den Border‑Routern und testen Sie TCP‑Workloads.
6. Reduzieren Sie die Tunnel‑MTU auf beiden Seiten konservativ (z. B. 1400) und testen Sie erneut.
7. Überwachen Sie CPU/MTU‑bezogene Metriken; fragmentierte Pakete verursachen CPU‑Last bei Routern/Firewalls.
8. Dokumentieren Sie die Änderung im Change‑Log und planen Sie ein Zeitfenster für ein reversibles Rollback.

Konkrete Troubleshooting‑Beispiele

Fehlerbild: Webseiten laden nicht, SSH verbindet nicht über den Tunnel

Vorgehen:

1. Ping mit DF prüfen: Wenn kein großes ICMP möglich, PMTUD‑Problem wahrscheinlich.
2. tcpdump auf Tunnelendpunkt prüfen: Fragmentierte Pakete oder fehlende ICMP?
3. MSS‑Clamping setzen und testen; wenn das hilft, ist TCP‑Problem gelöst. Falls nicht, Tunnel‑MTU reduzieren.

Fehlerbild: UDP‑Streaming bricht bei bestimmten Streams ab

UDP wird nicht durch MSS‑Clamping beeinflusst. Prüfen Sie Tunnel‑MTU, reduzieren Sie diese und prüfen Sie, ob das Problem verschwindet. Falls Streaming sehr große Pakete sendet, kann eine Anwendungskonfiguration nötig sein, damit sie kleinere UDP‑Datagrams nutzt.

Rollback‑ und Sicherheitsstrategie

Änderungen an MTU und Firewall müssen reversibel sein und in klar abgestimmten Wartungsfenstern stattfinden. Empfehlungen:

• Vor Änderung: Konfigurations-Backup und ein klarer Testplan mit Messpunkten (Latenz, Paketloss, CPU).
• Änderung schrittweise, zuerst auf Testsegment oder Off‑Peak.
• Automatische Überwachung (SNMP/Netflow/IPS‑Alarme) aktivieren, um Regressionen sofort zu erkennen.
• Fallback: Wiederherstellen der alten MTU/MSS‑Regeln und dokumentierten Kommunikation an betroffene Teams.

Wann ist eine Architekturänderung sinnvoll?

Wenn Sie regelmäßig hohe Overheads durch IPsec/GRE/NAT haben und viele Probleme mit UDP‑Anwendungen oder Multicast bestehen, sollten Sie prüfen, ob eine Reduzierung der Tunnelkapselung (z. B. nur IPsec zum Schützen einzelner Subnetze statt GRE für Multicast) oder der Einsatz von nativen VPN‑Alternativen (z. B. VXLAN mit IPsec, moderne SD‑WAN Lösungen) langfristig weniger Betriebsaufwand verursacht. Solche Änderungen sind jedoch Projekten mit Testphasen und Migrationsplänen vorbehalten.

Zusammenfassung und konkrete Handlungsanweisung

MTU‑ und Fragmentierungsprobleme sind in VPN‑Szenarios mit GRE und IPsec eine wiederkehrende Ursache für schlecht erklärbare Verbindungsabbrüche und Performance‑Einbrüche. Die pragmatische Reihenfolge im produktiven Betrieb ist:

1. Ermitteln (MTU‑Checks, ping mit DF, tcpdump auf Fragmenten und ICMP).
2. Schnelle Maßnahmen (MSS‑Clamping für TCP, temporäre Tunnel‑MTU‑Reduktion).
3. Dauerhafte Konfiguration (MTU auf Tunnel, Firewall‑Regeln für ICMP, dokumentiertes Rolling‑Plan).

Wenn Sie diese Schritte systematisch durchlaufen, lässt sich die Mehrzahl der Probleme beheben, ohne tiefgreifende Architekturänderungen. Nur wenn Fragmentierung und ICMP‑Blockierung regelmäßig auftreten und kritische Dienste betroffen sind, ist eine Re‑Architektur empfehlenswert.

Praxis‑Snippets: Wichtige Befehle auf einen Blick

MTU prüfen, Tunnel‑MTU setzen, MSS‑Clamping, tcpdump‑Filter:

# 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 

Weiterführende Links und interne Verlinkungs‑Hinweise

Für tieferes Troubleshooting empfehlen sich Beiträge zu IPsec‑Troubleshooting mit tcpdump/IKE‑Logs, Firewall‑Regelprüfung und Monitoring‑Baselines. Planen Sie Links zu Ihren internen Runbooks: IKE‑Log‑Analyse, Firewall‑ICMP‑Regeln, Monitoring‑Dashboards für Fragmentierung und CPU‑Spike‑Alerts.

Fazit

MTU- und Fragmentierungsprobleme sind vermeidbar, wenn Sie die Overheads der Kapselung bewusst planen, PMTUD‑Signalpfade intakt halten oder alternativ MSS‑Clamping und eine konservative Tunnel‑MTU einsetzen. Konservative Tests, reproduzierbare Messungen mit tcpdump und ping sowie rollbare Änderungen sind die Grundlage eines stabilen Betriebs. GRE über IPsec bietet Funktionalität, verlangt aber disziplinierte MTU‑Planung – sonst zahlen Sie mit Paketverlusten, Latenz und erhöhten Betriebsaufwänden.

Für dieses Thema sind auch Gre Tunneling wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.