Konfigurera och testa L2TP-fjärråtkomst på Sophos Firewall

L2TP-fjärråtkomst är fortfarande tillgänglig på Sophos Firewall, men bör inte automatiskt vara förstahandsvalet för nya hanterade endpoints. Sophos Connect med IPsec eller SSL VPN är enklare att driva centralt och ger den mer kompletta Sophos-klientvägen. L2TP är fortsatt användbart när ett operativsystem måste använda sin inbyggda VPN-klient eller när en befintlig kompatibel miljö behöver fortsätta på ett kontrollerat sätt.

Bedömning för nya miljöer: Den aktuella hjälpen för SFOS 22 dokumenterar fortfarande L2TP som en konfigurerbar typ av fjärråtkomst. Sophos har inte publicerat något meddelande om att funktionen ska avvecklas. Det innebär dock ingen garanti för stöd i en framtida huvudversion. Avanet rekommenderar inte L2TP som ny standard för hanterade klienter. Implementera inte en ny L2TP-åtkomst utan ett konkret äldre kompatibilitetskrav eller behov av att driva en befintlig miljö vidare.

L2TP i sig definierar tunneln, inte den säkerhet som krävs. På Sophos Firewall skyddar en IPsec-policy anslutningen. IPsec-profil, autentisering, preshared key eller certifikat och klientkonfiguration måste därför stämma överens. En grön Active-status betyder dessutom bara att policyn är aktiverad; först Connection-status och faktisk trafik bekräftar tunneln.

⚠️ Den Route Precedence som Sophos kräver för L2TP placerar globalt vpn före Static och SD-WAN Policy Routes. En ny L2TP-policy med wildcard-peer kan också påverka befintliga preshared keys. Före ändringen måste därför den aktuella ordningen, en oberoende hanteringsväg och alla andra VPN-, Static- och SD-WAN-vägar dokumenteras.

L2TP i åtta steg

1. Kontrollera att L2TP verkligen behövs och att klient, IPsec-profil och autentisering är kompatibla.
2. Planera ett privat lease-intervall utan överlappning, interna DNS-servrar och en snävt avgränsad användargrupp.
3. Aktivera L2TP och lägg till användare under Remote access VPN > L2TP > L2TP global settings.
4. Skapa en L2TP-policy med matchande IPsec-profil, WAN-port, autentisering och NAT Traversal.
5. Under Administration > Device access, tillåt tjänsten IPsec för den WAN-tillgänglighet som krävs.
6. Spara aktuell Route Precedence och placera vpn först genom en kontrollerad ändring.
7. Skapa en snäv brandväggsregel med loggning från zonen VPN till de interna mål som faktiskt behövs.
8. Verifiera autentisering, lease-adress, DNS, regel, returväg och ett negativt test med en extern pilotklient.

När L2TP passar

L2TP kan vara användbart för operativsystemens inbyggda klienter eller befintliga enheter där Sophos Connect inte är avsett. Det är också ett rimligt val när en liten, redan dokumenterad L2TP-miljö ska fortsätta utan ytterligare klientprogramvara.

För en ny standardutrullning är Sophos Connect med IPsec eller SSL VPN oftast lämpligare. Profildistribution, klientdiagnostik och den Sophos-specifika supportvägen är tydligare där. PPTP är inte ett modernt reservalternativ: protokollet definierar inte självt kryptering och bör inte längre planeras för nya fjärranslutningar.

Tre gränser måste vara tydliga före konfigurationen:

• På Sophos Firewall använder L2TP en gemensam global adresspool och gemensamma DNS-inställningar för alla L2TP-policyer.
• Grupper som importeras från Active Directory eller Microsoft Entra ID aktiveras inte automatiskt för L2TP. De måste uttryckligen läggas till via Add members.
• L2TP och PPTP tar bara hänsyn till relevant Main Group när gruppmedlemskap utvärderas. Ett ytterligare gruppmedlemskap bevisar därför inte ensamt behörighet. Hantera användargrupper och Main Group korrekt förklarar bakgrunden.

Exempel och förberedelser

Exemplet ansluter en extern klient till ett internt applikationsnät. Värdena är avsiktligt dokumentationsvärden och måste anpassas till den egna miljön:

