Sophos Connect auf Sophos Firewall konfigurieren

Sophos Connect wird für IPsec Remote Access auf SFOS 22 unter Remote access VPN > IPsec konfiguriert. Der Tunnel allein gibt noch keinen Zugriff frei: Authentifizierung, Client-Adressierung, DNS, Firewall-Regeln und das verteilte Profil müssen als Ganzes funktionieren.

Dieser Artikel bleibt bewusst auf der Firewallseite. Installation und Import sind separat für Windows und macOS beschrieben. Für SSL VPN gilt Sophos Firewall SSL VPN Remote Access einrichten; bei einer offenen Architekturentscheidung hilft Sophos Connect oder SSL VPN.

Vor dem ersten Klick

Für einen kontrollierten Aufbau braucht es:

• administrativen Zugriff auf WebAdmin und eine erreichbare WAN-Adresse;
• Benutzer oder Gruppen in einer von Sophos Connect unterstützten Quelle, etwa lokal, Active Directory, RADIUS oder Microsoft Entra ID, sowie ein passendes MFA-Konzept;
• einen freien privaten Client-Pool, interne Zielnetze und die wirklich benötigten Dienste;
• DNS-Server, die die vorgesehenen internen Namen auflösen können, und bei Bedarf ein DNS-Suffix;
• ein IKEv1-IPsec-Profil und entweder einen Preshared Key oder geeignete RSA-Zertifikate;
• einen externen Testzugang, beispielsweise über einen Mobilfunk-Hotspot. IPsec Remote Access aus der LAN-Zone wird von SFOS nicht unterstützt.

Bei einem Upgrade auf SFOS 22.0 MR1 oder neuer zuerst prüfen, ob Legacy Remote Access IPsec migriert werden muss.

Authentifizierungsdienste zuerst zuordnen

Unter Authentication > Services müssen die gewünschten Server an den richtigen Stellen in Selected authentication server stehen:

• VPN portal authentication methods für VPN-Portal und Provisioning;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods für die Anmeldung am IPsec-Tunnel.

Üblich ist Local plus der unter Authentication > Servers eingerichtete Verzeichnis-, RADIUS- oder Entra-ID-Server. Diese Zuordnung vor dem Export testen. Bei Microsoft Entra ID SSO muss der Entra-ID-Server bereits hier ausgewählt sein, bevor die Konfigurationsdatei heruntergeladen wird; andernfalls fehlen dem .scx die SSO-Werte. Der vollständige Ablauf steht unter Microsoft Entra ID SSO für VPN, die OTP-Seite unter Sophos Firewall MFA einrichten.

Für SSO unter Windows ab Sophos Connect 2.4 nach Firmware und Provider unterscheiden: Auf SFOS 22 gilt der oben verlinkte Entra-ID-Ablauf; auf SFOS 23 ist OpenID Connect (OIDC) mit einem unterstützten Identity Provider (IdP) vorgesehen. Entra ID bleibt eine gültige Variante. Die Einrichtung für Google Workspace OIDC beschreibt die andere hier abgedeckte Provider-Variante und deren Grenzen; das ist keine Zusage für beliebige OIDC-Anbieter, Clientplattformen oder Firmware-Builds.

Auch bei einem direkt importierten Profil den vorgesehenen IdP-Server unter Authentication > Services auswählen, bevor die Konfiguration heruntergeladen wird. Bei direktem SSL VPN müssen VPN Portal und SSL VPN denselben Server verwenden. Bei direktem IPsec darf der Tunnel denselben oder einen anderen Server als das VPN Portal verwenden; daraus folgt keine beliebige Austauschbarkeit von Providern. Die Windows-OIDC-Erweiterung erweitert nicht die unten beschriebene Entra-ID-SSO-Unterstützung auf macOS.

Adressen, Ziele und Rückfallweg festlegen

Für ein kollisionsfreies Design darf sich der VPN-Pool nicht mit LAN, WLAN, VLANs, Site-to-Site-VPNs oder typischen Heimnetzen überschneiden. SFOS selbst verlangt, dass der Bereich in einem mindestens /24 grossen Subnetz liegt und nicht zugleich für SSL VPN, L2TP oder PPTP verwendet wird. Ein Beispiel ist 10.250.10.10 bis 10.250.10.200 innerhalb 10.250.10.0/24.

Vor der Änderung den aktuellen IPsec-Stand, die ausgewählten Zertifikate und IDs, die Regelreihenfolge sowie die bisher verteilten .scx-/.pro-Versionen dokumentieren. Das alte Profil sicher aufbewahren. So lässt sich eine misslungene Änderung durch Rücksetzen der einzelnen Werte und Regeln zurücknehmen, ohne bestehende Benutzer, Zertifikate oder andere VPN-Konfigurationen zu löschen. Reset am Ende der IPsec-Seite setzt dagegen die Remote-Access-IPsec-Konfiguration auf Werkseinstellungen zurück und ist kein normaler Rollback.

