Konfigurera SSL VPN-fjärråtkomst på Sophos Firewall

Remote Access SSL VPN konfigureras på Sophos Firewall under Remote access VPN > SSL VPN. För säker åtkomst måste sex delar fungera tillsammans:

Användare eller grupper tilldelas en SSL VPN-policy.
Protokoll, certifikat, gateway, leaseintervall och DNS konfigureras globalt.
Split Tunnel eller Use as default gateway väljs medvetet.
Trafik från zonen VPN tillåts med snäva brandväggsregler.
VPN Portal, autentisering, MFA och Device Access säkras.
En aktuell .ovpn-profil eller, för Windows, en .pro-provisioneringsfil distribueras och åtkomsten testas både positivt och negativt.

⚠️ SSL VPN är en publikt nåbar ingång. MFA och starka lösenord ersätter inte snäva användargrupper, Local Service ACLs, brandväggsregler, aktuella profiler, loggar och regelbundna granskningar.

Den här artikeln behandlar brandväggssidan. Installationen beskrivs separat för Windows, macOS, iPhone och iPad, Android och Linux. Inför valet mellan SSL VPN, IPsec och ZTNA hjälper Sophos Connect eller SSL VPN.

Förbered förutsättningar och objekt

Före konfigurationen måste den publika åtkomsten, behöriga användare och interna mål vara fastställda:

aktuell SFOS-version och aktuell Sophos Connect-klient;
publik FQDN eller publik IP-adress;
certifikat för SSL VPN-tunneln och VPN Portal;
användare eller grupper samt autentiseringsservrar;
MFA-metod för portal och tunnel;
SSL VPN-leaseintervall utan överlappning;
interna målnät, DNS-servrar och sökdomän;
beslut om Split Tunnel eller Full Tunnel;
process för profildistribution och klientuppdateringar.

Interna mål skapas först som värdar eller nätverksobjekt:

Hosts and services > IP host

I följande exempel används:

LAN_Server: 10.10.10.0/24 för interna servrar;
LAN_Client: 10.10.20.0/24, om fjärranvändare verkligen behöver det klientnätet;
DNS_Internal: 10.10.10.10 för intern DNS eller domänkontrollant;
SSLVPN_Users: användargrupp för Policy members.

Hela interna nät ska inte tillåtas om enskilda servrar eller subnät räcker. Även DNS-servrar behöver ett tydligt objekt så att rutten och brandväggsregeln kan följas upp senare.

Konfigurera globala SSL VPN-inställningar

De globala inställningarna gäller för alla Remote Access SSL VPN-policyer och ingår i .ovpn-konfigurationen:

Remote access VPN > SSL VPN > SSL VPN global settings

Dessa värden används även för SSL Site-to-Site-anslutningar mellan två Sophos Firewalls. Den som ändrar port, protokoll, certifikat eller Override hostname måste därför kontrollera både Remote Access-profiler och befintliga SSL Site-to-Site-tunnlar och distribuera deras konfiguration på nytt.

Dokumentera Protocol, Port, Override hostname, SSL server certificate, lease- och DNS-värden samt konfigurationen för berörda SSL Site-to-Site-peers innan globala profilvärden ändras. Ta även med framförliggande NAT eller portvidarebefordran i fallback-planen. Om acceptanstestet misslyckas återställer du dessa värden och den tidigare Site-to-Site-konfigurationen och upprepar portal-, tunnel-, allowed- och blocked-testerna med den gamla profilen.

Protokoll, certifikat, gateway och port

SSL VPN stöder TCP och UDP. UDP är oftast det effektivare förstahandsvalet; TCP kan fungera som ett testat alternativ när externa nät blockerar UDP. Valet ska provas i verkliga hotellnät, mobilnät och gästnät.

Standardporten för SSL VPN är 8443, medan VPN Portal som standard använder 443. För varje publikt nåbar tjänst är en unik kombination av WAN-IP, port och protokoll tydligast.

Sophos skiljer mellan två certifikat:

Det SSL server certificate som valts under de globala SSL VPN-inställningarna används av SSL VPN-servern.
HTTPS-certifikatet för VPN Portal väljs under Administration > Admin and user settings.

Båda certifikaten ska motsvara respektive publik FQDN. För certifikat från en extern CA måste även den nödvändiga certifikatkedjan finnas.

Override hostname bestämmer FQDN eller publik IP-adress i klientprofilen. Detta är särskilt viktigt vid överordnad NAT, flera WAN-gränssnitt eller DDNS. Om fältet lämnas tomt kan flera gränssnittsadresser hamna i profilen. Sophos Connect prioriterar DDNS-gateways och provar övriga poster i omvänd ordning; en entydig FQDN är därför enklare att testa och förvalta.

