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: De jämförda hjälpsidorna för SFOS 22 och 23 beskriver L2TP som en konfigurerbar typ av fjärråtkomst. Det visar det dokumenterade funktionsomfånget, inte tillgängligheten i varje build eller något löfte för senare huvudversioner. Avanet rekommenderar inte L2TP som ny standard för hanterade klienter. Skapa ingen ny L2TP-åtkomst utan ett konkret krav kopplat till äldre system eller kompatibilitet.

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. För enskilda applikationer kan Clientless SSL VPN ge webbläsarbaserad åtkomst utan en fullständig nätverkstunnel. PPTP är inget modernt reservalternativ: protokollet definierar varken kryptering eller autentisering i sig; valbara inloggningsmetoder gör det inte till en säker ny målarkitektur.

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.

De fullständiga L2TP-hjälpsidorna för SFOS 22 och 23 beskriver samma globala inställningar, policyfält och konfigurationssteg. Denna dokumentationsjämförelse är inget test av brandväggsenheter eller klienter och gör inte SFOS 22-exemplet till en verifierad SFOS 23-konfiguration. Plattformsmatrisen för Sophos Connect, IPsec och SSL VPN i FAQ:n om fjärråtkomst är inte heller någon kompatibilitetsmatris för L2TP; vid ett byte följer man den klientjämförelse som länkas ovan och respektive arbetsflöde för IPsec eller SSL VPN.

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

Aktivera Enable L2TP under Remote access VPN > L2TP > L2TP global settings. 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. DNS är ett valfritt fält: välj servern i listan eller ange dess adress via Other. Secondary DNS server, Primary WINS server och Secondary WINS server anges endast om de faktiskt behövs i miljön; WINS ersätter inte DNS.

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.

Välj därefter gruppen L2TP_Users via Add members, lägg till den med Add 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 huvudgrupp 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.

Begränsningar vid automatisering via XML-API

Stegen i gränssnittet utgör inte en färdig XML-API-begäran. De jämförda API-sidorna för SFOS 22 och 23 skiljer under L2TPConfiguration de globala värdena i L2TPSettings från medlemmarna i L2TPMembers med UserName. Till skillnad från gränssnittet anger tabellen PrimaryDNSServer som ett obligatoriskt fält med en IPv4-adress. Att DNS-fältet är valfritt i gränssnittet bevisar därför inte att denna API-parameter får utelämnas. L2TPGeneralSettings och LeaseIPFromRadiusServer anges där som valfria, med Disable som dokumenterat standardvärde; detta fastställer inget testat beteende när de utelämnas. Före automatisering måste API-kontraktet för den installerade builden klargöras, utan att gissa en kodning för ett tomt DNS-värde. Läs därefter tillbaka de avsedda globala värdena och medlemskapet; proceduren i gränssnittet och RADIUS-reservförfarandet som beskrivs ovan förblir separata.

För den sparade policy som beskrivs nedan visar API-exemplet L2TPConnection med Configuration; bredvid finns styrgrenarna Connection, DisConnection, Active och DeActive, var och en med Name. Att spara, ansluta, koppla från och aktivera avser alltså inte samma identitet eller åtgärd. Ikonerna i gränssnittet styrker inte en körbar API-begäran. Dessutom motsäger exemplet och fälttabellen varandra: RemoteHost innehåller ett värdnamn eller en IP-adress i exemplet, medan tabellen tillåter IPv4 eller *; AliasLocalWANPort står endast för ett WAN-alias i exemplet, men är obligatoriskt i tabellen. För DisconnectOnIdleInterval anger tabellen standardvärdet 0, men samtidigt intervallet 120 till 999; 600 är endast exempelvärdet. Härled varken någon betydelse för noll eller säkra ersättningsvärden från detta. Klargör dessa punkter för den specifika builden före API-ändringar och kontrollera den oberoende hanteringsvägen samt effekterna på delade wildcard-PSK:er enligt beskrivningen ovan.

