Konfigurera Sophos Connect på Sophos Firewall

Sophos Connect är standardklienten för Remote Access med Sophos Firewall i många miljöer. Den verkliga kvaliteten på lösningen avgörs dock inte först på Windows eller macOS, utan på firewallen: användarbehörighet, IP-pool, DNS, autentisering, MFA, firewall-regler och senare profildistribution måste passa ihop.

Den här artikeln beskriver planering och konfiguration på firewall-sidan för Sophos Connect, framför allt för IPsec Remote Access och profildistribution. För SSL VPN beskrivs själva Remote Access policy i artikeln Konfigurera Sophos Firewall SSL VPN Remote Access. För grundbeslutet mellan IPsec, SSL VPN, mobila klienter och ZTNA passar först Sophos Connect eller SSL VPN: vilken Remote Access-lösning passar?.

Vilken artikel passar?

Beroende på uppgift är olika startpunkter rimliga:

• Planera Sophos Connect på firewall-sidan för IPsec: Den här artikeln
• Konfigurera SSL VPN Remote Access på firewallen: Konfigurera Sophos Firewall SSL VPN Remote Access
• Använda Microsoft Entra ID SSO för Sophos Connect: Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal
• Installera Sophos Connect på Windows eller macOS: Windows eller macOS
• Styra klientversioner och profiländringar i drift: Kontrollera och uppdatera Sophos Connect Client-versionen säkert
• Analysera anslutningsproblem i tunneln: Sophos Firewall IPsec VPN troubleshooting

Den här uppdelningen är viktig eftersom Sophos Connect berör flera delar: IPsec-konfiguration, SSL VPN-konfiguration, VPN Portal, provisioning, autentisering, klientversion och firewall-regler.

Förutsättningar

• Sophos Firewall med stödd SFOS-version
• adminåtkomst till WebAdmin-gränssnittet
• definierade användare eller grupper för Remote Access
• ledigt IP-adressintervall för VPN-klienter
• interna DNS-servrar om interna namn måste lösas
• MFA-koncept för Remote Access
• klargjorda målnät och tjänster som ska vara nåbara via VPN
• tydlig process för profildistribution, profiländringar och klientuppdateringar

Om firewallen ska uppdateras till SFOS 22.0 MR1 eller senare måste man först kontrollera om Legacy Remote Access IPsec fortfarande finns. Den gamla konfigurationen kan blockera uppgraderingen. Förloppet beskrivs i Migrera Legacy Remote Access IPsec före SFOS 22 MR1.

I aktuella SFOS-versioner ligger IPsec Remote Access-konfigurationen under Remote access VPN > IPsec. I äldre gränssnitt eller äldre guider finns fortfarande sökvägar som VPN > Sophos Connect Client. I befintliga skärmbilder och äldre kundmiljöer kan benämningen därför avvika.

Planera före konfiguration

Innan funktionen slås på bör det kort dokumenteras hur Remote Access ska drivas senare. Det förhindrar typiska fel som överlappande IP-pooler, för breda firewall-regler eller profiler som inte distribueras igen efter en ändring.

Viktiga planeringsfrågor:

• Användare: Lokala användare, AD-grupp, RADIUS eller annan autentisering
• MFA: OTP/MFA aktivt, testat och dokumenterat för helpdesk-processer
• IP-pool: egen pool utan överlappning med LAN, WLAN, VLAN, Site-to-Site VPN eller hemnät
• DNS: interna DNS-servrar och sökdomäner när interna FQDN används
• Åtkomst: tillåt endast nödvändiga servrar, nät och tjänster
• Klientdistribution: .scx, .tgb, .ovpn, .pro, mjukvarudistribution, versionsstatus och fallback-väg
• Drift: Log Viewer, supportprocess, profiländringar och avslutade användare

För MFA-grunder passar Konfigurera Sophos Firewall MFA. Om Remote Access senare körs via Microsoft Entra ID SSO, RADIUS eller AD bör autentiseringskedjan dessutom testas separat.

Profiltyper och distribution

Före konfigurationen bör det vara klart vilken fil som senare hamnar på vilken klient. Det förhindrar många supportfall.

• .scx: Sophos Connect för IPsec Remote Access innehåller även avancerade Sophos Connect-inställningar
• .tgb: IPsec-konfiguration för äldre eller tredjepartsklienter innehåller inga avancerade Sophos Connect-inställningar
• .ovpn: SSL VPN för Sophos Connect eller OpenVPN-kompatibla klienter kommer från SSL VPN-konfiguration eller VPN Portal
• .pro: provisioningfil för automatisk import laddar konfigurationer via VPN Portal efter lyckad inloggning

För nya Sophos Connect IPsec-rollouts är .scx oftast bättre standard, eftersom den innehåller de avancerade inställningarna från firewallen. .tgb bör bara användas medvetet när en tredjepartsklient eller en gammal process kräver det.

