Path MTU Discovery troubleshooten: Wenn Pakete mysteriös verschwinden

1. Was Path MTU Discovery eigentlich löst

Jede Netzwerkverbindung entlang eines Pfades kann eine unterschiedliche maximale Paketgröße, die Maximum Transmission Unit, unterstützen. Während lokale Ethernet-Segmente üblicherweise 1500 Byte erlauben, reduzieren Tunnel-Technologien wie VPNs, GRE oder PPPoE die tatsächlich nutzbare Größe durch zusätzlichen Protokoll-Overhead häufig auf Werte zwischen 1400 und 1480 Byte. Ohne einen Mechanismus, der diese Unterschiede erkennt, würden Router entweder Pakete stillschweigend fragmentieren oder, schlimmer, größere Pakete einfach verwerfen.

Path MTU Discovery löst dieses Problem, indem der Absender seine Pakete mit gesetztem Don't Fragment Bit versendet und damit Routern explizit untersagt, das Paket bei Bedarf in kleinere Fragmente aufzuteilen. Stößt ein Router unterwegs auf ein Paket, das größer ist als die MTU des nächsten Hops, verwirft er es und schickt stattdessen eine ICMP-Nachricht vom Typ 3, Code 4, Fragmentation Needed, an den Absender zurück, die zusätzlich die tatsächlich unterstützte MTU des betroffenen Hops enthält. Der Absender reduziert daraufhin die Paketgröße für diese Verbindung und versucht die Übertragung erneut.

2. Warum blockierte ICMP-Nachrichten zum eigentlichen Problem werden

In der Praxis konfigurieren viele Firewalls pauschale Regeln, die sämtlichen ICMP-Verkehr verwerfen, oft aus einem veralteten Sicherheitsverständnis heraus, das ICMP grundsätzlich als potenzielles Angriffsvektor betrachtet. Genau diese Regeln blockieren jedoch auch die für Path MTU Discovery essenzielle Fragmentation-Needed-Nachricht, wodurch der Absender niemals erfährt, dass sein Paket verworfen wurde, und weiterhin Pakete in der ursprünglichen, zu großen Größe sendet.

Dieses Verhalten wird als Black Hole PMTUD bezeichnet, weil Pakete oberhalb der tatsächlichen Pfad-MTU im Netzwerk buchstäblich verschwinden, ohne dass Absender oder Anwendung eine Rückmeldung erhalten. Da kleinere Pakete, etwa der initiale TCP-Handshake oder kurze SSH-Kontrollnachrichten, das Problem nicht auslösen, funktioniert die Verbindung zunächst scheinbar einwandfrei, bis die Anwendung erstmals ein größeres Paket senden möchte, das dann kommentarlos verworfen wird und die Verbindung effektiv einfriert.

3. Typische Symptome: Hängende SSH-Sitzungen und abbrechende HTTP-Antworten

Ein klassisches Symptom ist eine SSH-Verbindung, die sich problemlos aufbaut und auch für einfache Befehle wie ls funktioniert, aber komplett einfriert, sobald ein Befehl mit umfangreicher Ausgabe wie cat auf eine größere Datei oder ein interaktives Programm mit vollem Terminal-Redraw ausgeführt wird. Der SSH-Handshake selbst besteht aus vielen kleinen Paketen unterhalb der problematischen Größenschwelle, während die eigentliche Nutzdatenübertragung erstmals Pakete in voller MTU-Größe erzeugt.

Auf HTTP- und HTTPS-Ebene äußert sich dasselbe Problem als Seiten, die nur teilweise laden, TLS-Handshakes, die erfolgreich abschließen, aber danach hängen bleiben, oder API-Antworten, die bei kleinen JSON-Payloads funktionieren, bei größeren Antworten jedoch systematisch timeout auslösen. Besonders tückisch ist, dass dieses Verhalten oft nur für bestimmte Ziel- oder Quellnetze auftritt, während andere Verbindungen über denselben Server völlig unauffällig funktionieren, weil nur bestimmte Pfadabschnitte tatsächlich eine reduzierte MTU aufweisen.

4. Diagnose Schritt eins: Die tatsächliche Pfad-MTU mit ping ermitteln

Der zuverlässigste erste Diagnoseschritt ist ein gezielter ping mit explizit gesetztem Don't Fragment Bit und variabler Paketgröße, um iterativ die größte noch funktionierende Paketgröße zu ermitteln. Unter Linux wird das Don't Fragment Bit über die Option -M do gesetzt, während -s die Nutzdatengröße ohne den 28 Byte umfassenden IP- und ICMP-Header festlegt, weshalb bei einer Ziel-MTU von 1500 Byte der maximale funktionierende -s Wert bei 1472 liegt.