• L2TP-pool: 10.250.30.10 till 10.250.30.100 inom 10.250.30.0/24
• intern DNS-server: 10.10.10.10
• tillåten grupp: L2TP_Users
• policynamn: L2TP_Remote_Access
• IPsec-profil: DefaultL2TP som utgångspunkt för kompatibilitetstestet
• internt målnät: 10.10.10.0/24
• exempeltjänst: HTTPS

Intervallet 10.250.30.0/24 är endast ett privat exempelnät. Det får inte överlappa LAN-, VLAN-, Site-to-Site- eller hemnät och inte heller lease-intervall för Remote Access IPsec, SSL VPN eller PPTP. Sophos tillåter högst 254 adresser för Assign IP from, inom ett /24 eller mindre subnet.

Kontrollera dessutom följande före start:

• En passande IPsec-profil är anpassad till inställningarna som den inbyggda klienten stöder.
• Den publika adressen eller FQDN för vald WAN-port kan nås från klienten.
• Systemtid, DNS och certifikatkedja är korrekta när ett certifikat används.
• Användaren eller gruppen finns och rätt autentiseringsmetod är angiven under Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• Aktuell utdata från system route_precedence show och ett motsvarande rollback-kommando är dokumenterade.
• WebAdmin eller konsolen förblir tillgänglig via en oberoende hanteringsväg.

Autentiseringskällan och klienten måste stödja samma metod: SFOS anger PAP, CHAP eller MSCHAPv2 för Local och RADIUS, endast PAP för Active Directory och LDAP, samt PAP eller CHAP för TACACS+. Kontrollera före utrullningen vilken metod som stöds av både källan och den inbyggda klienten. Det yttre IPsec-skyddet är fortfarande obligatoriskt för L2TP; denna kompatibilitetsmatris är ingen rekommendation för PPTP eller oskyddad användning av PAP.

Konfigurera globala L2TP-inställningar

Under Remote access VPN > L2TP > L2TP global settings, aktivera Enable L2TP. Ange i exemplet 10.250.30.10 till 10.250.30.100 under Assign IP from. Välj 10.10.10.10 som Primary DNS server om servern kan slå upp interna namn. Ange sekundär DNS och WINS endast när miljön faktiskt behöver dem.

Alternativet Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client är bara meningsfullt när RADIUS-servern tillförlitligt levererar en lämplig adress. Om den inte returnerar en adress använder brandväggen först en statisk adress som konfigurerats för användaren eller därefter den globala poolen. Både RADIUS-tilldelningen och reservvägen måste därför planeras utan överlappning. Konfigurera RADIUS på Sophos Firewall beskriver serverkonfigurationen.

Lägg därefter till gruppen L2TP_Users via Add members och kontrollera den med Show members. För en kataloganvändare räcker inte en lyckad gruppimport. En pilotanvändare måste faktiskt tillhöra den tillåtna gruppen, och gruppen måste vara den Main Group som används vid L2TP-utvärderingen.

Skapa L2TP-policyn

Under Remote access VPN > L2TP, använd Add för att skapa policyn L2TP_Remote_Access.

Profil och startbeteende

Välj den IPsec-profil som matchar klienterna under Profile. I exemplet används den befintliga profilen DefaultL2TP som utgångspunkt för kompatibilitetstestet. Algoritmer och lifetimes måste ändå jämföras med värdena som klienten stöder; ett namn som innehåller Default är ingen bestående säkerhetsgaranti. De två värdena för Gateway type har olika driftskonsekvenser:

• Respond only håller policyn redo efter en omstart så att den kan svara på inkommande förfrågningar.
• Disable lämnar den inaktiv tills den slås på manuellt via Active-status.

För en produktiv Remote Access-tjänst är Respond only normalt den mest begripliga utgångspunkten. Kontrollera valet uttryckligen efter en omstart av brandvägg eller tjänst, så att aktivering och anslutningsstatus inte förväxlas.

Autentisering och preshared key

Tillgängliga värden för Authentication type är Preshared key och Digital certificate. Certifikat undviker en delad PSK men kräver en fullständigt planerad förtroendekedja och lämpligt klientstöd. En PSK måste vara lång och slumpmässig, överföras separat och förnyas kontrollerat.

