Sophos Firewall SSL VPN Remote Access einrichten

SSL VPN bleibt auf Sophos Firewall ein wichtiger Remote-Access-Weg, vor allem wenn Benutzer aus Hotels, Gast-WLANs, Mobilfunknetzen oder restriktiven Fremdnetzen arbeiten. Entscheidend ist aber nicht nur, ob der Tunnel aufgebaut wird. Entscheidend ist, ob die Firewall den Zugriff sauber begrenzt, ob DNS funktioniert, ob MFA greift und ob die Firewall-Regeln den Traffic aus der VPN-Zone kontrolliert erlauben.

Der Artikel beschreibt die firewallseitige Konfiguration von SSL VPN Remote Access auf Sophos Firewall. Für die Clientinstallation passen anschliessend Sophos SSL VPN mit Sophos Connect auf Windows einrichten, Sophos SSL VPN mit Sophos Connect auf macOS einrichten, Sophos SSL VPN auf iPhone und iPad einrichten und Sophos SSL VPN auf Android einrichten.

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 SSL-VPN-Artikel passt?

SSL VPN besteht aus Firewall-Konfiguration, Portal, Client, Authentifizierung und späterer Fehleranalyse. Je nach Aufgabe passt ein anderer Einstieg:

• SSL VPN auf der Firewall einrichten: Dieser Artikel.
• Sophos Connect oder SSL VPN grundsätzlich vergleichen: Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.
• Sophos Connect Clientversionen und Profile pflegen: Sophos Connect Client Version prüfen und sicher aktualisieren.
• SSL-VPN-Client auf Windows einrichten: Sophos SSL VPN mit Sophos Connect auf Windows einrichten.
• SSL VPN auf macOS, iOS oder Android einrichten: macOS, iPhone/iPad oder Android.
• Microsoft Entra ID SSO oder Entra-MFA nutzen: Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten.
• VPN ist verbunden, aber Traffic funktioniert nicht: Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.
• Grosse Transfers hängen oder einzelne Anwendungen laden nicht: Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Diese Trennung ist wichtig: Ein Benutzerproblem im VPN Portal, ein veraltetes .ovpn-Profil, eine fehlende Firewall-Regel und ein DNS-Problem sehen für den Benutzer oft gleich aus. Für die Analyse müssen diese Ebenen getrennt werden.

Zielbild

Ein sauberer SSL-VPN-Aufbau besteht aus mehreren Bausteinen:

1. Benutzer oder Gruppen sind in der richtigen SSL-VPN-Policy berechtigt.
2. Die globalen SSL-VPN-Einstellungen definieren Gateway, Port, Zertifikat, Lease-Bereich, DNS und Kryptografie.
3. Das VPN Portal ist nur so breit erreichbar wie nötig und mit MFA geschützt.
4. Firewall-Regeln erlauben Traffic aus der VPN-Zone nur zu den benötigten Zielen.
5. Split Tunnel oder Full Tunnel ist bewusst entschieden.
6. Clients importieren ein aktuelles .ovpn-Profil.
7. Logs, Packet Capture und Supportdaten können im Fehlerfall ausgewertet werden.

Viele SSL-VPN-Probleme entstehen, weil nur der Clientdownload dokumentiert wird. In der Praxis muss man aber Portal, Authentifizierung, SSL-VPN-Policy, Firewall-Regel, DNS und NAT zusammen betrachten.

⚠️ SSL VPN ist ein öffentlich erreichbarer Einstiegspunkt. MFA und starke Passwörter sind wichtig, ersetzen aber keine Begrenzung über Device access, enge Benutzergruppen, aktuelle Profile, Logging und regelmässige Reviews.

⚠️ Änderungen an Gateway, Port, Zertifikat, DNS, Lease-Bereich oder Policy landen nicht automatisch in bereits importierten Clientprofilen. Nach relevanten Änderungen muss die .ovpn-Datei neu heruntergeladen, verteilt und auf den Clients ersetzt werden.

Voraussetzungen

Vor der Konfiguration sollten diese Punkte geklärt sein:

• Sophos Firewall mit aktueller SFOS-Version.
• Öffentliche Erreichbarkeit der Firewall oder ein vorgeschaltetes Port Forwarding.
• FQDN oder öffentliche IP-Adresse für den VPN-Zugang.
• Zertifikat für VPN Portal und SSL VPN, idealerweise passend zum FQDN.
• Benutzer oder Gruppen für Remote Access.
• Authentifizierungsserver für VPN Portal und SSL VPN: lokal, Active Directory, RADIUS oder Microsoft Entra ID.
• MFA/OTP-Konzept für VPN Portal und Remote Access.
• Interne Zielnetze, DNS-Server und Suchdomain.
• Entscheidung für Split Tunnel oder Full Tunnel.
• Firewall-Regeln für Traffic aus der VPN-Zone.
• Prozess für Clientupdate und Neuverteilung der .ovpn-Datei.

Wenn Microsoft Entra ID SSO verwendet werden soll, muss die Authentifizierung vor dem Download der VPN-Konfiguration korrekt vorbereitet sein. Der Ablauf steht in Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten.

1. Lokale Objekte vorbereiten

Zuerst sollten die Zielnetze als Hosts oder Netzwerkobjekte existieren:

Hosts and services > IP host

Typische Objekte:

