MTU-Mismatch in Tunnels/VPN: Ursache für „Works on Small Payloads“

MTU-Mismatch in Tunnels/VPN ist eine der klassischsten Ursachen für das irritierende Produktionssymptom „Works on Small Payloads“: Kleine Requests funktionieren zuverlässig, aber größere Antworten hängen, brechen sporadisch ab oder werden extrem langsam. In Incident-Triage wirkt das oft wie ein zufälliges Netzwerkproblem – mal geht es, mal nicht – und genau deshalb kostet es Teams viel Zeit. Die Root Cause ist jedoch häufig deterministisch: Ein Pfad in Ihrem Netzwerk (oder im Provider-Underlay) kann keine so großen Pakete transportieren, wie Sender und Empfänger annehmen. Besonders anfällig sind Umgebungen mit VPN, IPsec, GRE, VXLAN, Geneve, WireGuard, Service Mesh, Cloud-Hybrid-Verbindungen oder Multi-Region-Tunneling. Durch Encapsulation entsteht zusätzlicher Overhead, wodurch die effektive MTU sinkt. Wenn Path MTU Discovery (PMTUD) nicht sauber funktioniert – etwa weil ICMP „Packet Too Big“ oder „Fragmentation Needed“ gefiltert wird – entsteht ein sogenanntes Blackhole: TCP-Verbindungen bauen sich auf, aber bei größeren Segmenten kommt es zu Retransmissions, Timeouts und scheinbar „mysteriösen“ Disconnects. Dieser Artikel erklärt verständlich, wie MTU-Mismatch entsteht, warum kleine Payloads täuschen, wie Sie das Problem in Produktion beweisen und welche pragmatischen Mitigations dauerhaft helfen.

MTU, PMTU und warum Tunnels/VPN das Risiko erhöhen

Die MTU (Maximum Transmission Unit) beschreibt, wie groß ein Paket auf einem Link maximal sein darf. Für Ethernet sind 1500 Bytes im Alltag typisch, aber das ist nur ein lokaler Wert. Entscheidend ist die Path MTU (PMTU): die kleinste MTU entlang des gesamten Pfades zwischen zwei Endpunkten. PMTUD ist der Mechanismus, mit dem Hosts die PMTU ermitteln und ihre Paketgröße anpassen. Für IPv4 basiert das klassische PMTUD auf dem DF-Bit und ICMP „Fragmentation Needed“ (siehe RFC 1191). Für IPv6 ist ICMPv6 „Packet Too Big“ zentral (siehe RFC 8201).

Tunnels und VPN machen MTU-Mismatch wahrscheinlicher, weil sie zusätzliche Header hinzufügen. Diese Encapsulation ist aus Sicht des Underlays „extra Nutzlast“, die auf den gleichen Link passen muss. Wenn Sie im Overlay weiterhin 1500 Bytes senden, kann das Underlay überlaufen und Pakete verwerfen oder fragmentieren (wenn erlaubt). Viele moderne Pfade fragmentieren nicht zuverlässig oder möchten Fragmentierung vermeiden – und dann wird aus „ein bisschen Overhead“ ein Produktionsproblem.

Warum „Works on Small Payloads“ ein typisches MTU-Symptom ist

Das Symptom entsteht, weil kleine Payloads typischerweise unterhalb der effektiven PMTU bleiben. Ein kleiner HTTP-Request oder eine kurze JSON-Antwort passt auch dann noch in ein Paket, wenn die PMTU durch Encapsulation von 1500 auf z. B. 1420 oder 1380 Bytes sinkt. Sobald jedoch eine Antwort größer wird (z. B. größere Header, Cookies, JWTs, Kompression, Datei-Download, große gRPC-Messages), überschreitet sie die PMTU. Dann passiert eines der folgenden Dinge:

• Fragmentierung ist verboten oder unterdrückt: Das Paket wird verworfen, und ohne funktionierendes PMTUD merkt der Sender nicht, warum.
• ICMP wird gefiltert: „Packet Too Big“ oder „Fragmentation Needed“ erreicht den Sender nicht; der Sender sendet weiter zu große Pakete.
• Zwischenkomponenten fragmentieren/defragmentieren inkonsistent: Fragmente gehen verloren, Retransmissions steigen, Tail Latency explodiert.