IPsec Remote Access vollständig konfigurieren

Ältere Oberflächen und der vorhandene Screenshot zeigen noch VPN > Sophos Connect Client. In SFOS 22 lautet der Pfad Remote access VPN > IPsec.

General settings

1. IPsec remote access einschalten.
2. Unter Interface den WAN-Port wählen, der als Tunnelendpunkt dient. SFOS bietet in dieser Remote-Access-Konfiguration genau ein WAN-Interface an; mehrere Provisioning-Gateways ändern diese Tunnelbindung nicht.
3. Unter IPsec profile ein IKEv1-Profil wählen. Es erscheint nur, wenn Dead Peer Detection ausgeschaltet oder auf Disconnect gesetzt ist. Phase-1- und Phase-2-Algorithmen, DH/PFS und Laufzeiten müssen zum Sicherheitsstandard passen. Starke Algorithmen und PFS sind sinnvolle Best Practices, die genannten IKEv1-/DPD-Bedingungen dagegen SFOS-Vorgaben.
4. Authentication type als Preshared key oder Digital certificate festlegen.
5. Local ID, Remote ID und Allowed users and groups vervollständigen.

Ein PSK wird in die exportierte Konfiguration aufgenommen. Er muss zufällig und geschützt sein und bei Verdacht zusammen mit den betroffenen Profilen ersetzt werden. MFA schützt die Benutzeranmeldung zusätzlich, ersetzt diesen Tunnel-Schlüssel aber nicht.

Für Digital certificate gelten auf SFOS 22 klare Grenzen:

• IPsec verwendet RSA-, keine ECDSA-Zertifikate;
• Local und Remote Certificate benötigen eine Certificate ID;
• External certificate darf nicht ausgewählt sein;
• Local und Remote Certificate müssen von derselben Vertrauenskette stammen. Entweder lokal erzeugte Zertifikate oder Zertifikate derselben Drittanbieter-CA verwenden und deren Signing CA auf die Firewall laden.

Sophos empfiehlt eine Local ID zur Identifikation der Firewall und eine andere Remote ID für die Clients. Zulässig sind DNS, IP Address, Email und bei Zertifikaten DER ASN1 DN [X509]. Bei letzterem übernimmt die Firewall den Distinguished Name des Zertifikats. IDs müssen nicht öffentlich auflösbar sein, aber Firewall und exportiertes Profil müssen dieselben Werte erwarten.

Benutzer und Gruppen sauber freigeben

Unter Allowed users and groups nur die vorgesehenen Konten aufnehmen. IPsec Remote Access berücksichtigt bei einem Verzeichnisbenutzer die Main group. Die erlaubte AD-Gruppe muss daher seine Hauptgruppe sein; andernfalls den Benutzer gezielt freigeben, statt eine breite Gruppe zu öffnen.

Unter Authentication > Groups die effektive Einstellung IPsec remote access und die Gruppenreihenfolge prüfen. Solange Remote Access IPsec nicht konfiguriert ist, ist es standardmässig für alle Gruppen deaktiviert. Nach der Konfiguration bleiben importierte AD-Gruppen und migrierte Gruppen standardmässig deaktiviert; neu angelegte lokale Gruppen sind dagegen standardmässig aktiviert. Bei mehreren Gruppen greift die Policy der obersten Gruppe. Individuelle Benutzer-Policies haben grundsätzlich Vorrang: Ein Benutzer kann beispielsweise trotz deaktivierter Gruppe ausdrücklich aktiviert werden. Die entscheidende Ausnahme: Ist IPsec Remote Access für eine Gruppe ausdrücklich aktiviert, lässt sich dieser Zugriff nicht durch individuelles Deaktivieren eines Mitglieds sperren. Beim Offboarding deshalb die effektive Main-group-Zuordnung, Gruppenreihenfolge und alle Benutzer- oder Gruppenfreigaben prüfen und die wirksame Berechtigung entziehen, statt sich auf den Benutzerschalter zu verlassen. Das Deaktivieren einer Gruppe trennt laut Sophos deren aktive Sitzungen und verhindert die Wiederverbindung; individuelle Freigaben sind dabei gesondert zu prüfen. Mit einem normalen Pilotbenutzer die effektive Authentisierung und erlaubte sowie gesperrte Ziele kontrollieren. Beim Offboarding unter Current activities > IPsec connections aktive Sitzungen prüfen, nötigenfalls gezielt Disconnect verwenden und anschliessend bestätigen, dass der Benutzer sich nicht erneut authentisieren oder auf geschützte Ziele zugreifen kann. Diese Prüfungen sind Abnahmeschritte, kein hier nachgewiesener Geräteeffekt. Active Directory mit Sophos Firewall verbinden.