VPN Portal och SSL VPN kan tekniskt dela samma port och protokoll. Inställningarna för Login Security fungerar då inte som avsett och VPN Portal blir nåbar från de zoner där SSL VPN är aktiverat. WAF måste skilja sig från VPN Portal genom WAN-IP eller port och från SSL VPN genom WAN-IP, port eller protokoll. Ytterligare WAF-beroenden förklaras i Sophos Firewall WAF.

Leaseintervall och DNS

IPv4-leaseintervallet måste vara privat och får inte överlappa interna nät, site-to-site-VPN, statiska routes, andra Remote Access-pooler eller vanliga hemnät. Vanliga exempel är 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 och 10.0.1.0/24.

Dokumentationen för SFOS 22 motsäger sig själv om tillåtet prefix för mindre IPv4-pooler. Fälthjälpen anger /24 som gräns och säger att /25 eller mindre subnät inte kan väljas, medan den aktuella FAQ:n även beskriver mindre subnät som internt fördelas över flera OpenVPN-instanser. Den SFOS-version som används är därför avgörande: kontrollera vilket prefix gränssnittet erbjuder och verifiera sedan det faktiska antalet tillgängliga leases.

Enligt Sophos FAQ beror antalet samtidiga SSL VPN-instanser på CPU:erna i brandväggsmodellen. Varje instans skapar ett tun0-interface och behöver ett eget subnät för routing och intern fördelning. SFOS delar upp den konfigurerade poolen för detta; dessa adresser förbrukas innan klientleases tilldelas. Som illustration anger FAQ:n 192.168.0.0/27, åtta samtidiga instanser och bara en återstående IP-adress som kan tilldelas. Detta är inte ett allmänt kapacitetsvärde eller ett rekommenderat exempelnät: kontrollera faktiska leases på målbuild och modell; konflikten mellan fälthjälp och FAQ som beskrivs ovan kvarstår.

SFOS 23: Det valbara IPv4-intervallet beror på brandväggsmodellen; större modeller stöder subnät med fler IP-adresser. Hjälpen för SFOS 23 anger /24 som det minsta valbara subnätet. Detta är en modellberoende gräns för valet, inte ett löfte om ett visst antal klientleases. Den CPU-beroende interna uppdelningen förklarar adressförbrukningen, men inte vilka intervall som stöds i valet. Detta löser inte konflikten i SFOS 22 och gör inte /27-illustrationen till en konfigurationsrekommendation.

Dokumentera SFOS-build, modell, tidigare intervall och statiska tilldelningar före ändringen och spara tidigare värden för återställning. Välj endast ett intervall som målmodellen stöder i gränssnittet, håll användarnas statiska adresser inom det resulterande statiska intervallet och kontrollera faktiskt tillgängliga leases. Anslut sedan en pilotanvändare på nytt och testa lease, DNS samt tillåtna och blockerade mål. Återställ tidigare värden och tilldelningar om acceptanstestet misslyckas och testa igen. Om build, gränssnitt, hjälp eller FAQ motsäger varandra, stoppa den kapacitetsutökning som beror på detta tills support har klargjort skillnaden; tvinga inte fram en mask.

SFOS 23 XML API – status 551: Den råa statusraden för Configure SSLVPN Tunnel Access hänvisar till den olösta runtime-identifieraren Message.SSLVPNInvalidLeaseIPv4Mask. Den fastställer varken en bekräftad meddelandetext, en säker orsak till avvisningen eller ett nytt maskintervall som stöds. Om API:t returnerar 551, spara hela svaret och de tidigare inställningarna. Kontrollera före varje ändring StartIP, SubnetMask och det poolval som den installerade builden och modellen stöder, med hjälp av den för miljön godkända dokumentationen eller Sophos Support; tvinga inte fram en mask.

Efter en korrigering som stöds, kontrollera API-svaret, de inställningar som faktiskt sparats på målbrandväggen och leasen för en pilotanvändare som har anslutit på nytt. Spara tidigare värden och tilldelningar för återställningen som beskrivs ovan. Om diagnosen eller meddelandetexten fortfarande är avgörande för godkännandet och förblir oklar, ska utrullningen fortsatt avvakta.

En liten pool är inget åtkomstskydd; för det används policy och brandväggsregler. I regler används systemvärdarna ##ALL_SSLVPN_RW och för IPv6 ##ALL_SSLVPN_RW6.