Provisioning kan förenkla distributionen, men ökar beroendet av VPN Portal. Om användare ska använda provisioningfilen från internet måste VPN Portal vara nåbar från den nödvändiga zonen. Det hör hemma under Administration > Device access och ska härdas medvetet i Local Service ACL, eftersom en WAN-nåbar portal skapar ytterligare angreppsyta. För härdning passar Device Access och Local Service ACL på Sophos Firewall.

Aktivera Sophos Connect

Öppna Remote access VPN > IPsec i WebAdmin-gränssnittet. I äldre gränssnitt kan sökvägen fortfarande heta VPN > Sophos Connect Client. Den exakta visningen kan variera något beroende på SFOS-version, men grundbesluten är likartade.

1. Aktivera Connect Client

Aktivera IPsec Remote Access. Sätt därefter de övriga inställningarna och rulla inte ut direkt i produktion.

2. Välj extern interface

Som interface väljs vanligtvis WAN-interfacet genom vilket Remote Access-anslutningar når firewallen. Vid flera WAN-anslutningar bör man medvetet välja vilken anslutning som är stabil för VPN, dokumenterad och nåbar från internet.

Kontrollera:

• publik IP eller korrekt DynDNS/FQDN finns
• port forwards och framförliggande routrar passar
• WAN failover-beteende är känt
• Device Access och lokala service-ACLs tillåter endast nödvändiga tjänster
• VPN Portal är endast nåbar där den verkligen behövs för nedladdning eller provisioning

Remote Access är en publikt nåbar ingångspunkt. Ren funktion räcker därför inte; åtkomst, MFA och logging måste också beaktas.

För härdning av nåbara firewall-tjänster passar Device Access och Local Service ACL på Sophos Firewall.

3. Välj autentisering

För IPsec Remote Access finns olika autentiseringsmodeller beroende på SFOS-version och konfiguration. Preshared Key och certifikat är ofta relevanta alternativ.

Praktisk indelning:

• Preshared Key är snabb att konfigurera, men måste vara stark, skyddad och roteras vid misstanke.
• Certifikat är renare för kontrollerade miljöer, men kräver certifikathantering och tydliga processer.
• MFA ersätter varken PSK eller certifikat, utan skyddar användarinloggningen ytterligare.

Om Preshared Key har distribuerats i flera profiler är ett byte mer arbetskrävande i drift. Nyckeln bör därför inte behandlas som ett engångsvärde.

För certifikat bör man dessutom kontrollera om certifikattyp, giltighetstid, privata nycklar och målklient passar ihop. För IPsec Remote Access är särskilt RSA-certifikat relevanta. Certifikatbyten är alltid också en profil- och rolloutfråga.

4. Kontrollera Local ID och Remote ID

Local ID och Remote ID är valfria, men kan vara viktiga vid flera tunnlar eller särskilda peers. Om de sätts måste de passa till den använda profilen och klientkonfigurationen.

Typiska värden är:

• DNS-namn
• IP-adress
• email
• certifikat

I enkla setups lämnas dessa fält ofta tomma. Om fel som no IKE config found eller proposal/ID-problem uppstår senare hör detta område till kontrollen. För djupare analys är Sophos Firewall IPsec VPN troubleshooting bättre som fortsättningsartikel.

5. Tilldela användare och grupper

Välj endast användare eller grupper som verkligen behöver Remote Access. I produktionsmiljöer är en dedikerad VPN-grupp oftast bättre än en bred standardgrupp.

Kontrollera:

• Gruppen innehåller endast behöriga användare.
• Avslutade användare tas bort.
• MFA är aktivt och testat för dessa användare.
• Helpdesk vet hur användare spärras, låses upp eller provisioneras på nytt.

Guest users hör inte hemma i Remote Access. För produktionsmiljöer är en dedikerad VPN-grupp bättre än en bred standardgrupp från katalogtjänsten.

Konfigurera klientdata

6. Ange namn

Anslutningsnamnet bör vara begripligt för användare och support. Namn som homeoffice, remote-access-ipsec eller ett platsnamn är mer hjälpsamma än interna förkortningar.

Om flera profiler distribueras bör namngivningen vara konsekvent. Det minskar förväxlingar i Sophos Connect Client.

7. Ange IP-pool

Firewallen tilldelar VPN-klienter en adress ur den definierade poolen. Detta intervall får inte överlappa interna nät, andra VPN-pooler, Site-to-Site-nät eller vanliga hemnätsintervall.

God praxis:

• separat adressintervall endast för Remote Access
• tillräcklig storlek för samtidiga användare
• ingen överlappning med 192.168.0.0/24, 192.168.1.0/24 eller vanliga hemnätsintervall om det kan undvikas
• tydlig dokumentation i IPAM eller nätverksdokumentation

