Sophos Connect auf Sophos Firewall konfigurieren

Sophos Connect ist für viele Umgebungen der Standardclient für Remote Access mit Sophos Firewall. Die eigentliche Qualität der Lösung entscheidet sich aber nicht erst auf Windows oder macOS, sondern auf der Firewall: Benutzerberechtigung, IP-Pool, DNS, Authentifizierung, MFA, Firewall-Regeln und spätere Profilverteilung müssen zusammenpassen.

Der Artikel beschreibt die firewallseitige Planung und Konfiguration für Sophos Connect, vor allem für IPsec Remote Access und die Profilbereitstellung. Für SSL VPN ist die eigentliche Remote-Access-Policy im Artikel Sophos Firewall SSL VPN Remote Access einrichten beschrieben. Für die grundsätzliche Entscheidung zwischen IPsec, SSL VPN, mobilen Clients und ZTNA passt zuerst Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.

Welcher Artikel passt?

Je nach Aufgabe ist ein anderer Einstieg sinnvoll:

Diese Trennung ist wichtig, weil Sophos Connect mehrere Dinge berührt: IPsec-Konfiguration, SSL-VPN-Konfiguration, VPN Portal, Provisioning, Authentifizierung, Clientversion und Firewall-Regeln.

Voraussetzungen

• Sophos Firewall mit unterstützter SFOS-Version
• Adminzugriff auf die WebAdmin-Oberfläche
• definierte Benutzer oder Gruppen für Remote Access
• freier IP-Adressbereich für VPN-Clients
• interne DNS-Server, falls interne Namen aufgelöst werden müssen
• MFA-Konzept für Remote Access
• geklärte Zielnetze und Dienste, die über VPN erreichbar sein sollen
• klares Verfahren für Profilverteilung, Profiländerungen und Clientupdates

Wenn die Firewall auf SFOS 22.0 MR1 oder neuer aktualisiert werden soll, muss vorher geprüft werden, ob noch Legacy Remote Access IPsec vorhanden ist. Diese alte Konfiguration kann das Upgrade blockieren. Der Ablauf ist in Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren beschrieben.

In aktuellen SFOS-Versionen liegt die IPsec-Remote-Access-Konfiguration unter Remote access VPN > IPsec. In älteren Oberflächen oder älteren Anleitungen findet man noch Pfade wie VPN > Sophos Connect Client. Bei bestehenden Screenshots und älteren Kundenumgebungen kann die Bezeichnung deshalb abweichen.

Vor der Konfiguration planen

Vor dem Einschalten sollte kurz dokumentiert werden, wie der Remote Access später betrieben wird. Das verhindert typische Fehler wie überlappende IP-Pools, zu breite Firewall-Regeln oder Profile, die nach einer Änderung nicht neu verteilt werden.

Wichtige Planungsfragen:

Für MFA-Grundlagen passt Sophos Firewall MFA einrichten. Wenn Remote Access später über Microsoft Entra ID SSO, RADIUS oder AD läuft, sollte zusätzlich die Authentifizierungsstrecke separat getestet werden.

Profiltypen und Bereitstellung

Vor der Konfiguration sollte klar sein, welche Datei später auf welchem Client landet. Das verhindert viele Supportfälle.

Für neue Sophos-Connect-IPsec-Rollouts ist .scx meist der bessere Standard, weil er die erweiterten Einstellungen aus der Firewall enthält. .tgb sollte nur bewusst verwendet werden, wenn ein Drittanbieter-Client oder ein alter Prozess dies benötigt.

Provisioning kann die Verteilung vereinfachen, erhöht aber die Abhängigkeit vom VPN Portal. Wenn Benutzer aus dem Internet die Provisioning-Datei nutzen sollen, muss das VPN Portal aus der benötigten Zone erreichbar sein. Das gehört unter Administration > Device access und Local Service ACL bewusst gehärtet, weil ein WAN-erreichbares Portal zusätzliche Angriffsfläche schafft. Für die Härtung passt Device Access und Local Service ACL auf Sophos Firewall.