• LAN_Server: 10.10.10.0/24 für interne Server.
• LAN_Client: 10.10.20.0/24 für ein Clientnetz, falls es wirklich benötigt wird.
• DNS_Internal: 10.10.10.10 für internen DNS oder Domain Controller.
• SSLVPN_Users: Benutzergruppe für die Policy members.

Man sollte nicht einfach komplette interne Netzbereiche freigeben, wenn nur einzelne Server oder Subnetze nötig sind. Je enger die Objekte definiert sind, desto einfacher wird später die Firewall-Regel.

Wenn DNS-Server im Tunnel genutzt werden, sollten sie nicht nur in den globalen SSL-VPN-Einstellungen stehen, sondern auch als Zielobjekte existieren. Besonders bei Full Tunnel oder streng begrenzten Ressourcen ist sonst der Tunnel verbunden, aber Namensauflösung bleibt kaputt.

2. Globale SSL-VPN-Einstellungen prüfen

Die globalen Einstellungen gelten für alle Remote-Access-SSL-VPN-Policies:

Remote access VPN > SSL VPN > SSL VPN global settings

Protokoll und Port

SSL VPN kann je nach Konfiguration TCP oder UDP verwenden. UDP ist häufig effizienter, TCP kann in restriktiven Netzen besser funktionieren. Die Entscheidung sollte mit den Netzen getestet werden, aus denen Benutzer tatsächlich arbeiten.

Beim Port muss man Überschneidungen vermeiden:

• SSL VPN Standardport ist häufig 8443.
• VPN Portal verwendet in aktuellen SFOS-Versionen standardmässig 443.
• WAF-Regeln und SSL VPN dürfen sich auf derselben WAN-IP nicht mit gleichem Port und gleichem Protokoll überschneiden.
• Wenn SSL VPN und VPN Portal denselben Port verwenden, können Login-Security-Funktionen nicht wie erwartet greifen.

Wenn WAF, VPN Portal, User Portal und SSL VPN auf derselben WAN-IP betrieben werden, sollte man Port, Protokoll und Zertifikat bewusst dokumentieren. Für WAF-Grundlagen passt Sophos Firewall WAF einrichten und typische Fehler vermeiden.

Zertifikat und Override Hostname

Unter SSL server certificate sollte ein Zertifikat verwendet werden, das zum öffentlichen FQDN passt. Ein Zertifikatsfehler im VPN Portal oder im SSL-VPN-Profil führt später zu unnötigen Supportfällen.

Unter Override hostname legt man fest, welchen Hostnamen oder welche IP-Adresse Clients im .ovpn-Profil verwenden. Das ist besonders wichtig bei:

• mehreren WAN-IP-Adressen,
• vorgeschaltetem Router,
• NAT oder Port Forwarding vor der Firewall,
• dynamischer WAN-IP mit DDNS,
• getrennten FQDNs für WebAdmin, VPN Portal und SSL VPN.

Wenn das Feld leer bleibt, können mehrere Interface-Adressen im Profil landen. Das kann funktionieren, ist aber in produktiven Umgebungen oft weniger eindeutig als ein sauberer FQDN. Sophos Connect versucht die Gateways aus der .ovpn-Datei nicht einfach in der sichtbaren Reihenfolge; dynamische DNS-Gateways und die Reihenfolge mehrerer Einträge können deshalb in der Praxis anders wirken als erwartet. Für produktive Setups ist ein eindeutiger Override Hostname einfacher zu testen und zu supporten.

Nach einer Änderung am Override Hostname muss man ein neues Profil herunterladen und prüfen, ob im Client wirklich der neue FQDN oder die neue öffentliche IP-Adresse steht. Sonst testet man unter Umständen die alte Verbindung, obwohl die Firewallkonfiguration bereits korrekt ist.

Lease-Bereich

Sophos Firewall vergibt SSL-VPN-Clients Adressen aus dem konfigurierten Lease-Bereich. Dieser Bereich darf nicht mit internen Netzen, statischen Routen, Site-to-Site-VPNs, anderen Remote-Access-Pools oder typischen Heimnetz-Bereichen kollidieren.

Vermeiden sollte man besonders häufige Subnetze wie:

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 10.0.0.0/24
• 10.0.1.0/24

Wenn der Lease-Bereich mit dem Heimnetz eines Benutzers kollidiert, verbindet sich der Tunnel manchmal erfolgreich, aber interne Ziele bleiben unerreichbar. Das wirkt dann wie ein Firewall-Regelproblem, ist aber ein Routingproblem am Endpoint.

Für IPv4 akzeptiert Sophos Firewall in den globalen SSL-VPN-Einstellungen nur Subnetze bis /24. Kleinere Netze wie /25 sind dort nicht auswählbar. Wenn nur wenige Benutzer erwartet werden, sollte man trotzdem ein sauberes, nicht kollidierendes VPN-Netz planen und den Zugriff über Firewall-Regeln begrenzen, nicht über einen künstlich kleinen Lease-Bereich.

Für Firewall-Regeln sollte man die Systemhosts ##ALL_SSLVPN_RW und bei IPv6 ##ALL_SSLVPN_RW6 verwenden, nicht manuell nachgebaute Hosts mit alten Lease-Bereichen.

Statische SSL-VPN-IP-Adressen und Key Lifetime

