MTU ohne Schmerzen: Warum die Paketgröße VPN kaputt macht und wie du es schnell behebst

Einleitung: Was ist MTU und warum ist das überhaupt wichtig

MTU ganz einfach erklärt

MTU steht für die maximale Größe eines IP-Pakets, das eine Schnittstelle ohne Fragmentierung übertragen kann. Vereinfacht gesagt ist sie wie die Breite einer Tür im Netzwerk: alles, was größer ist, passt nicht durch. Die Türbreite ist fix, der Datenblock muss komplett hindurchpassen. Beim VPN wird aber der Datenblock durch die Tunnelverpackung dicker, und hier fangen die Schwierigkeiten an.

Die Standard-MTU für Ethernet liegt bei 1500 Byte. Für IPv6 ist die minimal garantierte Pfadgröße 1280 Byte. Im Rechenzentrum gibt’s sogenannte Jumbo Frames mit bis zu 9000 Byte, das ist aber mehr Luxus vor Ort. Im echten Internet, vor allem über 4G/5G, CGNAT und Wi‑Fi, schwankt die MTU unterwegs oft: mal 1500, dann 1472 oder auch 1400. Wir wollen doch, dass unser VPN ohne fiese Überraschungen läuft, oder?

Warum MTU für VPN so wichtig ist

Jedes VPN legt Overhead drauf. Der Tunnel fügt Kopfzeilen oben auf das Ursprungs-Paket. Beispiel: Du hast WireGuard über UDP in IPv4. IP- und UDP-Kopfzeilen plus der WireGuard-Header sind zusammen etwa 60 Byte. Aus 1500 werden also maximal 1440 Bytes für Nutzdaten im Tunnel. Wenn du das ignorierst, fragmentieren Pakete oder verschwinden sogar, weil unterwegs ICMP gesperrt wird und Path MTU Discovery blind wird. Folge: „grauenhafte Verzögerungen“, hängende Websites, nicht ladende Bilder und Timeouts bei RDP. Nervig, oder?

MTU vs. MSS: nicht Äpfel mit Birnen verwechseln

MTU bezieht sich auf die IP-Ebene. MSS ist TCP-spezifisch. MSS (Maximum Segment Size) beschreibt die maximale TCP-Nutzlast ohne IP- und TCP-Header. Wenn man sagt „MSS clamping machen“, meint man das erzwungene Verkleinern von MSS an der Grenze, damit TCP-Verbindungen direkt richtig segmentiert werden und nicht gegen die MTU-Grenze stoßen. Ist das ein Hack? Eher eine Sicherheitsmaßnahme auf rutschiger Straße: Du flickst nicht den Asphalt, senkst aber das Risiko für Unfälle.

Wie falsche MTU VPN-Verbindungen zerstört

Symptome: So erkennst du die Probleme

Bilder laden nicht vollständig. Die Website öffnet sich, aber viele Anfragen bleiben hängen. Mail wird erst beim zweiten Versuch gesendet. Videos ruckeln. RDP bricht beim Kopieren ab. Der Ping klappt, aber der Browser braucht ewig zum Laden. Das ist die typische „Blackhole-MTU“-Situation: Pakete mit gesetztem DF-Bit sind zu groß, werden unterwegs verworfen, ICMP „Fragmentation needed“ kommt nicht an, TCP versucht neu und verkleinert das Fenster. Alles läuft schleppend, klappt aber irgendwie – genau das nervt am meisten.

Praxisbeispiele: WireGuard, OpenVPN, IPsec

WireGuard: Oft wird MTU 1420 empfohlen. Schneidet der Provider die MTU aber schon auf 1472 runter und setzt du zusätzlich VLAN oder PPPoE drüber, bleibt plötzlich nur 1380–1400 übrig. Die Lösung: MTU im Interface wg klar neu berechnen und setzen, z. B. 1380 oder 1360. Kompromiss, aber stabil.

OpenVPN UDP: Hier ist der Overhead oft höher, vor allem mit TLS-Verschlüsselung und Extra-Optionen. Ein gängiges Setup sind tun-mtu 1500 und mssfix 1360, auf Mobilnetzen empfiehlt sich oft 1400 MTU im Tunnel und mssfix 1360 oder sogar 1320. Wer mit kleineren Werten startet und schrittweise höher geht, macht nichts falsch.