Om poolen ändras senare måste profiler och tester kontrolleras igen.

För IPsec Remote Access bör poolen åtminstone planeras rent som ett eget subnet. Dessutom får den inte överlappa andra Remote Access-pooler som SSL VPN, L2TP eller PPTP.

8. Ange DNS-servrar

Om användare ska nå interna system via namn måste lämpliga DNS-servrar och vid behov sökdomäner distribueras. I många miljöer är det en intern Domain Controller eller dedikerad DNS-server.

Externa resolvers som Cloudflare, Google, Quad9 eller OpenDNS löser inte interna zoner. Sådana resolvers är bara rimliga om inga interna namn behövs via VPN-tunneln eller om DNS medvetet löses på annat sätt.

Exempel på externa resolvers:

• Cloudflare: 1.1.1.1 och 1.0.0.1
• Google: 8.8.8.8 och 8.8.4.4
• Quad9: 9.9.9.9 och 149.112.112.112
• OpenDNS: 208.67.222.222 och 208.67.220.220

För produktiv Remote Access är det oftast viktigare att interna FQDN fungerar tillförlitligt. Om DNS inte är rent planerat ser tunneln “ansluten” ut för användare trots att applikationer inte går att använda.

Kontrollera avancerade inställningar

9. Sätt Session Timeout

En Session Timeout förhindrar att oanvända VPN-anslutningar förblir öppna obegränsat. För aggressiva värden kan dock skapa supportfall, eftersom användare måste återansluta efter korta avbrott.

Ett rimligt värde passar arbetsmodellen:

• korta timeouts för sporadisk adminåtkomst
• längre timeouts för stabila arbetssessioner
• tydlig kommunikation om användare måste återansluta efter inaktivitet

Om OTP/MFA används bör även påverkan på reconnects testas.

Om firewallen kopplar ned en idle client kan Sophos Connect Client bygga upp anslutningen igen i bakgrunden. Om det misslyckas måste användaren medvetet koppla ned anslutningen i klienten och ansluta igen. Detta beteende bör vara känt i helpdesk-processen.

10. Sätt Advanced settings medvetet

De avancerade inställningarna avgör hur klienten beter sig i vardagen. Vid IPsec Remote Access tas de med i .scx-filen, inte i .tgb-filen.

Viktiga punkter:

• Use as default gateway: Ska all internettrafik gå via firewallen eller bara interna resurser?
• Permitted network resources: Vilka interna nät får över huvud taget nås via tunneln?
• Send Security Heartbeat through tunnel: Används Sophos Endpoint/Synchronized Security och ska Heartbeat gå via VPN?
• Allow users to save username and password: Passar sparad inloggning till MFA- och säkerhetskonceptet?
• Prompt users for 2FA token: Ska OTP visas som separat fält eller kombineras i lösenordsfältet?
• Run AD logon script after connecting: Behövs logon scripts som enhetsmappningar verkligen och är de testade?
• Connect tunnel automatically: Ska tunneln byggas upp automatiskt vid användarinloggning?

Vid Full Tunnel via Use as default gateway krävs dessutom en firewall-regel från VPN till WAN och ett medvetet NAT/Security Policy-upplägg. Vid Split Tunnel måste de tillåtna interna resurserna dokumenteras tydligt.

Om Prompt users for 2FA token är aktivt blir användningen ofta tydligare för användare. Samtidigt bör man kontrollera om använda verktyg eller automatiseringar fungerar med denna inställning.

11. Spara och exportera konfiguration

Efter sparandet exporteras anslutningskonfigurationen. Beroende på klient och SFOS-version kan .scx, .tgb eller provisioningfiler vara relevanta. Filen bör inte lagras öppet eller lämnas vidare till obehöriga.

Efter ändringar av användargrupp, pool, DNS, profil, gateway, port, certifikat eller Advanced Settings måste berörda klienter få den uppdaterade konfigurationen. Gamla profiler är en vanlig orsak till svårförståeliga VPN-problem.

Om provisioning används måste man dessutom kontrollera om klienten hämtar ändringarna automatiskt eller om användare måste uppdatera policy i Sophos Connect Client eller logga in igen. Ändringar av SSL VPN-port, gateway, servercertifikat eller protokoll är typiska fall där en ny inloggning eller ett medvetet uppdateringssteg kan behövas.

Skapa firewall-regler

Sophos Connect bygger bara upp tunneln. Åtkomst till interna system styrs fortfarande via firewall-regler. Utan passande regler kan anslutningen vara grön, men produktiv åtkomst ändå inte fungera.

För åtkomst från VPN-klienter till interna system skapas typiskt en regel från VPN till LAN eller till en specifik målzon.

• Source Zone: VPN
• Destination Zone: LAN

Bättre än bred åtkomst till hela LAN är oftast en regel till de nät eller tjänster som faktiskt behövs. Logging bör aktiveras under införandefasen så att fel syns i Log Viewer.