Statische SSL-VPN-IP-Adressen können in Einzelfällen sinnvoll sein, zum Beispiel für Adminzugänge, streng geloggte Sonderzugriffe oder Legacy-Anwendungen mit IP-basierter Freigabe. Als Standard für alle Benutzer sind sie aber nicht geeignet. Je mehr statische Zuordnungen existieren, desto schwieriger werden Betrieb, Fehleranalyse und spätere Migrationen.

Zusätzlich unterstützt Sophos Firewall bei Benutzern mit statisch zugewiesener SSL-VPN-IP-Adresse keine gleichzeitigen Remote-Access-Anmeldungen. Das ist wichtig bei geteilten Konten, parallelen Geräten oder Testfällen, in denen ein Benutzer auf Notebook und Zweitgerät gleichzeitig verbunden sein soll. Solche Designs sollten nicht über statische IPs gelöst werden.

In der Known-Issues-Liste ist ein konkreter Sonderfall dokumentiert: Bei SSL VPN mit lokaler Authentifizierung und statisch zugewiesener SSL-VPN-IP kann die erneute Authentifizierung nach Ablauf der Key Lifetime fehlschlagen. Die Firewall kann die bereits vergebene Lease-Adresse als Konflikt behandeln. Benutzer müssen sich dann manuell neu verbinden, obwohl der Tunnel vorher funktioniert hat. Ein typischer Key-Lifetime-Wert ist 18000 Sekunden.

Wenn ein Benutzer nach mehreren Stunden wiederholt neu anmelden muss, sollte man deshalb nicht nur MFA, Clientversion und Firewall-Regel prüfen. Zusätzlich gehören diese Punkte in die Analyse:

• Wird lokale Authentifizierung für SSL VPN verwendet?
• Hat der Benutzer eine statische SSL-VPN-IP-Adresse?
• Tritt das Problem ungefähr nach Ablauf der Key Lifetime auf?
• Funktioniert derselbe Benutzer mit dynamischer IP-Zuweisung stabiler?
• Ist eine statische IP wirklich nötig oder reicht eine Regel über Benutzergruppe, SSL-VPN-Systemhost und Logging?

Als pragmatische Gegenmassnahmen nennt Sophos zwei Richtungen: Key Lifetime so planen, dass sie den normalen Arbeitstag abdeckt, oder dynamische IP-Zuweisung verwenden. In vielen Umgebungen ist dynamische Zuweisung sauberer, weil Firewall-Regeln ohnehin über VPN-Zone, Benutzergruppe, Zielobjekte und die SSL-VPN-Systemhosts kontrolliert werden sollten.

DNS und Domain Name

Für interne Namensauflösung werden in den globalen SSL-VPN-Einstellungen DNS-Server und optional ein Domain Name gesetzt. In Active-Directory-Umgebungen ist das meistens ein interner DNS-Server oder Domain Controller.

Zusätzlich muss unter Administration > Device access DNS aus der VPN-Zone erlaubt sein, wenn die Firewall selbst als DNS-Resolver im VPN-Design verwendet wird.

Wenn ein interner DNS-Server direkt erreicht werden soll, braucht der VPN-Benutzer auch Zugriff auf diesen DNS-Server. Das heisst: Der DNS-Server gehört in die erlaubten Ressourcen oder wird über eine passende Firewall-Regel aus der VPN-Zone erlaubt. Bei Full Tunnel sollte man DNS nicht als Nebeneffekt der Internetregel behandeln, sondern bewusst testen.

Wenn DNS im Tunnel nicht funktioniert, sollte man getrennt testen:

• Ist das Ziel per IP-Adresse erreichbar?
• Wird der interne DNS-Server durch die Firewall-Regel erlaubt?
• Erhält der Client die richtige Suchdomain?
• Nutzt der Client wirklich das aktuelle .ovpn-Profil?
• Greift lokale DNS- oder DoH-Konfiguration des Endpoints dazwischen?

Bei Split Tunnel sollte DNS besonders bewusst geplant werden. Wenn nur interne Zielnetze durch den Tunnel geroutet werden, muss klar sein, ob interne Namen über den internen DNS-Server aufgelöst werden und ob öffentliche Namen lokal oder über die Firewall laufen. Sonst entstehen Fehlerbilder, bei denen IP-Zugriff funktioniert, interne Hostnamen aber nur auf einzelnen Clients auflösen.

3. SSL-VPN-Policy erstellen

Die Policy erstellt man unter:

Remote access VPN > SSL VPN

Sophos bietet dafür den SSL-VPN-Assistenten oder die manuelle Konfiguration. Der Assistent kann Policy, VPN Portal, Authentifizierungsserver, Firewall-Regel und Device Access in einem Ablauf anlegen. Das ist für neue Setups hilfreich. In bestehenden Umgebungen ist Configure manually oft besser, weil Regelposition, Zielobjekte, Logging und Portalzugriff bewusst geprüft werden können.

Ablauf für die manuelle Konfiguration:

1. Add auswählen.
2. Configure manually verwenden.
3. Namen vergeben, zum Beispiel SSLVPN-Remote-Users.
4. Unter Policy members die berechtigten Benutzer oder Gruppen auswählen.
5. Split Tunnel oder Full Tunnel festlegen.
6. Bei Split Tunnel die Permitted network resources auswählen; bei Full Tunnel die späteren Zielobjekte vor allem für Firewall-Regeln vorbereiten.
7. Optional Disconnect idle clients konfigurieren.
8. Speichern und anschliessend mit einem Testbenutzer prüfen.

