Windows L2TP laadt maar enkele sites: wis de DF-bit op pfSense

De laptop maakt verbinding, het intranet laadt en een handvol openbare sites blijft hangen. Authenticatie en routering werken duidelijk, waardoor de pakketgrootte als verklaring overblijft. In een L2TP/IPsec-tunnel is de bruikbare MTU kleiner dan wat de adapter nog aankondigt, en de client blijft pakketten op volle grootte sturen met de don’t-fragment-bit gezet. Een pfSense-gateway kan opdracht krijgen die bit te wissen, en dat is de snelste manier om de diagnose te bevestigen voordat je het goed oplost.

Begin bij de pagina’s die mislukken

Noteer welke bestemmingen mislukken en welke slagen voordat je een instelling aanraakt. Handshakes die onder de tunnelgrens blijven, ronden normaal af, terwijl overdrachten die een segment op volle grootte nodig hebben halverwege blijven steken. Die splitsing is de signatuur van een grootteprobleem en niet van een filter, omdat een geblokkeerde bestemming bij het opzetten van de verbinding mislukt en niet midden op de pagina. Beide waarnemingen kosten niets en vernauwen de zoektocht meteen.

Test met een ping die de bit zet en de payloadgrootte regelt. De grootste payload die doorkomt, vertelt je de werkelijke pad-MTU, en de aangekondigde waarde van de adapter laat zien hoe ver die twee uit elkaar liggen.

Schrijf beide getallen op. De oplossing hangt ervan af welke fout is, en het paar is wat een opname later bevestigt.

Wat de DF-bit doet bij het naar buiten gaan

Inkapseling is de reden dat de getallen verschillen. IPsec voegt ESP toe, L2TP nog een header, en de tunnel vervoert daardoor minder payload dan de fysieke verbinding. Windows meldt nog steeds 1500 bytes op de adapter en zet don’t-fragment op wat het verstuurt. Als zo’n pakket niet past, is het juiste antwoord van de gateway een ICMP-bericht dat de afzender vraagt te krimpen. Daarom kan een tunnel die kleine pings doorlaat, toch een bestandsdownload laten mislukken.

Dat bericht komt vaak nooit aan. Een hop kan ICMP filteren, of niets genereert het, en de afzender herhaalt dezelfde grootte tot de overdracht opgeeft.

Stilte is hier de normale presentatie, en daarom wordt het symptoom gelezen als selectieve blokkering. Niets in het clientlog registreert een ontbrekend ICMP-bericht.

De pfSense-optie, en wat die niet doet

De optie staat op de pagina Systeem, Geavanceerd, Firewall en NAT, met het label «Ongeldige DF-bits wissen in plaats van de pakketten te laten vallen». In plaats van een te groot pakket met de vlag weg te gooien, verwijdert het filter de vlag en laat het pakket verderop splitsen. Een pakket geldt als ongeldig wanneer het de uitgaande interface niet in één stuk kan passeren.

De optie herstelt de verbinding zonder de client aan te raken, en daarom is hij populair. Het is ook een omweg: fragmentatie kost CPU en maakt elk verloren fragment duurder.

Hij geldt alleen voor doorgestuurd verkeer, niet voor verkeer dat de firewall zelf opwekt. Dezelfde pagina biedt «Firewall-scrub uitschakelen», wat normalisatie volledig uitzet, en dat is een veel bredere wijziging dan dit probleem nodig heeft.

Een smallere oplossing die TCP ongefragmenteerd houdt

Bijna alle vastgelopen stromen zijn TCP, en TCP kan een kleiner segment onderhandelen in plaats van op fragmentatie te vertrouwen. MSS beperken op de tunnelinterface herschrijft de aangekondigde waarde tijdens de handshake, zodat elke kant verstuurt wat werkelijk past. Het pad gedraagt zich dan voorspelbaar en geen pakket hoeft te worden gesplitst.

Dat laat UDP over aan ontdekking of aan de DF-optie. Wanneer de mislukkende sites gewone webpagina’s zijn, is de beperking de wijziging die je moet verkiezen.

De client kan zijn eigen adapter-MTU rapporteren via netsh interface ipv4 show subinterfaces. Vergelijk dat getal met wat de server denkt dat is onderhandeld, want die twee zijn niet altijd gelijk. Die waarde is wat het besturingssysteem werkelijk gebruikt, wat de onderhandeling ook meldde.

Bevestig met een opname en herstel daarna de status

Neem aan beide kanten op voordat je beslist: één spoor waar de tunnel loopt, en één waar de WAN-interface loopt. Pakketten die op volle grootte vertrekken zonder dat ICMP terugkomt, wijzen op de beperking als de juiste laag. Antwoorden die aankomen en dan op de terugweg sterven, wijzen juist op de MTU van de tunnel.

Leeg de statustabel voordat je het opnieuw probeert, want bestaande stromen houden hun oude segmentgroottes. Laad daarna de pagina die mislukte en lees de statusweergave voor tweerichtingsverkeer in plaats van eenzijdige tellers. Als het nog steeds blijft steken, neem dan opnieuw op in plaats van een ander selectievakje te proberen.