MTU in Tunneln: Ursache für „komische“ Errors

„MTU in Tunneln“ ist einer der häufigsten, aber am schwersten zu erkennenden Gründe für scheinbar „komische“ Errors im Netzwerk: Verbindungen, die mal funktionieren und mal hängen, APIs, die sporadisch Timeouts liefern, SSH-Sessions, die einfrieren, oder HTTPS, das beim Upload plötzlich abbricht – ohne dass Firewall-Regeln oder Routing auf den ersten Blick falsch aussehen. Der Kern des Problems ist fast immer derselbe: Pakete werden größer als der Pfad erlaubt, werden unterwegs fragmentiert oder still verworfen, und die beteiligten Systeme können die optimale Paketgröße nicht sauber aushandeln. Besonders tückisch wird es, wenn Tunnel im Spiel sind: VPN (IPsec), WireGuard, GRE, VXLAN, Service-Mesh-Overlays oder Cloud-Tunnel erhöhen den Overhead, reduzieren die effektive Nutzlast und verschieben damit die Grenze dessen, was „durchpasst“. Wer MTU in Tunneln korrekt versteht und testet, kann diese schwer greifbaren Fehler systematisch eliminieren – statt im Kreis zwischen Application Logs, Load Balancer, Firewalls und DNS zu suchen.

MTU, MSS und Path MTU: Die drei Größen, die Sie unterscheiden müssen

MTU (Maximum Transmission Unit) ist die maximale Größe eines Layer-2-Frames beziehungsweise eines Layer-3-Pakets (je nach Kontext), die ohne Fragmentierung übertragen werden kann. In IP-Netzen ist damit häufig die maximale IP-Paketgröße gemeint, die über eine bestimmte Schnittstelle gesendet werden darf. MSS (Maximum Segment Size) ist die maximale TCP-Nutzdatenmenge pro Segment und hängt von der MTU ab: MSS = MTU minus IP- und TCP-Header. Path MTU (PMTU) ist die kleinste MTU entlang des gesamten Übertragungspfads – also das tatsächliche Limit, das End-to-End zählt.

• MTU: Limit pro Link/Schnittstelle (z. B. Ethernet typischerweise 1500)
• MSS: TCP-Nutzlast pro Segment (z. B. bei MTU 1500 oft 1460)
• Path MTU: kleinster Wert entlang des Pfads (entscheidend für Ende-zu-Ende)

Viele „komische“ Errors entstehen, weil die lokale MTU zwar hoch ist, die Path MTU aber wegen Tunneln oder Zwischenstrecken niedriger liegt – und PMTU Discovery nicht zuverlässig funktioniert.

Warum Tunnel MTU-Probleme so häufig verursachen

Ein Tunnel verpackt (encapsuliert) ein Paket in ein anderes Paket. Dadurch wächst jedes übertragene Paket um Header (und ggf. Trailer). Das ist prinzipiell kein Problem – solange die effektive Nutzlast entsprechend kleiner wird. In der Praxis passiert aber oft das Gegenteil: Anwendungen senden weiterhin Pakete in „normaler“ Größe, und der Tunnel versucht, sie zusätzlich einzukapseln. Das Ergebnis sind zu große Pakete, die fragmentiert oder verworfen werden.

Der Overhead variiert je nach Tunneltyp, Konfiguration und Protokoll (IPv4/IPv6, NAT-Traversal, zusätzliche Auth/Enc-Header). Daher gibt es keine universelle „richtige“ Tunnel-MTU – aber es gibt eine universelle Konsequenz: Die effektive MTU im Tunnel ist kleiner als die MTU des darunterliegenden Pfads.

Typische Tunnelarten mit MTU-Fallstricken

• IPsec (inkl. ESP/AH, NAT-T): zusätzlicher Overhead, häufige PMTU-Probleme bei blockiertem ICMP
• WireGuard: effizient, aber ebenfalls Overhead; falsche MTU kann zu Drops führen
• GRE: unkompliziert, aber oft unterschätzt, besonders bei verschachtelten Tunneln
• VXLAN/Geneve: Overlay-Netze in Rechenzentren/Kubernetes; Fragmentierung kann Performance massiv senken
• Service Mesh/Sidecar + mTLS: nicht nur MTU, auch Record-Größen und zusätzliche Header spielen hinein