Sophos Connect aktivieren

In der WebAdmin-Oberfläche den Bereich Remote access VPN > IPsec öffnen. In älteren Oberflächen kann der Pfad noch VPN > Sophos Connect Client heissen. Die genaue Darstellung kann je nach SFOS-Version leicht abweichen, die grundlegenden Entscheidungen bleiben aber ähnlich.

1. Connect Client aktivieren

IPsec Remote Access aktivieren. Danach erst die restlichen Einstellungen setzen und nicht sofort produktiv ausrollen.

2. Externe Schnittstelle wählen

Als Interface wird üblicherweise das WAN-Interface gewählt, über das Remote-Access-Verbindungen die Firewall erreichen. Bei mehreren WAN-Anschlüssen sollte bewusst entschieden werden, welcher Anschluss für VPN stabil, dokumentiert und aus dem Internet erreichbar ist.

Zu prüfen:

• öffentliche IP oder korrektes DynDNS/FQDN vorhanden
• Portfreigaben und vorgeschaltete Router passen
• WAN-Failover-Verhalten ist bekannt
• Device Access und lokale Service-ACLs erlauben nur benötigte Dienste
• VPN Portal ist nur dort erreichbar, wo es für Download oder Provisioning wirklich benötigt wird

Remote Access ist ein öffentlich erreichbarer Einstiegspunkt. Die reine Funktion ist deshalb nicht genug; Zugriff, MFA und Logging müssen mitgedacht werden.

Für die Härtung der erreichbaren Firewall-Dienste passt Device Access und Local Service ACL auf Sophos Firewall.

3. Authentifizierung wählen

Für IPsec Remote Access stehen je nach SFOS-Version und Konfiguration unterschiedliche Authentifizierungsmodelle zur Verfügung. Häufig sind Preshared Key und Zertifikat relevante Optionen.

Praktische Einordnung:

• Preshared Key ist schnell eingerichtet, muss aber stark, geschützt und bei Verdacht rotiert werden.
• Zertifikat ist sauberer für kontrollierte Umgebungen, braucht aber Zertifikatsmanagement und klare Prozesse.
• MFA ersetzt weder PSK noch Zertifikat, sondern schützt die Benutzeranmeldung zusätzlich.

Wenn der Preshared Key in mehreren Profilen verteilt wurde, ist ein Wechsel operativ aufwendiger. Deshalb sollte der Schlüssel nicht als Wegwerfwert behandelt werden.

Bei Zertifikaten sollte man zusätzlich prüfen, ob Zertifikatstyp, Laufzeit, private Schlüssel und Zielclient zusammenpassen. Für IPsec Remote Access sind insbesondere RSA-Zertifikate relevant. Zertifikatswechsel sind immer auch ein Profil- und Rollout-Thema.

4. Lokale und entfernte ID prüfen

Lokale und entfernte ID sind optional, können aber bei mehreren Tunneln oder speziellen Gegenstellen wichtig sein. Wenn sie gesetzt werden, müssen sie zum verwendeten Profil und zur Clientkonfiguration passen.

Typische Werte sind:

• DNS-Name
• IP-Adresse
• E-Mail
• Zertifikat

In einfachen Setups bleiben diese Felder oft leer. Wenn später Fehler wie no IKE config found oder Proposal-/ID-Probleme auftreten, gehört dieser Bereich aber in die Prüfung. Für eine tiefergehende Analyse ist Sophos Firewall IPsec VPN Troubleshooting der bessere Anschlussartikel.

5. Benutzer und Gruppen zuordnen

Nur die Benutzer oder Gruppen auswählen, die Remote Access wirklich benötigen. In produktiven Umgebungen ist eine dedizierte VPN-Gruppe meist besser als eine breite Standardgruppe.

Zu prüfen:

• Gruppe enthält nur berechtigte Benutzer.
• Ausgetretene Benutzer werden entfernt.
• MFA ist für diese Benutzer aktiv und getestet.
• Helpdesk weiss, wie Benutzer gesperrt, entsperrt oder neu provisioniert werden.