Die Permitted network resources begrenzen bei Split Tunnel die internen Ziele, die Remote-Benutzer erreichen sollen. Bei Use as default gateway ist dieser Punkt anders: Sophos Firewall erzwingt die Permitted Resources dann nicht als Zugriffslimit. Der gesamte Traffic läuft durch die Firewall, und die eigentliche Begrenzung muss über Firewall-Regeln, Zonen, Zielobjekte, Services und Logging passieren.

Für Full Tunnel sollte man interne Zielnetze trotzdem sauber als Objekte modellieren, aber nicht darauf vertrauen, dass die SSL-VPN-Policy allein sie begrenzt. Interfaces sind dafür kein guter Ersatz, weil ein Interface nicht automatisch beschreibt, welche Subnetze dahinter fachlich erlaubt sind.

Wenn FQDN-Objekte bei Split Tunnel als erlaubte Ressourcen verwendet werden, muss man den Betrieb bewusst planen. Die SSL-VPN-Logs zeigen die aufgelösten IP-Adressen, und dynamische FQDN-Änderungen landen nicht automatisch in bereits bestehenden Tunneln. Betroffene Benutzer müssen trennen und neu verbinden, damit geänderte Zieladressen wirksam werden.

Wichtig: Wenn Benutzer oder Gruppen in einer neueren SSL-VPN-Policy eingetragen werden, die bereits in einer älteren SSL-VPN-Policy enthalten sind, entfernt Sophos Firewall diese Zuordnung aus der früheren Policy. Deshalb sollte man Policy-Überschneidungen vermeiden und pro Benutzergruppe klar definieren, welche Policy gilt.

Nach Policy-Änderungen sollte ein normaler Benutzer aus der Zielgruppe im VPN Portal geprüft werden. Sichtbar sein sollte genau die erwartete SSL-VPN-Konfiguration, nicht mehrere alte Profile und nicht gar keine Konfiguration. Dieser Portaltest deckt Gruppenfehler schneller auf als ein reiner Admin-Test mit Sonderrechten.

4. Split Tunnel oder Full Tunnel entscheiden

Split Tunnel

Bei Split Tunnel läuft nur Traffic zu den erlaubten internen Ressourcen durch den VPN-Tunnel. Internettraffic des Benutzers geht weiter direkt über das lokale Netz des Benutzers.

Split Tunnel passt oft für:

• Zugriff auf wenige interne Anwendungen,
• geringere Firewall-Last,
• bessere Benutzerperformance,
• kleinere Aussenstandorte und mobile Benutzer.

Die Sicherheit hängt dann stärker vom Endpoint, der lokalen Netzumgebung und den freigegebenen internen Ressourcen ab.

Full Tunnel

Bei Full Tunnel wird der gesamte Traffic des Remote-Benutzers über die Firewall geleitet. In Sophos Firewall entspricht das der Option Use as default gateway.

Full Tunnel passt eher, wenn:

• Internettraffic zentral kontrolliert werden soll,
• Web Protection, DNS Protection oder Logging für VPN-Benutzer greifen sollen,
• Benutzer aus unsicheren Netzen arbeiten,
• Compliance zentrale Auswertung verlangt.

Bei Full Tunnel reicht die SSL-VPN-Policy allein nicht. Man braucht zusätzlich Firewall-Regeln und NAT/SNAT für Internettraffic aus der VPN-Zone. Ausserdem sollte man Performance, Bandbreite, Webfilterung und Logging vorher testen.

Full Tunnel sollte nicht nur aktiviert werden, weil einzelne Split-Tunnel-Ziele schwer zu pflegen sind. Wenn der gesamte Internettraffic über die Firewall läuft, werden Kapazität, Webfilterung, DNS, Logging, Datenschutz und Supportaufwand Teil des Designs.

Auch bei Full Tunnel sollten interne Zielnetze und DNS-Server sauber als Firewall-Ziele modelliert werden. Sonst funktioniert zwar der Default-Gateway-Pfad, aber interne Anwendungen oder Namensauflösung hängen an einer zu breiten Internetregel.

5. Firewall-Regeln für VPN-Zone erstellen

Der Tunnelaufbau bedeutet noch nicht, dass Traffic erlaubt ist. Für den Zugriff auf interne Ressourcen braucht man eine passende Firewall-Regel:

Rules and policies > Firewall rules

Empfohlene Regel für Split Tunnel:

• Rule name: VPN_SSLVPN_to_Internal_Servers
• Source zone: VPN
• Source networks and devices: ##ALL_SSLVPN_RW
• Destination zones: interne Zielzonen, zum Beispiel LAN oder DMZ
• Destination networks: nur erlaubte Server oder Subnetze
• Services: nur benötigte Dienste
• Log firewall traffic: aktivieren

Für Full Tunnel braucht es zusätzlich eine Regel von VPN nach WAN oder Any, je nach Design. Die Source Networks sollten weiterhin die SSL-VPN-Systemhosts sein. Danach muss geprüft werden, ob eine passende SNAT-Regel existiert.