Was genau passiert, wenn ein Paket „zu groß“ ist?

Wenn ein Gerät ein IP-Paket senden soll, das größer ist als die MTU des nächsten Links, gibt es grundsätzlich zwei Wege: Fragmentierung oder Verwerfen. Bei IPv4 kann Fragmentierung unterwegs erfolgen (wenn DF nicht gesetzt ist). Bei IPv6 fragmentieren Router nicht; das Fragmentieren muss am Sender passieren. In modernen Umgebungen wird Fragmentierung oft vermieden, weil sie Performance kostet und Fehlerbilder verstärkt. Stattdessen setzt man auf PMTU Discovery: Der Sender findet die maximale Paketgröße, die End-to-End funktioniert, indem er auf ICMP-Meldungen reagiert.

Fragmentierung: Funktioniert, aber ist teuer und fehleranfällig

• Fragmentierte Pakete erhöhen Last (mehr Pakete, mehr Reassembly-Arbeit)
• Wenn ein Fragment verloren geht, muss das gesamte Paket neu gesendet werden
• Manche Middleboxes behandeln Fragmente restriktiv oder fehlerhaft

PMTU Discovery: Elegant – wenn ICMP nicht blockiert wird

PMTU Discovery basiert darauf, dass ein Gerät ein zu großes Paket sendet (oft mit „Don’t Fragment“ bei IPv4) und ein Router dann eine ICMP-Meldung zurückschickt („Fragmentation Needed“ bzw. bei IPv6 „Packet Too Big“) mit der Information, welche MTU zulässig ist. Wenn diese ICMP-Meldungen gefiltert werden, entsteht ein klassisches „Blackhole“-Problem: Pakete verschwinden, ohne dass der Sender die Ursache korrekt erkennen und die Paketgröße reduzieren kann. Hintergrund und Standards dazu finden Sie in der Spezifikation zu Path MTU Discovery für IPv4 (RFC 1191) und zu Path MTU Discovery für IPv6 (RFC 8201).

Die typischen „komischen“ Errors, die auf MTU in Tunneln hindeuten

MTU-Probleme äußern sich selten als klarer Hinweis „MTU zu klein“. Stattdessen sehen Sie Symptome, die wie TLS-, HTTP-, DNS- oder Applikationsprobleme wirken. Besonders auffällig ist das Muster „kleine Daten gehen, große Daten brechen“ – etwa: Login funktioniert, aber Upload nicht; GET geht, POST hängt; Ping geht, aber HTTPS hängt; oder nur bestimmte Webseiten funktionieren.

• HTTPS/TLS: Handshake hängt, Downloads brechen ab, „connection reset“, „EOF“, sporadische Timeouts
• SSH: Session aufgebaut, aber beim Tippen/Scrollen friert es ein oder wird extrem langsam
• VPN: bestimmte Subnetze funktionieren, andere nicht; oder nur bei großen Transfers Probleme
• Kubernetes/Overlay: Pod-zu-Pod funktioniert für kleine Antworten, aber große Responses hängen
• SMB/NFS/DB-Replikation: Performance bricht ein, Retransmits steigen, Transfers „stottern“
• ICMP/Ping: Ping mit Standardgröße ok, Ping mit „Do not fragment“ und größerer Payload scheitert

Rechnen statt raten: MTU, Header-Overhead und effektive Nutzlast

Um „MTU in Tunneln“ sauber zu dimensionieren, hilft eine simple Rechnung: Effektive MTU = Underlay-MTU minus Tunnel-Overhead. Der Tunnel-Overhead ist abhängig von Protokollen und Optionen, aber das Prinzip bleibt. Für TCP ist zudem relevant: MSS = effektive MTU minus IP-Header minus TCP-Header. Je besser Sie diese Größen kennen, desto gezielter können Sie MSS-Clamping, Interface-MTU oder Tunnelparameter setzen.

$\mathrm{MTU}\_\mathrm{effektiv}=\mathrm{MTU}\_\mathrm{underlay}–\mathrm{Overhead}\_\mathrm{tunnel}$
$\mathrm{MSS}=\mathrm{MTU}–\mathrm{IPHeader}–\mathrm{TCPHeader}$