IPsec mit NAT-T: ESP in UDP mit zusätzlichen Headern. PPPoE verkleinert zusätzlich um etwa 8 Byte. Dazu kommenunter Umständen Markierungs-Header. Eine gute Arbeitsgröße liegt zwischen 1400 und 1440, je nach Strecke und Geräten. An der Grenze schaltet man MSS clamping auf 1360–1380, damit TCP nicht fragmentiert.

Besonders empfindlich: Mobilnetze, CGNAT, Wi‑Fi

4G/5G und CGNAT schneiden gern an der MTU, ICMP wird oft gefiltert. Ergebnis: PMTUD funktioniert nicht, Daten werden „blind“ geschickt. Wi‑Fi-Router für den SOHO-Bereich aktivieren manchmal ICMP-Schutz. Gute Absichten, nur ohne Effekt. 2026 setzen Betreiber verstärkt IPv6-only und Transport über QUIC/HTTP3 ein – das bringt weitere Encapsulation-Schichten. Jetzt heißt’s wieder, Bytes zählen – jetzt auch für UDP/QUIC über TLS.

Fragmentierung, PMTUD und DF-Bit: Netzwerkmechanik verstehen

Wie Fragmentierung in IPv4 und IPv6 funktioniert

IPv4 kann Pakete unterwegs fragmentieren: wenn das Paket groß ist und DF=0 gesetzt ist, schneidet der Router es in Teile, der Empfänger setzt sie wieder zusammen. Im Konzept schön, in der Praxis schlecht: Fragmente gehen leichter verloren, Firewalls blockieren sie, Performance leidet. IPv6 verlangt strikte Fragmentierung nur beim Sender, unterwegs nicht, und garantiert minimal 1280 Bytes MTU. MTU-Fehler schlagen deswegen bei IPv6 deutlicher und schmerzhafter zu.

Path MTU Discovery: Warum es scheitert

PMTUD findet die kleinste MTU auf dem Weg, basierend auf ICMP „Fragmentation needed“ oder „Packet too big“. Wird ICMP blockiert, ist PMTUD blind, Pakete stoßen an die Decke und verschlucken sich. So entsteht das Blackhole MTU-Problem. 2026 setzen viele TCP-Stacks PLPMTUD (Packetization Layer PMTUD) ein: es testet Segmentgrößen ohne ICMP. Alte Geräte und Apps vertragen das aber nicht immer.

DF, ICMP und Filterpolitik

Das DF-Bit verbietet Fragmentierung unterwegs. Es wird fast immer gesetzt, auch bei VPNs, wo Fragmentierung außerhalb des Tunnels gefährlich ist. Wenn dann ICMP geblockt wird, entsteht ein Dilemma: fragmentieren geht nicht, und man kann dem Sender nicht sagen „mach’s kleiner“. Resultat: festhängende TCP-Sessions. Daher die goldene Regel: ICMP „Fragmentation needed“ und IPv6 „Packet too big“ müssen durchkommen. Immer. Auch wenn du aus Sicherheitsgründen rigoros sein willst.

MSS-Clamping: Wann und wie es hilft

MSS vs. MTU: Kurz und prägnant

MSS-Clamping heißt, an der Grenzstelle das MSS in TCP SYN-Paketen herunterzusetzen, damit Sender keine zu großen Segmente senden. Es ersetzt nicht die korrekte MTU-Konfiguration, schützt aber die TCP-Verbindungen. UDP profitiert nicht davon, aber 80% der Webprobleme sind so sofort erledigt.

Wo MSS-Clamping eingestellt wird

Unter Linux benutzt man Firewall-Regeln. Bei nftables oder iptables fügt man Regeln ein, die das MSS in SYN-Paketen anpassen. MikroTik bietet Mangle-Module für TCP. Cisco und Juniper haben Firewall-/Zone-Policies mit tcp-mss. Wichtig ist, dass das MSS-Clamping an der Tunnelgrenze passiert, wo der Traffic rein oder raus geht, damit die MSS-Anpassung zum echten MTU der Encapsulation passt.

Fallstricke

Zu kleines MSS verschlechtert TCP-Effizienz, zu großes sorgt wieder für MTU-Probleme. Wenn du das Tunnel-MTU änderst, denk daran, auch MSS neu zu berechnen. Klassisch: MSS = MTU - 40 für IPv4 (IP+TCP=20+20), bei IPv6 ebenfalls minus 40, wegen anderer Header-Struktur. VPN-Overhead muss man abziehen, wenn das Clamping vor der Encapsulation passiert.