Guest users gehören nicht in Remote Access. Für produktive Umgebungen ist eine dedizierte VPN-Gruppe besser als eine breite Standardgruppe aus dem Verzeichnisdienst.

Clientdaten konfigurieren

6. Namen vergeben

Der Verbindungsname sollte für Benutzer und Support verständlich sein. Namen wie homeoffice, remote-access-ipsec oder ein Standortname sind hilfreicher als interne Abkürzungen.

Wenn mehrere Profile verteilt werden, sollte die Benennung konsistent bleiben. Das reduziert Verwechslungen im Sophos Connect Client.

7. IP-Pool festlegen

Die Firewall weist VPN-Clients eine Adresse aus dem definierten Pool zu. Dieser Bereich darf sich nicht mit internen Netzen, anderen VPN-Pools, Site-to-Site-Netzen oder typischen Heimnetzbereichen überschneiden.

Gute Praxis:

• separater Adressbereich nur für Remote Access
• ausreichende Grösse für gleichzeitige Benutzer
• keine Überschneidung mit 192.168.0.0/24, 192.168.1.0/24 oder häufigen Heimnetzbereichen, wenn vermeidbar
• eindeutige Dokumentation in IPAM oder Netzwerkdokumentation

Wenn der Pool später geändert wird, müssen Profile und Tests erneut geprüft werden.

Für IPsec Remote Access sollte der Pool mindestens sauber als eigenes Subnetz geplant werden. Zusätzlich darf er sich nicht mit anderen Remote-Access-Pools wie SSL VPN, L2TP oder PPTP überschneiden.

8. DNS-Server eintragen

Wenn Benutzer interne Systeme über Namen erreichen sollen, müssen passende DNS-Server und gegebenenfalls Suchdomains verteilt werden. In vielen Umgebungen ist das ein interner Domain Controller oder dedizierter DNS-Server.

Externe Resolver wie Cloudflare, Google, Quad9 oder OpenDNS lösen interne Zonen nicht auf. Solche Resolver sind nur sinnvoll, wenn über den VPN-Tunnel keine internen Namen benötigt werden oder DNS bewusst anders gelöst wird.

Beispiele für externe Resolver:

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

Für produktiven Remote Access ist meist wichtiger, dass interne FQDNs zuverlässig funktionieren. Wenn DNS nicht sauber geplant ist, wirkt der Tunnel für Benutzer “verbunden”, obwohl Anwendungen nicht nutzbar sind.

Erweiterte Einstellungen prüfen

9. Session Timeout setzen

Ein Session Timeout verhindert, dass nicht mehr genutzte VPN-Verbindungen unbegrenzt offen bleiben. Zu aggressive Werte können aber Supportfälle erzeugen, weil Benutzer bei kurzen Unterbrüchen neu verbinden müssen.

Sinnvoll ist ein Wert, der zum Arbeitsmodell passt:

• kurze Timeouts für sporadische Adminzugriffe
• längere Timeouts für stabile Arbeitssitzungen
• klare Kommunikation, wenn Benutzer nach Inaktivität neu verbinden müssen

Wenn OTP/MFA eingesetzt wird, sollte man auch die Auswirkung auf Reconnects testen.

Wenn die Firewall einen idle Client trennt, kann der Sophos Connect Client die Verbindung im Hintergrund neu aufbauen. Wenn das nicht gelingt, muss der Benutzer die Verbindung im Client bewusst trennen und erneut verbinden. Dieses Verhalten sollte im Helpdesk-Prozess bekannt sein.

10. Advanced settings bewusst setzen

Die erweiterten Einstellungen entscheiden, wie sich der Client im Alltag verhält. Bei IPsec Remote Access werden sie in die .scx-Datei übernommen, nicht in die .tgb-Datei.

Wichtige Punkte:

