MTU & VPN: Warum große Pakete im Tunnel brechen

MTU & VPN ist eines der klassischsten Troubleshooting-Themen, wenn „kleine Dinge gehen, aber große brechen“: Webseiten laden teilweise, SSO-Logins hängen, große Dateiuploads scheitern, RDP/VDI wirkt instabil oder bestimmte APIs timeouten – und das alles, obwohl Ping funktioniert und die Bandbreite „eigentlich“ ausreicht. Der Kernfehler liegt fast immer im Zusammenspiel aus MTU (Maximum Transmission Unit), Tunnel-Overhead und Path MTU Discovery (PMTUD). VPNs – egal ob IPsec, SSL-VPN oder moderne Overlays – kapseln Pakete zusätzlich ein. Dadurch wächst jedes Paket um Header und ggf. Authentifizierungs-/Verschlüsselungsdaten. Wenn das physische oder logische Netz darunter weiterhin nur eine bestimmte Paketgröße zulässt (z. B. 1500 Byte auf Ethernet), müssen Pakete entweder verkleinert, fragmentiert oder durch PMTUD korrekt angepasst werden. Genau hier scheitern viele Umgebungen: ICMP „Fragmentation Needed“ oder „Packet Too Big“ wird geblockt, MSS-Clamping fehlt, MTU ist inkonsistent konfiguriert oder es existiert ein Teilpfad (z. B. Provider, LTE, PPPoE, Cloud-Gateway), der eine kleinere MTU erzwingt. Das Ergebnis sind scheinbar zufällige Störungen, die besonders bei TLS/HTTPS und großen Payloads sichtbar werden. Dieser Leitfaden erklärt praxisnah, wie MTU-Probleme im VPN entstehen, wie Sie sie eindeutig nachweisen und welche Maßnahmen in der Realität am zuverlässigsten helfen.

MTU, MSS und Fragmentierung: Die Begriffe, die Sie wirklich brauchen

Für sauberes Troubleshooting ist es entscheidend, MTU und MSS nicht zu verwechseln. Beide hängen zusammen, wirken aber an unterschiedlichen Stellen.

• MTU (Maximum Transmission Unit): Maximale Größe eines IP-Pakets (bzw. Frames), die ein Link ohne Fragmentierung transportieren kann. Im klassischen Ethernet sind das häufig 1500 Byte.
• MSS (Maximum Segment Size): Maximale TCP-Nutzlast (Payload) innerhalb eines TCP-Segments. MSS berücksichtigt Header: grob gilt MSS ≈ MTU − IP-Header − TCP-Header. Bei IPv4 ohne Optionen ist das typischerweise $1500-20-20=1460$.
• Fragmentierung (IPv4): Router können IPv4-Pakete fragmentieren, wenn ein Link kleinere MTU hat – sofern das DF-Bit nicht gesetzt ist. Fragmentierung ist möglich, aber häufig unerwünscht (Performance, Drops, Debug-Komplexität).
• Keine Fragmentierung durch Router (IPv6): In IPv6 fragmentieren Router unterwegs nicht; Fragmentierung ist nur am Sender vorgesehen. Das macht PMTUD besonders kritisch.

In VPN-Tunneln ist die wichtigste praktische Frage: Wie groß darf die TCP-Payload sein, damit das eingekapselte Paket überall durchpasst? Genau dafür ist MSS-Clamping so effektiv.

Warum VPN-Tunnel „Pakete wachsen lassen“

Ein VPN kapselt Ihren Originalverkehr ein. Das Original-IP-Paket wird zur „Nutzlast“ innerhalb eines neuen äußeren Pakets (Outer Header). Dazu kommen je nach Tunneltyp zusätzliche Header und Trailer. Das Ergebnis: Das Paket wird größer als im ungetunnelten Pfad.

• IPsec (ESP): Zusätzlicher IP-Header plus ESP-Header/Trailer und ggf. Authentifizierungsdaten. Die genaue Größe hängt vom Modus (Tunnel/Transport), von Algorithmen und Padding ab.
• GRE/UDP-Encapsulation: Zusätzliche Header (GRE, UDP), häufig kombiniert mit IPsec.
• SSL-VPN/DTLS: Kapselung auf höheren Schichten, oft über TCP oder UDP (DTLS). Auch hier entsteht Overhead und ggf. zusätzliche Fragmentierung auf dem Weg.
• PPPoE/LTE/Provider-Links: Der Unterlay-Pfad hat eventuell schon eine reduzierte MTU (PPPoE z. B. oft 1492 statt 1500), wodurch der verfügbare Spielraum im Tunnel noch kleiner wird.