Under IPv4 DNS anges interna DNS-servrar. Domain name innehåller sökdomänen som läggs till korta värdnamn. Vid Split Tunnel måste DNS-servern eller dess nät dessutom ingå i Permitted network resources och vara nåbar genom en brandväggsregel från zonen VPN. Vid Full Tunnel försvinner Split Tunnel-routen, men inte behovet av brandväggsregeln.

Om brandväggen själv fungerar som DNS-resolver anger du dess lämpliga adress under IPv4 DNS. Tillåt dessutom DNS under Administration > Device access för zonen VPN. Ett separat test via IP-adress och via värdnamn skiljer routingproblem från DNS-problem.

Statiska IP-adresser, parallella sessioner och tidsvärden

Statiska SSL VPN-IP-adresser kan användas i motiverade specialfall, till exempel för en IP-baserad behörighet i ett äldre system, och måste ligga inom den pool som konfigurerats för detta. En användare med statisk SSL VPN-IP-adress kan dock inte upprätta parallella Remote Access-sessioner.

Oberoende av detta begränsar Simultaneous logins under Authentication > Services eller direkt för den lokala användaren antalet parallella inloggningar. Det globala värdet gäller endast användare som skapas därefter.

Key lifetime styr när en ny nyckelförhandling sker och är inte en idle-timeout eller maximal sessionstid. Inaktiva anslutningar hanteras genom de globala idle-inställningarna och valfritt Disconnect idle clients i policyn. Vid oväntade avbrott ska dessa värden, statisk IP-tilldelning, parallell inloggning och loggar kontrolleras separat.

Disconnect dead peer after är ett globalt värde i sekunder och stänger anslutningar från klienter som inte svarar. Standardvärdena är 180 sekunder för TCP och 100 sekunder för UDP; för UDP accepterar SFOS värden från 60 till 110. Disconnect idle peer after anges däremot i minuter och stänger sessioner som faktiskt är inaktiva. Fastställ före en höjning med hjälp av sslvpn.log, klientloggen och uppgifter om paketförlust vilken timer som faktiskt utlöses.

En policys Override global timeout kan bara förkorta det globala idle-värdet. Om policyvärdet är högre gäller fortfarande det globala värdet. En äldre felsökningssida från Sophos rekommenderar ett högre policyvärde för enskilda användare, men den aktuella fälthjälpen i SFOS 22 motsäger uttryckligen detta. För att tillåta längre sessioner ska policyvärdet därför inte höjas utan effekt; anpassa i stället det globala värdet efter en konsekvensanalys och testa på nytt med samma användargrupp.

Skapa en SSL VPN-policy

Policyn skapas manuellt eller med guiden:

Remote access VPN > SSL VPN

Sophos rekommenderar guiden särskilt för den första SSL VPN-policyn. Guiden visar de globala inställningarna endast för kontroll och kan inte ändra dem. Den tillämpar valda autentiseringsservrar och -metoder, konfigurerar Device Access för VPN Portal och SSL VPN samt skapar policyn och brandväggsregeln. Vid första användningen skapar den regelgruppen Automatic VPN rules högst upp i regeltabellen och aktiverar den nya regeln. Senare guidegenererade regler placeras längst ned i gruppen. Kontrollera deras position och den Rule ID som faktiskt matchar efter varje körning. I befintliga miljöer är Configure manually oftast mer transparent:

Välj Add > Configure manually.
Ange exempelvis SSLVPN-Remote-Users som Name.
Välj gruppen SSLVPN_Users under Policy members.
Välj Split Tunnel eller Use as default gateway.
Välj LAN_Server och DNS_Internal som Permitted network resources för Split Tunnel. Använd nätverks- eller värdobjekt här, inte gränssnitt: att välja ett gränssnitt säkerställer inte åtkomst till dess subnät.
Ställ valfritt in Disconnect idle clients och Override global timeout.
Spara och testa med en vanlig medlem i målgruppen.

Gästanvändare och gästgrupper kan inte användas som Policy members. Om en användare eller grupp redan ingår i en äldre SSL VPN-policy tar SFOS bort tilldelningen från den tidigare policyn. Kontrollera därför överlappningar före sparandet.

En policyspecifik Override global timeout fungerar bara om värdet är lägre än det globala idle-värdet. Ett högre värde upphäver inte den globala gränsen.

Split Tunnel eller Full Tunnel

Vid Split Tunnel routas endast de IPv4- och IPv6-nät samt stödda FQDN-mål som valts under Permitted network resources via VPN. FQDN-mål stöds endast för IPv4. Övrig internettrafik förblir lokal. Detta minskar brandväggsbelastning och latens men kräver noggrann resurs- och DNS-planering.