Bei Full Tunnel über Use as default gateway braucht es zusätzlich eine Firewall-Regel von VPN nach WAN und ein bewusstes NAT-/Security-Policy-Design. Bei Split Tunnel müssen die erlaubten internen Ressourcen sauber dokumentiert sein.

Wenn Prompt users for 2FA token aktiv ist, wird die Bedienung für Benutzer oft klarer. Gleichzeitig sollte man prüfen, ob eingesetzte Tools oder Automatisierungen mit dieser Einstellung funktionieren.

11. Speichern und Konfiguration exportieren

Nach dem Speichern wird die Verbindungskonfiguration exportiert. Je nach Client und SFOS-Version können .scx, .tgb oder Provisioning-Dateien relevant sein. Die Datei sollte nicht offen abgelegt oder an unberechtigte Personen weitergegeben werden.

Nach Änderungen an Benutzergruppe, Pool, DNS, Profil, Gateway, Port, Zertifikat oder Advanced Settings müssen die betroffenen Clients die aktualisierte Konfiguration erhalten. Alte Profile sind eine häufige Ursache für schwer nachvollziehbare VPN-Probleme.

Wenn Provisioning verwendet wird, muss zusätzlich geprüft werden, ob der Client die Änderungen automatisch nachlädt oder ob Benutzer im Sophos Connect Client die Policy aktualisieren beziehungsweise sich neu anmelden müssen. Änderungen an SSL-VPN-Port, Gateway, Serverzertifikat oder Protokoll sind typische Fälle, bei denen eine erneute Anmeldung oder ein bewusster Update-Schritt nötig sein kann.

Firewall-Regeln einrichten

Sophos Connect baut nur den Tunnel auf. Der Zugriff auf interne Systeme wird weiterhin über Firewall-Regeln gesteuert. Ohne passende Regeln kann die Verbindung grün sein, aber kein produktiver Zugriff funktionieren.

Für den Zugriff von VPN-Clients auf interne Systeme wird typischerweise eine Regel von VPN nach LAN oder in eine spezifische Zielzone erstellt.

• Source Zone: VPN
• Destination Zone: LAN

Besser als eine breite Freigabe auf das gesamte LAN ist meist eine Regel auf die tatsächlich benötigten Netze oder Dienste. Logging sollte für die Einführungsphase aktiviert werden, damit Fehler im Log Viewer sichtbar sind.

Wenn der Client als Full Tunnel arbeitet und Internetverkehr ebenfalls durch die Firewall laufen soll, braucht es zusätzlich eine Regel von VPN nach WAN und ein bewusstes NAT-/Security-Policy-Design.

• Source Zone: VPN
• Destination Zone: WAN

Für die Fehlersuche in Regeln ist Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture hilfreich.

Firewall-Regeln sollten nicht nur “funktionieren”, sondern prüfbar sein. Für die Einführungsphase ist Logging auf den Remote-Access-Regeln hilfreich. Später kann man entscheiden, welche Regeln dauerhaft geloggt werden und welche Ereignisse zusätzlich nach Sophos Central oder Syslog gehen sollen.

Nach dem Rollout testen

Ein grüner Sophos-Connect-Status reicht nicht als Abnahmetest. Mindestens diese Punkte sollten mit einem Testbenutzer geprüft werden:

• Client importiert die Konfiguration ohne Fehler.
• Anmeldung funktioniert mit Passwort und MFA.
• Client erhält eine Adresse aus dem erwarteten VPN-Pool.
• Interne DNS-Namen werden korrekt aufgelöst.
• Zentrale interne Systeme sind erreichbar.
• Log Viewer zeigt die erwartete Firewall-Regel.
• Split Tunnel oder Full Tunnel verhalten sich wie geplant.
• Reconnect nach Netzwerkwechsel funktioniert.
• Alte Profile wurden nicht weiterverwendet.
• Bei Full Tunnel funktioniert Internetzugriff über die Firewall wie geplant.
• Bei Split Tunnel bleiben nicht erlaubte Ziele blockiert.
• Log Viewer zeigt Treffer auf den erwarteten Regeln.
• Bei Provisioning werden Profiländerungen nachvollziehbar aktualisiert.

