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.

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.

Zusätzlich unter Authentication > Groups kontrollieren, ob IPsec remote access für diese Gruppe aktiv ist. Der Schalter ist bei importierten AD-Gruppen und migrierten Gruppen standardmässig aus, bei neu angelegten lokalen Gruppen standardmässig an. Bei mehreren Gruppen greift die Policy der obersten Gruppe; eine individuelle Benutzer-Policy hat Vorrang. Wird IPsec Remote Access für eine Gruppe ausgeschaltet, trennt SFOS deren aktive Sitzungen und verhindert den erneuten Aufbau. Weitere Hintergründe zur Reihenfolge enthält 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.

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.

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 Provisioning die VPN-Konfiguration neu abrufen. Bei einem manuell importierten IPsec-Profil stossen Benutzer den Abruf im Client über Edit connection > Update policy an; ein Client-Update allein aktualisiert die Firewall-Policy nicht. Bestehende Profile bleiben nach einem reinen Sophos-Connect-Versionsupdate grundsätzlich verwendbar.

Lädt Provisioning alte Werte oder gar keine Konfiguration, nacheinander Erreichbarkeit und Zertifikat des VPN Portal, Portal-Port, gateway, Benutzeranmeldung und MFA prüfen. Bei Entra ID SSO muss gateway zudem zu der registrierten Redirect URI passen.

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.

FAQ