MTU in Cloud-VPN/Tunneln: Ursache für „Small works, large fails“

MTU in Cloud-VPN/Tunneln ist eine der häufigsten Ursachen für das klassische Fehlerbild „Small works, large fails“: Kleine Pakete (z. B. Ping, kurze API-Requests, kleine DNS-Antworten) funktionieren, während größere Daten (Datei-Uploads, TLS-Handshakes mit vielen Extensions, große HTTP-Responses, Datenbankabfragen) sporadisch hängen bleiben, extrem langsam werden oder timeouten. In Cloud-Umgebungen ist dieses Problem besonders verbreitet, weil zusätzliche Encapsulation-Schichten (IPsec, GRE, VXLAN, GENEVE), Managed Gateways, virtuelle Router und Firewalls die effektive Nutzlast pro Paket reduzieren. Sobald ein Paket größer ist als die tatsächlich verfügbare Pfad-MTU, muss es fragmentiert werden oder die Endsysteme müssen kleinere Segmente senden. Wenn aber Fragmentierung blockiert wird (häufig durch Firewalls/Policies) oder Path MTU Discovery (PMTUD) scheitert (oft durch gefilterte ICMP-Meldungen), entsteht genau dieses Muster: „klein geht, groß nicht“. Dieser Artikel erklärt die technische Ursache, zeigt typische Cloud-VPN-Szenarien, liefert praxistaugliche Detection-Methoden und gibt eine robuste Checkliste, wie Sie MTU/MSS so einstellen, dass der Tunnel stabil läuft.

MTU-Grundlagen: Was bedeutet MTU in der Praxis?

Die Maximum Transmission Unit (MTU) beschreibt die maximale Paketgröße (in Bytes), die ein Layer-2/Layer-3-Pfad ohne Fragmentierung transportieren kann. Im IP-Kontext meint man häufig die maximale IP-Paketgröße, die über einen Link passt. Auf Ethernet liegt die klassische MTU bei 1500 Bytes, aber Cloud-Backbones und bestimmte Netztypen unterstützen Jumbo Frames (z. B. 9001). Entscheidend ist jedoch nicht die MTU eines einzelnen Links, sondern die Pfad-MTU (Path MTU): die kleinste MTU entlang des gesamten Weges zwischen Sender und Empfänger.

• MTU: maximale Paketgröße auf einem Link oder Interface
• Path MTU: kleinste MTU entlang des End-to-End-Pfads
• Fragmentierung: Aufteilung eines IP-Pakets in mehrere Fragmente (IPv4) oder Verwerfen (IPv6)
• PMTUD: Mechanismus, der Sender dazu bringt, passend kleine Pakete zu senden

Warum Tunnel die effektive MTU reduzieren

Jeder Tunnel fügt Overhead hinzu: zusätzliche Header (z. B. IPsec ESP, UDP, neue IP-Header). Dadurch bleibt weniger Platz für Nutzdaten. Ein Paket, das ohne Tunnel „passt“, ist im Tunnel plötzlich zu groß. Wenn Sender und Empfänger das nicht berücksichtigen, kommt es zu Fragmentierung oder Drops.

Das Symptom „Small works, large fails“ technisch erklärt

Das Fehlerbild entsteht, wenn kleine Pakete unterhalb der Pfad-MTU liegen, während größere Pakete die Pfad-MTU überschreiten und dann nicht korrekt behandelt werden. Typische Ausprägungen:

• Pings funktionieren, solange sie klein sind, aber Pings mit großer Payload (oder DF-Flag) scheitern.
• TCP-Verbindungen bauen sich auf (SYN/SYN-ACK/ACK), aber Datenübertragung hängt bei größeren Segmenten.
• TLS-Handshakes funktionieren manchmal (kleine ClientHello), scheitern aber bei größeren ClientHello/ServerHello (z. B. viele Cipher Suites, SNI, ALPN, Zertifikatsketten).
• HTTP: kleine GETs gehen durch, große Responses/Uploads führen zu Timeouts oder Retries.

Die zwei typischen Ursachenfamilien

• PMTUD ist kaputt: ICMP „Fragmentation Needed“ (IPv4) oder „Packet Too Big“ (IPv6) wird geblockt, sodass der Sender nie lernt, kleiner zu senden.
• Fragmentierung ist kaputt oder unerwünscht: Fragmente werden im Pfad verworfen (Security/Performance), und große Pakete verschwinden.

PMTUD: Warum ICMP in VPN-Szenarien oft der „unsichtbare“ Blocker ist