Wenn eine Verbindung steht, aber kein Zugriff funktioniert, sollte man zuerst den Log Viewer prüfen. Für die Methodik passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Regeln für SSL VPN sollten in einer klar benannten Gruppe liegen, zum Beispiel VPN Remote Access. Eine breite Regel wie VPN_to_LAN_Any ist zwar bequem, macht spätere Fehleranalyse aber schwierig und erlaubt oft mehr Zugriff als fachlich nötig. Besser sind getrennte Regeln pro Zielbereich oder Dienstklasse mit aktivem Logging.

6. VPN Portal und Device Access absichern

Benutzer laden Sophos Connect und die .ovpn-Datei typischerweise über das VPN Portal:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

Mindestens prüfen:

• VPN Portal Port und Zertifikat.
• VPN Portal Authentication Methods.
• SSL VPN Authentication Methods.
• MFA für VPN Portal und Remote Access.
• Device Access für VPN Portal nur in benötigten Zonen.
• Device Access für SSL VPN auf der WAN-Zone nur, wenn extern nötig.
• Kein dauerhaft offenes User Portal auf WAN, wenn es nicht gebraucht wird.

Zur Härtung lokaler Firewall-Dienste passt Device Access und Local Service ACL auf Sophos Firewall. Für MFA-Grundlagen passt MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Das VPN Portal erscheint für Benutzer nur dann sinnvoll, wenn sie oder ihre Gruppen in einer passenden Remote-Access-Policy enthalten sind. Fehlt die Policy-Zuordnung, sieht der Benutzer die benötigten Konfigurationsdownloads nicht.

Unter Authentication > Services sollten VPN Portal und SSL VPN getrennt geprüft werden. Das VPN Portal steuert die Anmeldung für Download und Profilzugriff, SSL VPN authentication methods steuert die eigentliche Tunnelanmeldung. Beide Bereiche können denselben Server verwenden, müssen aber nicht automatisch korrekt zueinander passen. Bei RADIUS ist zusätzlich wichtig: Challenge-basierte MFA für das VPN Portal wird nicht unterstützt; solche Designs sollten vor dem Rollout mit einem echten Testbenutzer geprüft werden.

Wenn VPN Portal oder SSL VPN auf der WAN-Zone erlaubt werden müssen, sollte das bewusst dokumentiert sein. In vielen Umgebungen reicht es nicht, den Dienst weltweit zu öffnen und sich auf MFA zu verlassen. Wo möglich, sollten feste Quellnetze, Länderbegrenzung, Threat Feeds, Logprüfung oder ein vorgelagertes Remote-Access-Design geprüft werden.

Wichtig ist die Trennung zwischen WebAdmin und VPN Portal. WebAdmin ist die Administrationsoberfläche der Firewall. Das VPN Portal ist der Benutzerzugang für Downloads und VPN-Profile. Beide Dienste sollten nicht gedanklich zusammengefasst werden, weil sie unterschiedliche Risiken, Ports, Berechtigungen und Zielgruppen haben.

7. Clientprofil verteilen

Nach der Policy- und Portal-Konfiguration wird die .ovpn-Datei verteilt. Das kann über das VPN Portal oder kontrolliert durch den Adminprozess passieren.

Wichtig:

• Nach Änderungen an Gateway, Port, Zertifikat, DNS, Lease-Bereich, Policy oder Authentifizierung muss das Profil neu geladen werden.
• Ein Sophos-Connect-Update ersetzt kein altes .ovpn-Profil.
• Profilnamen sollten eindeutig sein.
• Alte Profile sollten bei Standortwechsel, Gatewaywechsel oder Benutzerwechsel entfernt werden.
• Windows, macOS, iOS, Android und Linux verwenden teilweise unterschiedliche Clientpfade.
• Sophos-Connect-Provisioning-Dateien (.pro) können IPsec- und SSL-VPN-Konfigurationen automatisch importieren, sind aber ein Sophos-Connect-Betriebsmodell und kein Ersatz für eine saubere SSL-VPN-Policy.

Für Sophos Connect sollte man die Plattformgrenzen aktiv prüfen: Aktuelle Clients unterstützen Windows 10 und 11, macOS 13 oder neuer, und Windows ARM ab Sophos Connect 2.5. Microsoft Entra ID SSO im Sophos Connect Client ist ein Windows-Szenario mit Sophos Connect 2.4 oder neuer. Mobile Plattformen wie iOS und Android verwenden nicht Sophos Connect für SSL VPN, sondern OpenVPN-kompatible Apps oder andere Clientpfade.

Typische Profiländerungen im Betrieb:

• Neuer FQDN oder neue öffentliche IP: .ovpn neu herunterladen und altes Profil ersetzen.
• Port oder Protokoll geändert: Profil neu importieren und alten Verbindungseintrag entfernen.
• Zertifikat erneuert oder gewechselt: Profil neu verteilen und Zertifikatswarnungen aktiv prüfen.
• DNS-Server oder Domain Name geändert: Neues Profil importieren und Namensauflösung testen.
• Lease-Bereich geändert: Profil neu importieren und Route beziehungsweise Clientadresse prüfen.
• Benutzergruppe oder Policy gewechselt: Portaldownload mit normalem Zielbenutzer testen.

Für Clientupdates und Versionspflege passt Sophos Connect Client Version prüfen und sicher aktualisieren.

Bei Sophos Connect lädt eine Provisioning-Datei die .ovpn-Konfiguration nur für Benutzer, die einer SSL-VPN-Policy zugeordnet sind. Wenn ein Benutzer per .pro-Datei nur IPsec oder gar keine SSL-VPN-Verbindung erhält, ist deshalb nicht automatisch die Provisioning-Datei kaputt. Zuerst Policy members, VPN-Portal-Erreichbarkeit, Authentifizierungsmethoden und Benutzergruppe prüfen.