Även vid senare avveckling måste borttagning av en sparad anslutning skiljas från inaktivering av den och från global avstängning av L2TP. Inventera först den befintliga konfigurationen, inaktivera den avsedda anslutningen och kontrollera beroenden. Delete L2TP Connection kräver det exakta sparade Name (första bokstaven A-Za-z, därefter A-Za-z0-9_, högst 50 tecken); sidan innehåller inget exempel på en begäran. Dess statusmappningar 200/L2TPDeleteSuccess, 203/L2TPConnInUse och 500/L2TPDeleteFail hänvisar till olösta Message-identifierare, inte till bekräftade meddelandetexter eller en HTTP-klassificering. Räkna i synnerhet inte 203 som en generell lyckad borttagning i 2xx-klassen. När borttagningsbegäran har klargjorts ska det exakta målnamnet kontrolleras igen och det ska bekräftas att den produktionsåtkomst som fortfarande behövs finns kvar; gissa inte ett begärandehölje för borttagning eller automatisk efterföljande rensning.

Statisk användaradress och befintliga PPTP-beroenden

De användarspecifika fälten för adresstilldelning finns under Authentication > Users > [användare] i avsnittet för fjärråtkomstinställningar. L2TP tillåter L2TP-åtkomst och har ett fält för den IP-adress som ska leasas till fjärranvändaren. PPTP har ett eget reglage och ett separat fält för den IP-adress som ska leasas. Det är två separata kontoinställningar, inte den globala poolen och inte någon IP-tilldelning för SSL VPN. Hantera den lokala användaren och dess lösenord enligt Skapa lokala användare på Sophos Firewall. Planera en unik, konfliktfri adress endast för en motiverad befintlig åtkomst, spara med Save och kontrollera den faktiskt tilldelade adressen och returvägen vid nästa anslutning från ett externt nätverk. Vid RADIUS-leasing fungerar användaradressen fortfarande som den reservlösning som beskrivs ovan om RADIUS inte levererar någon adress; ett kontoreglage ersätter varken behörigheten via Add members eller brandväggsregeln.

Första inloggningen före tunneln: Hjälpen för att lägga till användare i SFOS 22 och 23 kräver att policymedlemmar, efter att L2TP eller PPTP har aktiverats, först loggar in på VPN portal och skapar ett lösenord innan de ansluter. Kontrollera detta dokumenterade första åtkomststeg med ett pilotkonto för den build och autentiseringsserver som används. Återställ inte befintliga lösenord på chans och byt inte generellt från en fungerande kataloginloggning till lokala lösenord. Portalens tillgänglighet och VPN portal authentication methods ska kontrolleras separat från tunnelns autentiseringsmetod; WebAdmin behöver inte öppnas från WAN för detta.

Vid inventering av en redan befintlig PPTP-åtkomst finns Enable PPTP, Assign IP from, det gemensamma alternativet för RADIUS-leasing samt primär DNS-server och valfria sekundära DNS-/WINS-servrar under Remote access VPN > PPTP. Leasen gäller under anslutningens varaktighet; det privata adressintervallet ligger i ett /24 eller mindre subnät och innehåller högst 254 adresser. Det får inte överlappa adressintervallen för Remote Access IPsec och SSL VPN. Hjälpen beskriver Apply för globala värden samt Add members och Show members för användarbehörighet; inte heller här ger en import av AD- eller Entra ID-grupper automatiskt åtkomst. Dessa fält läses endast av i den befintliga konfigurationen för migrering och felsökning, inte som en rekommendation att aktivera PPTP. De dokumenterade metoderna PAP, CHAP och MS-CHAPv2 ger ingen modern säkerhetsstandard; ersättningen planeras med IPsec, SSL VPN eller applikationsspecifik åtkomst.

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. Digital certificate autentiserar ändpunkterna genom utbyte av lokalt signerade certifikat eller certifikat som utfärdats av en certifikatutfärdare. Certifikat gör att man slipper en gemensam 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 regelbundet förnyas på ett kontrollerat sätt.

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.