PMTUD funktioniert so, dass der Sender Pakete mit gesetztem „Don’t Fragment“ (DF) sendet (bei IPv4) und der Pfad bei zu großen Paketen eine ICMP-Meldung zurückschickt. Der Sender reduziert daraufhin die Paketgröße. In IPv6 ist Fragmentierung durch Router nicht erlaubt; stattdessen ist PMTUD praktisch zwingend, weil nur der Sender fragmentieren darf und der Pfad ICMP „Packet Too Big“ melden muss.

• IPv4: ICMP „Fragmentation Needed“ (Type 3 Code 4) ist zentral für PMTUD.
• IPv6: ICMPv6 „Packet Too Big“ (Type 2) ist essenziell.

Warum ICMP häufig gefiltert wird

Viele Security-Baselines blocken ICMP pauschal („ICMP ist unsicher“). In Wirklichkeit ist gezielt erlaubtes ICMP in VPN/Hybrid-Umgebungen oft notwendig, um MTU-Probleme zu vermeiden. Wenn ICMP geblockt wird, bleibt TCP häufig in Retransmits stecken: Es sendet große Segmente, die verschwinden, und wartet dann, bis Timeouts und Backoffs greifen. Das wirkt wie „Netzwerk instabil“, ist aber ein deterministisches MTU/PMTUD-Problem.

MSS statt MTU: Der praxisrelevante Hebel bei TCP

In der Praxis lösen Teams MTU-Probleme bei TCP häufig über MSS-Clamping. MSS (Maximum Segment Size) ist die maximale TCP-Nutzdatenmenge pro Segment (ohne IP- und TCP-Header). Wenn Sie die MSS passend reduzieren, bleiben IP-Pakete unterhalb der Pfad-MTU, ohne dass IP-Fragmentierung nötig ist.

Die Beziehung ist vereinfacht:

$\mathrm{MSS}=\mathrm{MTU}-(\mathrm{IP\_Header}+\mathrm{TCP\_Header})$

Für typische Headergrößen gilt (ohne Optionen): IPv4-Header 20 Bytes, TCP-Header 20 Bytes. Dann ist bei MTU 1500 die MSS ungefähr 1460. In Tunneln sinkt die effektive MTU, und damit muss auch die MSS sinken.

Warum MSS-Clamping in Cloud-VPNs so gut funktioniert

• Vermeidet Fragmentierung: Der Sender segmentiert kleiner, statt große IP-Pakete zu erzeugen.
• Stabilisiert TCP: Weniger Retransmits, weniger Timeouts, vorhersehbarere Performance.
• Einfach umsetzbar: Viele VPN-Gateways, Firewalls und Router können MSS automatisch clampen.

Typische Cloud-VPN/Tunnel-Szenarien, in denen MTU schiefgeht

MTU-Probleme sind selten „zufällig“; sie entstehen häufig nach Änderungen am Pfad, an Encapsulation oder an Security-Policies. Diese Szenarien sind besonders typisch:

• Site-to-Site IPsec (On-Prem ↔ Cloud): IPsec-Overhead reduziert die Nutzlast; On-Prem-Firewall blockt ICMP oder Fragmente.
• Transit-/Hub-and-Spoke: Traffic läuft durch zentrale Firewalls oder virtuelle Appliances mit eigener MTU/Fragment-Policy.
• Double Encapsulation: IPsec über GRE oder IPsec über UDP plus zusätzlicher Overlay (z. B. SD-WAN) – Overhead addiert sich.
• Cloud-to-Cloud VPN: Zwei Provider mit unterschiedlichen Defaults (MTU, MSS, ICMP-Handling) treffen aufeinander.
• Kubernetes/Service Mesh: Zusätzliche Header durch Overlay-Netzwerke, Sidecars, eBPF-Policies; PMTUD-Signale gehen verloren.

Warum „es ging gestern noch“ ein MTU-Hinweis ist

Eine scheinbar kleine Änderung kann die Pfad-MTU verschieben: neue Firewall-Regeln, andere Route über ein Transit-Gateway, Wechsel von Internet-VPN zu Direct-Connect/ExpressRoute, Aktivierung von NAT, neue Appliance-Version, geänderte Cipher/Encapsulation-Settings. Das Symptom zeigt sich dann als Regression: kleine Requests gehen, große nicht.

Detection: So beweisen Sie MTU als Root Cause

Die Diagnose ist am besten, wenn Sie sie messbar machen. Statt „wir vermuten MTU“ wollen Sie klare Signale: Ab welcher Paketgröße scheitert es? Welche Richtung ist betroffen? Ist PMTUD aktiv oder blockiert?

Methoden auf Client-Seite