Danach können die Installationsanleitungen für Windows und macOS verwendet werden.

Betriebscheckliste

Nach dem technischen Rollout sollte der Betrieb nicht offen bleiben:

• Verantwortliche VPN-Gruppe dokumentiert.
• Austrittsprozess entfernt Benutzer aus Remote-Access-Gruppen.
• MFA-Reset-Prozess ist bekannt.
• Profilversion oder Änderungsdatum wird dokumentiert.
• Helpdesk weiss, welche Profile aktuell sind.
• Log Viewer und relevante Service-Logs sind bekannt.
• Änderungen an IP-Pool, DNS, Gateway, Zertifikat und Advanced Settings lösen eine Profilprüfung aus.
• Vor SFOS-Upgrades werden Legacy Remote Access IPsec und Clientprofile geprüft.

Troubleshooting

Verbindung wird aufgebaut, aber es fliesst kein Traffic

Dann liegt die Ursache häufig nicht beim Tunnel, sondern bei Firewall-Regeln, NAT, Routing, DNS oder dem Rückweg. Zuerst im Log Viewer prüfen, ob Traffic aus der VPN-Zone die erwartete Regel trifft. Danach mit Packet Capture oder Policy Test eingrenzen.

Benutzer kann sich nicht anmelden

Benutzergruppe, Authentifizierungsserver, MFA, gesperrter Benutzer und Passwortstatus prüfen. Wenn AD, RADIUS oder Microsoft Entra ID SSO beteiligt ist, sollte die Authentifizierung getrennt vom VPN getestet werden.

Client nutzt eine alte Konfiguration

Nach Änderungen an IP-Pool, DNS, Benutzergruppe, Profil, Gateway, Zertifikat oder Advanced Settings muss die Konfiguration neu verteilt oder neu importiert werden. Alte .tgb, .scx, .ovpn oder Provisioning-Dateien sollten nicht parallel im Umlauf bleiben.

Provisioning funktioniert nicht

Zuerst prüfen, ob das VPN Portal aus der benötigten Zone erreichbar ist und ob Device Access bewusst gesetzt wurde. Danach Gateway-Wert, Portal-Port, Zertifikat, Benutzeranmeldung, MFA und bei Entra SSO die Zuordnung unter Authentication > Services prüfen.

SSO funktioniert nur teilweise

Bei Microsoft Entra ID SSO müssen VPN Portal, IPsec und SSL VPN je nach Workflow zum richtigen Entra-ID-Server passen. Bei Provisioning muss der gateway-Wert zur Redirect URI der Entra-Konfiguration passen. Wenn nur einzelne Benutzer betroffen sind, zusätzlich UPN, E-Mail-Adresse, Gruppen-Mapping und importierte Benutzergruppen prüfen.

Verbindung steht, aber grosse Transfers hängen

Wenn Login, DNS und kleine Zugriffe funktionieren, grössere Dateiübertragungen oder bestimmte Anwendungen aber hängen, sollte MTU/MSS geprüft werden. Das Fehlerbild passt oft zu Fragmentierung, PPPoE, getunnelten Verbindungen oder einem asymmetrischen Pfad. Der Ablauf steht in Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

IPsec bricht in Fremdnetzen ab

IPsec kann in Hotels, Gast-WLANs, Mobilfunknetzen oder streng gefilterten Firmennetzen blockiert werden. In solchen Fällen sollte geprüft werden, ob SSL VPN Remote Access, ZTNA oder ein anderes Remote-Access-Design besser passt.

Full Tunnel hat keinen Internetzugriff

Wenn Use as default gateway aktiv ist, muss Traffic von VPN nach WAN erlaubt und passend per NAT behandelt werden. Zusätzlich sollten Web Protection, Application Control, DNS und Logging wie bei anderen Client-Netzen bewusst geplant werden.

FAQ