Sophos använder den senast konfigurerade PSK:n för alla anslutningar med samma lyssningsinterface och samma remote peer. För Remote Access är Remote host normalt inställd på *. En ny eller ändrad wildcard-policy kan därför ersätta PSK:n för befintliga Remote Access-konfigurationer. Granska alla policyer som använder samma WAN-port och wildcard-gateway innan konfigurationen sparas.

Definiera matchande värden för Local ID och Remote ID när PSK används. ID-typen DER ASN1DN (X.509) accepteras inte med PSK. ID-värdena måste stämma med den inbyggda klienten och får inte sättas till godtyckliga värden av bekvämlighet.

WAN-port, peer och selektorer

Välj den WAN-port som faktiskt kan nås under Local WAN port. För klienter med varierande adresser ställs Remote host in på wildcardvärdet *. Aktivera Allow NAT traversal när klienter befinner sig bakom NAT, vilket är normalt i hemnät, mobilnät och hotellnät.

För den typiska Remote Access-processen använder Sophos-exemplet Remote subnet: Any, Local port: 1701 och Remote port: *. 1701 är L2TP-porten på brandväggen; klientporten kan variera. Dessa värden är tunnelselektorer och ersätter inte en brandväggsregel. Den efterföljande åtkomsten förblir begränsad till specifika zoner, mål och tjänster.

Med Disconnect when tunnel is idle kan brandväggen koppla från inaktiva klienter efter perioden som anges under Idle session time interval. Anpassa värdet till det faktiska arbetsmönstret och testa med realistiska pauser. Ett för kort intervall orsakar onödiga återanslutningar; utan gräns kan bortglömda sessioner förbli aktiva längre.

Aktivera policyn efter Save via den röda ikonen i kolumnen Active. Grönt under Active betyder ännu inte att en klient är ansluten. Den separata Connection-statusen visar om tunneln faktiskt har etablerats.

Tillgänglighet, routing och brandväggsregel

Tillåt IPsec på WAN

Under Administration > Device access måste IPsec tillåtas för den WAN-tillgänglighet som krävs. Behörigheten ska implementeras så snävt som topologin medger. En stark PSK eller ett certifikat motiverar inte onödigt bred åtkomst till WebAdmin, User Portal eller SSH. Device Access och Local Service ACL förklarar skillnaden mellan tjänstens tillgänglighet och användarbehörighet.

Ställ in Route Precedence kontrollerat

Sophos kräver för L2TP att VPN-rutter utvärderas före Static och SD-WAN Policy Routes. Spara först utgångsläget i Device Console:

system route_precedence show

Ställ därefter in den dokumenterade L2TP-ordningen och kontrollera den igen:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Ändringen är global och inte en isolerad inställning för den nya L2TP-policyn. Testa både före och efter ändringen överlappande Static-, SD-WAN- och VPN-vägar samt hanteringsåtkomst. Justera Route Precedence på Sophos Firewall förklarar effekten och säker rollback.

Tillåt åtkomst till interna mål

Skapa en IPv4-regel med loggning under Rules and policies > Firewall rules. Sophos-exemplet med Any för källa, mål och tjänst är enkelt för ett första funktionstest, men är ingen bra permanent säkerhetsstandard. Exemplet här är snävare:

• Source zone: VPN
• Source network: L2TP-poolen 10.250.30.0/24 eller ett matchande IP host-objekt
• Destination zone: zonen som innehåller applikationsnätet
• Destination network: 10.10.10.0/24 eller helst de servrar som behövs
• Services: HTTPS eller endast de tjänster som faktiskt krävs
• Log firewall traffic: aktiverad

Internettrafik genom brandväggen kräver en separat regel från VPN till WAN och en medveten NAT- och säkerhetsdesign. Åtkomsten skapas inte automatiskt enbart för att L2TP-tunneln är etablerad.

Verifiera anslutningen

Verifieringen görs från ett verkligt externt nätverk. Ett test från samma LAN eller via en redan befintlig VPN-väg kan dölja problem med routing, NAT och publik tillgänglighet.