Om IP-adressen för ett tillåtet FQDN-mål ändras uppdateras inte befintliga tunnlar automatiskt. Berörda användare måste koppla från och ansluta igen.

Vid Full Tunnel aktiveras Use as default gateway. All användartrafik går då genom brandväggen. Permitted network resources tillämpas inte som åtkomstbegränsning. Interna mål och Services måste begränsas genom brandväggsregler; IPv4-internetåtkomst kräver dessutom en lämplig SNAT-/MASQ-regel.

Full Tunnel möjliggör central kontroll av webbtrafik, DNS och loggar, men ökar behovet av bandbredd, brandväggsbelastningen samt arbetet med integritet och support. Läget ska därför testas med verkliga applikationer och samtidiga användare.

Brandväggsregler, Device Access och autentisering

Brandväggsregler och DNS

En upprättad tunnel ger ännu ingen åtkomst till interna resurser. En regel måste skapas:

Rules and policies > Firewall rules

Exempel för Split Tunnel:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: endast nödvändiga applikationstjänster och DNS
Log firewall traffic: aktiverat

Regeln ska ligga ovanför bredare VPN-regler. Ett negativt test mot ett otillåtet mål visar om en generell regel längre ned oavsiktligt ändå ger åtkomst.

För IPv4 Full Tunnel tillkommer en regel från VPN till WAN och en lämplig SNAT-/MASQ-regel. IPv6 kräver i stället medveten IPv6-routing och separata IPv6-brandväggsregler. Vid utebliven åtkomst hjälper Log Viewer, Rule ID och guiden för att testa brandväggsregler.

VPN Portal, Device Access och MFA

Portal, lokala tjänster och autentisering kontrolleras på skilda platser:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Minst följande krävs:

SSL VPN i de zoner från vilka tunneln får upprättas;
VPN Portal endast i de zoner som faktiskt behövs;
DNS i zonen VPN endast om brandväggen fungerar som resolver;
lämpliga VPN portal authentication methods;
lämpliga SSL VPN authentication methods;
MFA för portal och tunnel.

När en autentiseringsmetod innehåller flera servrar frågar SFOS dem i den visade ordningen. Högst 20 servrar kan väljas per metod. Kontrollera vid identiska användarnamn eller fallback-beteende vilken server som faktiskt behandlar begäran.

Vanliga brandväggsregler styr inte dessa lokala tjänster. Snävare källnät, enskilda IP-adresser eller länder konfigureras genom Local Service ACL Exception Rules. Hela säkerhetsflödet beskrivs i Device Access och Local Service ACL.

Brandväggens webbproxy är ett specialfall: HTTP- och HTTPS-begäranden som passerar genom den behandlas som interna för lokala tjänster. Användare med proxyåtkomst kan därför nå VPN Portal även om den inte är aktiverad för deras källzon. Testa denna nåbarhet separat när proxyn används i stället för att enbart lita på zonmatrisen under Device Access.

Third-party Threat Feeds kan även blockera systemriktad åtkomst till VPN-tjänster. Kända oönskade källor kan därmed spärras ytterligare; konfiguration och begränsningar beskrivs i Threat Feeds på Sophos Firewall.

VPN portal authentication methods styr inloggningen till portalen och profilnedladdningen, medan SSL VPN authentication methods styr själva tunnelinloggningen. WebAdmin är ett separat administrationsgränssnitt och behöver inte öppnas från WAN-zonen för SSL VPN.

SSO efter SFOS-version: På SFOS 22 konfigureras Microsoft Entra ID med Server type: Microsoft Entra ID SSO. På SFOS 23 öppnar man Authentication > Servers > Add, väljer Server type: OpenID Connect och sedan IdP vendor: Microsoft Entra ID eller IdP vendor: Google Workspace. Konfiguration av app, server, Redirect URIs och grupper beskrivs i Microsoft Entra ID SSO för Sophos Connect respektive Google Workspace OIDC på Sophos Firewall. Dessa versionsalternativ bekräftar inte GA-tillgänglighet för en build.

