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.

XML-API:ts begränsning för SFOS 22/23: Den äldre API-dokumentationen för Configure SSLVPN Tunnel Access anger för DisconnectDeadPeerAfter standardvärdet 300 sekunder, intervallet 60 till 1800 och värdet 180 i exemplet, utan koppling till ett specifikt protokoll. Detta fastställer varken ett standardvärde vid körning för TCP/UDP eller ett nytt standardvärde i GUI:t. Ersätt därför inte de TCP-/UDP-värden som beskrivs ovan utifrån denna API-tabell; kontrollera den timer som faktiskt har sparats under Remote access VPN > SSL VPN > SSL VPN global settings på den installerade builden.

Även leaseschemats villkor förblir oklara: LeaseMode tillåter IPv4, trots att IPv6Lease och IPv6Prefix anges som obligatoriska fält och lämnas tomma i exemplet; för prefixet anger tabellen 64 till 112. Detta innebär varken att tomma IPv6-fält får skickas eller att stöd för dual-stack saknas. EndIP och CompressSSLVPNTraffic förekommer endast i exemplet och fastställer varken ett validerat kontrakt för skrivoperationer eller en rekommendation om komprimering. Före automatisering som är beroende av detta måste Sophos Support eller den dokumentation som är godkänd för målbuilden klargöra de villkorligt obligatoriska fälten och vilka värden som får skrivas; utför tills dess ingen XML-ändring som bygger på dessa uppgifter. För ändringar som stöds ska du först spara de faktiska globala timer-, lease- och DNS-värdena samt konfigurationerna för berörda SSL Site-to-Site-peers och därefter kontrollera svaret, de sparade värdena och leasen för en pilotanvändare som har anslutit på nytt. Om acceptanstestet misslyckas ska du återställa exakt de antecknade ursprungsvärdena och tillhörande peer-konfigurationer och upprepa samma åtkomsttester.

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.

XML-API:ts begränsning för policyn: Add/Edit-exemplen för SFOS 22/23 skiljer inom SSLVPNPolicy mellan grenarna TunnelPolicy och ClientlessPolicy, var och en med eget Name och PolicyMembers/Member. Tunnelåtkomst till nätverksresurser och klientlös publicering är olika uppgifter med separata policynamn och medlemstilldelningar. WebAccessibleResources innehåller BookmarkGroups och Bookmarks, inte IP-resurser för tunneln. Behandla inte en ändring som en gemensam ändring av båda delpolicyerna; tolka inte om bokmärkesbehörigheter till tunnelresurser.

Tabellen anger dessutom det obligatoriska fältet Web Access med värdena 1 och 6, utan motsvarande fält i exemplet eller bekräftad koppling till GUI-lägen. För UseAsDefaultGateway anges standardvärdet SplitTunnel och för DisconnectIdleClients UseGlobalSettings, trots att båda endast anger Off och On som tillåtna värden. Härled inte någon numerisk koppling till lägen, något standardvärde som kan skickas, någon effekt av utelämnade fält eller någon serialisering av medlemmar från detta. Avvakta med den API-ändring som är beroende av dessa uppgifter tills de har klargjorts för målbuilden; GUI-konfigurationen som beskrivs ovan är fortfarande den säkra vägen. Full Tunnel kräver fortsatt snävt avgränsade brandväggsregler, och policyns idle-värde kan endast förkorta 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.

Avveckla en SSL VPN-policy säkert

Ta bort en policy som inte längre behövs på ett riktat sätt; att koppla från en session ersätter inte detta. Fastställ före borttagningen vilken åtkomst som ska upphöra och vilka behörigheter som fortfarande behövs.