Ein AD-Benutzer muss sich vor seinem ersten klassischen Sophos-Connect-Login in der Regel an einem anderen Authentication Client wie dem User Portal anmelden. Provisioning kann das Konto beim ersten Login erzeugen und anhand des Server-Mappings zuordnen. Guest users und guest groups sind für Remote Access nicht zulässig.

Client information und Idle time

Unter Client information werden alle Felder bewusst gesetzt:

• Name: ein kurzer, eindeutiger Anzeigename wie remote-access-ipsec;
• Assign IP from: Start und Ende des geplanten privaten Pools;
• Allow leasing IP address from RADIUS server for L2TP, PPTP, and IPsec remote access: nur bei RADIUS-Adressvergabe einschalten. Liefert RADIUS keine Adresse, verwendet SFOS zuerst eine für den Benutzer konfigurierte statische Adresse und sonst eine Lease aus Assign IP from;
• DNS server 1 und DNS server 2: Resolver, die für die benötigten Zonen zuständig sind oder korrekt dorthin weiterleiten.

Öffentliche Resolver sind nicht pauschal falsch, lösen private Unternehmenszonen ohne eine passende Veröffentlichung oder Weiterleitung aber üblicherweise nicht auf. Für interne Ressourcen deshalb den tatsächlich autoritativen oder weiterleitenden DNS-Pfad testen.

Unter Idle time kann Disconnect when tunnel is idle aktiviert werden. Idle session time interval wird in Sekunden angegeben. Der Wert ist eine betriebliche Entscheidung: Ein kurzer Timeout reduziert verwaiste Sitzungen, kann aber Arbeitsabläufe und MFA-Reconnects stören. Nach einem Idle Disconnect versucht Sophos Connect den Neuaufbau im Hintergrund; klappt das nicht, im Client erst Disconnect, dann Connect wählen.

Advanced settings

Diese Werte landen in .scx, nicht in .tgb:

• Use as default gateway: eingeschaltet für Full Tunnel, ausgeschaltet für Split Tunnel. Diese Entscheidung gilt für alle unter Allowed users and groups eingetragenen Benutzer; unterschiedliche Vorgaben innerhalb derselben IPsec-Konfiguration sind nicht möglich.
• Permitted network resources (IPv4): interne Netze und Hosts für den Split Tunnel. Nur eintragen, was Benutzer über den Tunnel erreichen sollen.
• Send Security Heartbeat through tunnel: Heartbeat eines vorhandenen Sophos Endpoint durch den Tunnel senden.
• Allow users to save username and password: nur zulassen, wenn Geräteschutz und MFA-Vorgaben dies erlauben. Für Connect tunnel automatically empfiehlt Sophos gespeicherte Zugangsdaten.
• Prompt users for 2FA token: separates OTP-Feld anzeigen. Die Firewall übermittelt trotzdem passwordotp; challenge-basierte MFA wird nicht unterstützt. SCCLI funktioniert mit dieser Option nicht.
• Run AD logon script after connecting: AD-Anmeldeskript nach Tunnelaufbau ausführen.
• Connect tunnel automatically: Verbindung nach der Anmeldung am Endgerät automatisch aufbauen.
• Hostname or DNS suffix to monitor: einen nur intern auflösbaren Hostnamen oder ein internes Suffix eintragen. Sophos Connect prüft damit die automatische Verbindung; der überwachte Host muss ICMP-Probes beantworten dürfen.
• Assign client DNS suffix: Suffix wie firma.example an den Netzwerkadapter des Endgeräts anhängen, damit kurze Hostnamen als FQDN aufgelöst werden.

Bei Split Tunnel erstellt SFOS für die erlaubten Subnetze separate ESP-SAs und entfernt bei Inaktivität nur die betroffene Child SA. Bei Full Tunnel besteht eine ESP SA, die nach dem Idle-Intervall ohne Datenverkehr entfernt wird.

Erreichbarkeit vor der Firewall prüfen

Liegt Sophos Firewall hinter einem Router oder einer anderen NAT-Instanz, muss dieser die öffentliche Adresse auf das ausgewählte Firewall-WAN-Interface umsetzen. Für NAT-T sind UDP 500 und UDP 4500 freizugeben und weiterzuleiten. Ohne NAT auf dem Pfad läuft der ESP-Datenverkehr als IP-Protokoll 50; das vorgelagerte Gerät muss ihn dann ebenfalls passieren lassen. Erkennt SFOS NAT, kapselt NAT-T die weiteren IKE- und ESP-Pakete über UDP 4500.