Wenn Ihr Underlay-Link 1500 Byte zulässt, Ihr VPN aber z. B. 60–80 Byte Overhead erzeugt, dann ist die effektive MTU im Tunnel nicht 1500, sondern eher 1420–1440 (je nach Setup). Wenn Clients dennoch versuchen, 1500-byte Pakete zu senden (oder TCP mit MSS 1460), brechen große Pakete.

Das typische Fehlerbild: „Klein geht, groß hängt“

MTU-Probleme werden selten als MTU erkannt, weil sie nicht überall gleich sichtbar sind. Folgende Symptome sind besonders typisch:

• TLS/HTTPS-Timeouts: Einige Webseiten laden nicht oder bleiben beim Login hängen (Handshake oder große Zertifikatsketten).
• SSO/OAuth-Probleme: Redirects funktionieren, aber Token-POSTs oder Callback-Requests hängen.
• Dateiübertragungen brechen ab: Downloads starten, stoppen dann; Uploads enden in Timeouts.
• VPN verbunden, aber „bestimmte Apps“ gehen nicht: Besonders APIs mit größeren Responses oder MTU-sensitiven Pfaden.
• Pings funktionieren, aber TCP nicht: Ping nutzt oft kleine Payloads; das sagt wenig über MTU aus.
• Viele TCP Retransmissions: Im Mitschnitt sieht man Wiederholungen und „Blackhole“-Verhalten.

Ein starker Indikator ist: Der Fehler tritt verstärkt über VPN auf und verschwindet, wenn der Traffic ohne Tunnel oder über einen anderen ISP/Weg läuft.

PMTUD: Warum es ohne ICMP oft kaputt geht

Path MTU Discovery (PMTUD) sorgt dafür, dass Sender die maximal mögliche Paketgröße entlang des Pfads herausfinden. Das Grundprinzip: Der Sender setzt „Do not Fragment“ (IPv4) oder sendet in IPv6 ohne Router-Fragmentierung. Wenn unterwegs ein Link eine kleinere MTU hat, sendet ein Router/Node ein ICMP-Fehlerpaket zurück:

• IPv4: ICMP „Fragmentation Needed“ (bei DF gesetzt)
• IPv6: ICMPv6 „Packet Too Big“

Wenn Security-Regeln ICMP (oder bestimmte ICMP-Typen) blocken, kann der Sender seine Paketgröße nicht anpassen. Dann entstehen sogenannte PMTUD Blackholes: Pakete sind „zu groß“, werden gedroppt, und der Sender probiert es immer wieder. Für IPv4-PMTUD ist RFC 1191 eine zentrale Referenz, für IPv6-PMTUD RFC 8201.

Warum „ICMP blocken“ bei VPN besonders riskant ist

• Tunnel-Overhead erzeugt häufiger „zu große“ Pakete.
• Unterlay-Pfade sind heterogen (PPPoE, Mobilfunk, Cloud, MPLS, Internet) und damit MTU-uneinheitlich.
• VPN-Edges sind oft Firewalls, die ICMP restriktiv behandeln – genau dort, wo PMTUD Signale gebraucht werden.

TCP MSS-Clamping: Der pragmatische Fix in vielen Umgebungen

TCP MSS-Clamping ist in der Praxis eine der zuverlässigsten Maßnahmen gegen MTU-Probleme in VPNs, weil es das Problem dort löst, wo es entsteht: beim TCP-Verbindungsaufbau. Dabei wird die MSS im TCP-SYN (und SYN/ACK) nach unten angepasst, sodass Endgeräte gar nicht erst zu große TCP-Segmente senden. Ergebnis: Weniger Fragmentierung, weniger PMTUD-Abhängigkeit, stabilere Verbindungen.

• Vorteil: Wirkt sofort für TCP-Anwendungen (HTTPS, SMB, RDP, viele SaaS-Apps).
• Grenze: Hilft nicht für UDP-basierte Anwendungen (z. B. bestimmte VoIP/Streaming-Protokolle) – hier muss MTU/PMTUD trotzdem stimmen oder die App muss kleinere Payloads nutzen.
• Praxis: MSS-Wert so wählen, dass Outer MTU im Tunnel nicht überschritten wird (häufig 1360–1460 je nach Underlay und Overhead).

Wichtig ist, nicht „blind“ einen MSS-Wert zu setzen, sondern ihn aus dem Design abzuleiten und anschließend zu verifizieren.

Warum große Pakete im Tunnel brechen: Die häufigsten Ursachen