Das Ergebnis ist aus Sicht der Applikation nicht „MTU“, sondern: Timeouts, Retries, sporadische Verbindungsabbrüche, hängende Downloads oder gRPC-Streams, die nach einigen KB/MB stoppen. In IPv6 ist das Blackhole-Phänomen sogar explizit dokumentiert: Verbindungen können den Handshake schaffen, aber beim Datentransfer hängen bleiben (siehe Abschnitt in RFC 8201, häufig als „black-hole connection“ beschrieben).

Wo MTU-Mismatch in der Praxis entsteht

Damit Troubleshooting zielgerichtet bleibt, lohnt sich eine mentale Karte der typischen MTU-Bruchstellen. In Produktion finden sich MTU-Mismatches häufig an Übergängen zwischen Netzwerkdomänen:

• VPN/IPsec/SD-WAN: zusätzlicher Overhead durch Verschlüsselung/Encapsulation, häufig kombiniert mit strikten Firewall-Regeln.
• Overlay-Netze (VXLAN/Geneve/GRE): Encapsulation auf Node- oder Fabric-Ebene; CNI-Defaults passen nicht zum Underlay.
• Hybrid Cloud: On-Prem ↔ Cloud via Tunnel, Direct Connect/ExpressRoute plus zusätzliche Appliances.
• Service Mesh: Sidecars verändern Pfade, MTU und Paketgrößen; mTLS kann Header/Record-Größen beeinflussen.
• Multi-Hop Egress: NAT, Firewall, Proxy-Ketten; ICMP wird oft „aus Sicherheitsgründen“ blockiert.

Besonders gefährlich ist die Kombination aus Encapsulation und ICMP-Filterung. Dann scheitert PMTUD und das Problem wirkt zufällig, obwohl es streng von Paketgröße und Pfad abhängt.

MTU-Overhead verstehen: Warum 1500 nicht gleich 1500 ist

Operativ hilft eine einfache Rechnung: Die effektive MTU im Overlay ist die Underlay-MTU minus Overhead. Der Overhead hängt vom Tunneltyp ab (IP-Header, UDP, ESP, WireGuard, VXLAN/Geneve, ggf. zusätzliche Optionen). Eine vereinfachte Formel lautet:

$\mathrm{MTU}{\mathrm{overlay}}_{}=\mathrm{MTU}{\mathrm{underlay}}_{}–\mathrm{Overhead}$

Wenn das Underlay 1500 Bytes unterstützt und Ihr Tunnel z. B. 80 Bytes Overhead erzeugt, sollten Sie im Overlay nicht mehr als 1420 Bytes MTU annehmen. Wenn zusätzlich ein Overlay-in-Overlay entsteht (z. B. VXLAN über WireGuard), sinkt die nutzbare MTU weiter. Wichtig ist weniger die exakte Zahl als die Konsequenz: Jede Encapsulation reduziert die „freie“ Nutzlast – und ohne Anpassung werden große Pakete zum Risiko.

MSS statt MTU: Der praxisnahe Hebel für TCP

Viele Produktionsprobleme betreffen TCP (HTTP, gRPC, Datenbanken). Hier ist die MSS (Maximum Segment Size) oft der praktischere Stellhebel. MSS beschreibt die maximale TCP-Payload pro Segment ohne IP- und TCP-Header. Vereinfacht:

$\mathrm{MSS}=\mathrm{MTU}–\mathrm{IP\_Header}–\mathrm{TCP\_Header}$

Bei IPv4 ohne Optionen sind IP-Header typischerweise 20 Bytes und TCP-Header 20 Bytes; bei IPv6 ist der IP-Header 40 Bytes. Diese Rechnung ist bewusst vereinfacht (Optionen wie TCP Timestamps erhöhen Header). Dennoch hilft sie, das Prinzip zu verstehen: Wenn Ihre effektive MTU sinkt, muss auch die MSS sinken – sonst entstehen zu große Segmente, die auf dem Pfad nicht durchkommen.

In der Praxis wird dieses Prinzip oft über MSS Clamping umgesetzt, z. B. am VPN-Gateway, am Firewall-Edge oder im Kubernetes-Node, um TCP-Segmente „automatisch“ klein genug zu halten. Das ist eine typische Mitigation, wenn PMTUD nicht zuverlässig ist oder ICMP nicht freigegeben werden kann.