MTU-Problem-Diagnose: Schritt-für-Schritt-Anleitung

Schneller Algorithmus

1. Symptome von Blackhole prüfen: Webseiten laden nur teilweise, lange Anfragen hängen, RDP bricht ab.
2. Ping mit großen Paketen und DF-Bit senden. IPv4: „ping -M do -s SIZE Adresse“. IPv6: „ping -s SIZE -M do“, je nach OS unterschiedlich. Ziel: größtes Paket ohne Fragmentierung finden.
3. Tracepath oder „traceroute --mtu“ ausführen, um zu sehen, wo MTU Schranken auftreten.
4. Prüfen, ob ICMP „Fragmentation needed“ und IPv6 „Packet too big“ durchkommen. Falls nicht, Policies anpassen und erlauben.
5. Tunnel-MTU reduzieren und MSS-Clamping aktivieren. Starte sicher mit 1360–1380, dann langsam erhöhen.

Praktische Werkzeuge

Ping mit DF und Größe suchen das maximale „-s“, das ohne Paketverlust durchgeht. Für Ethernet und WireGuard ist die typische Obergrenze 1380–1420, aber immer im Einzelfall testen. Tracepath zeigt die PMTU-Schätzung. Wireshark hilft beim Nachweis von ICMP „Packet too big“, falls sie kommen, und bei der Bestimmung der nötigen Größe. Linux-Befehle wie „ip link show dev wg0“ und „ip route get“ zeigen aktuelle MTU-Einstellungen und PMTU auf dem Pfad an.

Besonderheiten verschiedener Protokolle

GRE und L2TP bringen oft eigenen Overhead und Probleme mit PPPoE. IPsec ESP mit NAT-T fügt UDP- und ESP-Header hinzu – da gehen leicht 60–80 Byte verloren. WireGuard ist sparsam, aber empfindlich bei ICMP-Blockaden und schwankender MTU in Mobilnetzen. OpenVPN über UDP leidet öfter unter Fragmentierung, weil Apps große Pakete und TLS-Overhead senden.

Minimal-MTU entlang des Pfads bestimmen

Einfacher Ansatz: Binäre Suche mit Ping, DF bei 1400–1500, dann mit 10er- und 2er-Schritten feinjustieren. Von ermittelter Größe zieht man 20–40 Byte Reserve für Pfadschwankungen ab. Pfade ändern sich dynamisch: tagsüber ein Provider, nachts ein anderer. Eine konservative Reserve verhindert Überraschungen.

MTU-Lösungen und Tuning für VPN in 2026

Empfohlene Werte je Protokoll

• WireGuard über IPv4/UDP: Starte mit 1380–1420. Für 5G und CGNAT eher 1380–1400. Für IPv6 mindestens 1280 im Tunnel, wegen Encapsulation 1280–1360.
• OpenVPN UDP: tun-mtu 1400–1500, mssfix 1360 als Ausgangspunkt. Auf Mobil- und Wi‑Fi-Netzen besser 1400/1360 oder weniger.
• IPsec ESP NAT-T: Tunnel-MTU 1400–1440, MSS 1360–1380. PPPoE zieht noch mal 8–12 Byte ab.
• GRE/L2TP: Strecke prüfen, meist 1400–1460, PPPoE bedeutet 1380 oder darunter.

Automatisierung und Management

Skripte, die regelmäßig PMTU prüfen und Interface-MTU neu setzen, sind 2026 voll im Trend. Für WireGuard eignen sich pre-up-Hooks in wg-quick und systemd-networkd mit netlink, um beim Aufbau des Tunnels schnell einen Test zu machen, eine sichere MTU zu ermitteln und diese zu setzen. Eine kleine Reserve von 20 Byte unter dem Testergebnis spart Stunden Supportaufwand.

Richtlinien an der Grenze

Erlaube immer ICMP-Typen „Fragmentation needed“ und IPv6 „Packet too big“. Das ist keine Sicherheitslücke, sondern Luft für PMTUD. In ACLs und Security Groups muss dafür eine Ausnahme existieren. Falls DPI oder WAF im Einsatz sind, stell sicher, dass sie ICMP nicht standardmäßig schneiden. Das ist ein alter Reflex, der 2026 archaisch wirkt.