Remote host kan även innehålla en IP-adress eller ett värdnamn för en fast motpart. Remote subnet beskriver de fjärranslutna näten; kontrollera värdet mot den aktuella klientlösningen. Fälthjälpen tillåter TCP-/UDP-portar eller wildcardvärdet * för Local port och Remote port; exemplet med lokal port 1701 är ingen allmän föreskrift för alla selektorkonfigurationer. Policyhjälpen kallar avsnittet QuickHA mode, medan konfigurationsguiden talar om Quick Mode-selektorer. Rubriken får inte tolkas som att det finns en HA-funktion: det avgörande är de två portfälten och de samordnade IPsec-selektorerna.

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.

Efter Save aktiveras policyn 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; hjälpen beskriver anslutningsåtgärden via dess statusikon. För en fjärrklient är det fortfarande klientens anslutningsförsök från ett externt nätverk som är avgörande. Logs på L2TP-sidan öppnar L2TP-loggarna. När Active är avaktiverat är policyn inaktiv, oavsett ett tidigare tunneltillstånd.

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, VPN. För L2TP måste däremot VPN-rutter utvärderas först; Static och SD-WAN kan därefter följa i valfri ordning. Logga in i brandväggens CLI och välj 4. Device Console. Spara först det faktiska utgångsläget där:

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 regel med loggning under Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule och spara den sedan med Save. Ange ett tydligt Rule name, exempelvis VPN-LAN. Sophos-exemplet med Any för källa, mål och tjänst är enkelt för en första funktionskontroll, 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. Anslut 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ör 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.

Överför inte L2TP-regler vid byte till Sophos Connect

FAQ:n om fjärråtkomst behandlar IPsec och SSL VPN, inte något ytterligare klientstöd för L2TP. Plattformstabellen anger .pro eller .scx för IPsec och .pro eller .ovpn för SSL VPN på Windows; samma filtyper anges för macOS med Sophos Connect från version 2.1. macOS med Connect 2.0 använder .scx respektive .ovpn; före 2.0 används fortfarande Sophos Connect med .scx för IPsec, men en tredjepartsklient med .ovpn för SSL VPN. Android använder tredjepartsklienter med .tgb för IPsec eller .ovpn för SSL VPN; iOS behöver ingen ytterligare klient för IPsec och hämtar konfigurationen från VPN portal, men behöver en tredjepartsklient med .ovpn för SSL VPN. Kontrollera den aktuella klient-/OS-kombinationen före bytet. Kryptering kontrolleras under Remote access VPN > IPsec > IPsec profiles > Encryption algorithm för IPsec och under Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings för SSL VPN. FAQ:ns generella påstående om krypterad fjärråtkomst får inte överföras till PPTP utan separat protokollskydd.

Vid Sophos Connect-provisionering används gatewayadresserna i .pro endast för hämtning från portalen, inte för tunnelval: IPsec använder det konfigurerade gränssnittet, medan SSL VPN använder gränssnitten från .ovpn som finns under Network > Interfaces och tillåts av Local Service ACL. Override hostname anger den önskade publika SSL VPN-adressen; bakom en router ska routerns publika FQDN eller WAN-IP anges i .pro, en lämplig DNAT-vidarebefordran konfigureras på routern och dess WAN-IP anges som gateway i .scx för IPsec. Det privata standardcertifikatet för WebAdmin och VPN Portal kan orsaka ett förtroendefel vid provisionering; korrigera certifikatkedjan i stället för att stänga av kontrollen. Brandväggskonfigurationen för Sophos Connect och arbetsflödet för SSL VPN ersätter här L2TP-konfigurationen.

Vid IPsec-ändringar kräver FAQ:n Edit connection > Update policy och en ny hämtning från portalen; för SSL VPN gäller manuella uppdateringar framför allt port, protokoll, gateway och SSL-servercertifikat. .pro hämtar vissa SSL VPN-ändringar automatiskt; en ny import kan hämta båda konfigurationerna på nytt. Följ Hämta SSL VPN-profilen på nytt för att skilja mellan profiluppdateringar och nedladdningsfel. Sophos Connect använder SSL VPN-gatewayadresserna från .ovpn i omvänd prioritetsordning, inte nödvändigtvis i ordningen från .pro. SSL VPN fördelar poolen på CPU-beroende instanser med egna tun0-subnät: mindre intervall än /24 minskar kapaciteten för adresstilldelning; för /27 och åtta instanser anger FAQ:n att endast en lease-adress återstår. Det är ingen poolgräns för L2TP. Uteblivna .ovpn-nedladdningar kan också hänga samman med användar-ID:n över den gemensamma användar-/grupp-ID-gränsen på 65535; Kontrollera användar-ID-gränsen säkert beskriver kontrollerad rensning i stället för generell borttagning.