PMTUD und Blackholes: Wenn ICMP fehlt, wird MTU zum Incident

Das klassische PMTUD-Modell verlässt sich auf ICMP-Meldungen. Bei IPv4 signalisiert ein Router per ICMP, dass ein Paket zu groß ist und wegen DF nicht fragmentiert werden konnte (RFC 1191). Bei IPv6 ist Fragmentierung durch Router nicht vorgesehen; der Sender muss auf ICMPv6 „Packet Too Big“ reagieren (RFC 8201).

In vielen Unternehmens- und Cloud-Setups wird ICMP jedoch pauschal blockiert oder nur teilweise erlaubt. Das führt zu einem PMTUD-Blackhole: Große Pakete verschwinden, ohne dass der Sender die PMTU lernt. Die Symptome sind dann besonders tückisch:

• Handshake ok, Datenfluss hängt: TCP SYN/SYN-ACK/ACK sind klein, aber Datenpakete groß.
• Retransmissions steigen: TCP interpretiert das Ausbleiben von ACKs als Verlust und sendet erneut.
• Tail Latency und Timeouts: Applikations-Timeouts schlagen zu, Retries verstärken die Last.

Als robustere Alternative existiert Packetization Layer PMTUD (PLPMTUD), das ohne ICMP auskommen kann, indem es im Transport „probt“ (siehe RFC 4821). Für Datagramm-Transporte gibt es DPLPMTUD (siehe RFC 8899). Für viele Produktionsumgebungen ist das relevant, weil ICMP-Policies selten perfekt sind.

Wie Sie MTU-Mismatch in Produktion beweisen

MTU-Probleme sind mess- und beweisbar, wenn Sie systematisch vorgehen. Ziel ist es, den Zusammenhang zwischen Paketgröße und Fehler zu zeigen, statt nur „irgendwas ist langsam“ zu beobachten.

Paketgrößen-Test: Der schnellste Reality-Check

Ein bewährter Ansatz ist, kontrolliert mit unterschiedlichen Paketgrößen zu testen. Operativ bedeutet das: Sie suchen die maximale Paketgröße, die zuverlässig durchkommt. Das lässt sich mit Ping-Tests (mit DF/„don’t fragment“) oder mit tools wie „tracepath“ erreichen. Die konkrete Toolwahl hängt von OS und Berechtigungen ab, aber das Prinzip bleibt gleich: Wenn 1200 Bytes funktionieren und 1472 Bytes hängen, haben Sie einen starken MTU-Hinweis.

• Wenn kleine Größen stabil sind und größere scheitern, ist MTU/PMTU hochwahrscheinlich.
• Wenn der Schwellenwert konstant ist, passt das zu einem festen kleinsten Link (PMTU).
• Wenn der Schwellenwert je Pfad variiert, deutet das auf unterschiedliche Underlay-Wege oder Policy-Routen hin.

Symptome im Monitoring: Welche Signale passen zu MTU-Blackholes?

MTU-Mismatch hinterlässt typische Spuren in Telemetrie. Besonders nützlich sind Kombinationen aus Transport- und Applikationssignalen:

• TCP Retransmissions und ggf. steigende RTO-Events: deuten auf „Pakete kommen nicht durch“ hin.
• Connect ok, Request hängt: Connect-Zeit bleibt normal, aber Read/Response-Timeouts steigen.
• gRPC: Streams starten, aber größere Messages führen zu Abbrüchen oder „UNAVAILABLE“.
• HTTP: Kleine Endpoints ok, große JSON/Downloads scheitern, oft mit Timeouts statt klarer Fehlermeldung.

Wichtig ist hier die Segmentierung: Tritt es nur über VPN auf? Nur zwischen bestimmten Zonen? Nur über einen bestimmten Egress? MTU-Probleme sind häufig pfadabhängig.

Typische Root Causes in Tunnels/VPN

Wenn Sie den MTU-Verdacht haben, ist die nächste Frage: Warum ist die PMTU kleiner als erwartet? In der Praxis sind diese Ursachen besonders häufig:

• Encapsulation-Overhead nicht berücksichtigt: Tunnel wurde „auf 1500“ belassen, obwohl Underlay nur 1500 kann.
• Jumbo Frames nur teilweise: Ein Segment im Pfad kann nur 1500, andere können 9000; „mixed MTU“ ohne PMTUD-Hygiene.
• ICMP gefiltert: PMTUD kann nicht konvergieren; Blackholes entstehen.
• Zusätzliche Header durch Security/Policy: IPsec/ESP, zusätzliche Optionen oder Service-Mesh-Encapsulation.
• Overlay-in-Overlay: z. B. Kubernetes VXLAN plus VPN-Tunnel, oft mit Default-MTU in CNI.

Mitigation: Was Sie kurzfristig tun können, um Incidents zu stoppen

Wenn Produktion betroffen ist, brauchen Sie schnelle, risikoarme Maßnahmen. Ziel ist es, große Pakete zu vermeiden oder PMTUD wieder funktionsfähig zu machen.

MTU im Overlay reduzieren

Die direkteste Maßnahme ist, die MTU dort zu senken, wo die Encapsulation entsteht: Tunnel-Interface, Overlay-Interface, CNI-MTU in Kubernetes oder virtuelle NICs. Damit erzwingen Sie kleinere Pakete, die sicher durch das Underlay passen.

MSS Clamping für TCP einsetzen

Wenn Sie TCP-Traffic stabilisieren müssen und nicht überall MTU sauber setzen können, ist MSS Clamping eine pragmatische Option. Es reduziert die maximale TCP-Segmentgröße, sodass Endpunkte auch bei 1500er Interface-MTU effektiv kleinere Segmente nutzen. Das ist besonders hilfreich, wenn ICMP nicht zuverlässig ist und Sie Blackholes vermeiden müssen.

ICMP für PMTUD gezielt erlauben

Langfristig ist PMTUD ohne ICMP oft fragil. Wenn Sicherheitsrichtlinien es erlauben, ist es sauberer, die relevanten ICMP-Typen zuzulassen (IPv4 „Fragmentation Needed“, IPv6 „Packet Too Big“), statt ICMP pauschal zu blockieren. Die Standards hinter PMTUD sind in RFC 1191 und RFC 8201 beschrieben.

Mitigation für gRPC/HTTP2/QUIC: PLPMTUD und Protokoll-Settings prüfen

Wenn Ihre Plattform moderne Transportmechanismen nutzt, lohnt sich ein Blick auf PLPMTUD-Konzepte. PLPMTUD (RFC 4821) und DPLPMTUD (RFC 8899) sind darauf ausgelegt, auch bei ICMP-Problemen eine funktionierende Pfad-MTU zu finden. In der Praxis bedeutet das: Protokoll- und Library-Defaults ernst nehmen, und nicht nur „Netzwerk“ zu optimieren.

Prävention: Wie Sie MTU-Mismatch dauerhaft vermeiden

MTU-Probleme lassen sich zuverlässig verhindern, wenn Sie sie als Designparameter behandeln, nicht als Zufallsfehler. In Plattformteams haben sich diese Praktiken bewährt:

• MTU-Budget dokumentieren: Underlay-MTU, Tunnel-Overhead, Ziel-MTU im Overlay – als klare Tabelle im Architektur-Standard.
• Standard-MTU pro Umgebung: z. B. definierte MTU für Kubernetes-Nodes und CNI, passend zu Ihrem Overlay.
• ICMP-Policy bewusst gestalten: PMTUD-spezifische ICMP-Typen erlauben, statt pauschal zu blockieren.
• Monitoring für PMTU-Indikatoren: Retransmissions, Timeout-Muster, Größe-abhängige Fehler, segmentiert nach Pfaden.
• Staging-Tests mit großen Payloads: Nicht nur Healthchecks, sondern auch realistische Response-Größen testen.
• Change Management für Tunnels: Jede Änderung an VPN/Overlay erfordert MTU-Review (Overhead, MSS, ICMP).

Besonders effektiv ist es, „Works on Small Payloads“ als eigenes Runbook-Pattern zu führen. Sobald ein Incident dieses Profil zeigt, wird MTU/PMTUD automatisch zur Top-Hypothese – und die Zeit bis zur Diagnose sinkt drastisch.

Outbound-Links für vertiefende Informationen

• RFC 1191: Path MTU Discovery für IPv4
• RFC 8201: Path MTU Discovery für IPv6
• RFC 4821: Packetization Layer PMTUD (PLPMTUD)
• RFC 8899: PLPMTUD für Datagramm-Transporte (DPLPMTUD)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.