Schlägt ein ping mit einer bestimmten Größe fehl, während kleinere Größen erfolgreich sind, grenzt eine binäre Suche zwischen den beiden Werten die tatsächliche Pfad-MTU schnell ein. Bleibt jede Fehlermeldung aus und die Pakete verschwinden einfach ohne Antwort, ist das bereits ein starkes Indiz dafür, dass die notwendige ICMP-Rückmeldung irgendwo auf dem Pfad blockiert wird, statt dass tatsächlich keine MTU-Beschränkung vorliegt.

# Testet, ob eine Paketgroesse von 1472 Byte Nutzdaten (1500 MTU) durchkommt
ping -M do -s 1472 -c 3 zielserver.example.com

# Bei Fehlschlag schrittweise kleinere Groessen testen, bis die
# tatsaechliche Pfad MTU gefunden ist
ping -M do -s 1400 -c 3 zielserver.example.com

5. Diagnose Schritt zwei: tracepath für die automatisierte MTU-Ermittlung

Statt die passende Paketgröße manuell per Bisektion zu suchen, automatisiert tracepath genau diesen Prozess und ermittelt gleichzeitig, an welchem Hop entlang des Pfades die MTU tatsächlich reduziert wird. Das Werkzeug sendet Pakete mit steigender TTL, ähnlich wie traceroute, kombiniert dies aber mit Path MTU Discovery und zeigt in der Ausgabe explizit an, an welcher Stelle die zulässige Paketgröße erstmals kleiner wird.

Bricht die tracepath Ausgabe an einem bestimmten Hop ohne weitere pmtu Meldungen ab, deutet das auf eine ICMP-Blockade genau an dieser Stelle hin, wo die eigentlich notwendige Fragmentation-Needed-Nachricht entweder vom betroffenen Router selbst nicht generiert oder auf dem Rückweg von einer Firewall verworfen wird. Diese Information ist besonders wertvoll, wenn mehrere Netzwerksegmente involviert sind, etwa bei einer VPN-Verbindung zwischen zwei Rechenzentren, weil sie eingrenzt, ob das Problem beim eigenen Edge-Router oder erst beim Provider auftritt.

# Pfad MTU und einzelne Hops mit reduzierter MTU automatisch ermitteln
tracepath zielserver.example.com

# Beispielausgabe mit einem Hop, der die MTU auf 1420 reduziert
#  3:  vpn-gateway.example.net       1.2ms pmtu 1420
#  4:  no reply

6. Diagnose Schritt drei: ICMP-Verkehr mit tcpdump direkt beobachten

Um zweifelsfrei zu klären, ob eine ICMP Fragmentation-Needed-Nachricht überhaupt beim ursprünglichen Absender ankommt, hilft eine gezielte tcpdump-Mitschnitt-Session auf dem betroffenen Server während eines gleichzeitig ausgeführten Tests mit großen Paketen. Kommt keine ICMP-Type-3-Code-4-Nachricht an, obwohl der ping oder tracepath Test eindeutig auf eine MTU-Beschränkung hindeutet, liegt der Fehler mit hoher Wahrscheinlichkeit in einer lokalen oder vorgelagerten Firewall-Regel, die eingehende ICMP-Pakete pauschal verwirft.

Besonders in Cloud-Umgebungen und bei Security-Groups, die standardmäßig nur ausgewählte Ports statt gesamter Protokolle öffnen, ist eine fehlende ICMP-Freigabe eine der häufigsten Ursachen für PMTUD-Probleme. Der Mitschnitt macht sichtbar, ob das Problem tatsächlich am eigenen System liegt oder weiter stromaufwärts beim Provider, was die Fehlersuche erheblich beschleunigt, statt auf Verdacht Konfigurationen an mehreren Stellen gleichzeitig zu ändern.

# Eingehenden ICMP Verkehr auf dem Server mitschneiden
tcpdump -ni eth0 icmp

# Während des Mitschnitts in einem zweiten Terminal einen Test mit
# großen Paketen ausloesen, um die Fragmentation Needed Antwort zu pruefen
ping -M do -s 1472 -c 3 zielserver.example.com

7. TCP MTU Probing: PMTUD ohne Abhängigkeit von ICMP