Trends 2026: QUIC, MASQUE, BBRv3, 5G SA

QUIC und MASQUE machen VPN über HTTP/3 zur Normalität statt Exot. Der Overhead wird komplexer, PMTUD für UDP-Tracks doppelt so wichtig. BBRv3 in modernen Kernel-Versionen verbessert Verhalten bei Paketverlust, kann aber harte Fragmentierungsprobleme nicht lösen. In 5G SA und Netzwerk-Slicing setzen Betreiber Optimierungen ein, die MTU dynamisch verändern. Das verlangt Nachjustieren via regelmäßiges Auto-Tuning und Monitoring – Pflichtprogramm.

Sicherheit und Performance: Nicht schaden

Risiken durch Fragmentierung

Angriffe mit überlappenden Fragmenten, das gute alte Teardrop-Like, kommen in falschen Konfigurationen immer noch vor. Fragmentierung vergrößert die Angriffsfläche, VPN erhöht sie wegen Encapsulation und komplexem Pfad noch. Am besten vermeidet man Fragmentierung komplett: MTU senken und MSS-Clamping verwenden.

QoS, ECN und TFO

MTU beeinflusst QoS-Qualität: Falsche Paketgrößen zerstören Klassifizierung und Queue-Management. ECN und TCP Fast Open bringen mehr Reaktionsfähigkeit, helfen bei Blackhole-MTU aber nicht und können durch unnötige Retransmits schlimmer machen. Erst MTU richtig einstellen, dann Details feintunen.

SLO-Monitoring

Wichtige Kennzahlen sind SRT (Server Response Time), RTT, Paketverlust, Anteil TCP-Retransmits, Anzahl ICMP „Packet too big“. Steigt der Anteil von RST und FIN mit kurzen Sessions, schau auf MSS. Kommt ein Time-Wait-Sturm, prüfe MTU und Clamping. Ein einfaches Dashboard mit Korrelation „MTU-Änderungen – Benutzerbeschwerden“ zeigt das Problem oft sofort an.

Checklisten und fertige Vorlagen

Schnelle MTU-Checkliste fürs VPN

1. Finde die echte PMTU-Pfadgröße, vertraue nicht einfach auf „1500 Standard“.
2. Setze die Tunnel-MTU sicher unter den ermittelten Wert minus 20–40 Byte.
3. Aktiviere MSS-Clamping an der Grenze für TCP (Start 1360, dann anpassen).
4. Erlaube ICMP-Typen „Fragmentation needed“ und „Packet too big“.
5. Führe A/B-Tests auf Teilverkehr durch, beobachte Beschwerden und Metriken.
6. Automatisiere PMTU-Prüfung bei Interface-Start.

Konfigurationsvorlagen: Was wo anpassen

• WireGuard: MTU im Interface-Config setzen. Start 1380–1420. Ping mit DF testen. Bei PPPoE noch weiter runter.
• OpenVPN: tun-mtu und mssfix benutzen. Viele mobile Clients? Starte mit 1400/1360.
• IPsec: MTU am Tunnel-Inneninterface senken, MSS-Clamping einrichten. NAT-T und PPPoE beachten.

Clouds und Provider: Besonderheiten

2026 unterstützen viele Clouds Jumbo Frames innerhalb des VPC, aber an der Internet-Grenze gilt meist 1500 (oder weniger). Entweder end-to-end Kontrolle mit ICMP erlauben oder mit „zufälligen“ Performanceeinbrüchen rechnen. Besonders spannend sind interregionale 5G-Backhauls, wo MTU im Tagesverlauf schwankt. Auto-Tuning oder statisch 1360 verhindern Kämpfe.

SOHO- und mobile Router

Heim- und Semi-Pro-Router haben oft verborgene Optionen „Block ICMP“. Ausschalten! MSS-Clamping im Bereich „Firewall“ oder „Mangle“ aktivieren. Für OpenVPN-Clients ruhig mal MTU auf 1400 setzen, wenn es an der Verbindung hakt oder zu 90 % ausgelastet erscheint.

Häufige MTU-Mythen

„Kleinere MTU ist immer besser“