Ein normaler TCP/UDP-Port-Check beweist daher nicht den ganzen IPsec-Pfad. Auch Carrier-NAT, ein doppeltes NAT oder ein restriktives Gastnetz kann den Aufbau verhindern. Bei einer öffentlichen Adresse direkt auf SFOS braucht es keine vorgelagerte DNAT-Regel.

Steht die Firewall hinter einem Router, zuerst die exportierte .scx sicher als Ausgangsprofil sichern. Gemäss Sophos-FAQ die Gateway-Adresse in der .scx manuell auf die WAN-IP-Adresse des Routers ändern. Das korrigierte Profil kontrolliert verteilen und neu importieren; danach aus einem externen Netz Tunnel und erlaubten Datenfluss testen. Die Weiterleitungen für IKE/NAT-T bleiben erforderlich. gateway in .pro adressiert dagegen das VPN Portal und repariert nicht automatisch den Tunnelendpunkt in .scx; hier wird kein unbestätigter Schema-Schlüssel vorausgesetzt.

Firewall-Regeln und Device Access

Zugriff auf interne Ziele

Unter Rules and policies > Firewall rules eine gezielte IPv4-Regel erstellen:

• Rule name: eindeutig, beispielsweise VPN-SophosConnect-to-ERP;
• Rule position: oberhalb einer allgemeineren Drop- oder widersprechenden Accept-Regel;
• Action: Accept;
• Log firewall traffic: für Abnahme und Betrieb einschalten;
• Source zones: VPN;
• Source networks and devices: der IPsec-Client-Pool beziehungsweise ein passendes IP-Host-Objekt, nicht unnötig Any;
• During scheduled time: All the time oder ein begründetes Zeitfenster;
• Destination zones: die tatsächlich benötigte Zone, etwa LAN oder DMZ;
• Destination networks: nur freigegebene Server oder Netze;
• Services: nur benötigte Protokolle und Ports;
• Match known users sowie Users or groups: optional als zusätzliche Identitätsbedingung, wenn dies zum Authentifizierungsdesign passt.

SFOS wertet Regeln von oben nach unten aus und stoppt beim ersten Treffer. Nach dem Speichern deshalb die effektive Position kontrollieren; automatisch oder später ganz oben erstellte Regeln können die Reihenfolge verändern. Web-, Application-Control-, IPS-, Heartbeat- und weitere Security Policies sind keine pauschale SFOS-Pflicht für VPN-Verkehr. Sie werden nach Schutzbedarf gewählt und mit den Anwendungen getestet.

Full Tunnel ins Internet

Mit Use as default gateway braucht es zusätzlich Verkehr von VPN nach WAN:

Auch diese Regel erhält den Client-Pool als Source network, passende Dienste, Logging und die gewünschten Web-, Application-Control- oder IPS-Policies. Der Client-Pool muss ausserdem von einer passenden SNAT/Masquerading-Regel erfasst werden; das kann bereits eine bestehende NAT-Regel leisten. Eine verknüpfte NAT-Regel ist möglich, aber keine Pflicht. NAT-Regeln werden ebenfalls in Reihenfolge ausgewertet, sodass eine frühere, breiter passende Regel gewinnt. Full Tunnel ohne abgestimmte NAT- und Security Policies führt deshalb oft zu einem grünen Tunnel ohne Internetzugriff oder zu unbeabsichtigt ungefiltertem Verkehr.

Local Service ACL

Firewall-Regeln steuern weitergeleiteten Verkehr, nicht die lokalen Dienste der Firewall. Unter Administration > Device access:

• IPsec aus der verwendeten WAN-Zone erlauben;
• VPN portal nur aus den Zonen zulassen, aus denen Download oder Provisioning benötigt wird; WAN-Zugriff empfiehlt Sophos nur temporär;
• DNS aus VPN nur erlauben, wenn die Firewall selbst als DNS-Resolver angesprochen wird;
• Ping/Ping6 aus VPN nur erlauben, wenn die Firewall selbst Testziel sein soll.

Wo eine pauschale Zone zu breit wäre, kann eine Local service ACL exception rule den Zugriff auf bestimmte Quellhosts oder Netze einschränken. Details erklärt Device Access und Local Service ACL.

Profil exportieren oder provisionieren