Praktisch bedeutet das: Wenn Ihr Underlay 1500 MTU hat und der Tunnel Overhead hinzufügt, muss die effektive MTU im Tunnel darunter liegen. Andernfalls muss fragmentiert werden oder es kommt zu Drops. Bei verschachtelten Tunneln (z. B. VPN über Overlay) addiert sich der Overhead – und die effektive MTU schrumpft schneller, als viele erwarten.

Warum PMTU Discovery in der Praxis häufig scheitert

In realen Netzen wird ICMP oft pauschal blockiert – aus Sicherheitsgründen oder aus Unwissen. Das ist problematisch, weil ICMP für PMTU Discovery essenziell sein kann. Wenn ICMP „Fragmentation Needed“ (IPv4) oder „Packet Too Big“ (IPv6) nicht zurück zum Sender kommt, bleibt der Sender bei einer zu großen Paketgröße und wiederholt den Sendeversuch. Die Folge sind Retransmits, Timeouts und schwer zuzuordnende Applikationsfehler.

Häufige Ursachen für PMTU-Blackholes

• ICMP wird an Firewalls/NACLs/NSGs geblockt oder rate-limitiert
• ICMP kommt zurück, aber an einer falschen Stelle verworfen (Asymmetrie)
• Tunnel-Endpunkte setzen DF/Fragmentierung ungünstig um
• Middleboxes verändern Paketheader oder MSS, ohne konsistent zu sein

MTU-Probleme sicher diagnostizieren: Tests, die wirklich helfen

Die Diagnose sollte immer mit reproduzierbaren, möglichst einfachen Tests beginnen. Ziel ist nicht, „irgendwie“ Traffic zu erzeugen, sondern die maximal funktionierende Paketgröße für den Pfad zu finden und zu verstehen, wo sie reduziert wird.

1) Ping mit DF/PMTU-Logik (sofern möglich)

Ein klassischer Ansatz ist, ICMP Echo Requests mit gesetztem „Don’t Fragment“ zu senden und die Payload schrittweise zu erhöhen, bis es nicht mehr funktioniert. Das zeigt Ihnen, ab welcher Größe der Pfad fragmentieren müsste oder Pakete verworfen werden. Wichtig: Je nach Betriebssystem und Umgebung sind die Optionen unterschiedlich, und ICMP kann gefiltert sein. Trotzdem ist dieses Verfahren hilfreich, um ein MTU-Blackhole sichtbar zu machen.

2) TCP-MSS beobachten und gezielt begrenzen (MSS-Clamping)

Wenn das Problem TCP-basiert ist (HTTPS, SSH, Datenbank), ist MSS-Clamping eine bewährte Methode: Der Gateway oder Tunnel-Endpunkt passt die MSS in SYN-Paketen nach unten an, damit Endpunkte gar nicht erst zu große TCP-Segmente senden. Das behebt viele MTU-Probleme, ohne dass Sie überall die Interface-MTU anfassen müssen. Der Nachteil: Es ist eine „Symptombehandlung“, die bei UDP-Workloads nicht hilft und Overhead/Performanceeffekte haben kann.

3) Packet Captures und Retransmits

Wenn Sie Zugriff auf Captures haben (z. B. an Tunnel-Endpunkten), achten Sie auf:

• Viele Retransmits ohne Fortschritt
• TCP-Segmente nahe der MSS-Grenze, die „verschwinden“
• ICMP „Fragmentation Needed“/„Packet Too Big“ (wenn nicht geblockt)

Wenn Captures nicht möglich sind, helfen oft Metriken: Retransmit-Zähler, Drop-Zähler, Interface-Errors, sowie Logs von VPN-Gateways oder Overlays.

Praxis: Welche Stellschraube ist die richtige?

Es gibt nicht „die eine“ Lösung. Entscheidend ist, ob Sie die MTU-End-to-End sauber aushandeln können oder ob Sie in einer Umgebung arbeiten, in der PMTU Discovery unzuverlässig ist (z. B. durch ICMP-Filter). In vielen Unternehmen ist die pragmatische Lösung eine Kombination aus korrekter Tunnel-MTU und MSS-Clamping, plus gezieltem Zulassen der notwendigen ICMP-Typen.

Option A: Tunnel-MTU korrekt setzen

• Sauber, wenn Sie Kontrolle über Tunnel-Endpunkte und Underlay haben
• Wirkt für TCP und UDP
• Erfordert Kenntnis des tatsächlichen Overheads und der kleinsten MTU im Pfad