Före nedladdning av profilen måste samma konfigurerade IdP-server väljas under Authentication > Services för VPN portal authentication methods och SSL VPN authentication methods, med Apply för varje tjänst; på SFOS 22 är detta samma Entra-server. Jämför hela Redirect URI hos vald leverantör, inklusive FQDN, port och sökväg, och kontrollera nödvändiga inloggningsendpoints. Lyckad SSO ersätter inte gruppmedlemskap, Policy members eller snävt avgränsade brandväggsregler. Spara tjänstetilldelningar, serverordning och fungerande profiler före bytet. Ladda ned och importera aktuell konfiguration på nytt efter SSO-ändringar och testa med en vanlig pilotanvändare portal, tunnel, IdP-MFA, DNS samt tillåtna och blockerade mål. Återställ dokumenterade tjänstetilldelningar, ordning och tillhörande profiler vid fel och upprepa samma tester; ta inte bort den tidigare åtkomstmetoden före godkänt acceptanstest.

För SFOS inbyggda OTP väljer du målanvändare eller målgrupper under Authentication > Multi-factor authentication och aktiverar både VPN portal och SSL VPN remote access under Require MFA for. Med Generate OTP token with next sign-in måste användaren först skanna QR-koden i VPN Portal; därefter kan tunneltestet börja.

VPN Portal stöder inte RADIUS-autentisering med Challenge-MFA. Sophos Connect stöder inte heller en OTP-challenge, utan skickar lösenord och OTP tillsammans; call- och pushmetoder stöds. Den valda metoden måste testas med en vanlig pilotanvändare. Fler grunder finns i MFA för Sophos Firewall.

Distribuera och uppdatera klientprofilen

Om profilrelevanta globala värden som protokoll, port, gränssnitt, servercertifikat eller Override hostname ändras ska du hämta den aktuella .ovpn-filen på nytt från VPN Portal, distribuera den på ett skyddat sätt och vid manuell distribution importera den på nytt i klienten. Update policy är inte det första steget här och ersätter inte manuell återimport. Den dokumenterade användningen gäller en anslutning som provisionerats via .pro: efter en ändring av SSL-VPN-port eller protokoll ska du köra Update policy för den anslutningen; ytterligare konfigurationsändringar hämtas automatiskt via denna provisioneringsväg. Vid ändringar av exempelvis port, gateway, servercertifikat eller protokoll kan en ny inloggning krävas. En programuppdatering av Sophos Connect ersätter inte en inaktuell profil. Förvara den kända fungerande profilen och tillhörande globala brandväggsvärden säkert för återställning; före bred distribution ska du testa den nya importen med en vanlig pilotanvändare och kontrollera gateway/port, autentisering/MFA, rutter, DNS samt tillåtna och spärrade mål. Om acceptanstestningen misslyckas ska du återställa de sammanhörande gamla värdena och den kända fungerande profilen och upprepa samma kontroller.

Efter en ändring av Override hostname eller port ska det kontrolleras i klienten att den nyimporterade profilen faktiskt använder det nya gatewaynamnet och den nya porten.

Efter ändringar av Policy members, Permitted network resources eller IP-adressen för ett FQDN-mål räcker normalt en frånkoppling och återanslutning. Tillåtna nät lagras inte statiskt i .ovpn-filen; SFOS lägger till användarens resurser när tunneln upprättas. Dessa ändringar kräver därför ingen ny nedladdning av .ovpn.

.pro hämtar IPsec (.scx) och användarens behöriga SSL VPN-konfigurationer (.ovpn) via VPN Portal samt senare ändringar; filen är inte själv en tunnelprofil. Kompatibla Windows-klienter och Sophos Connect för macOS från 2.1 stöds, inte macOS-klient 2.0 eller äldre. IPsec-provisionering kräver Sophos Connect 2.1 eller senare. Med macOS-klient 2.0 krävs fortfarande direktimport och kontrollerad manuell uppdatering.

Om provisioning-gateway eller vpn_portal_port ändras måste även .pro anpassas och distribueras på nytt. Det äldre fältet user_portal_port accepteras endast av kompatibilitetsskäl. Vid den första distributionen med OTP eller en annan MFA-metod kan inloggningen visas två gånger: först för profilnedladdningen och sedan för tunnelanslutningen.

Om .pro endast ger en IPsec-anslutning eller ingen SSL VPN-konfiguration kontrolleras först Policy members, gruppmedlemskap, nåbarhet för VPN Portal och autentisering.

För SSO-provisionering med .pro på Windows med Sophos Connect 2.4 eller senare beskriver SFOS 22 Entra ID; SFOS 23 stöder de OIDC-identitetsleverantörer som stöds för detta flöde, inte godtyckliga leverantörer. Under Authentication > Services måste VPN Portal, IPsec VPN och SSL VPN använda samma konfigurerade IdP-server. gateway innehåller endast brandväggens FQDN eller IP-adress från serverns avsnitt Redirect URI, inte hela callback-URI:n; portalporten anges separat i vpn_portal_port. För SSO är macOS med Sophos Connect 2.1 eller senare här fortfarande begränsat till Entra ID, utan utökning till allmänt OIDC-stöd; den nedan angivna bekräftelsen av stöd före utrullning krävs fortfarande. Följande provisioneringsartikel förklarar leverantörs- och versionsspecifika förutsättningar.