Export connection erzeugt ein Archiv mit .scx und .tgb. Für Sophos Connect ist .scx der Standard und enthält General sowie Advanced Settings. .tgb ist für kompatible Drittanbieter-Clients gedacht und enthält nur General Settings. Nach Änderungen an General oder Advanced Settings muss die Konfiguration erneut verteilt werden; bei reinen Advanced-Änderungen betrifft dies nur .scx.

Eine .pro-Datei kann unter Windows mit Sophos Connect 2.1 oder neuer die IPsec- und berechtigten SSL-VPN-Konfigurationen vom VPN Portal laden und spätere Änderungen automatisch übernehmen. Die genaue JSON-Struktur, mehrere Portalgateways, MFA-Felder und GPO-Verteilung beschreibt Sophos Connect Provisioning mit .pro und GPO.

Bei Microsoft Entra ID SSO mit Sophos Connect für macOS ab 2.1 auch die Anmeldung im vom Client geöffneten Browser und die Rückkehr zum Client in die Abnahme aufnehmen. Der macOS-Anmeldeablauf mit Browserwahl und Fallback erklärt die Schritte; danach Tunnelstatus, VPN-IP, DNS und Zugriff prüfen, ohne Conditional Access, MFA oder Zertifikatsprüfungen abzuschwächen. Falls dafür eine angepasste .pro nötig ist, die wörtliche Feldsyntax und die zulässigen Werte von sso_auth_browser_type unter Sophos Connect Provisioning verwenden.

Wichtig für die Fehlersuche: gateway in .pro ist die FQDN- oder IPv4-Adresse der Firewall, über die der Client das VPN Portal erreicht und Konfigurationen abruft. Sie ist nicht automatisch das Gateway des IPsec-Tunnels. Der Tunnel endet am Interface, das unter Remote access VPN > IPsec gewählt und im geladenen .scx hinterlegt ist. Mehrere .pro-Gateways bieten deshalb mehrere Provisioning-Wege, aber kein Multi-WAN für diese einzelne IPsec-Remote-Access-Konfiguration.

Ändern sich gateway oder der VPN-Portal-Port, muss .pro angepasst und erneut verteilt werden. Bleiben beide gleich, kann der konfigurierte Provisioning-Pfad die VPN-Konfiguration und spätere Änderungen erneut abrufen. Bei einer manuell importierten .scx ist dagegen nach Änderungen der General oder Advanced Settings die aktuelle Verbindung erneut über Export connection zu exportieren, über einen geschützten Kanal zu verteilen und im Client erneut zu importieren. Update policy ist kein Ersatz für diese manuelle Verteilung und den erneuten Import; die dokumentierte Verwendung betrifft den provisionierten Pfad, insbesondere geänderten SSL-VPN-Port oder geändertes Protokoll. Ein Client-Softwareupdate aktualisiert die Firewall-Policy oder ein veraltetes Profil nicht automatisch; bestehende Profile bleiben nach einem reinen Sophos-Connect-Versionsupdate grundsätzlich verwendbar. Das bekannte funktionierende Profil und die zugehörigen Firewall-Werte sicher für einen kontrollierten Rollback aufbewahren. Vor der breiten Verteilung mit einem normalen Pilotbenutzer Profilversion und Tunnel-Gateway, Authentisierung/MFA, Routen, DNS sowie erlaubte und gesperrte Ziele prüfen. Bei fehlgeschlagener Abnahme die zusammengehörigen alten Firewall-Werte und das bekannte funktionierende Profil wiederherstellen und dieselben Prüfungen wiederholen.

Lädt Provisioning alte Werte oder gar keine Konfiguration, nacheinander Erreichbarkeit und Zertifikat des VPN Portal, Portal-Port, gateway, Benutzeranmeldung und MFA prüfen. Für SSO-Provisioning müssen VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods und SSL VPN authentication methods unter Authentication > Services denselben konfigurierten IdP-Server verwenden: Entra ID auf SFOS 22, ein unterstützter OIDC-IdP auf SFOS 23 im oben eingegrenzten Windows-Pfad. gateway muss dem Firewall-FQDN beziehungsweise der IPv4-Adresse im Abschnitt Redirect URI dieses unter Authentication > Servers konfigurierten Servers entsprechen. Gemeint ist nur der Host, nicht die vollständige Callback-URI mit Schema, Port und Pfad; den VPN-Portal-Port separat in vpn_portal_port eintragen. Provider-spezifische Einschränkungen bleiben verbindlich: Für Google Workspace den im Detailartikel geforderten gültigen FQDN verwenden, keine IP-Adresse. Vor der Verteilung Serverzuordnung, Host und Portal-Port vergleichen. Bei SSO-Fehlern den zur Firmware und zum Provider passenden Ablauf im oben verlinkten Entra- oder Google-Artikel verwenden; Entra-Diagnosen nicht pauschal auf andere OIDC-Provider übertragen.