1. Ansluta med en behörig pilotanvändare och den dokumenterade klientkonfigurationen.
2. Kontrollera Active- och Connection-status separat under Remote access VPN > L2TP.
3. Kontrollera att klienten får en adress från 10.250.30.10 till 10.250.30.100 och avsedda DNS-servrar.
4. Slå upp ett internt namn och nå ett uttryckligen tillåtet mål via HTTPS.
5. Kontrollera förväntad Firewall Rule ID, käll-IP från L2TP-poolen, mål, tjänst och action i Log Viewer.
6. Kontrollera returvägen från målnätet till L2TP-poolen och upprepa samma åtkomst efter en ny anslutning.
7. Genomföra ett negativt test med en användare som inte har lagts till; användaren får inte få en användbar tunnel.
8. Testa idle-beteende, frånkoppling, återanslutning och vid HA en kontrollerad failover med en ny inloggning.

Lyckad autentisering bevisar inte datapathen. En grön tunnel bevisar inte heller att DNS, regel, NAT och returväg är korrekta. Testa regler på Sophos Firewall förklarar hur bevis från Log Viewer och Packet Capture skiljs åt.

Felsök systematiskt

Policyn är aktiv, men tunneln förblir down

Jämför först WAN-port, publik tillgänglighet, IPsec under Device Access, NAT Traversal, klientadress, PSK eller certifikat, Local/Remote ID och IPsec-profil. Kontrollera därefter om en senare sparad wildcard-policy har ersatt den förväntade PSK:n.

Använd i den första avgränsningen l2tpd.log för L2TP och strongswan.log eller charon.log för IPsec-förhandlingen. Tjänster och loggfiler på Sophos Firewall innehåller hela mappningen. Korrelera loggarna med exakt tid, användare, klientens publika IP och policynamn; en omstart av tjänsten är inte det första diagnostiksteget.

Inloggningen misslyckas eller användaren får ingen åtkomst

Under Authentication > Services, kontrollera metoden för VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Kontrollera därefter om användaren eller gruppen finns under Add members och vilken grupp som visas som Main Group i användarobjektet. Vid RADIUS kontrolleras dessutom autentisering och valfri lease-tilldelning separat.

Tunneln är up, men interna mål kan inte nås

Kontrollera i tur och ordning lease-adress, Route Precedence, Firewall Rule ID, målroute och returväg. En bred SD-WAN-route eller konkurrerande Static Route kan ändra vägen. L2TP-poolen måste kunna nås från det interna nätet utan att en andra identisk route eller ett överlappande nät tar över returvägen.

Om Log Viewer visar Rule 0, en oväntad Rule ID eller ingen matchande post ska den faktiska regelmatchningen fastställas innan något breddas till Any. Om det utgående paketet syns men inget svar återkommer fortsätter kontrollen på målhosten, dess gateway, lokala brandvägg eller returroute.

Anslutningen är långsam eller instabil

Kontrollera latency, packet loss, MTU eller fragmentering, WAN-byten och CPU-belastning under ett reproducerbart test. En enda SMB-överföring är inget rent test av VPN-throughput. Flera kontrollerade TCP-strömmar i båda riktningarna hjälper till att skilja tunnel, transport och applikation åt.

Om bara L2TP-anslutningar är instabila jämförs tidsstämplar i l2tpd.log, IPsec-loggarna, WAN-händelser och klientloggen. Ändra profil, MTU eller idle time separat och i ett underhållsfönster först när ett konkret samband har styrkts.

Säker rollback

Håll den oberoende hanteringsvägen öppen under rollback. Återställ först exakt den sparade Route Precedence och testa hanterings-, Static-, SD-WAN- och VPN-vägar. Inaktivera därefter L2TP-policyn och bekräfta med en pilotklient att inget produktionsberoende återstår.

Ta sedan bort brandväggsreglerna och IPsec-behörigheten om ingen annan tjänst är beroende av dem. Först därefter tas användarna bort från Add members och Enable L2TP stängs av. Återställ inte Preshared Key blint till ett tidigare värde; kontrollera alla policyer med samma WAN-port och wildcard-gateway tillsammans.

FAQ