Waarom L2TP/IPsec naast IPsec ook UDP 1701 nodig heeft

Firewalls die IKE en ESP toestaan maar niet UDP 1701, breken L2TP-verbindingen op een manier die op een probleem met inloggegevens lijkt. De reden is dat L2TP een tweede protocol is dat binnen het eerste reist. IPsec draagt en authenticeert de uitwisseling, en L2TP laat zijn eigen tunnel over UDP 1701 lopen, die de lokale stack nog steeds moet afleveren. Weten waar elke header verschijnt, verklaart welk apparaat welke regel nodig heeft.

Twee protocollen, twee poortsets

Een L2TP/IPsec-verbinding gebruikt IKE op UDP 500, NAT-traversal op UDP 4500 waar vertaling aanwezig is, en ESP als IP-protocol 50 waar dat niet zo is. L2TP zelf is een tunnelprotocol op UDP 1701, en het draait nadat IPsec de peer heeft geauthenticeerd. De twee helften falen verschillend, en de logregels die erover rapporteren komen van verschillende componenten. Een regelset die alleen de eerste helft dekt, levert een verbinding op die onderhandelt en vervolgens sterft in de tunnel-fase.

Poortnummers beschrijven transporteindpunten, en ESP is helemaal geen poort. Daarom kan een firewallinterface die alleen TCP- en UDP-regels biedt geen volledig IPsec-beleid uitdrukken. Protocol 50 moet als protocol worden toegestaan, en een regel die alleen UDP noemt, zal er nooit op passen.

De wikkel verklaart de poort

Op de draad toont een L2TP/IPsec-verbinding gewoonlijk IKE op 500 en ingekapselde ESP op 4500. De UDP 1701-header zit binnen de beschermde lading, daarom toont een opname op de buitenste interface hem niet. De lokale host moet dat datagram nog steeds aan de L2TP-daemon afleveren, en de aflevering gebeurt na de decapsulatie. De regel voor 1701 hoort daarom bij de firewall van het eindpunt zelf, zelfs wanneer geen enkele tussenbox de poort ooit ziet.

De verwerkingsvolgorde verklaart het grootste deel van de verwarring. Als de stack het IPsec-beleid vóór het hostfilter toepast, wordt het gedecapsuleerde L2TP-pakket als UDP 1701 gematcht; als de volgorde omgekeerd is, zijn de buitenste poorten wat de regelset ziet. Beide gedragingen komen in de praktijk voor, daarom lijkt dezelfde regelset op het ene platform te werken en op het andere te falen.

Controleer het pad in volgorde

Maak eerst een opname op de buitenste interface en bevestig dat IKE en ingekapselde ESP in beide richtingen bewegen. Controleer daarna de tellers van de lokale firewall voor het gedecapsuleerde verkeer. De volgorde is belangrijk, want een opname die helemaal niets toont, betekent dat het probleem boven de host zit.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

De opname bevestigt de eerste helft van de uitwisseling en toont of de peer antwoordt. De regellijst toont of er een regel voor 1701 bestaat en waar die staat ten opzichte van enig drop-beleid. De socketlijst bevestigt dat de L2TP-daemon gebonden is en luistert, wat een dienst uitsluit die nooit is gestart. Lees alle drie voordat je een regel wijzigt, want een ontbrekende luisteraar en een gefilterde poort leveren identieke klachten van de gebruiker op.

Wat een poortscan niet kan tonen

Een externe scan van UDP 1701 tegen een correct geconfigureerde server meldt gewoonlijk niets, en dat is het verwachte resultaat. De poort is niet aan het internet blootgesteld; hij is alleen bereikbaar nadat IPsec de peer heeft geauthenticeerd. Het gesloten resultaat als fout behandelen leidt ertoe dat een poort wordt geopend die gesloten zou moeten blijven. De scan kan niet in de tunnel kijken, net zomin als hij het verkeer van de toepassing kan zien.

Test in plaats daarvan met een echte client, en lees welke fase hij bereikt. Als de verbinding onderhandelt en dan vastloopt, zijn de L2TP-daemon of het lokale filter de verdachte; als hij nooit onderhandelt, zijn het de buitenste poorten. Die ene splitsing neemt het meeste giswerk weg over welke regel moet worden toegevoegd, en de protocolgelaagdheid maakt het voorspelbaar in plaats van mysterieus.