Profile enthalten sicherheitsrelevante Angaben und gehören in einen geschützten Verteilkanal. Alte und neue Versionen eindeutig benennen, damit Helpdesk und Benutzer nicht versehentlich zurückwechseln.

Die Verteilung einer neuen Firewall-Policy ist von der Aktualisierung der Clientsoftware zu unterscheiden. Versionen, Freigabe in Pilotgruppen und Rückfallplanung behandelt Sophos Connect sicher aktualisieren.

Für den Betrieb verantwortliche VPN-Gruppe und Austrittsprozess, MFA-Reset sowie Sperren und Entsperren von Benutzern dokumentieren. Ebenso gehören Profilversion, Änderungsdatum und Verantwortlicher, dauerhafte Logging-Vorgaben einschliesslich Sophos Fusion (ehemals Sophos Central) oder Syslog sowie eine erneute Prüfung der Profile vor SFOS-Upgrades in die Betriebsdokumentation.

Abnahme mit echtem Remote-Client

Nach dem Import mit einem normalen Zielbenutzer aus einem externen Netz testen:

1. Anmeldung und MFA funktionieren, der Client erhält die erwartete Pool- oder RADIUS-Adresse.
2. Unter Current activities > IPsec connections erscheint die Sitzung. Die Liste lässt sich unter anderem nach Connection name, Username, Local subnet und Remote host/subnet filtern; Refresh aktualisiert die Ansicht, Disconnect beendet gezielt eine Verbindung.
3. Interne FQDNs und – falls konfiguriert – kurze Namen über das DNS-Suffix werden korrekt aufgelöst.
4. Erlaubte Ziele funktionieren, nicht erlaubte Ziele bleiben gesperrt.
5. Der Log Viewer zeigt Treffer auf der vorgesehenen Firewall-Regel.
6. Split Tunnel lässt übrigen Internettraffic lokal; Full Tunnel führt ihn über die Firewall, die erwartete SNAT-Regel und die vorgesehenen Security Policies.
7. Reconnect nach Idle Timeout, Netzwerkwechsel und Endpoint-Neustart funktioniert.
8. Im Sophos-Connect-Client zeigen Events den zeitlichen Ablauf von Import, Anmeldung und Tunnelaufbau. Bei einem reproduzierbaren Fehler einen Support report im Client erzeugen und zusammen mit Zeitpunkt, Benutzer, Clientversion und Profilversion sichern, bevor Profile oder Zertifikate verändert werden.

Für die Regelanalyse eignet sich Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Bei tieferer Tunnelanalyse folgt Sophos Firewall IPsec VPN Troubleshooting.

Gezielte Fehlersuche

Anmeldung schlägt fehl

Zuerst Authentication > Services, Passwort-/MFA-Status, Sperren und den Authentifizierungsserver unabhängig vom VPN prüfen. Danach Main group, Allowed users and groups und den Gruppenschalter IPsec remote access vergleichen. Sophos Connect unterstützt in Benutzernamen nur ASCII-Zeichen; Umlaute und andere UTF-8-/UTF-16-Zeichen können die Anmeldung verhindern.

Statt eine einzelne, nicht eindeutig dokumentierte IKE-Textmeldung als Diagnose zu verwenden, den Ablauf trennen: Kommt der Versuch bis zur Benutzerauthentifizierung, stimmen Interface, IPsec-Profil, Zertifikat beziehungsweise PSK sowie Local/Remote ID überein, und ist der Benutzer wirklich über seine Main group freigegeben? Client-Events und zeitgleiche Firewall-Logs liefern dafür die belastbarere Spur.

Failed to validate certificate nach einem Neustart

Wenn der erste Aufbau klappt, nach einem Neustart aber Failed to validate certificate erscheint, sind Local und Remote Certificate häufig nicht von derselben CA signiert. Certificate IDs und Vertrauenskette prüfen. Entweder lokal erzeugte Zertifikate beziehungsweise Zertifikate derselben Drittanbieter-CA verwenden und deren Signing CA laden oder bewusst auf PSK wechseln. Anschliessend .scx neu exportieren, importieren und erneut nach einem Neustart testen.

Tunnel ist verbunden, Traffic fehlt

Zuerst die Lease-Adresse und Routen am Client prüfen, danach Permitted network resources, Regelposition, Source/Destination networks, Services, Rückroute und DNS. Bei Full Tunnel zusätzlich die VPN-nach-WAN-Regel und die tatsächlich treffende SNAT-Regel kontrollieren. Device access ist nur beteiligt, wenn die Firewall selbst das Ziel ist, etwa für DNS oder Ping.