Nein. Zu kleine MTU verschlechtert Effizienz: mehr Header, mehr Pakete, mehr Interrupts. Balance ist entscheidend. Beginne konservativ und steigere langsam, wenn die Strecke stabil ist.

„1500 ist Naturgesetz“

Das ist eine praktische Ethernet-Konvention, aber kein Dogma. Über PPPoE, Tunnel, Mobilnetze ist oft weniger angesagt. Akzeptiere Pfadfakten statt Lehrbuch-Mythen.

„IPv6 ist immer besser bei MTU“

IPv6 ist strenger mit Fragmentierung, deshalb fallen MTU-Probleme schneller auf. Das ist gut, denn Schmerzen kommen sofort, nicht verteilt über Retransmits. Aber „besser“ heißt nicht „ohne Konfiguration“. PMTUD für IPv6 einschalten, ICMPv6 und „Packet too big“ nicht blockieren.

Fazit: Kurze Zusammenfassung und nächste Schritte

Ein Satz Zusammenfassung

MTU ist Netz-Physik und gesunder Menschenverstand. VPN fügt Bytes hinzu, das Internet ist Lautstärke und Filter. Entweder du respektierst PMTUD und lässt ICMP durch oder spielst Ratespiel und verschwendest Supportzeit. Entscheide dich für Ersteres und schläfst besser.

Fehler, die du vermeiden solltest

• Blockieren von ICMP „Fragmentation needed“ und „Packet too big“.
• Vertrauen auf „1500 reicht“ ohne Pfadtests.
• Kein MSS-Clamping für TCP.
• Ignorieren von PPPoE- und NAT-T-Overhead bei Berechnungen.

So geht’s weiter

1. Teste Hauptstrecken mit DF und tracepath.
2. Setze Tunnel-MTU mit Reserve und aktiviere MSS-Clamping.
3. Automatisiere Tests beim Interface-Start.
4. Füge MTU-bezogene Kennzahlen zum Monitoring hinzu.

FAQ: Kurze Antworten auf knifflige Fragen

Wie erkenne ich schnell, dass MTU das Problem ist?

Wenn „Internet scheint da zu sein, aber nur Teile laden“, besonders beim Laden großer Ressourcen oder Downloads – ziemlich sicher MTU. Teste Ping mit DF und großen Paketen, vergleiche mit Tracepath. ICMP-Blockade ist fast ein sicherer Indikator.

Welchen MTU-Wert soll ich in WireGuard bei 5G nehmen?

Starte mit 1380. Läuft es stabil, schraube hoch auf 1400–1420. Bei merkwürdigen Hängern zu Spitzenzeiten zurück auf 1380. Und vergiss nicht MSS-Clamping bei 1360.

Kann ich einfach MSS-Clamping aktivieren und MTU ignorieren?

Das erleichtert TCP, hilft aber nicht UDP und löst das Problem nicht vollständig. Korrekte MTU plus MSS-Clamping ist das beste Team. Nur eins von beiden zu machen heißt, den Anwendern Restprobleme zu lassen.

Warum geht bei mir zu Hause alles schnell, während bei entfernten Mitarbeitern alles klemmt?

Wegen unterschiedlicher Pfade: Büro mit ordentlichem 1500 vom Provider, zuhause CGNAT, Wi-Fi und ein „kluger“ Router, der ICMP blockiert. Dein perfektes MTU auf dem Papier passt nicht zur realen Strecke.

Welches Mindest-MTU sollte ich bei IPv6 und VPN einhalten?

Nicht unter 1280 im Tunnel gehen. Denk an Encapsulation-Overhead. Die meisten Setups funktionieren gut mit 1280–1360. ICMPv6 „Packet too big“ unbedingt erlauben.

Wie wichtig ist ICMP-Freigabe in der Produktion?

Sehr wichtig. Das ist wie ohne Licht auf der Autobahn fahren. Klar gibt es PLPMTUD und Tricks, aber Zeitverlust durch ICMP-Sperren ist teurer – in Arbeitszeit und Nutzerzufriedenheit.

Was ist bei QUIC/HTTP3 und MTU zu beachten?

QUIC auf UDP reagiert empfindlich auf verlorene große Datagramme. Falsche MTU führt zu Lags und plötzlich schwankender Geschwindigkeit. PMTU prüfen, konservativ einstellen und für TCP-Sessions trotzdem MSS-Clamping aktiv lassen.