Varför L2TP/IPsec behöver UDP 1701 utöver IPsec

Brandväggar som tillåter IKE och ESP men inte UDP 1701 bryter L2TP-anslutningar på ett sätt som ser ut som ett problem med inloggningsuppgifter. Orsaken är att L2TP är ett andra protokoll som färdas inuti det första. IPsec bär och autentiserar utbytet, och L2TP kör sin egen tunnel över UDP 1701, som den lokala stacken fortfarande måste leverera. Att veta var varje header dyker upp förklarar vilken enhet som behöver vilken regel.

Två protokoll, två portuppsättningar

En L2TP/IPsec-anslutning använder IKE på UDP 500, NAT-genomgång på UDP 4500 där översättning finns, och ESP som IP-protokoll 50 där den inte finns. L2TP självt är ett tunnelprotokoll på UDP 1701, och det körs efter att IPsec har autentiserat motparten. De två halvorna misslyckas olika, och loggraderna som rapporterar om dem kommer från olika komponenter. En regeluppsättning som bara täcker den första halvan ger en anslutning som förhandlar och sedan dör i tunnelstadiet.

Portnummer beskriver transportändpunkter, och ESP är inte en port alls. Därför kan ett brandväggsgränssnitt som bara erbjuder TCP- och UDP-regler inte uttrycka en fullständig IPsec-policy. Protokoll 50 måste tillåtas som protokoll, och en regel som bara nämner UDP kommer aldrig att matcha den.

Omslaget förklarar porten

På ledningen visar en L2TP/IPsec-anslutning vanligtvis IKE på 500 och inkapslad ESP på 4500. UDP 1701-headern sitter inuti den skyddade nyttolasten, därför visar en fångst på det yttre gränssnittet den inte. Den lokala värden måste ändå leverera det datagrammet till L2TP-demonen, och leveransen sker efter avkapslingen. Regeln för 1701 hör därför till slutpunktens egen brandvägg, även när ingen mellanliggande enhet någonsin ser porten.

Bearbetningsordningen förklarar det mesta av förvirringen. Om stacken tillämpar IPsec-policyn före värdens filter matchas det avkapslade L2TP-paketet som UDP 1701; om ordningen är omvänd är det de yttre portarna som regeluppsättningen ser. Båda beteendena finns i praktiken, därför verkar samma regeluppsättning fungera på en plattform och misslyckas på en annan.

Kontrollera vägen i ordning

Gör först en fångst på det yttre gränssnittet och bekräfta att IKE och inkapslad ESP rör sig i båda riktningarna. Kontrollera sedan värdens brandväggsräknare för den avkapslade trafiken. Ordningen spelar roll, eftersom en fångst som inte visar någonting alls betyder att problemet ligger ovanför värden.

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

Fångsten bekräftar den första halvan av utbytet och visar om motparten svarar. Regelistan visar om det finns en regel för 1701 och var den står i förhållande till en eventuell dropp-policy. Socketlistan bekräftar att L2TP-demonen är bunden och lyssnar, vilket utesluter en tjänst som aldrig startade. Läs alla tre innan du ändrar en regel, eftersom en saknad lyssnare och en filtrerad port ger identiska klagomål från användaren.

Vad en portskanning inte kan visa

En extern skanning av UDP 1701 mot en korrekt konfigurerad server rapporterar vanligtvis ingenting, och det är det förväntade resultatet. Porten är inte exponerad mot internet; den nås bara efter att IPsec har autentiserat motparten. Att behandla det stängda resultatet som ett fel leder till att en port öppnas som borde förbli stängd. Skanningen kan inte se in i tunneln mer än den kan se applikationens trafik.

Testa i stället med en riktig klient, och läs vilket stadium den når. Om anslutningen förhandlar och sedan fastnar är L2TP-demonen eller det lokala filtret misstänkt; om den aldrig förhandlar är det de yttre portarna. Den enda uppdelningen tar bort det mesta av gissandet om vilken regel som ska läggas till, och protokollagren gör det förutsägbart i stället för mystiskt.