Option B: MSS-Clamping für TCP

• Schnell wirksam bei HTTPS/SSH/DB
• Hilft nicht bei UDP-Protokollen
• Kann Performance reduzieren, ist aber oft stabiler als Fragmentierung

Option C: ICMP gezielt erlauben (statt pauschal blocken)

Aus Security-Sicht ist „ICMP komplett blocken“ selten optimal. Besser ist, ICMP-Typen selektiv zu erlauben, die für PMTU Discovery notwendig sind. Bei IPv6 ist das besonders wichtig, weil Router nicht fragmentieren und „Packet Too Big“ eine zentrale Rolle spielt. Eine gute Grundlage liefert die PMTU-Dokumentation in den oben genannten RFCs sowie Provider-Guidance zu ICMP/PMTU in ihren Netzwerken. Für IPv6 und Best Practices zu ICMP in modernen Netzen ist außerdem die Übersicht zu ICMPv6-Filtering Empfehlungen (RFC 4890) hilfreich.

MTU in Cloud- und Kubernetes-Umgebungen: Typische Stolpersteine

In Cloud-Umgebungen treffen Sie häufig auf mehrere Abstraktionsschichten: VPC/VNet, virtuelle Router, Security-Komponenten, Load Balancer und dann noch Overlays in Kubernetes. Jeder Layer kann die effektive MTU verändern. Besonders in Kubernetes-Clustern hängt die korrekte MTU vom CNI-Plugin, vom Overlay-Modus und vom Underlay (z. B. VPC MTU) ab. Wenn die Pod-MTU zu hoch ist, sehen Sie oft genau diese „komischen“ Errors bei bestimmten Services oder Pfaden.

• Overlay + VPN: VXLAN/Geneve plus IPsec/WireGuard addiert Overhead und reduziert effektive MTU stark
• Load Balancer Pfade: Client → LB → Backend kann eine andere PMTU haben als Backend → Backend
• Cross-Zone/Peering: Der Pfad kann andere MTU/Policies haben als innerhalb einer Zone

Wenn Sie in der Cloud arbeiten, lohnt ein Blick in die offiziellen Networking-Grundlagen, weil Provider teils eigene MTU-Werte und Empfehlungen haben: AWS VPC Networking Konzepte, Azure Virtual Network Überblick und Google Cloud VPC Grundlagen.

Erkennungsmerkmale in Logs und Monitoring

Da MTU-Probleme selten einen eindeutigen Fehlertext liefern, hilft es, auf indirekte Indikatoren zu achten. Wenn Sie solche Muster sehen, ist „MTU in Tunneln“ ein sehr wahrscheinlicher Kandidat.

• Timeouts steigen, aber CPU/Memory sind unauffällig
• Retransmits und „Out-of-Order“ Events nehmen zu
• Nur große Responses/Uploads scheitern (z. B. ab einer bestimmten Payload-Größe)
• Probleme treten nur über bestimmte Pfade auf (VPN, Peering, bestimmte Subnetze)
• Workaround „kleinere Pakete“ (z. B. kleinerer MTU/MSS) behebt es sofort

Best Practices, um MTU-Fehler dauerhaft zu vermeiden

• MTU-Design dokumentieren: Underlay-MTU, Tunnel-Overhead, effektive MTU je Segment festhalten
• PMTU Discovery ermöglichen: ICMP selektiv erlauben, statt pauschal zu blocken
• Fragmentierung vermeiden: lieber effektive MTU/MSS sauber einstellen als auf Fragmentierung zu hoffen
• Verschachtelung minimieren: Tunnel über Tunnel nur, wenn zwingend notwendig
• Standardisierte Tests: regelmäßige PMTU-Checks auf kritischen Pfaden (z. B. Site-to-Site-VPN, Cluster-Peering)
• Change-Management: MTU-Änderungen bei VPN, CNI, Load Balancer oder Firewall als risikoreiche Changes behandeln

Weiterführende Quellen zu MTU, PMTU und Tunnel-Encapsulation

• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)
• RFC 4890: Empfehlungen zum Filtern von ICMPv6
• AWS: VPC Networking Grundlagen
• Microsoft Learn: Azure Virtual Network Überblick
• Google Cloud: VPC Grundlagen

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.