Välj exakt det sparade Name och avsedd policygren: TunnelPolicy för tunnelåtkomst eller ClientlessPolicy för klientlös åtkomst. Utgå inte enbart från ett liknande visningsnamn.
Kontrollera Policy members, faktiska gruppmedlemskap och tilldelade nätverksresurser eller bokmärken och bokmärkesgrupper. Bekräfta att avvecklingen är godkänd och att ingen åtkomst som fortfarande behövs är beroende av policyn. Stoppa vid oklara tilldelningar och klargör först beroendena; en ny tilldelning kan ta bort medlemmar från en äldre policy.
Spara namn, gren, medlemmar och alla tillhörande inställningar säkert och i återställbar form. Ta under Remote access VPN > SSL VPN endast bort den valda policyn med den borttagningsprocedur som stöds för den installerade målbuilden. Om proceduren inte är tydligt bekräftad, använd godkänd dokumentation eller Sophos Support före ändringen.
Om åtkomsten måste upphöra omedelbart, kontrollera aktiva sessioner separat under Current activities > Remote users utifrån användare, adresser och Mode och avsluta berörda sessioner riktat med Disconnect. Frånkoppling ersätter inte indragning av behörighet; härled inte automatisk tunnelavslutning från borttagningen.
Kontrollera sparade policyer och medlemstilldelningar igen. Kontrollera med en berörd vanlig användare den förväntade konfigurationen i VPN Portal och behörigheten vid ett nytt anslutningsförsök. Åtkomst som tidigare beviljades genom den avvecklade policyn måste upphöra; åtkomst som fortfarande är godkänd genom andra policyer måste finnas kvar. Kontrollera faktiskt tillåten och blockerad trafik med brandväggsloggarna och, för klientlös åtkomst, även förväntade bokmärkesbehörigheter. Klargör oväntade resultat före ytterligare borttagningar; använd de sparade inställningarna för en riktad återställning endast efter godkännande.

Dokumentationens gräns: Delete-sidorna i det äldre XML-API:t för SFOS 22/23 anger Name som obligatorisk parameter, men bekräftar inget fullständigt XML-kontrakt för borttagning, inga kaskadeffekter och ingen resultat- eller sessionssemantik. Härled därför ingen Delete-payload, inga statuskoder, inga meddelandetexter eller någon omedelbar indragning av åtkomst från dem.

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.

Slutför konfigurationen och förbered felsökningen

I en ny miljö anger du namn och nätverk eller värdadress under Hosts and services > IP host > Add och väljer Save. Skapa SSLVPN_Users under Authentication > Groups > Add med lämpliga värden för Surfing quota och Access time och spara. Ange användarnamn, visningsnamn och denna grupp under Authentication > Users > Add och spara. Obegränsad internetåtkomst och obegränsade åtkomsttider är exempelvärden, inte säkerhetskrav. För befintliga kataloganvändare kontrollerar du den nuvarande grupptilldelningen i stället för att skapa onödiga lokala konton.

Kontrollera även följande globala värden utöver dem som beskrivs ovan:

Lease mode: IPv4 only tilldelar endast IPv4; IPv4 and IPv6 both tilldelar båda adressfamiljerna. IPv6-pool, rutter och regler måste stämma överens. Use static IP addresses visar det automatiskt uppdelade statiska intervallet; tilldela enskilda adresser under Authentication > Users.
IPv4 WINS: Ange primär och sekundär WINS-server endast om miljön behöver denna namntjänst. WINS ersätter inte DNS.
Encryption algorithm, Authentication algorithm och Key size: Välj kryptering, meddelandeautentisering och nyckellängd medvetet enligt godkända säkerhetskrav. Key lifetime anges i sekunder. Försvaga inte kryptografin för att felsöka en anslutning.
Enable debug mode: Ger mer detaljerade SSL VPN-loggar. Aktivera endast för en specifik undersökning, skydda loggarna och återställ sedan det tidigare läget.

Spara globala ändringar med Apply. För en externt signerad certifikatkedja importerar du servercertifikatet med den privata nyckeln, mellanliggande CA och rot-CA. Ändringar av Default CA vid användning av ApplianceCertificate eller ett lokalt signerat certifikat kräver också en ny manuell .ovpn-import. Använd inte UTF-8-tecken i certifikat- och CA-fält; specialtecken i användarnamn kan även påverka portalen, filnamn och tredjepartsklienter.

