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.

Versions- och klientgränser

Guiden är avsedd för SFOS 22.0 MR2 Build 546 och gränssnittet som beskrivs i onlinehjälpen för 22.0. L2TP är tillgängligt i den här versionen. Avanets uppgraderingskontroll för SFOS 22 samlar aktuella uppgraderingsspärrar och stödda vägar; jämför där den konkreta källbuilden med målbuilden före varje migrering. Det finns ingen fullständig kompatibilitetsmatris för inbyggda L2TP-klienter. 22.0-guiden nämner endast Windows 10 som ett konkret klientexempel. Det bevisar inte kompatibilitet med andra eller senare operativsystemsversioner.

Testa därför varje OS-version som faktiskt används separat med avsedd IPsec-profil, autentiseringsserver och ID-typ. Maximalt 254 pooladresser är bara en adressgräns, inte ett löfte om lika många samtidiga sessioner. Den offentliga 22.0-hjälpen anger ingen allmän gräns för L2TP-sessioner. Verifiera kapacitet och stabilitet på den faktiska brandväggsmodellen med förväntad samtidighet.

Den aktuella hjälpen beskriver valbara värden men anger inget universellt standardvärde för Gateway type, Authentication type, Allow NAT traversal eller Disconnect when tunnel is idle i befintliga eller migrerade konfigurationer. Dokumentera dessa fält före och efter en uppgradering i stället för att återskapa dem utifrån en antagen default.

Konfigurera och verifiera den inbyggda Windows-klienten

Skapa anslutningen i Windows under Inställningar > Nätverk och Internet > VPN > Lägg till VPN. Välj Windows (inbyggt) som VPN-leverantör, ange brandväggens publika FQDN eller WAN-adress som Servernamn eller serveradress och välj L2TP/IPsec med i förväg delad nyckel eller det certifikatalternativ som matchar brandväggsprofilen som VPN-typ. Den delade nyckeln måste stämma med L2TP-policyns PSK. Som inloggningsuppgifter används användarnamn och lösenord för ett konto som tillåtits under Add members; dokumentera VPN-typ, inloggningsmetod, ID-värden och klientversion tillsammans.

Genomför det första testet från ett externt nätverk. Efter anslutningen används ipconfig /all för att kontrollera adressen från L2TP-poolen och avsedda DNS-servrar, därefter testas intern namnuppslagning och tillåten HTTPS-åtkomst. Om själva tunneluppkopplingen misslyckas jämförs först servernamn, PSK- eller certifikatläge, inloggningsmetod och överenskommen IPsec-profil, varefter tidsstämpeln korreleras med l2tpd.log och IPsec-loggarna. Varje Windows-version som används förblir en separat klientkombination som måste verifieras.

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.

Klicka på Apply efter ändringar av globala inställningar och medlemmar. Kontrollera sedan de sparade globala värdena och Show members igen. Save för L2TP-policyn är ett separat, senare steg.

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. Idle session time interval anges i sekunder.

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.

Med flera lokala och fjärranslutna subnät skapas en tunnel för varje lokalt/fjärranslutet subnätspar. Connection kan visa ett delvis anslutet tillstånd: konfigurationen är aktiv, men minst en tunnel är inte etablerad. Testa varje nödvändigt subnätspar och dess dataflöde separat; aktiverat Active bekräftar inte alla tunnlar.

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

Standardordningen som Sophos dokumenterar är Static, SD-WAN Policy Routes och därefter VPN. För L2TP måste VPN-rutter i stället utvärderas först; Static och SD-WAN kan sedan följa i valfri ordning. Spara först det faktiska 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. Med flera lokala och fjärranslutna subnät skapas en tunnel för varje lokalt/fjärranslutet subnätspar. Connection kan visa ett delvis anslutet tillstånd: konfigurationen är aktiv, men minst en tunnel är inte etablerad. Testa varje nödvändigt subnätspar och dess dataflöde separat; aktiverat Active bekräftar inte alla tunnlar.
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.

Migrera till SFOS 22

Planera en firmwaremigrering separat från en ändring av L2TP-konfigurationen. Inventera före uppgraderingen exakt firmware och plattform, globala L2TP-inställningar, tillåtna användare och Main Groups, varje L2TP-policy med profil, ID-värden och autentisering, Device Access, Route Precedence samt tillhörande brandväggs- och NAT-regler. Förbered även en krypterad säkerhetskopia och en oberoende hanteringsväg. Använd uppgraderingskontrollen för SFOS 22 för att jämföra den konkreta källbuilden med den aktuella uppgraderingstabellen; det allmänna påståendet att konfigurationer kan migreras till 22.0 GA ersätter inte denna vägkontroll.

Förväxla inte L2TP med Remote Access IPsec (legacy): L2TP är fortfarande tillgängligt i SFOS 22.0 MR2, medan den äldre IPsec-varianten togs ur bruk i 22.0 MR1. Det går inte att uppgradera en brandvägg som innehåller den äldre konfigurationen till 22.0 MR1 eller senare. Dessutom stöder SFOS 22.0 GA och senare versioner inte XG- eller SG-hårdvaruenheter. Plattformen och befintliga fjärråtkomsttyper är därför verkliga stoppvillkor och inte bara inventeringsposter.

SFOS 22.0 MR1 Build 490 rättade NC-162171, där NAS-Identifier inte infogades för L2TP-anslutningar med MS-CHAPv2 eller MS-CHAP. Om RADIUS-regler är beroende av NAS-Identifier och brandväggen kommer från en äldre build ska efter uppgraderingen inte bara inloggningen utan även mottagen RADIUS-request och den RADIUS-policy som faktiskt matchar verifieras. Rättningen bevisar inte att alla klient- och autentiseringskombinationer automatiskt är kompatibla.

Jämför firmwareversionen och alla inventerade fält efter omstarten. Genomför sedan hela verifieringen från ett externt nätverk, inklusive negativt test, DNS, datapath, idle-beteende och en ny inloggning efter en HA-failover. Behåll den gamla åtkomstmetoden som kontrollerad reservväg tills kontrollerna är godkända.

En firmware-rollback är mer än att inaktivera L2TP. Aktiv och tidigare firmware ligger i separata partitioner tillsammans med respektive konfigurationsläge. När den tidigare firmwaren startas blir även dess tidigare konfigurationsläge aktivt, så ändringar sedan uppgraderingen ingår inte i den aktiva konfigurationen efter återställningen. Spara därför nödvändiga senare ändringar separat, kontrollera att målversionen stöds och bekräfta underhållsfönstret för omstarten innan detta steg.

Säker rollback av L2TP-konfigurationen

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