Sophos Connect-provisionering med .pro och GPO beskriver den fullständiga JSON-strukturen, MFA-fälten, gatewayvalet och GPO-distributionen.

För Google Workspace SSO gäller denna vägledning endast Windows med Sophos Connect 2.4 eller senare; Entra-anvisningar för macOS gäller inte Google. För Entra anger översiktssidorna macOS från 2.1, inte 2.0, medan kravsidorna endast anger Windows från 2.4. Denna motsägelse är fortfarande olöst även i den länkade detaljartikeln: stoppa före en macOS-utrullning tills stöd för målbuild, klientplattform/version och nödvändig VPN-typ har bekräftats och testats separat. Kontrollera kompatibla SFOS-inställningar, aktuell klientkonfiguration, autentiseringsmetoder och Redirect URI för varje godkänd väg; testa MFA hos IdP. Varken ett identiskt webbläsarflöde eller tillämplighet av Windows GPO-distribution på macOS utlovas.

Profilnamn ska vara entydiga. Ta bort gamla anslutningsposter efter byte av gateway eller användare och testa distributionen med en vanlig målanvändare. Information om klientversioner finns i Uppdatera Sophos Connect säkert.

SSL VPN med Sophos Connect: Windows 10/11; macOS-klient 2.0 på macOS 13+ och klient 2.1 eller senare på macOS 14+. Linux, iOS och Android använder en kompatibel OpenVPN-klient.

Under Current activities > Remote users kan inloggade fjärranvändare filtreras efter Connection date, Username, Source IP address och Leased IP address. Kolumnen Mode skiljer mellan tre tillstånd:

SSL VPN (remote access): upprättad fjärråtkomsttunnel
User portal (clientless access): portalinloggning för en medlem i en clientless SSL VPN-policy
User portal: portalinloggning utan sådant medlemskap

En portalpost bevisar därför inte att en SSL VPN-tunnel finns. Disconnect avslutar den valda sessionen. Dokumentera användare, adresser, läge och tidpunkt före ett support- eller acceptanstest.

Testa konfigurationen och avgränsa fel

Acceptanstest

Ett fullständigt test använder en vanlig pilotanvändare och ett konkret internt mål:

Användaren ser exakt den förväntade SSL VPN-konfigurationen i VPN Portal.
MFA testas med rätt och fel faktor.
.ovpn eller .pro importeras och den tilldelade leaseadressen kontrolleras.
Vid Split Tunnel kontrolleras routen till LAN_Server och DNS_Internal.
Det interna målet testas först via IP-adress och därefter via värdnamn.
Den tillåtna tjänsten öppnas och Firewall Rule ID kontrolleras i Log Viewer.
Ett otillåtet anrop skapas och blockeringen bekräftas.
Vid Full Tunnel kontrolleras dessutom publik internetåtkomst, DNS, Web Policy och IPv4-SNAT.
Efter en policy- eller FQDN-ändring kopplas tunneln från, ansluts på nytt och samma test upprepas.

Varje test ska innehålla tidpunkt, användare och grupp, klientplattform och klientversion, källnät, mål och tjänst. Om bara en administratör testar förblir fel i grupper, MFA och policy lätt oupptäckta.

Loggar efter felfas

Först fastställs om felet uppstår vid portalåtkomst, autentisering, tunnelanslutning eller först vid åtkomst till målet:

VPN Portal: vpnportal.log
Normal autentisering: access_server.log
Microsoft Entra SSO på SFOS 22: oauth_sso_vpn.log; använd för SFOS 23 de versionsspecifika logganvisningarna i respektive Entra- eller Google-detaljartikel.
Användarspecifika SSL VPN-certifikat: peruser_cert_sslvpn.log
SSL VPN-tjänst: sslvpn.log
Aktiva anslutningar: openvpn-status*.log
Måltrafik: brandväggslogg, Rule ID och vid behov Packet Capture

I Packet Capture visar Incoming endast att brandväggen har tagit emot paketet. Vid Forwarded utan svar kontrolleras returroute, NAT, målsystem och dess lokala brandvägg.

För TUN-trafik kan SFOS-loggar ange TUN-gränssnittets adress som källa och klientens leasade adress som mål. Det betyder inte att adresserna har kastats om. Tolka posten utifrån användare, lease, trafikriktning, Rule ID och testtid tillsammans.