Nach der Konfiguration testen

Mit einem Testbenutzer sollte man nicht nur prüfen, ob Sophos Connect Connected anzeigt.

Testliste:

• Benutzer sieht im VPN Portal den Sophos Connect Download und die SSL-VPN-Konfiguration.
• .ovpn-Datei lässt sich importieren.
• MFA wird wie erwartet abgefragt.
• Client erhält eine Adresse aus dem SSL-VPN-Lease-Bereich.
• Route zu den erlaubten internen Netzen erscheint am Endpoint.
• Bei Full Tunnel ist klar, dass interne Zugriffe durch Firewall-Regeln begrenzt werden, nicht durch Permitted Resources allein.
• Bei FQDN-Ressourcen funktioniert ein Reconnect-Test nach DNS-Änderung.
• Interne DNS-Namen werden aufgelöst.
• Zugriff auf erlaubte Server funktioniert.
• Nicht erlaubte Netze bleiben blockiert.
• Log Viewer zeigt die richtige Firewall-Regel.
• Ein bewusster Negativtest wird abgelehnt und geloggt.
• Packet Capture zeigt Traffic über ein tun-Interface, wenn nötig.
• Bei Full Tunnel funktioniert auch Internetzugriff und SNAT.

Wenn der Test nur mit einem Adminbenutzer gemacht wird, übersieht man leicht Gruppen- und Policyfehler. Besser ist ein normaler Pilotbenutzer aus der Zielgruppe.

Ein guter Abnahmetest enthält immer auch einen blockierten Zugriff. Nur so sieht man, ob die Firewall-Regeln wirklich begrenzen oder ob eine zu breite Regel weiter unten im Regelwerk den Zugriff trotzdem erlaubt.

Abnahmetest nach Szenario

Vor einem breiten Rollout sollte man mindestens diese Testfälle sauber dokumentieren:

• Neuer Benutzer: Anmeldung am VPN Portal und Profilimport testen. Der Benutzer sollte nur die passende SSL-VPN-Konfiguration sehen und das Profil importieren können.
• MFA aktiv: Login mit richtigem und falschem OTP testen. Der richtige Faktor erlaubt Zugriff, der falsche Faktor wird abgelehnt und geloggt.
• Split Tunnel: Zugriff auf erlaubtes und nicht erlaubtes internes Ziel testen. Erlaubte Ziele funktionieren, andere Netze bleiben blockiert.
• Full Tunnel: Internetzugriff über VPN testen. Firewall-Regel, SNAT, DNS und Web-/Security-Policy greifen wie geplant.
• DNS: Zugriff per Name und per IP-Adresse testen. So lassen sich DNS-Fehler von Routing- oder Regelproblemen trennen.
• Profiländerung: Neues .ovpn-Profil importieren. Geänderter FQDN, Port, DNS oder Zertifikat sollte im Clientprofil sichtbar sein.
• Fehlerfall: Log Viewer und Packet Capture prüfen. Die tatsächlich matchende Firewall-Regel und der Paketfluss sollten nachvollziehbar sein.

Für produktive Umgebungen sollte jeder Test eine Uhrzeit, einen Benutzer, eine Clientplattform und ein konkretes Ziel enthalten. Aussagen wie “VPN funktioniert” oder “VPN geht nicht” sind für spätere Supportfälle zu ungenau.

Logs und Nachweise sammeln

Bei SSL-VPN-Problemen sollte man zuerst klären, ob der Fehler beim Login, beim Tunnelaufbau oder beim Zugriff auf interne Ziele liegt. Diese Trennung spart Zeit, weil sonst Authentifizierung, Clientprofil, Routing und Firewall-Regeln durcheinander geprüft werden.

Für einen reproduzierbaren Testfall sollten diese Angaben notiert werden:

• Benutzername und Gruppe: zeigt, welche SSL-VPN-Policy und Authentifizierung greifen sollten.
• Clientplattform und Sophos-Connect-Version: trennt Clientfehler von Firewallkonfiguration.
• Uhrzeit des Tests: macht Log Viewer, sslvpn.log und Authentifizierungslogs vergleichbar.
• Quellnetz des Benutzers: hilft bei Hotel-WLAN, Mobilfunk, CGNAT, restriktiven Firewalls oder Portproblemen.
• Zielsystem und Dienst: verhindert zu breite Aussagen wie “VPN geht nicht”.
• Ergebnis per IP-Adresse und per DNS-Name: trennt Routing- und DNS-Probleme.

Danach sollte man die Prüfung in dieser Reihenfolge durchführen:

1. Authentifizierung prüfen: Im Log Viewer und bei Bedarf in den Authentifizierungslogs prüfen, ob Benutzer, MFA, Gruppe und Authentifizierungsserver erfolgreich sind. Bei Microsoft Entra ID SSO ist zusätzlich oauth_sso_vpn.log relevant.
2. Tunnelstatus prüfen: SSL-VPN-Verbindung, Lease-Adresse und OpenVPN-Status prüfen. Auf der Firewallseite helfen sslvpn.log und openvpn-status*.log.
3. Firewall-Regel prüfen: Im Log Viewer nach Traffic aus der VPN-Zone suchen und kontrollieren, welche Regel wirklich matcht. Die Regel sollte Log firewall traffic aktiv haben.
4. Paketfluss prüfen: Wenn der Log Viewer nicht reicht, mit Packet Capture auf Quelle, Ziel und Dienst filtern. Wichtig ist, ob Pakete nur Incoming sind oder auch Forwarded werden.
5. Zielseite prüfen: Wenn Traffic die Firewall verlässt, aber keine Antwort zurückkommt, sind Rückroute, Server-Firewall, lokale Host-Firewall oder ein Netzkonflikt wahrscheinlicher als die SSL-VPN-Policy.

Für die Zuordnung der wichtigsten Logdateien passt Sophos Firewall Troubleshooting: Services und Logs. Für Regelanalyse mit Log Viewer, Policy Test und Packet Capture passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Troubleshooting

Benutzer sieht keine SSL-VPN-Konfiguration im VPN Portal

Meist fehlt die Policy-Zuordnung. Man prüft, ob der Benutzer oder seine Gruppe in der SSL-VPN-Policy unter Policy members enthalten ist. Zusätzlich sollten Authentifizierung, MFA und VPN-Portal-Erreichbarkeit geprüft werden.

Wenn Anmeldung und Policy-Zuordnung korrekt wirken, der Download der .ovpn-Datei aber trotzdem fehlt oder fehlschlägt, sollte auch das Sophos Firewall User-ID-Limit geprüft werden. Das ist besonders relevant, wenn mehrere Benutzer das Portal nutzen, aber nur einzelne Downloads unerwartet scheitern.

Tunnel verbindet, aber interne Systeme sind nicht erreichbar

Zuerst prüfen, ob am Endpoint eine Route zum internen Zielnetz existiert. Danach im Log Viewer nach Traffic aus der VPN-Zone suchen. Wenn kein Traffic sichtbar ist, erreicht der Client die Firewall nicht wie erwartet oder das Profil ist veraltet.

Wenn Traffic sichtbar ist, aber die falsche Regel greift, muss die Regelreihenfolge oder die Service-/Zieldefinition korrigiert werden. Wenn gar keine Rückantwort kommt, sind Routing, Ziel-Firewall, lokale Server-Firewall oder ein Netzkonflikt wahrscheinlich.

Nach einer Änderung funktioniert nur ein Teil der Clients

Wenn neue Benutzer funktionieren, alte Clients aber nicht, ist meist die Profilverteilung das Problem. Man prüft, ob betroffene Clients wirklich das aktuelle .ovpn-Profil importiert haben und ob alte Verbindungseinträge entfernt wurden.

Besonders nach Änderungen an FQDN, Port, Zertifikat, DNS, Lease-Bereich, Policy oder Authentifizierung sollte man nicht nur die Firewall speichern, sondern aktiv einen Profildownload mit einem normalen Benutzer testen. Danach lässt sich am Endpoint prüfen, ob Gateway, DNS und Routen dem aktuellen Design entsprechen.

DNS funktioniert nicht

Man prüft, ob der Zugriff per IP-Adresse funktioniert. Wenn ja, liegt der Fehler wahrscheinlich bei DNS. Danach DNS-Server in den globalen SSL-VPN-Einstellungen, Domain Name, Device Access für DNS aus der VPN-Zone und Endpoint-DNS-Verhalten prüfen.

Wenn der interne DNS-Server selbst als erlaubte Ressource fehlt oder durch keine Firewall-Regel aus der VPN-Zone erreichbar ist, hilft auch ein korrektes .ovpn-Profil nicht. Deshalb sollte DNS immer mit einem konkreten DNS-Server, einem konkreten internen Namen und einem Log-Viewer-Filter auf den DNS-Dienst getestet werden.

Zugriff funktioniert nur bei manchen Benutzern

Dann sind Gruppenmitgliedschaft, Policy-Zuordnung, statische SSL-VPN-IP-Adressen, MFA-Status oder veraltete Profile wahrscheinlicher als ein globaler Firewallfehler. Auch doppelte Policy-Zuordnungen sollte man prüfen.

Wenn ein Benutzer mehrere Geräte parallel verwendet oder ein gemeinsames Konto genutzt wird, statische SSL-VPN-IP-Adressen besonders kritisch prüfen. Sophos unterstützt bei statisch zugewiesener SSL-VPN-IP keine gleichzeitigen Remote-Access-Anmeldungen für denselben Benutzer.

Benutzer muss sich nach mehreren Stunden erneut verbinden

Wenn SSL VPN zunächst funktioniert, aber nach mehreren Stunden eine erneute Anmeldung oder ein manueller Neuaufbau nötig wird, sollte man zuerst Zeitmuster, Authentifizierung und Lease-Modell prüfen. Besonders relevant ist das bei lokaler Authentifizierung mit statisch zugewiesener SSL-VPN-IP.

Praktischer Ablauf:

1. Uhrzeit des Verbindungsaufbaus und des Abbruchs notieren.
2. Zeitpunkt mit der konfigurierten Key Lifetime vergleichen.
3. Kontrollieren, ob der Benutzer eine statische SSL-VPN-IP-Adresse hat.
4. Testweise dynamische IP-Zuweisung für einen Pilotbenutzer prüfen, falls betrieblich möglich.
5. In sslvpn.log, openvpn-status*.log und Log Viewer nach Authentifizierung, Lease-Adresse und erneuter Anmeldung suchen.
6. Falls eine längere Key Lifetime gewählt wird, Änderung dokumentieren und nicht als Ersatz für MFA oder saubere Session-Kontrolle verstehen.