Verbindung bricht ungefähr alle vier Stunden ab

Bei IKEv1-Rekeying kann eine neue OTP-Anforderung den Tunnel trennen. Sophos nennt für das Default-IPsec-Profil ein Rekey-Intervall von ungefähr vier Stunden; ein eigenes Profil kann bis zu 24 Stunden verwenden. Die Sicherheitsabwägung und Umsetzung erklärt IPsec Remote Access Timeout nach vier Stunden beheben.

Grosse Transfers hängen oder nur einzelne Fremdnetze scheitern

Wenn Login, DNS und kleine Zugriffe funktionieren, grössere Übertragungen aber hängen, MTU und MSS prüfen. Scheitert IPsec nur in Hotels, Gast-WLANs oder streng gefilterten Firmennetzen, kann der fremde Zugang UDP 500/4500 oder ESP blockieren. Dann ist SSL VPN oder ein anderes Remote-Access-Design für diese Benutzer möglicherweise robuster.

Remote Access IPsec nach HA-Failover

Der in den SFOS-22-Release-Notes dokumentierte Fehler NC-175860 betrifft Remote Access IPsec nach einem HA-Failover, wenn das Appliance Certificate zuvor neu erzeugt wurde. Er ist in SFOS 22.0 MR2 Build 546 vom 14. Juli 2026 behoben. Sophos nennt dazu weder eine spezielle Logmeldung noch einen offiziellen Workaround.

Vor einer Massnahme Firmware und Build, HA-Modus, Rollen und Last status change beider Geräte, Zeitpunkt des Failovers, Authentication Type, Local/Remote Certificate samt Certificate IDs und Profilversion sichern. Das Appliance Certificate nicht auf Verdacht neu erzeugen. Auf einer älteren betroffenen Version den freigegebenen Upgradepfad zu MR2 Build 546 oder neuer prüfen und danach in einem Wartungsfenster einen kontrollierten Failover samt externem Neuaufbau testen. Die Grundlagen zur Topologie stehen unter Sophos Firewall HA-Cluster-Varianten, der Upgradeprozess unter SFOS Firmware Update.

Ergänzende Kontrollen für Rollout und Migration

Zertifikate, IDs und Advanced settings

Falls das benötigte RSA-Zertifikat noch fehlt, unter Certificates > Certificates > Add Generate locally-signed certificate wählen oder ein vorhandenes Zertifikat mit Upload certificate hochladen. Zertifikatsdetails und Subject Name ausfüllen; unter Subject Alternative Names den vorgesehenen DNS-Namen oder die IP-Adresse mit + hinzufügen. Danach Certificate IDs und gemeinsame Vertrauenskette wie oben prüfen. Remote ID darf nicht mit Local ID identisch sein. General und Advanced settings mit Apply speichern, bevor Export connection verwendet wird.

Gespeicherte Zugangsdaten werden laut Sophos über die Keychain-Dienste des Endgeräts geschützt; das ersetzt weder Geräteschutz noch die Freigabe durch eure Sicherheitsrichtlinie. Prompt users for 2FA token setzt tatsächlich konfigurierte MFA für Remote Access IPsec unter Authentication > Multi-factor authentication oder beim OTP-Anbieter voraus. Ist das separate Feld deaktiviert, OTP direkt an das Passwort anhängen: passwordotp. Benötigen verschiedene Benutzer unterschiedliche Split-/Full-Tunnel-Modi, separate SSL-VPN-Remote-Access-Richtlinien verwenden statt widersprüchliche IPsec-Profile zu verteilen.

Client ausliefern und Anmeldung wiederherstellen

Administratoren laden den Client unter Remote access VPN > IPsec oder SSL VPN > Download client herunter. Benutzer finden Download for Windows und Download for macOS im VPN portal > VPN > Sophos Connect client. Den auf der Firewall angebotenen Clientstand unter Backup & Firmware > Pattern updates aktualisieren; die installierten Endgeräte separat nach dem verlinkten Update-Runbook ausrollen. Logs auf der IPsec-Seite öffnet die Protokolle; IPsec profiles führt zu den IKE-Parametern.

Provisioning mit .pro ist auch auf macOS mit Sophos Connect 2.1 oder neuer dokumentiert; SSL VPN mit direkt importierter .ovpn ab macOS-Client 2.0. GPO-Verteilung bleibt ein Windows-Verfahren. Bei der Migration von einem Drittanbieter-Client können vorhandene Konfigurationen importierbar sein; für IPsec bevorzugt ein frisch exportiertes .scx oder ein aktuelles .pro, damit die Advanced settings enthalten sind. Den macOS-Ablauf beachten.

