Die Verbindung steht, der Handshake läuft durch, kleine Anfragen werden beantwortet — aber sobald echte Daten fließen sollen, bleibt alles hängen. Dieses Fehlerbild führt fast immer zur selben Ursache, und sie hat nichts mit Routing oder Firewall-Regeln zu tun.

Zwei Begriffe, zwei Ebenen

Die MTU (Maximum Transmission Unit) ist das größte IP-Paket, das eine Strecke am Stück transportieren kann. Im Ethernet sind das 1500 Byte. Sie ist eine Eigenschaft des Weges, nicht der Verbindung.

Die MSS (Maximum Segment Size) ist die größte Nutzlast eines TCP-Segments. Sie ist eine Eigenschaft der Verbindung: Beide Seiten teilen beim Verbindungsaufbau im SYN mit, wie viel sie entgegennehmen können.

Zusammen hängen sie über die Header, die noch dazukommen:

MSS = MTU − IP-Header − TCP-Header

IPv4:  1500 − 20 − 20 = 1460
IPv6:  1500 − 40 − 20 = 1440

Ein Rechner am Ethernet kündigt also üblicherweise eine MSS von 1460 an. Das ist die Zahl, die man in jedem SYN-Paket sieht — und der Ausgangspunkt für alles Weitere.

Wo die MTU kleiner wird

Solange der ganze Weg 1500 Byte kann, fällt das Thema nie auf. Interessant wird es, sobald irgendwo gekapselt wird — jede zusätzliche Hülle kostet Platz:

  • PPPoE — 8 Byte, MTU 1492, damit MSS 1452
  • GRE — 24 Byte, MTU 1476, damit MSS 1436
  • IPsec — je nach Verfahren und Modus grob 50 bis 70 Byte, in der Praxis landet man häufig um 1400

Bei IPsec lohnt es sich, nicht zu rechnen, sondern zu messen: Der genaue Aufschlag hängt von Transport- oder Tunnelmodus, Verschlüsselungsverfahren, Authentifizierung und einer eventuellen NAT-Traversal-Kapselung ab.

Warum es niemandem auffällt — bis es zu spät ist

Eigentlich gibt es einen Mechanismus dafür. Bei Path MTU Discovery setzt der Absender im IP-Header das DF-Bit: nicht fragmentieren. Kommt ein Router an eine Strecke, die das Paket nicht am Stück weiterreichen kann, verwirft er es und schickt eine ICMP-Nachricht zurück — Typ 3, Code 4, „Fragmentation Needed and DF Set". Darin steht die zulässige Größe. Der Absender verkleinert daraufhin seine Segmente.

Das funktioniert allerdings nur, solange dieses ICMP-Paket auch ankommt. Wird es unterwegs verworfen — weil jemand ICMP pauschal für unsicher hält und alles blockiert —, erfährt der Absender nie, dass seine Pakete zu groß sind. Er schickt sie weiter, sie verschwinden weiter, und niemand meldet es. Man nennt das ein PMTUD-Blackhole.

Das Fehlerbild ist charakteristisch:

  • Der TCP-Handshake funktioniert — die Pakete sind winzig
  • Kleine Anfragen werden beantwortet
  • Größere Übertragungen bleiben mittendrin stehen und laufen in einen Timeout
  • SSH-Login klappt, aber ein ls in einem großen Verzeichnis hängt
  • Eine Webseite lädt endlos, während der Ping tadellos aussieht

Genau diese Mischung führt bei der Fehlersuche gern in die Irre: Erreichbarkeit ist gegeben, Routing stimmt, die Firewall-Regel greift — trotzdem geht nichts.

Nachweisen

Der schnellste Test ist ein Ping mit fester Größe und gesetztem DF-Bit. Man schickt bewusst ein Paket, das exakt die vermutete MTU ausfüllt, und schaut, ob es durchkommt:

Windows:  ping -f -l 1472 ziel.example
Linux:    ping -M do -s 1472 ziel.example

Die 1472 sind kein Zufall: 1472 Byte Nutzlast plus 8 Byte ICMP-Header plus 20 Byte IP-Header ergeben genau 1500. Kommt keine Antwort, verkleinert man schrittweise. Der erste Wert, der durchgeht, plus 28 ergibt die tatsächliche MTU des Weges.

Wer es genauer mag, schaut sich das SYN im Mitschnitt an. Der angekündigte MSS-Wert steht als TCP-Option direkt darin — und verrät sofort, ob unterwegs jemand daran gedreht hat.

Die Lösung: MSS-Clamping

Man könnte die MTU auf allen Endgeräten anpassen. Das ist in einem Unternehmensnetz aussichtslos. Der praktikable Weg führt über den Router am Tunnel: Er schreibt den MSS-Wert im durchlaufenden SYN aktiv klein, bevor er weitergereicht wird. Beide Enden einigen sich damit von vornherein auf eine Größe, die passt — ganz ohne ICMP.

Cisco IOS, auf dem Tunnel-Interface:
  ip tcp adjust-mss 1360

FortiGate, in der Firewall-Policy:
  set tcp-mss-sender 1350
  set tcp-mss-receiver 1350

Die genaue Zahl richtet sich nach der tatsächlichen MTU des Tunnels. Ein bewusst konservativer Wert kostet etwas Durchsatz, aber deutlich weniger Nerven als ein Blackhole, das erst unter Last auffällt.

Eine wichtige Einschränkung: MSS-Clamping wirkt ausschließlich auf TCP, denn nur dort gibt es eine ausgehandelte Segmentgröße. UDP-basierte Protokolle — QUIC und damit ein wachsender Teil des Webverkehrs, DNS mit großen Antworten, VPN-in-UDP — bleiben davon unberührt. Dort hilft nur eine korrekt gesetzte MTU auf dem Pfad oder Fragmentierung.

Was hängen bleiben sollte

Wenn eine Verbindung zustande kommt, aber nichts Großes hindurchpasst, ist die MTU der erste Verdächtige — noch vor Routing und Regelwerk. Zwei Minuten mit einem Ping fester Größe ersparen oft einen halben Tag Suche an der falschen Stelle.

Und wer ICMP im Netz pauschal blockiert, sollte wenigstens Typ 3 Code 4 durchlassen. Sonst schaltet man einen Mechanismus ab, der genau diese Probleme von allein lösen würde.