Om klienten fungerar som Full Tunnel och även internettrafik ska gå via firewallen krävs dessutom en regel från VPN till WAN och ett medvetet NAT/Security Policy-upplägg.

• Source Zone: VPN
• Destination Zone: WAN

För felsökning i regler är Testa firewall-regler med Log Viewer, Policy Test och Packet Capture användbart.

Firewall-regler ska inte bara “fungera”, utan vara kontrollerbara. För införandefasen är logging på Remote Access-reglerna användbart. Senare kan man avgöra vilka regler som ska loggas permanent och vilka händelser som dessutom ska gå till Sophos Central eller Syslog.

Testa efter rollout

En grön Sophos Connect-status räcker inte som acceptanstest. Minst dessa punkter bör kontrolleras med en testanvändare:

• Klienten importerar konfigurationen utan fel.
• Inloggning fungerar med lösenord och MFA.
• Klienten får en adress ur förväntad VPN-pool.
• Interna DNS-namn löses korrekt.
• Centrala interna system är nåbara.
• Log Viewer visar förväntad firewall-regel.
• Split Tunnel eller Full Tunnel beter sig som planerat.
• Reconnect efter nätverksbyte fungerar.
• Gamla profiler har inte återanvänts.
• Vid Full Tunnel fungerar internetåtkomst via firewallen som planerat.
• Vid Split Tunnel förblir icke tillåtna mål blockerade.
• Log Viewer visar träffar på förväntade regler.
• Vid provisioning uppdateras profiländringar spårbart.

Därefter kan installationsguiderna för Windows och macOS användas.

Driftchecklista

Efter teknisk rollout bör driften inte lämnas öppen:

• Ansvarig VPN-grupp dokumenterad.
• Avslutsprocess tar bort användare från Remote Access-grupper.
• MFA-resetprocess är känd.
• Profilversion eller ändringsdatum dokumenteras.
• Helpdesk vet vilka profiler som är aktuella.
• Log Viewer och relevanta serviceloggar är kända.
• Ändringar av IP-pool, DNS, gateway, certifikat och Advanced Settings utlöser en profilkontroll.
• Före SFOS-uppgraderingar kontrolleras Legacy Remote Access IPsec och klientprofiler.

Troubleshooting

Anslutningen byggs upp, men ingen traffic flödar

Orsaken ligger ofta inte i tunneln, utan i firewall-regler, NAT, routing, DNS eller returvägen. Kontrollera först i Log Viewer om traffic från VPN-zonen träffar förväntad regel. Avgränsa sedan med Packet Capture eller Policy Test.

Användaren kan inte logga in

Kontrollera användargrupp, autentiseringsserver, MFA, spärrad användare och lösenordsstatus. Om AD, RADIUS eller Microsoft Entra ID SSO är inblandat bör autentisering testas separat från VPN.

Klienten använder en gammal konfiguration

Efter ändringar av IP-pool, DNS, användargrupp, profil, gateway, certifikat eller Advanced Settings måste konfigurationen distribueras eller importeras på nytt. Gamla .tgb, .scx, .ovpn eller provisioningfiler bör inte cirkulera parallellt.

Provisioning fungerar inte

Kontrollera först om VPN Portal är nåbar från nödvändig zon och om Device Access har satts medvetet. Kontrollera därefter gateway-värde, portalport, certifikat, användarinloggning, MFA och vid Entra SSO tilldelningen under Authentication > Services.

SSO fungerar bara delvis

Vid Microsoft Entra ID SSO måste VPN Portal, IPsec och SSL VPN beroende på workflow passa till rätt Entra ID-server. Vid provisioning måste gateway-värdet passa till Redirect URI i Entra-konfigurationen. Om bara enskilda användare påverkas, kontrollera dessutom UPN, emailadress, gruppmappning och importerade användargrupper.

Anslutningen står, men stora överföringar hänger

Om login, DNS och små åtkomster fungerar men större filöverföringar eller vissa applikationer hänger bör MTU/MSS kontrolleras. Felbilden passar ofta fragmentation, PPPoE, tunnlade anslutningar eller en asymmetrisk väg. Förloppet finns i Kontrollera Sophos Firewall MTU och MSS vid VPN-problem.

IPsec bryts i främmande nät

IPsec kan blockeras på hotell, gäst-Wi-Fi, mobilnät eller strikt filtrerade företagsnät. I sådana fall bör man kontrollera om SSL VPN Remote Access, ZTNA eller en annan Remote Access-design passar bättre.

Full Tunnel har ingen internetåtkomst

Om Use as default gateway är aktivt måste traffic från VPN till WAN tillåtas och hanteras med passande NAT. Dessutom bör Web Protection, Application Control, DNS och logging planeras medvetet som för andra klientnät.

FAQ