Andra processer och filer kopplas till respektive funktion i Sophos Firewall Services och loggar.

Ingen användare kan upprätta en tunnel: tjänst och flood-gränser

När alla användare påverkas ska du först utföra skrivskyddade kontroller innan du ändrar principer, flood-gränser eller tjänster. Anteckna testtiden, konfigurerat SSL VPN-protokoll och port, aktuella DoS-inställningar och om det finns minst en SSL VPN-princip.

Logga in i CLI, välj 5. Device management och sedan 3. Advanced shell, och kontrollera tjänstens status med kommandot som Sophos dokumenterar:
```
service -S | grep sslvpn
```
Tjänsten måste visa Running. UNREGISTERED innebär att ingen SSL VPN-princip är registrerad. Kontrollera att minst en sådan princip finns. Om en princip finns men tjänsten ändå inte visar Running ska du korrelera sslvpn.log med testtiden och undersöka avvikelsen i stället för att starta om tjänster utan en dokumenterad procedur.
Under Intrusion prevention > DoS & spoof protection > DoS settings kontrollerar du aktiverade alternativ och gränser för UDP-, TCP- och ICMP/ICMPv6-flood. Använd det konfigurerade SSL VPN-protokollet när du kontrollerar tunneltrafiken. SFOS kasserar SSL VPN-trafik och pingbegäranden när motsvarande flood-gräns överskrids. En misslyckad ping är inte i sig ett bevis på detta. Korrelera anslutningsförsöket med belägg för kasserad trafik innan du skapar ett undantag.
Endast när en matchning mot en flood-gräns har bekräftats ska du dokumentera den befintliga konfigurationen och skapa en så snäv tillfällig inbound-regel som möjligt under DoS bypass rules. Sophos exempel använder relevant käll-IP-adress/nätmask (eller * endast när det är oundvikligt), adressen till den tillåtna nätverksresursen som mål, det faktiska protokollet TCP eller UDP, källport Any och den konfigurerade SSL VPN-målporten (8443 som standard). Begränsa källa och mål ytterligare när testet tillåter det. Inaktivera inte flood-skyddet globalt.
Upprepa exakt samma tidsregistrerade anslutnings- och resurstester. Ta omedelbart bort bypass-regeln om den inte förklarar den kasserade trafiken. Efter diagnosen tar du bort den tillfälliga regeln eller ser till att det snäva undantaget godkänns formellt och dokumenteras. Återställ eventuella flood-gränser som ändrats separat till de antecknade värdena och upprepa sedan testerna av tillåten och blockerad åtkomst.

Begäran når servern, men svaret saknas

Om det är bekräftat att SSL VPN-klientens begäran når den tillåtna interna resursen, men svaret inte når klienten, kontrolleras returvägen i två steg: först från resursen till brandväggen och sedan från brandväggen till den tilldelade SSL VPN-adressen. En grön tunnelstatus avgränsar inte detta fel.

Kontrollera på den interna resursen eller dess router att returvägen till SSL VPN-adressintervallet går via Sophos Firewall. En specifik returrutt är tydligare än SNAT. Använd SNAT endast avgränsat när returvägen inte kan routas och den ändrade källadressen som detta medför är godtagbar.
Bekräfta med Packet Capture att svaret når brandväggen. Källadress, tilldelad måladress, tjänst och testtid måste stämma överens med det ursprungliga åtkomstförsöket.
Kontrollera aktuell Route Precedence och breda SD-WAN-rutter under Routing > SD-WAN routes. SSL VPN tillhör kategorin static. Om sdwan_policyroute står före kan en rutt med den interna resursen eller Any som källa och Any som mål och tjänst leda svaret bort från tunneln.
Begränsa i första hand den berörda SD-WAN-rutten så att SSL VPN-adressintervallet inte längre matchar som mål. Sophos anger alternativt ett tjänsteundantag för SSL VPN-porten och protokollet; denna variant måste passa den faktiska regel- och trafikdesignen.
Ändra den globala Route Precedence först efter en konsekvensanalys. Ändringen påverkar mer än denna anslutning. Förbered ursprunglig ordning, hanteringsåtkomst och rollback enligt Route Precedence på Sophos Firewall.
Upprepa åtkomsten och kontrollera i Packet Capture att svaret kommer in från resursen och vidarebefordras till den tilldelade adressen. Anslut därefter på nytt och testa igen med samma program.

⚠️ En bred Any-regel, en generell SNAT-regel eller en global ändring av Route Precedence kan flytta det synliga problemet och störa andra VPN-, WAN- eller hanteringsvägar. Stoppa om returvägen till brandväggen eller den SD-WAN-rutt som faktiskt matchar inte har bekräftats.

