Windows L2TP lädt nur manche Seiten: DF-Bit auf pfSense löschen

Der Laptop verbindet sich, das Intranet lädt, und eine Handvoll öffentlicher Seiten hängt. Authentifizierung und Routing funktionieren offensichtlich, sodass die Paketgröße als Erklärung bleibt. In einem L2TP/IPsec-Tunnel ist die nutzbare MTU kleiner, als der Adapter noch ankündigt, und der Client sendet weiterhin Pakete voller Größe mit gesetztem Don’t-Fragment-Bit. Einem pfSense-Gateway lässt sich befehlen, dieses Bit zu löschen, und das ist der schnellste Weg, die Diagnose zu bestätigen, bevor man sie richtig behebt.

Beginnen Sie mit den Seiten, die scheitern

Notieren Sie, welche Ziele scheitern und welche gelingen, bevor Sie irgendeine Einstellung anfassen. Handshakes, die unter dem Tunnellimit bleiben, laufen normal durch, während Übertragungen, die ein Segment voller Größe brauchen, auf halbem Weg stocken. Diese Trennung ist die Signatur eines Größenproblems und nicht eines Filters, denn ein blockiertes Ziel scheitert beim Verbindungsaufbau und nicht mitten auf der Seite. Beide Beobachtungen kosten nichts und verengen die Suche sofort.

Prüfen Sie mit einem Ping, der das Bit setzt und die Nutzlastgröße steuert. Die größte Nutzlast, die durchkommt, nennt Ihnen die tatsächliche Pfad-MTU, und der angekündigte Wert des Adapters zeigt, wie weit beide auseinanderliegen.

Schreiben Sie beide Zahlen auf. Die Korrektur hängt davon ab, welche falsch ist, und das Paar ist es, was ein Mitschnitt später bestätigt.

Was das DF-Bit beim Hinausgehen bewirkt

Die Kapselung ist der Grund für die unterschiedlichen Zahlen. IPsec fügt ESP hinzu, L2TP einen weiteren Header, und der Tunnel trägt daher weniger Nutzlast als die physische Strecke. Windows meldet am Adapter weiterhin 1500 Byte und setzt Don’t-Fragment auf das, was es sendet. Wenn ein solches Paket nicht passt, ist die richtige Antwort des Gateways eine ICMP-Nachricht, die den Absender bittet, sich zu verkleinern. Deshalb kann ein Tunnel, der kleine Pings durchlässt, trotzdem einen Dateidownload scheitern lassen.

Diese Nachricht kommt oft nie an. Ein Hop kann ICMP filtern, oder nichts erzeugt sie, und der Absender wiederholt dieselbe Größe, bis die Übertragung aufgibt.

Stille ist hier die normale Erscheinung, weshalb das Symptom als selektive Blockade gelesen wird. Nichts im Client-Log verzeichnet eine fehlende ICMP-Nachricht.

Die pfSense-Option und was sie nicht tut

Die Option sitzt auf der Seite System, Erweitert, Firewall und NAT mit der Bezeichnung „Ungültige DF-Bits löschen statt Pakete zu verwerfen“. Statt ein übergroßes Paket mit dem Flag zu verwerfen, entfernt der Filter das Flag und lässt das Paket weiter hinten aufteilen. Ein Paket gilt als ungültig, wenn es die ausgehende Schnittstelle nicht in einem Stück passieren kann.

Die Option stellt die Konnektivität wieder her, ohne den Client anzufassen, und ist deshalb beliebt. Sie ist auch ein Workaround: Fragmentierung kostet CPU und macht jedes verlorene Fragment teurer.

Sie gilt nur für weitergeleiteten Verkehr, nicht für Verkehr, den die Firewall selbst erzeugt. Dieselbe Seite bietet „Firewall-Scrub deaktivieren“, was die Normalisierung ganz abschaltet, und das ist eine viel breitere Änderung, als dieses Problem braucht.

Eine engere Korrektur, die TCP unfragmentiert lässt

Fast alle der hängenden Flüsse sind TCP, und TCP kann ein kleineres Segment aushandeln, statt auf Fragmentierung zu setzen. Das Begrenzen von MSS auf der Tunnelschnittstelle schreibt den angekündigten Wert während des Handshakes neu, sodass jede Seite sendet, was tatsächlich passt. Der Pfad verhält sich dann vorhersagbar, und kein Paket muss aufgeteilt werden.

Das überlässt UDP der Erkennung oder der DF-Option. Wenn die scheiternden Seiten gewöhnliche Webseiten sind, ist die Begrenzung die Änderung der Wahl.

Der Client kann seine eigene Adapter-MTU über netsh interface ipv4 show subinterfaces melden. Vergleichen Sie diesen Wert mit dem, den der Server für ausgehandelt hält, denn beide sind nicht immer gleich. Dieser Wert ist der, den das Betriebssystem tatsächlich verwendet, egal was die Aushandlung gemeldet hat.

Mit einem Mitschnitt bestätigen, dann den Zustand zurücksetzen

Nehmen Sie auf beiden Seiten auf, bevor Sie entscheiden: eine Spur, wo der Tunnel läuft, eine andere, wo die WAN-Schnittstelle läuft. Pakete, die in voller Größe hinausgehen, ohne dass ICMP zurückkommt, deuten auf die Begrenzung als richtige Schicht. Antworten, die ankommen und dann auf dem Rückweg sterben, deuten stattdessen auf die Tunnel-MTU.

Leeren Sie die Zustandstabelle, bevor Sie es erneut versuchen, denn bestehende Flüsse behalten ihre alten Segmentgrößen. Laden Sie dann die Seite, die gescheitert ist, und lesen Sie die Zustandsansicht für Verkehr in beide Richtungen statt einseitiger Zähler. Wenn es weiterhin stockt, nehmen Sie erneut auf, statt ein weiteres Kontrollkästchen zu probieren.