Es gehört zu den frustrierendsten IT-Problemen überhaupt, weil es allen üblichen Diagnosemustern widerspricht: Das VPN verbindet sich einwandfrei, der Ping ist niedrig, kleine Zugriffe funktionieren flott – aber sobald echte Datenmengen fließen sollen, bricht alles zusammen. Dateiübertragungen starten und bleiben dann hängen. Der Zugriff auf Netzlaufwerke quält sich. Videokonferenzen über den Tunnel ruckeln, während sie ohne VPN tadellos laufen. Die Internetleitung ist nachweislich schnell, der Server langweilt sich, die Firewall-Regeln stimmen – und trotzdem ist der Tunnel unbrauchbar. Wer dieses Muster kennt, sollte einen Verdächtigen ganz oben auf die Liste setzen, an den kaum jemand denkt: die MTU. In diesem Beitrag erklären wir anhand eines realen Falls aus unserer Praxis, was dahintersteckt – so, dass es auch ohne Netzwerktechnik-Studium nachvollziehbar ist – und wie die Lösung aussieht.
Der Fall: Ein Tunnel, der alles richtig macht – und trotzdem nicht funktioniert
Ausgangslage bei einem unserer Projekte: ein WireGuard-VPN, also ein moderner, schlanker VPN-Tunnel, wie er heute vielfach für Homeoffice-Anbindungen und Standortvernetzungen eingesetzt wird. Der Verbindungsaufbau funktionierte sofort, die Authentifizierung stimmte, kleine Anfragen – ein Ping, der Aufruf einer Weboberfläche – liefen ohne Auffälligkeit. Nur der Durchsatz war katastrophal: Statt der erwarteten Geschwindigkeit tröpfelten die Daten, größere Übertragungen blieben regelrecht stecken.
Die übliche Verdächtigenliste wurde abgearbeitet und brachte nichts: Die Serverlast war minimal, die Bandbreite beider Anschlüsse mehr als ausreichend, die Firewall-Regeln korrekt, die VPN-Konfiguration lehrbuchmäßig. Auffällig war nur die Netzwerk-Topologie: Der Anschluss hing hinter einem Provider-Modem, dahinter stand eine eigene Firewall – eine sogenannte Doppel-NAT-Situation, bei der die Datenpakete gleich zweimal hintereinander durch eine Adressumsetzung laufen. Diese Konstellation ist in österreichischen Betrieben und Homeoffices extrem verbreitet: Das Modem des Internetanbieters lässt sich oft nicht in einen reinen Durchleitungsmodus versetzen, und dahinter betreibt man die eigene Netzwerkausrüstung. Genau in solchen Konstellationen gedeiht das Problem, um das es hier geht: ein MTU- beziehungsweise PMTUD-Blackhole. Klingt kryptisch, ist aber gut erklärbar.
Was ist die MTU – und warum kann sie ein VPN lahmlegen?
Daten wandern durchs Netzwerk nicht als kontinuierlicher Strom, sondern zerlegt in einzelne Pakete. Die MTU – Maximum Transmission Unit – legt fest, wie groß ein einzelnes Paket maximal sein darf. Im klassischen Ethernet und bei den meisten Internetanschlüssen sind das 1500 Bytes. Man kann sich das wie eine Höhenbeschränkung auf einer Straße vorstellen: Fahrzeuge bis zu dieser Höhe kommen durch, größere nicht.
Jetzt kommt das VPN ins Spiel. Ein VPN-Tunnel verschlüsselt jedes Datenpaket und verpackt es in ein zusätzliches Transportpaket – man kann sich das als Kuvert im Kuvert vorstellen. Dieses äußere Kuvert braucht Platz: Verschlüsselungs- und Transport-Informationen kommen zum ursprünglichen Paket dazu, es wird also größer. Wenn nun der Computer im Homeoffice ein Paket in voller Standardgröße losschickt und das VPN sein Kuvert drumherum packt, ist das Gesamtpaket plötzlich größer als die 1500 Bytes, die die Leitung verträgt. Das Fahrzeug ist höher als die Brücke.
Für genau diese Situation haben die Erfinder des Internets einen Mechanismus vorgesehen: die Path MTU Discovery, kurz PMTUD. Die Idee: Wenn ein Paket irgendwo unterwegs zu groß ist, schickt die betroffene Station eine Rückmeldung an den Absender – sinngemäß „dein Paket passt hier nicht durch, mach es kleiner“. Der Absender verkleinert daraufhin seine Pakete, und alles läuft. Ein elegantes, selbstregulierendes System.
Nur: Es funktioniert lediglich, wenn diese Rückmeldungen auch ankommen. Und genau hier liegt das Problem. Diese Meldungen laufen über das Protokoll ICMP – dieselbe Protokollfamilie, zu der auch der Ping gehört –, und viele Firewalls und Router sind aus falsch verstandener Sicherheitsvorsicht so konfiguriert, dass sie ICMP pauschal verwerfen. In Doppel-NAT-Konstellationen gehen solche Meldungen zusätzlich gerne an der Adressumsetzung verloren, weil sie dem inneren Absender nicht mehr korrekt zugestellt werden können. Das Ergebnis ist das erwähnte Blackhole, das schwarze Loch: Der Absender schickt große Pakete los, irgendwo unterwegs werden sie verworfen, und die Nachricht darüber erreicht ihn nie. Er wartet, sendet erneut, wartet wieder – aus seiner Sicht verschwinden die Pakete spurlos im Nichts.
Und jetzt erklärt sich auch das paradoxe Fehlerbild vollständig: Kleine Pakete – der Verbindungsaufbau, ein Ping, der Abruf einer kleinen Webseite – bleiben unter der kritischen Größe und kommen problemlos durch. Deshalb „funktioniert“ das VPN scheinbar. Große Pakete – und jede Dateiübertragung, jeder Netzlaufwerk-Zugriff, jeder Video-Stream besteht überwiegend aus maximal gefüllten Paketen – verschwinden im schwarzen Loch. Deshalb bricht genau dann alles zusammen, wenn es um echten Durchsatz geht. Das Problem ist binär: Ein Paket passt durch oder es passt nicht. Es gibt kein „langsam durchquetschen“.
Die Lösung: Paketgröße bewusst begrenzen
Wenn der Aushandlungsmechanismus nicht funktioniert, weil seine Rückmeldungen unterwegs sterben, gibt es eine robuste Alternative: Man verzichtet auf die Aushandlung und legt die Paketgröße im Tunnel von vornherein so fest, dass sie garantiert überall durchpasst.
Bei WireGuard geschieht das über eine einzige Zeile in der Konfigurationsdatei, und zwar wichtig: auf beiden Seiten des Tunnels, also am Server ebenso wie am Client. Als robuster Wert für hartnäckige Fälle bietet sich 1280 an – das ist die Mindest-Paketgröße, die der IPv6-Standard auf jedem Pfad im Internet garantiert, sozusagen die Durchfahrtshöhe, die weltweit jede Brücke einhält:
ini[Interface]
MTU = 1280
In unserem Fall war das die Lösung: Nach dem Setzen der MTU auf beiden Seiten lief der Tunnel augenblicklich mit voller Geschwindigkeit. Keine neue Hardware, kein Providerwechsel, keine stundenlangen Umbauten – eine Konfigurationszeile, richtig gesetzt, nachdem die Ursache verstanden war. Es sei erwähnt, dass wir als Zwischenschritt zusätzlich das sogenannte TCP MSS Clamping auf dem Gateway aktiviert hatten – ein Mechanismus, bei dem der Router die maximale Segmentgröße von TCP-Verbindungen beim Verbindungsaufbau automatisch auf ein tunnelverträgliches Maß herabsetzt. Das entschärft das Problem für den Großteil des Datenverkehrs und ist eine sinnvolle Maßnahme auf jedem VPN-Gateway; die konservative MTU-Einstellung auf beiden Endpunkten war in diesem Fall aber die endgültige, vollständige Lösung, weil sie sämtlichen Verkehr erfasst und nicht nur TCP.
Wer es nach der Sofortlösung genauer wissen will, kann den optimalen Wert übrigens austesten: Läuft der Tunnel mit 1280 stabil, lässt sich die MTU schrittweise erhöhen, bis das Problem wieder auftritt – der letzte funktionierende Wert ist das Optimum für diesen konkreten Pfad. In der Praxis ist der Geschwindigkeitsunterschied zwischen 1280 und dem theoretischen Optimum allerdings so gering, dass sich der Aufwand selten lohnt; Stabilität schlägt hier die letzten Prozent Effizienz.
Ihre Merkliste für die Fehlersuche
Falls Sie ein zähes VPN plagen, hier das Diagnoseschema, das sich aus solchen Fällen ableitet. Erstens, das Muster erkennen: Verbindungsaufbau und kleine Zugriffe funktionieren, aber Übertragungen hängen und große Datenmengen quälen sich? Das ist die klassische MTU-Signatur – Bandbreiten- oder Serverprobleme sehen anders aus, die machen alles gleichmäßig langsam. Zweitens, die Topologie prüfen: Ist ein Doppel-NAT im Spiel, also ein eigener Router oder eine eigene Firewall hinter dem Provider-Modem? Dann erhärtet sich der Verdacht deutlich. Drittens, der Schnelltest: MTU im VPN testweise auf beiden Seiten auf 1280 setzen und die Übertragung wiederholen. Läuft es jetzt, ist die Diagnose bestätigt. Viertens, die dauerhafte Lösung: die MTU-Einstellung fix in die Konfiguration übernehmen und am Gateway zusätzlich MSS Clamping aktivieren. Und fünftens, falls all das nichts ändert: Dann liegt die Ursache woanders, und es lohnt der Blick auf Serverlast, Leitungsqualität und Routing – aber nach unserer Erfahrung ist bei diesem spezifischen Fehlerbild die MTU in der Mehrzahl der Fälle der Täter.
Fazit
Dieser Fall steht exemplarisch für eine ganze Klasse von IT-Problemen: Die Symptome sind dramatisch, die üblichen Verdächtigen unschuldig, und die Ursache ist ein einzelner unscheinbarer Parameter, der tief in den Mechanismen des Netzwerks vergraben liegt. Solche Fehler findet man nicht durch Ausprobieren, sondern durch Verständnis dafür, wie die Dinge unter der Haube funktionieren – und dann ist die Lösung oft verblüffend einfach. Wenn Ihr VPN also „eigentlich funktioniert, aber irgendwie nicht wirklich“: Es liegt vielleicht nicht an Ihrer Leitung, nicht an Ihrem Server und nicht an Ihrer Geduld. Vielleicht ist nur ein Paket zu groß für eine Brücke, von der es nie erfahren hat.
Ihr VPN, Ihre Standortvernetzung oder Ihre Homeoffice-Anbindung macht Probleme? Wir analysieren Ihre Netzwerkinfrastruktur systematisch, finden die tatsächliche Ursache statt an Symptomen zu doktern und sorgen für stabile, schnelle Verbindungen – von der Firewall über das VPN bis zum letzten Arbeitsplatz. Kontaktieren Sie uns, wir schauen uns das an.