Hemnätet och det interna målnätet överlappar

Om den externa klienten exempelvis använder 192.168.1.0/24 och den tillåtna interna resursen också finns i 192.168.1.0/24, betraktar operativsystemet normalt målet som lokalt. Paketet når då aldrig SSL VPN-tunneln. Den rena permanenta lösningen är att adressera om ett av de två näten.

Om det inte går att göra omedelbart dokumenterar Sophos en strikt begränsad DNAT-lösning. Välj en ledig virtuell måladress som inte överlappar något lokalt, internt, VPN-, statiskt eller SD-WAN-nät. Vid Split Tunnel måste adressen nå klienten som en Permitted network resource, varefter en ny anslutning krävs. DNAT-regeln använder SSL VPN-leaseintervallet som Original source, Original som Translated source, den virtuella adressen som Original destination och den verkliga interna värden som Translated destination. Begränsa tjänsterna och den tillhörande brandväggsregeln från VPN till målzonen till den åtkomst som faktiskt behövs.

Användaren ansluter därefter till den virtuella adressen eller ett särskilt DNS-namn som pekar på den. Log Viewer ska visa förväntad Firewall Rule ID och NAT Rule ID; en Packet Capture bekräftar översättningen och returvägen. Skapa inte ett helt ersättningsintervall om endast en värd behövs. Stoppa om den virtuella adressen inte entydigt är ledig eller om en bred NAT-regel skulle krävas.

Vanliga felbilder

Saknad eller tom .ovpn i VPN Portal: Åtgärda en saknad eller tom OVPN-nedladdning skiljer mellan fel i policy, User ID, certifikat, lagringsutrymme, firmware och HA. Gästkonton är inte tillåtna. Sophos Connect stöder endast ASCII-användarnamn; användarnamn och domän får tillsammans vara högst 51 tecken.
Inloggningen misslyckas: jämför access_server.log och vpnportal.log med testtiden; använd för Entra på SFOS 22 även oauth_sso_vpn.log, och på SFOS 23 de versionsspecifika OIDC-logganvisningarna i respektive detaljartikel. Kontrollera samma IdP-server för portal och SSL VPN, Redirect URIs samt hela certifikatkedjan.
Tunneln är uppe, men interna mål saknas: kontrollera routen på endpointen, Permitted Resources vid Split Tunnel, brandväggsregel, returroute, målbrandvägg och överlappning med det lokala hemnätet.
IP-adressen fungerar, men inte värdnamnet: kontrollera DNS-server, sökdomän, Split Tunnel-route, DNS-brandväggsregel, lokal DoH eller endpoint-DNS och vid behov Device Access för DNS.
Endast enskilda användare berörs: jämför gruppmedlemskap, policytilldelning, MFA, statisk IP-adress, Simultaneous logins och inläst profil.
Endast gamla klienter berörs: importera en aktuell .ovpn efter globala ändringar. Efter enbart policy- eller FQDN-ändringar ska tunneln först återanslutas och inläst routing kontrolleras.
Full Tunnel utan internet: kontrollera regeln från VPN till WAN, IPv4-SNAT, DNS samt tillämpade webb- och säkerhetspolicyer.
Stora överföringar hänger sig: om små anslutningar fungerar ska MTU och MSS längs den faktiska vägen kontrolleras. Följ guiden MTU och MSS vid VPN-problem.
Anslutningen avslutas efter längre tid: jämför start- och sluttid med Idle Timeout, Disconnect idle clients och Key lifetime. Kontrollera statisk IP-adress och Simultaneous logins, ge vid behov en pilotanvändare en dynamisk adress och analysera sslvpn.log samt openvpn-status*.log vid testtiden.
Tunneln upprättas inte för någon användare: sök, utöver Device Access och portöppningen, efter en bred DNAT-regel med Original destination: Any och Services: Any eller SSL VPN-porten som fångar upp anslutningen tidigare.
WAF, portal eller SSL VPN kolliderar: jämför WAN-IP, port och protokoll för alla lokala tjänster och WAF-regler. Delade kombinationer kan leda till extra exponering av portalen eller utebliven Login Security.

I den löpande driften ska grupper, MFA, statiska IP-tilldelningar, certifikatens utgång, leaseintervall, Device Access, brandväggsregler, profildistribution och loggar granskas regelbundet. Nya SFOS- och Sophos Connect-versioner godkänns först med en pilotanvändare samt ett positivt och negativt måltest.