Als Reaktion auf die weitverbreitete ICMP-Blockade im öffentlichen Internet definiert RFC 4821 mit Packetization Layer Path MTU Discovery einen Mechanismus, der die tatsächlich nutzbare Paketgröße direkt auf TCP-Ebene ermittelt, ohne auf eingehende ICMP-Nachrichten angewiesen zu sein. Statt auf eine Fragmentation-Needed-Antwort zu warten, sendet der TCP-Stack testweise größere Pakete und wertet aus, ob eine Bestätigung für diese Pakete eintrifft, wodurch fehlendes ICMP-Feedback keine Blockade mehr verursacht, sondern lediglich als fehlende Bestätigung interpretiert wird.

Unter Linux lässt sich dieses Verhalten über den Kernel-Parameter net.ipv4.tcp_mtu_probing aktivieren, wobei der Wert 1 Probing nur nach erkannten schwarzen Löchern aktiviert und der Wert 2 Probing standardmäßig für alle TCP-Verbindungen erzwingt. Für Server, die regelmäßig mit Netzwerken kommunizieren, deren ICMP-Konfiguration nicht kontrolliert werden kann, etwa bei Verbindungen zu Kundennetzwerken oder Drittanbieter-APIs, ist die Aktivierung von TCP MTU Probing eine wirksame Ergänzung zu MSS-Clamping und ICMP-Freigabe, weil sie das Problem selbst dann abfängt, wenn beide anderen Maßnahmen aus organisatorischen Gründen nicht durchsetzbar sind.

# TCP MTU Probing dauerhaft aktivieren, Wert 1 = nur nach erkanntem
# schwarzem Loch, Wert 2 = immer aktiv für alle TCP Verbindungen
sysctl -w net.ipv4.tcp_mtu_probing=1

# Persistent in der sysctl Konfiguration hinterlegen
echo "net.ipv4.tcp_mtu_probing = 1" >> /etc/sysctl.d/99-pmtud.conf
sysctl --system

8. Fix eins: ICMP Fragmentation Needed gezielt statt pauschal erlauben

Die sauberste und nachhaltigste Lösung ist, ICMP nicht pauschal zu blockieren, sondern gezielt die für Path MTU Discovery notwendigen Nachrichtentypen zuzulassen, während andere ICMP-Typen weiterhin eingeschränkt werden können. Für IPv4 betrifft das konkret ICMP Typ 3 Code 4, für IPv6 das strukturell äquivalente ICMPv6 Typ 2, Packet Too Big, das sogar noch essenzieller ist, weil IPv6-Router grundsätzlich keine Fragmentierung im Netz vornehmen und vollständig auf funktionierende PMTUD angewiesen sind.

Eine entsprechend präzise Firewall-Regel lässt sich sowohl mit klassischem iptables als auch mit dem moderneren nftables Framework umsetzen und sollte fester Bestandteil jeder produktiven Server-Firewall sein, unabhängig davon, wie restriktiv der übrige ICMP-Verkehr gehandhabt wird.

# ICMP Fragmentation Needed für IPv4 gezielt zulassen
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT

# Äquivalent für IPv6: Packet Too Big zulassen
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT

9. Fix zwei: MSS-Clamping als robuste Alternative auf Gateways und Tunneln

Wo sich blockierte ICMP-Nachrichten nicht zuverlässig beheben lassen, etwa weil sie bei einem vorgelagerten Provider verworfen werden, auf den kein Zugriff besteht, schafft MSS-Clamping Abhilfe, indem es das Problem an der Quelle vermeidet, statt auf funktionierende PMTUD zu vertrauen. Die Technik passt die TCP Maximum Segment Size direkt im SYN-Paket während des Verbindungsaufbaus so an, dass die resultierenden Pakete von vornherein unterhalb der tatsächlichen Pfad-MTU bleiben.

Besonders auf VPN-Gateways und Tunnel-Endpunkten, wo der zusätzliche Protokoll-Overhead die effektive MTU regelmäßig reduziert, ist MSS-Clamping die pragmatischere und robustere Lösung gegenüber dem alleinigen Verlassen auf ICMP-basierte PMTUD, weil sie unabhängig von Firewall-Konfigurationen entlang des restlichen Pfades funktioniert und das Problem strukturell verhindert, statt es nur zu erkennen.

# MSS Clamping auf einem VPN Gateway für ausgehenden Traffic über tun0
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

# Äquivalent in nftables Syntax
nft add rule inet mangle forward oifname tun0 tcp flags syn tcp option \
  maxseg size set rt mtu

10. Zusammenfassung

11. FAQ: PMTUD Troubleshooting