• Ping mit DF (IPv4): Testen Sie die maximale Payload, die ohne Fragmentierung durchkommt. Wenn kleine Payloads gehen und größere nicht, ist das ein starkes Signal.
• TCP-Tests: Einfache Upload/Download-Tests mit definierter Größe zeigen, ab wann es hängt.
• Vergleich intern vs. über VPN: Wenn intern alles geht, über den Tunnel aber nicht, ist MTU/Encapsulation wahrscheinlicher.

Methoden auf Netzwerk-/Gateway-Seite

• Flow Logs: Sie sehen Retransmits und einseitige Flows (SYN ok, Daten fehlen). Das beweist nicht direkt MTU, aber unterstützt die Hypothese.
• Firewall-Logs: Drops von Fragmenten oder ICMP-Meldungen sind sehr aussagekräftig.
• Gateway-Metriken: Zähler für Fragmentierung, „packet too big“, Drops bei ESP/UDP können Hinweise geben.

Ein praktikables Entscheidungsmodell

Wenn Sie ein Schwellenverhalten sehen („bis X Bytes ok, darüber fail“), ist MTU extrem wahrscheinlich. Eine einfache Heuristik: Der kritische Wert liegt oft nahe der effektiven MTU minus Header. Wenn Sie die Schwelle kennen, können Sie MSS/MTU zielgerichtet korrigieren.

Rechnen: Wie viel Overhead frisst ein Tunnel wirklich?

Die exakte Overhead-Höhe hängt von Protokollen, Modi und Optionen ab (ESP, UDP Encapsulation, zusätzliche IP-Header, VLAN, mögliche Optionen). Für die Praxis reicht meist eine konservative Kalkulation: lieber etwas kleiner clampen, statt am Limit zu fahren.

Eine vereinfachte Formel für die effektive MTU im Tunnel:

$\mathrm{Effektive\_MTU}=\mathrm{Physische\_MTU}-\mathrm{Tunnel\_Overhead}$

Und daraus abgeleitet eine konservative TCP-MSS:

$\mathrm{MSS\_konservativ}=\mathrm{Effektive\_MTU}-(20+20)$

Wenn Sie z. B. eine physische MTU von 1500 annehmen und einen konservativen Tunnel-Overhead von 60–80 Bytes, landen Sie bei einer effektiven MTU von etwa 1420–1440 und einer MSS von etwa 1380–1400. Viele Teams wählen in der Praxis bewusst einen bekannten „sicheren“ MSS-Wert (z. B. 1360 oder 1380) für IPsec-Tunnel, wenn die Umgebung heterogen ist.

Warum Fragmentierung in VPNs oft scheitert (und warum das sinnvoll sein kann)

Fragmentierung ist nicht automatisch „schlecht“, aber in vielen VPN/Hybrid-Setups ist sie unerwünscht oder unzuverlässig:

• Security: Fragmente können IDS/IPS und Firewalls komplizieren; manche Policies blocken Fragmente pauschal.
• Performance: Fragmentierung erhöht Overhead und Verlustanfälligkeit; ein verlorenes Fragment zerstört das gesamte Paket.
• Komplexität: NAT + Fragmentierung + Encapsulation kann zu schwer debuggbaren Corner Cases führen.
• IPv6: Router fragmentieren nicht; PMTUD ist faktisch Pflicht.

Konsequenz für die Praxis

Statt Fragmentierung „zu erlauben und zu hoffen“, ist es in produktiven Cloud-VPNs meist robuster, PMTUD zu ermöglichen und/oder MSS gezielt zu clampen.

Fix-Strategien: Stabilisieren, ohne Nebenwirkungen zu erzeugen

Je nach Architektur sind mehrere Lösungen möglich. Entscheidend ist, dass Sie den Fix an der richtigen Stelle ansetzen: am Sender (MSS/MTU), am Tunnel (Gateway/Appliance) oder an den Policies (ICMP/Fragmente). Die folgenden Strategien sind in der Praxis am zuverlässigsten.

MSS-Clamping am Gateway oder an der Firewall

• Clampen Sie MSS für TCP-Verbindungen, die über den Tunnel gehen.
• Wählen Sie einen konservativen Wert, der Ihre Encapsulation sicher abdeckt.
• Dokumentieren Sie den Wert und begründen Sie ihn (Overhead, Pfad, Provider).

ICMP gezielt zulassen, statt pauschal zu blocken

• Erlauben Sie relevante ICMP-Typen für PMTUD (IPv4 Fragmentation Needed, IPv6 Packet Too Big).
• Begrenzen Sie die Quellen/Ziele, um die Policy sicher zu halten.
• Überprüfen Sie, ob zentrale Appliances ICMP im Rückweg nicht still verwerfen.

