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:

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.

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: 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:

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.

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.

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 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 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.

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 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?

3. SSL-VPN-Policy erstellen

Die Policy erstellt man unter:

Remote access VPN > SSL VPN

Ablauf:

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.
7. Optional Disconnect idle clients konfigurieren.
8. Speichern und anschliessend mit einem Testbenutzer prüfen.

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.

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.

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:

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.

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.
• 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.

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.

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.

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

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.
• Interne DNS-Namen werden aufgelöst.
• Zugriff auf erlaubte Server funktioniert.
• Nicht erlaubte Netze bleiben blockiert.
• Log Viewer zeigt die richtige Firewall-Regel.
• 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.

Abnahmetest nach Szenario

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

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:

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.

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.

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.

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.

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.
• SSL-VPN-Policy enthält die richtigen Benutzer oder Gruppen.
• Split Tunnel oder Full Tunnel ist bewusst entschieden.
• Permitted network resources sind bei Split Tunnel eng definiert.
• DNS-Server und Domain Name sind korrekt gesetzt.
• 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.
• Key Lifetime passt zum Betriebsmodell und wurde mit Reconnect getestet.
• Altes .ovpn-Profil wird nach Änderungen neu verteilt.
• 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