MFA för ersättningslösningen planeras under Authentication > Multi-factor authentication med de nödvändiga valfälten User portal, SSL VPN remote access och IPsec remote access. Det separata OTP-fältet kräver för IPsec Prompt users for 2FA token och Apply, eller vid provisionering otp: true och 2fa: 1. Sophos Connect skickar lösenord och OTP kombinerat som passwordotp och stöder enligt FAQ:n inget OTP-challenge-flöde; metoder med telefonsamtal eller push stöds, och WebAdmin stöder dessutom challenge-baserad MFA. Kontrollera denna skillnad i pilotprojektet för provisionering och överför den inte till en inbyggd L2TP-klient. FAQ:n begränsar dessutom Remote Access IPsec till ett WAN-gränssnitt; det innebär varken samma begränsning för L2TP eller något löfte om Multi-WAN för ersättningslösningen.

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

Rollback innebär att endast de tillstånd som ändrats under denna procedur återställs till det dokumenterade utgångsläget, inte att en befintlig L2TP-miljö avvecklas. Före den första ändringen dokumenteras därför de globala L2TP-värdena, inklusive Enable L2TP, Active-statusen för varje berörd policy, den fullständiga listan under Add members, användarbehörigheter, brandväggsregler och IPsec-åtkomsten under Administration > Device access; nya element och ändringar av befintliga element noteras separat. Om utgångsvärden saknas eller det inte finns en bekräftad metod för exakt återställning på den installerade builden utförs inte den berörda ändringen; klargör först detta med Sophos Support. Ett dokumenterat standardvärde ersätter inte ett avläst utgångsvärde.

Under rollback hålls den oberoende hanteringsvägen öppen. Först återställs Route Precedence, om den ändrats under denna procedur, exakt till den tidigare sparade ordningen. Ordningen läses sedan av igen med system route_precedence show, och hanterings-, Static-, SD-WAN- och VPN-vägarna kontrolleras. Om ordningen inte har ändrats behålls den.

I en befintlig konfiguration återställs endast de ändrade värdena, policytillstånden, medlemskapen och behörigheterna exakt. Befintliga policyer, medlemmar, regler och åtkomsttillstånd behålls i sina ursprungliga tillstånd; om Enable L2TP tidigare var aktiverat förblir det aktiverat. Att återställa en enskild Device Console-ändring är inget skäl att ta bort dessa åtkomstmöjligheter eller stänga av L2TP globalt.

Avveckling av en driftsättning som skapats helt under denna procedur hanteras separat: före varje inaktivering eller borttagning kontrolleras beroendena och det bekräftas att ingen produktionsåtkomst som fortfarande behövs påverkas. Först därefter inaktiveras den nyskapade L2TP-policyn och effekterna kontrolleras med en pilotklient. Ta sedan endast bort nyskapade brandväggsregler och IPsec-åtkomsttillstånd som inte längre behövs, och ta endast bort de medlemmar från Add members som lagts till under denna procedur. Inaktivera Enable L2TP endast om det var inaktiverat före denna procedur och inget beroende som fortfarande behövs finns kvar. Befintliga gemensamt använda element tas inte bort som en del av rensningen.

Efter återställningen jämförs de sparade globala värdena, Show members, policystatus, användarbehörigheter, regler och Device Access med det dokumenterade utgångsläget. Bekräfta med en extern pilotklient att den produktionsåtkomst som behövdes tidigare fortfarande fungerar och att borttagna testbehörigheter inte längre tillåter åtkomst. Preshared Key återställs inte blint till ett tidigare värde; alla policyer med samma WAN-port och wildcard-gateway kontrolleras tillsammans.

FAQ