Wenn Remember username and password eine automatische Passwortanmeldung auslöst und die SSO-Auswahl nicht mehr erscheint, im Client Edit connection > Clear credentials wählen. Beim nächsten Anmelden erscheinen die Anmeldeoptionen wieder; dies ändert keine Firewall-Berechtigung.

SSO und verzögerte Trennung gezielt prüfen

Eine ausgegraute SSO-Auswahl bei Windows-Client 2.4+ oder macOS-Client 2.1+ kann an fehlenden sso_api_port und sso_api_domain in .scx beziehungsweise .ovpn liegen. Bei Entra ID zuerst den Server unter Authentication > Services zuordnen, danach eine neue Konfiguration exportieren beziehungsweise herunterladen und den passenden Importweg verwenden. Die Werte nicht erraten oder von einem anderen Mandanten kopieren; diese Entra-Diagnose nicht ungeprüft auf Google Workspace übertragen.

Scheitert Entra Conditional Access auf macOS 2.1+ im eingebetteten Browser, die Anmeldung im von Sophos Connect geöffneten Systembrowser abschliessen und zum Client zurückkehren. Meldet der Client fehlende Gerätekonformität, die geforderten Compliance-Massnahmen ausführen oder IT kontaktieren. Ein Profil-Reimport behebt fehlende Compliance nicht; Conditional Access nicht umgehen.

Nach Abschalten des zugehörigen WAN-Interfaces können Remote-Access-IPsec-Sitzungen erst beim Inaktivitäts- oder DPD-Timeout als getrennt erscheinen. Ein noch angezeigter Tunnel beweist daher keine Erreichbarkeit. Interfacezustand und Logs zusammen mit dem Sitzungsstatus prüfen; zum gezielten Beenden Disconnect verwenden, nicht das Abschalten des Interfaces als sofortige Abmeldung voraussetzen.

SSL-VPN- und Mobilgeräte-Grenzen

Bei .pro wird .scx als gemeinsame IPsec-Konfiguration geladen, während .ovpn den für den Benutzer freigegebenen SSL-VPN-Richtlinien entspricht; der Download erteilt noch keine Tunnelberechtigung. SSL-Profile stehen unter VPN portal > VPN > VPN configuration > SSL VPN configuration bereit. Änderungen an SSL-VPN-Port, Gateway, Serverzertifikat oder Protokoll können eine erneute Clientanmeldung verlangen; Port-/Protokolländerungen im provisionierten Ablauf zusätzlich mit Update policy übernehmen. Bei der Prüfung einer leeren .ovpn beachten: standardmässig verwendet SSL VPN ApplianceCertificate mit Default CA.

Bei einem parallelen SSL-VPN-Rollout gelten andere Fehlerbilder: Seit SFOS 20.0 MR1 funktioniert der frühere Legacy-SSL-VPN-Client nicht mehr; auf Sophos Connect oder ein geplantes IPsec-Design migrieren. Bei Migration von 18.5.x oder älter nach 19.5 oder neuer wird der frühere SSL-Leasebereich in ein Subnetz umgewandelt. Ein manuell gepflegtes IP-Host-Objekt kann dann nicht mehr passen. In den betreffenden Regeln die dynamischen Systemhosts ##ALL_SSLVPN_RW und ##ALL_SSLVPN_RW6 verwenden. Eine 0-Byte-.ovpn verlangt Prüfung von Zertifikat und Signing CA; erst nach bestätigter Ursache unter Änderungskontrolle das betroffene Zertifikat erneuern und .ovpn erneut herunterladen/importieren. Bei Login failed. Wrong fingerprint of certificate. nach Wechsel von Anmeldemethode oder Domain eine separate .pro oder .ovpn importieren, nicht die Zertifikatsprüfung abschalten. Details im SSL-VPN-Runbook.

iOS kann das IPsec-Profil im VPN portal > VPN > VPN configuration > IPsec VPN profile herunterladen. Das ist kein Sophos-Connect-Desktop-Profil für Mobilgeräte. Die Hersteller-Client-Matrix enthält eine widersprüchliche OpenVPN-Zuordnung in der IPsec-Zeile; daraus lässt sich keine sichere IPsec-Anleitung mit OpenVPN Connect ableiten. Für mobiles SSL VPN gilt .ovpn mit OpenVPN Connect; für mobiles IPsec den ausdrücklich passenden Client und Profiltyp vor dem Rollout verifizieren. Die genannten Abnahme- und Fehlerprüfungen wurden hier nicht auf einer Appliance oder einem Endgerät ausgeführt.

FAQ