• MTU-Mismatch zwischen Underlay und Tunnel: Tunnelinterface auf 1500, Underlay effektiv kleiner (PPPoE, LTE, Provider).
• ICMP/PMTUD blockiert: Fragmentation Needed oder Packet Too Big wird nicht zugestellt.
• Falsches MSS-Clamping: MSS zu hoch (kein Effekt) oder zu niedrig (unnötige Performanceeinbußen).
• VPN über TCP (TCP-over-TCP): Bei SSL-VPNs, die selbst TCP verwenden, können Retransmissions und Staukontrolle zu massiven Performanceproblemen führen, besonders bei Loss.
• Fragmentierung wird gedroppt: Manche Firewalls/Provider droppen IPv4-Fragmente oder behandeln sie schlechter; das wirkt wie sporadisches Hängen.
• Load Balancer/Path-Wechsel: Unterschiedliche Pfade haben unterschiedliche MTUs; der „beste“ Pfad wechselt, wodurch Probleme intermittierend auftreten.

Diagnose in der Praxis: So weisen Sie MTU-Probleme eindeutig nach

Das Ziel ist ein reproduzierbarer Nachweis, der zeigt: Ab einer bestimmten Paketgröße bricht es. Damit vermeiden Sie Diskussionen und können zielgerichtet fixen.

MTU-Pfad testen: Größe schrittweise erhöhen

• Testen Sie eine Ziel-IP, die über den VPN-Tunnel erreichbar ist (z. B. interner Server oder Gateway).
• Erhöhen Sie die Payload schrittweise, bis Pakete nicht mehr durchgehen. Wichtig: Bei IPv4 muss DF gesetzt sein, sonst fragmentiert der Sender evtl. und versteckt das Problem.
• Vergleichen Sie den Test mit und ohne VPN (oder über einen anderen Pfad), um die Tunnelwirkung zu isolieren.

In vielen Umgebungen sehen Sie einen klaren Cut: z. B. bis 1372 Byte Payload ok, darüber Timeouts. Daraus lässt sich die effektive MTU ableiten (je nach Header).

Packet Capture: Retransmissions und „Blackhole“-Muster sichtbar machen

Ein kurzer Paketmitschnitt am Client oder am VPN-Gateway zeigt typische Muster:

• TCP Retransmissions: Dieselben Segmente werden wiederholt, ACKs bleiben aus.
• Handshake hängt: ClientHello/ServerHello kommt nicht vollständig durch.
• Keine ICMP-Fehler sichtbar: Obwohl sie erwartet wären – Hinweis auf ICMP-Filter.

Für die Analyse ist die Wireshark Dokumentation hilfreich, insbesondere Filter für TCP Retransmissions und ICMP/ICMPv6.

Logs und Counters am VPN-Gateway/Firewall prüfen

• Drops/Discards auf Tunnel-Interfaces
• ICMP/ICMPv6 Denies (Fragmentation Needed / Packet Too Big)
• Fragment-Drops (IPv4 fragments)
• MTU/MSS Konfigurationsparameter auf Tunnel, Interface und Policy

MTU-Design: Wie Sie die richtige MTU und MSS sauber ableiten

Ein sauberes Design vermeidet „Guessing“. Vorgehensweise:

• Underlay MTU ermitteln: z. B. Ethernet 1500, PPPoE 1492, Provider/Cloud ggf. kleiner.
• Tunnel-Overhead abschätzen: abhängig von IPsec/ESP, UDP-Encap, GRE, IPv4 vs. IPv6 Outer Header, NAT-T, Auth/Encryption.
• Effective Tunnel MTU berechnen: Effective MTU = Underlay MTU − Overhead.
• MSS ableiten: Für TCP: MSS ≈ Effective MTU − IP-Header − TCP-Header (typisch 40 Byte bei IPv4, 60 Byte bei IPv6, ohne Optionen).

Wenn Sie mit IPv6 arbeiten, berücksichtigen Sie, dass Header größer sind und PMTUD noch kritischer ist. IPv6-Basis: RFC 8200.

Typische Praxisfälle und passende Maßnahmen

Fall: VPN via IPsec, Webseiten/SSO hängen sporadisch

• Wahrscheinlich: PMTUD Blackhole oder MSS zu hoch.
• Maßnahme: TCP MSS-Clamping am VPN-Gateway aktivieren, ICMP „Fragmentation Needed“ (IPv4) bzw. „Packet Too Big“ (IPv6) gezielt erlauben.

Fall: Große Dateiübertragungen brechen ab, kleine Downloads gehen

• Wahrscheinlich: Fragmentierung wird gedroppt oder MTU-Mismatch im Underlay.
• Maßnahme: MTU entlang des Pfades harmonisieren, Fragment-Drops prüfen, MSS-Clamping korrekt setzen.