Med en enda statisk offentlig WAN-IP kan Override hostname lämnas tomt. Med flera adresser anger du önskat FQDN eller en specifik gränssnittsadress, eller kontrollerar varje exporterad post. Bakom uppströms NAT anger du routerns offentliga anslutningspunkt och kontrollerar portvidarebefordran; för en dynamisk adress konfigurerar du först Network > DDNS och använder DDNS-FQDN. Kontrollera de faktiska gatewayposterna i .ovpn och testa namnuppslagningen separat.

Kontrollera de globala värdena i guiden, välj Next och ange VPN name, användare/grupper och Authentication servers. Alternativen är Same as VPN (IPsec, L2TP, PPTP), Same as firewall eller Set authentication method for SSL VPN. Välj tunnelläge och zoner separat; för Split Tunnel bekräftar du resurserna med Apply selected items längst ned i listan. Välj Finish först efter kontroll och granska de skapade reglerna. Guiden ersätter varken SNAT-kontrollen eller separat IdP-konfiguration.

⚠️ Inledningen i Full Tunnel-guiden hävdar att endast resurser som valts i policyn är åtkomliga; fälthjälpen säger uttryckligen att Permitted network resources inte tillämpas med Use as default gateway. En äldre felsökningsguide rekommenderar också fortfarande resursval i detta läge. Detta motsägelsefulla påstående garanterar inte åtkomstkontroll: använd uttryckliga brandväggsregler som kontroll för Full Tunnel och testa tillåtna och blockerade mål. Breda exempelregler med Any är inte obligatoriska; begränsa intern åtkomst och internetåtkomst separat.

För manuell klientkonfiguration öppnar du VPN i VPN Portal, väljer Download for Windows eller Download for macOS vid behov och installerar klienten. Download configuration for Windows, macOS, Linux ger .ovpn; importera med Import connection och logga in med portaluppgifter eller förberedd SSO. Administratören kan också hämta installationsfilen via Remote access VPN > SSL VPN > Download client. Den äldre SSL VPN-klienten har nått slutet av sin livscykel och erbjuds inte längre i portalen.

Om bara vissa endpoints misslyckas kontrollerar du först internetåtkomst och behörigheter i operativsystem, endpointbrandvägg och antivirus. Under ett anslutningsförsök använder du BPF-filtret port <SSL VPN port number> under Diagnostics > Packet capture; Details i Sophos Connect visar anslutningsparametrarna. Saknade paket bevisar inte att internetleverantören blockerar trafiken. Uteslut först andra orsaker; byt till en tillåten port/protokollkombination först efter kontroll av WAF-/portalkonflikter och förberedelse av profildistribution och återställning. Det dokumenterade komprimeringsproblemet för Android/OpenVPN gäller SFOS 20.0 GA och tidigare, inte SFOS 22/23 generellt.

Med en etablerad tunnel kontrollerar du målnätverk, TUN-gränssnitt och tilldelad adress i endpointens routningstabell. Om rutten saknas ansluter du först på nytt och kontrollerar klientlogg och endpointbehörigheter; en ny import hjälper endast med rätt aktuell konfiguration. Under Log viewer > Firewall filtrerar du på In interface, Is, tun och kontrollerar Firewall rule-ID. För användarspecifika regler kontrollerar du också Match known users och User or groups. För att skilja VPN-problem från interna nätverksproblem testar du åtkomst från brandväggen till målet under Diagnostics > Tools; ta sedan bort eventuell tillfällig pingbehörighet. Vid återanslutningsproblem kontrollerar du även ändringar av lease-, DNS-/WINS- och domänvärden och använder inte WAN-gränssnitt som Permitted network resources. Policyändringar avslutar inte befintliga tunnlar automatiskt: användarna måste koppla från och ansluta igen separat.

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. Om tjänsten visar UNREGISTERED, kontrollera att minst en SSL VPN-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. För detta diagnostiska undantag ska du använda 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.