MTU an Endsystemen anpassen (wenn sinnvoll)

• Setzen Sie Interface-MTU in betroffenen Segmenten herunter, wenn Sie die Umgebung kontrollieren (z. B. feste Workload-Gruppen).
• Vermeiden Sie jedoch „Wildwuchs“: unterschiedliche MTUs in einem Cluster erhöhen Komplexität.
• Bevorzugen Sie zentrale Lösungen (Gateway/Clamping), wenn viele Teams/Workloads betroffen sind.

Pfad vereinfachen: Double Encapsulation vermeiden

• Reduzieren Sie Schichten (z. B. nicht zusätzlich GRE über IPsec, wenn nicht nötig).
• Überprüfen Sie, ob SD-WAN/Overlay bereits encapsuliert und IPsec „nochmal“ darüber liegt.
• Wenn Double Encapsulation notwendig ist, clampen Sie MSS entsprechend aggressiver.

Cloud-spezifische Hinweise: AWS, Azure, GCP (ohne Vendor-Lock-in)

Die konkreten Defaults und Empfehlungen unterscheiden sich je nach Provider und Produkt (VPN Gateway, Cloud Router, Virtual WAN, Transit). Daher ist es sinnvoll, die offiziellen Dokumentationen als Referenz zu nutzen und Ihre Werte gegen die tatsächliche Encapsulation zu testen.

• AWS: AWS Site-to-Site VPN und AWS Transit Gateway
• Azure: Azure VPN Gateway und Azure Virtual WAN
• GCP: Google Cloud VPN Übersicht

Wichtig: Provider-Doku ist Referenz, nicht Ersatz für Messung

Selbst wenn ein Provider bestimmte MTU-/MSS-Werte empfiehlt, kann Ihr realer Pfad abweichen: zusätzliche Firewalls, IDS, NAT, SD-WAN oder Partnernetze verändern die Pfad-MTU. In produktiven Umgebungen ist daher ein kurzer, reproduzierbarer Test (Max-Payload ermitteln) genauso wichtig wie die Konfiguration.

Troubleshooting-Checkliste: Schritt für Schritt zu „Large works“

Diese Checkliste ist so aufgebaut, dass Sie in Incidents schnell zu einem belastbaren Befund kommen und danach gezielt fixen können.

• 1) Symptom validieren: Kleine Requests ok, große Requests fail? Größe des Fails grob bestimmen (z. B. Upload ab ~1–2 KB hängt, oder erst bei größeren Responses).
• 2) Pfad festlegen: Läuft der Traffic sicher über VPN/Tunnel? Gibt es alternative Routen (Internet-Fallback, parallele VPNs)?
• 3) PMTUD prüfen: Werden ICMP „Fragmentation Needed“ bzw. „Packet Too Big“ durchgelassen? Gibt es Logs, die ICMP-Drops zeigen?
• 4) Fragmentierung prüfen: Werden IP-Fragmente irgendwo im Pfad verworfen (Firewall/Appliance/Policy)?
• 5) MSS prüfen: Ist MSS-Clamping aktiv? Passt der Wert zur Encapsulation? Gibt es unterschiedliche Werte in verschiedenen Segmenten?
• 6) Double Encapsulation ausschließen: Gibt es zusätzliche Overlays (SD-WAN, GRE, Service Mesh), die Overhead addieren?
• 7) Fix wählen: Priorität meist: MSS clampen + ICMP für PMTUD gezielt erlauben.
• 8) Regression verhindern: Werte dokumentieren, Monitoring auf Timeouts/Handshake-Fails, Change-Guardrails für ICMP/Fragment-Policies.

Monitoring und Guardrails: MTU-Probleme früh erkennen

MTU-Probleme werden oft erst im Incident sichtbar, weil klassische Verfügbarkeitschecks (Ping, kurzer HTTP-Check) zu klein sind. Besser sind Tests, die bewusst größere Payloads oder realistische Handshakes abbilden.

• Synthetische Checks mit größerer Payload: z. B. definierte Downloadgröße oder POST mit einigen KB.
• TLS-Handshake-Metriken: Fehlerraten und Handshake-Dauer als frühes Signal.
• TCP-Retransmits: Steigende Retransmits/Timeouts über den Tunnel deuten auf PMTUD/MTU hin.
• Firewall-Drop-Counter: Spezifische Dashboards für ICMP-Drops und Fragment-Drops.

Outbound-Links zu relevanten Informationsquellen

• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)
• RFC 879: The TCP Maximum Segment Size and Related Topics
• AWS Site-to-Site VPN: Überblick
• Azure VPN Gateway: Überblick
• Google Cloud VPN: Konzepte und Überblick

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.