Fall: SSL-VPN über TCP ist „zäh“ bei leichtem Paketverlust

• Wahrscheinlich: TCP-over-TCP-Effekt (Staukontrolle und Retransmissions verstärken sich).
• Maßnahme: Wenn möglich DTLS/UDP-Modus nutzen, Loss-Quellen reduzieren, MTU/MSS trotzdem korrekt einstellen.

Fall: Nur Homeoffice (PPPoE/LTE) betroffen, Büro ok

• Wahrscheinlich: Unterlay MTU kleiner (z. B. 1492), Tunnel-Overhead drückt effektive MTU zu stark.
• Maßnahme: MSS-Clamping am Gateway so setzen, dass auch kleine Underlay-MTUs robust funktionieren, oder Client-VPN-Profil entsprechend anpassen.

Security korrekt gestalten: ICMP nicht „alles oder nichts“

Viele MTU-Probleme werden durch zu harte ICMP-Filter erst erzeugt. Gleichzeitig ist klar: ICMP soll nicht unkontrolliert offen sein. Die Lösung ist ein gezieltes Allowing relevanter Typen/Codes, statt pauschalem Blocken. Besonders wichtig:

• IPv4: ICMP „Fragmentation Needed“ (für PMTUD)
• IPv6: ICMPv6 „Packet Too Big“ (für PMTUD) sowie ND/RA, weil sonst IPv6-Basisfunktionen brechen

PMTUD für IPv4: RFC 1191. PMTUD für IPv6: RFC 8201.

Best Practices: MTU-Probleme im VPN dauerhaft vermeiden

• MTU-Design dokumentieren: Underlay MTU, Tunnel-Overhead, effektive MTU pro Tunneltyp und Standort.
• Standardisiertes MSS-Clamping: Für alle relevanten VPN-Edges konsistent konfigurieren und nach Change testen.
• ICMP gezielt erlauben: PMTUD-Signale müssen funktionieren, sonst werden Störungen unvermeidlich.
• Monitoring auf Retransmissions und Drops: Interface-Discards, Fragment-Drops, TCP Retransmissions und TLS Handshake Errors als Indikatoren.
• Remote Access Profile testen: Homeoffice/PPPoE/Mobilfunk haben andere MTU-Realitäten – Tests nicht nur im LAN durchführen.
• Change-Management: VPN-Algorithmuswechsel (Padding/Overhead), NAT-T-Änderungen oder neue Underlay-Carrier können MTU plötzlich ändern.

Outbound-Links zur Vertiefung

• RFC 1191: Path MTU Discovery für IPv4 – „Fragmentation Needed“ verstehen
• RFC 8201: Path MTU Discovery für IPv6 – „Packet Too Big“ und typische Blackholes
• RFC 4301: IPsec Architektur – Kontext zu Tunnel-Overhead und Encapsulation
• RFC 8200: IPv6 – warum PMTUD und ICMPv6 kritisch sind
• Wireshark Dokumentation: Retransmissions, ICMP und MTU-Probleme in Captures erkennen

Checkliste: MTU & VPN – wenn große Pakete im Tunnel brechen

• Symptom erkennen: „klein geht, groß hängt“, TLS/SSO-Timeouts, Retransmissions, nur über VPN betroffen.
• Testfall definieren: ein Ziel über VPN, ein Ziel ohne VPN (Vergleich), Zeitfenster und betroffene App.
• MTU-Schwelle finden: Payload schrittweise erhöhen (mit DF/PMTUD-Logik), bis es bricht; Ergebnis dokumentieren.
• PMTUD prüfen: Werden ICMP „Fragmentation Needed“ (IPv4) bzw. „Packet Too Big“ (IPv6) zugelassen oder geblockt?
• MSS prüfen: Ist TCP MSS-Clamping aktiv? Passt der Wert zur effektiven Tunnel-MTU?
• Underlay berücksichtigen: PPPoE/LTE/Provider-Links können die MTU reduzieren; Standortunterschiede testen.
• Capture/Logs sichern: TCP Retransmissions, fehlende ICMP-Fehler, Fragment-Drops, Tunnel-Interface Discards.
• Fix umsetzen: MSS-Clamping korrekt setzen, ICMP gezielt erlauben, MTU konsistent konfigurieren, Fragment-Drops vermeiden.
• Verifizieren: Gleicher Testfall nach Änderung (TLS, große Downloads/Uploads, API-Requests) und Vorher/Nachher vergleichen.
• Nachhaltig machen: MTU/MSS als Standard-Template, Monitoring auf MTU-Indikatoren, Change-Checks bei VPN/Underlay-Änderungen.

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.