Wenn statische IPs nur verwendet werden, damit Firewall-Regeln einfacher aussehen, sollte das Design überarbeitet werden. Meist sind Gruppen, klar benannte Zielobjekte, enge Dienste und Logging die bessere Grundlage als einzelne Benutzer-IP-Adressen.

Full Tunnel hat keinen Internetzugriff

Bei Use as default gateway braucht es eine Firewall-Regel für Traffic aus der VPN-Zone Richtung Internet und eine passende SNAT-Regel. Ausserdem müssen Web-, DNS- und Security-Policies so geplant sein, dass sie VPN-Benutzer nicht unerwartet blockieren.

Verbindung steht, aber grosse Transfers hängen

Wenn Login, DNS und kleine Zugriffe funktionieren, aber RDP, Dateitransfers, Webanwendungen oder grosse Downloads hängen, sollte man MTU und MSS prüfen. Das Fehlerbild passt oft zu Fragmentierung, PPPoE, getunnelten Verbindungen oder einem asymmetrischen Pfad, nicht nur zu SSL VPN selbst.

Für die systematische Analyse passt Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

WAF oder Portal kollidiert mit SSL VPN

Wenn WAF, VPN Portal, User Portal und SSL VPN auf derselben WAN-IP laufen, müssen Port und Protokoll sauber getrennt sein. Besonders kritisch sind gemeinsam genutzte Kombinationen aus WAN-IP, Port und TCP. Bei unklaren Drops Log Viewer und Packet Capture prüfen.

Profil ist nach Änderung veraltet

Nach Änderungen an SSL-VPN-Policy, Gateway, DNS, Zertifikat, Port oder Authentifizierung sollte die .ovpn-Datei neu heruntergeladen und importiert werden. Viele scheinbare Clientprobleme sind veraltete Profile.

Wenn Sophos Connect mit einer .pro-Provisioning-Datei betrieben wird, zusätzlich prüfen, ob der Client das Profil wirklich aktualisiert hat oder ob noch ein alter Verbindungseintrag verwendet wird. Bei gemeinsam genutzten Windows-Geräten mit Entra-ID-SSO sollte nach Benutzerwechseln ein erneuter SSO-Login erzwungen werden, damit nicht der vorherige Benutzerkontext weiterwirkt.

Betriebscheckliste

Vor dem produktiven Rollout

• FQDN und Zertifikat für VPN Portal und SSL VPN geprüft.
• SSL-VPN-Lease-Bereich kollidiert nicht mit internen oder typischen Heimnetzen.
• IPv4-Lease-Bereich ist als /24 oder grösseres auswählbares Netz geplant, nicht als kleineres /25-Design.
• SSL-VPN-Policy enthält die richtigen Benutzer oder Gruppen.
• Split Tunnel oder Full Tunnel ist bewusst entschieden.
• Bei Split Tunnel sind Permitted network resources eng definiert.
• Bei Full Tunnel begrenzen Firewall-Regeln die internen Ziele und Services.
• DNS-Server und Domain Name sind korrekt gesetzt.
• Interne DNS-Server sind als erlaubte Ressource oder über eine passende Regel erreichbar.
• Firewall-Regel von VPN zu internen Zielen existiert und loggt.
• Bei Full Tunnel existieren Internetregel und SNAT.
• Device Access für SSL VPN und VPN Portal ist bewusst gesetzt.
• MFA ist für Remote Access getestet.
• Testbenutzer kann Profil herunterladen, importieren und interne Ziele erreichen.

Für den laufenden Betrieb

• MFA für VPN Portal und Remote Access erzwingen.
• VPN-Gruppen regelmässig prüfen.
• Firewall-Regeln für VPN eng halten und loggen.
• Lease-Bereich vor Netzänderungen kontrollieren.
• Statische SSL-VPN-IP-Adressen nur gezielt verwenden und regelmässig prüfen.
• DNS und Suchdomain dokumentieren.
• Portal- und SSL-VPN-Zertifikate vor Ablauf erneuern.
• Sophos Connect Versionen verfolgen.
• Profilneuverteilung nach Änderungen einplanen.
• Logs längerfristig über Syslog oder Sophos Central auswerten, wenn Nachvollziehbarkeit wichtig ist.

Für Logdateien und Dienste passt Sophos Firewall Troubleshooting: Services und Logs.

Sonderfälle regelmässig prüfen

• Statische SSL-VPN-IP-Adressen sind begründet und dokumentiert.
• Statische SSL-VPN-IP-Adressen werden nicht für Benutzer benötigt, die parallele Remote-Access-Anmeldungen brauchen.
• Key Lifetime passt zum Betriebsmodell und wurde mit Reconnect getestet.
• Altes .ovpn-Profil wird nach Änderungen neu verteilt.
• FQDN-Ressourcen werden mit Reconnect-Verhalten getestet.
• VPN Portal, User Portal, WAF und SSL VPN kollidieren nicht auf derselben WAN-IP mit Port und Protokoll.
• Benutzer mit Sonderrechten oder Adminzugriff werden separat überprüft.

FAQ