Sophos Firewall SSL VPN Remote Access einrichten

Remote Access SSL VPN wird auf Sophos Firewall unter Remote access VPN > SSL VPN eingerichtet. Für einen sicheren Zugang müssen sechs Bausteine zusammenpassen:

Benutzer oder Gruppen einer SSL-VPN-Policy zuordnen.
Protokoll, Zertifikat, Gateway, Lease-Bereich und DNS global konfigurieren.
Split Tunnel oder Use as default gateway bewusst wählen.
Traffic aus der VPN-Zone mit engen Firewall-Regeln erlauben.
VPN Portal, Authentifizierung, MFA und Device Access absichern.
Ein aktuelles .ovpn-Profil oder unter Windows eine .pro-Provisioning-Datei verteilen und den Zugriff positiv sowie negativ testen.

⚠️ SSL VPN ist ein öffentlich erreichbarer Einstiegspunkt. MFA und starke Passwörter ersetzen keine engen Benutzergruppen, Local Service ACLs, Firewall-Regeln, aktuellen Profile, Logs und regelmässigen Reviews.

Dieser Artikel behandelt die Firewallseite. Die Installation steht separat für Windows, macOS, iPhone und iPad, Android sowie Linux. Für die vorgelagerte Entscheidung zwischen SSL VPN, IPsec und ZTNA hilft Sophos Connect oder SSL VPN.

Voraussetzungen und Objekte vorbereiten

Vor der Konfiguration müssen der öffentliche Zugang, die berechtigten Benutzer und die internen Ziele feststehen:

aktuelle SFOS-Version und aktueller Sophos-Connect-Client;
öffentlicher FQDN oder öffentliche IP-Adresse;
Zertifikate für SSL-VPN-Tunnel und VPN Portal;
Benutzer oder Gruppen sowie Authentifizierungsserver;
MFA-Verfahren für Portal und Tunnel;
nicht kollidierender SSL-VPN-Lease-Bereich;
interne Zielnetze, DNS-Server und Suchdomain;
Entscheid für Split Tunnel oder Full Tunnel;
Prozess für Profilverteilung und Clientupdates.

Interne Ziele werden zuerst als Hosts oder Netzobjekte angelegt:

Hosts and services > IP host

Das folgende Beispiel verwendet:

LAN_Server: 10.10.10.0/24 für interne Server;
LAN_Client: 10.10.20.0/24, falls Remote-Benutzer dieses Clientnetz wirklich benötigen;
DNS_Internal: 10.10.10.10 für internen DNS oder Domain Controller;
SSLVPN_Users: Benutzergruppe für die Policy members.

Ganze interne Netze sollten nicht freigegeben werden, wenn einzelne Server oder Subnetze ausreichen. DNS-Server benötigen ebenfalls ein eindeutiges Objekt, damit Route und Firewall-Regel später nachvollziehbar bleiben.

Globale SSL-VPN-Einstellungen konfigurieren

Die globalen Einstellungen gelten für alle Remote-Access-SSL-VPN-Policies und sind Bestandteil der .ovpn-Konfiguration:

Remote access VPN > SSL VPN > SSL VPN global settings

Diese Werte werden auch für SSL-Site-to-Site-Verbindungen zwischen zwei Sophos Firewalls verwendet. Wer Port, Protokoll, Zertifikat oder Override hostname ändert, muss daher sowohl Remote-Access-Profile als auch bestehende SSL-Site-to-Site-Tunnel prüfen und deren Konfiguration neu verteilen.

Bevor globale Profilwerte geändert werden, dokumentiert man Protocol, Port, Override hostname, SSL server certificate, Lease- und DNS-Werte sowie die Konfiguration betroffener SSL-Site-to-Site-Peers. Auch vorgeschaltete NAT- oder Portweiterleitungen gehören in den Rollback-Plan. Schlägt die Abnahme fehl, stellt man diese Werte und die vorherige Site-to-Site-Konfiguration wieder her und wiederholt Portal-, Tunnel-, Positiv- und Negativtest mit dem alten Profil.

Protokoll, Zertifikate, Gateway und Port

SSL VPN unterstützt TCP und UDP. UDP ist meist die effizientere Ausgangswahl; TCP kann als getestete Alternative helfen, wenn Fremdnetze UDP blockieren. Die Wahl sollte mit realen Hotel-, Mobilfunk- oder Gastnetzen geprüft werden.

Der Standardport für SSL VPN ist 8443, das VPN Portal verwendet standardmässig 443. Für jeden öffentlich erreichbaren Dienst ist eine eindeutige Kombination aus WAN-IP, Port und Protokoll am übersichtlichsten.

Sophos trennt zwei Zertifikate:

Das unter den globalen SSL-VPN-Einstellungen gewählte SSL server certificate wird vom SSL-VPN-Server verwendet.
Das HTTPS-Zertifikat des VPN Portals wird unter Administration > Admin and user settings gewählt.

Beide Zertifikate sollten zum jeweils verwendeten öffentlichen FQDN passen. Bei Zertifikaten einer externen CA muss auch die benötigte Zertifikatskette vorhanden sein.

Override hostname bestimmt den FQDN oder die öffentliche IP-Adresse im Clientprofil. Das ist besonders bei vorgeschaltetem NAT, mehreren WAN-Interfaces oder DDNS wichtig. Bleibt das Feld leer, können mehrere Interface-Adressen im Profil stehen. Sophos Connect priorisiert DDNS-Gateways und versucht weitere Einträge in umgekehrter Reihenfolge; ein eindeutiger FQDN ist deshalb leichter zu testen und zu betreiben.

VPN Portal und SSL VPN dürfen technisch denselben Port und dasselbe Protokoll teilen. Dann funktionieren Login-Security-Einstellungen jedoch nicht wie vorgesehen, und das VPN Portal wird aus den für SSL VPN aktivierten Zonen erreichbar. WAF muss sich vom VPN Portal in WAN-IP oder Port und vom SSL VPN in WAN-IP, Port oder Protokoll unterscheiden. Weitere WAF-Abhängigkeiten erklärt Sophos Firewall WAF.

Lease-Bereich und DNS

Der IPv4-Lease-Bereich muss privat sein und darf nicht mit internen Netzen, Site-to-Site-VPNs, statischen Routen, anderen Remote-Access-Pools oder typischen Heimnetzen kollidieren. Besonders häufig sind 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24 und 10.0.1.0/24.

Bei der zulässigen Maske für kleinere IPv4-Pools widersprechen sich die SFOS-22-Dokumente. Die Feldhilfe nennt /24 als Grenze und bezeichnet /25 oder kleinere Netze als nicht auswählbar. Die aktuelle FAQ beschreibt dagegen auch kleinere Subnetze, die intern auf mehrere OpenVPN-Instanzen verteilt werden. Massgeblich ist deshalb die eingesetzte SFOS-Version: Dort prüft man, welche Maske die Oberfläche anbietet, und kontrolliert anschliessend die Zahl der tatsächlich verfügbaren Leases.

Ein kleiner Pool ist kein Zugriffsschutz; dafür dienen Policy und Firewall-Regeln. In den Regeln werden die Systemhosts ##ALL_SSLVPN_RW und für IPv6 ##ALL_SSLVPN_RW6 verwendet.

Unter IPv4 DNS werden interne DNS-Server eingetragen. Domain name enthält die Suchdomain, die an kurze Hostnamen angehängt wird. Bei Split Tunnel muss der DNS-Server oder sein Netz zusätzlich unter Permitted network resources liegen und durch eine Firewall-Regel aus der VPN-Zone erreichbar sein. Bei Full Tunnel entfällt die Split-Tunnel-Route, nicht aber die Firewall-Regel.

Wenn die Firewall selbst als DNS-Resolver dient, wird ihre geeignete Adresse unter IPv4 DNS eingetragen. Zusätzlich muss DNS unter Administration > Device access für die VPN-Zone erlaubt sein. Ein Test per IP-Adresse und ein separater Test per Hostname unterscheiden Routing- von DNS-Problemen.

Statische IPs, parallele Sitzungen und Zeitwerte

Statische SSL-VPN-IP-Adressen sind für begründete Sonderfälle wie eine IP-basierte Legacy-Freigabe möglich und müssen im dafür konfigurierten Pool liegen. Ein Benutzer mit statischer SSL-VPN-IP kann jedoch keine parallelen Remote-Access-Sitzungen aufbauen.

Unabhängig davon begrenzt Simultaneous logins unter Authentication > Services oder direkt beim lokalen Benutzer die parallelen Anmeldungen. Der globale Wert gilt nur für Benutzer, die danach angelegt werden.

Key lifetime steuert den Rekey-Zeitpunkt und ist kein Idle- oder maximales Session-Timeout. Idle-Verbindungen werden über die globalen Idle-Einstellungen und optional Disconnect idle clients in der Policy behandelt. Bei unerwarteten Abbrüchen müssen diese Werte, statische IP-Zuweisung, parallele Anmeldung und Logs getrennt geprüft werden.

Disconnect dead peer after wird global in Sekunden angegeben und beendet nicht antwortende Clients. Die Standardwerte sind 180 Sekunden für TCP und 100 Sekunden für UDP; bei UDP lässt SFOS Werte von 60 bis 110 zu. Disconnect idle peer after wird dagegen in Minuten angegeben und beendet tatsächlich inaktive Sitzungen. Vor einer Erhöhung wird deshalb anhand von sslvpn.log, Clientlog und Paketverlust geklärt, welcher Timer überhaupt auslöst.

Ein Override global timeout in einer Policy kann den globalen Idle-Wert nur verkürzen. Ist der Policy-Wert höher, gilt weiterhin der globale Wert. Eine ältere Sophos-Troubleshooting-Seite empfiehlt für einzelne Benutzer einen höheren Policy-Wert, die aktuelle SFOS-22-Feldhilfe widerspricht dem jedoch ausdrücklich. Für eine längere Sitzungsdauer wird deshalb nicht wirkungslos in der Policy erhöht, sondern der globale Wert mit Auswirkungsprüfung angepasst und danach mit derselben Benutzergruppe erneut getestet.

SSL-VPN-Policy erstellen

Die Policy wird manuell oder über den Assistenten angelegt:

Remote access VPN > SSL VPN

Sophos empfiehlt den Assistenten vor allem für die erste SSL-VPN-Policy. Er zeigt die globalen Einstellungen nur zur Kontrolle an und kann sie nicht ändern. Er übernimmt die gewählten Authentifizierungsserver und -methoden, setzt Device Access für VPN Portal und SSL VPN und erstellt Policy und Firewall-Regel. Beim ersten Lauf legt er am Anfang der Regeltabelle die Regelgruppe Automatic VPN rules an und aktiviert die neue Regel. Weitere Assistentenregeln landen am Ende dieser Gruppe. Nach jedem Lauf sollte man deshalb die Position und die tatsächlich matchende Rule ID kontrollieren. In bestehenden Umgebungen ist Configure manually oft transparenter:

Add > Configure manually auswählen.
Als Name zum Beispiel SSLVPN-Remote-Users eintragen.
Unter Policy members die Gruppe SSLVPN_Users auswählen.
Split Tunnel oder Use as default gateway festlegen.
Bei Split Tunnel LAN_Server und DNS_Internal als Permitted network resources auswählen. Hier Netz- oder Hostobjekte verwenden, keine Interfaces: Ein ausgewähltes Interface stellt den Zugriff auf sein Subnetz nicht sicher.
Optional Disconnect idle clients und Override global timeout setzen.
Speichern und mit einem normalen Mitglied der Zielgruppe prüfen.

Gastbenutzer und Gastgruppen können nicht als Policy members verwendet werden. Ist ein Benutzer oder eine Gruppe bereits in einer älteren SSL-VPN-Policy enthalten, entfernt SFOS die Zuordnung aus der früheren Policy. Überschneidungen sollten deshalb vor dem Speichern geprüft werden.

Ein Policy-spezifischer Override global timeout wirkt nur, wenn er kleiner als der globale Idle-Wert ist. Ein höherer Wert hebt die globale Grenze nicht auf.

Split Tunnel oder Full Tunnel

Bei Split Tunnel werden nur die unter Permitted network resources ausgewählten IPv4- und IPv6-Netze sowie unterstützte FQDN-Ziele über das VPN geroutet. FQDN-Ziele werden nur für IPv4 unterstützt. Der übrige Internettraffic bleibt lokal. Das reduziert Firewalllast und Latenz, verlangt aber eine genaue Ressourcen- und DNS-Planung.

Ändert sich die IP-Adresse eines erlaubten FQDN-Ziels, werden bestehende Tunnel nicht automatisch aktualisiert. Betroffene Benutzer müssen trennen und neu verbinden.

Bei Full Tunnel wird Use as default gateway aktiviert. Der gesamte Traffic des Benutzers läuft dann durch die Firewall. Permitted network resources werden dabei nicht als Zugriffslimit erzwungen. Interne Ziele und Services müssen durch Firewall-Regeln begrenzt werden; IPv4-Internetzugriff benötigt zusätzlich eine passende SNAT-/MASQ-Regel.

Full Tunnel ermöglicht zentrale Web-, DNS- und Logkontrolle, erhöht aber Bandbreitenbedarf, Firewalllast, Datenschutz- und Supportaufwand. Er sollte deshalb mit realen Anwendungen und gleichzeitigen Benutzern getestet werden.

Firewall-Regeln, Device Access und Authentifizierung

Firewall-Regeln und DNS

Der Tunnelaufbau erlaubt noch keinen Zugriff auf interne Ressourcen. Dafür wird eine Regel erstellt:

Rules and policies > Firewall rules

Beispiel für Split Tunnel:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: nur die benötigten Anwendungsdienste und DNS
Log firewall traffic: aktiviert

Die Regel sollte oberhalb breiterer VPN-Regeln stehen. Ein Negativtest zu einem nicht erlaubten Ziel zeigt, ob eine allgemeine Regel weiter unten den Zugriff unbeabsichtigt freigibt.

Für IPv4 Full Tunnel kommt eine Regel von VPN nach WAN und eine passende SNAT-/MASQ-Regel hinzu. IPv6 benötigt stattdessen bewusstes IPv6-Routing und eigene IPv6-Firewall-Regeln. Bei fehlendem Zugriff helfen Log Viewer, Rule ID und die Anleitung zum Testen von Firewall-Regeln.

VPN Portal, Device Access und MFA

Portal, lokale Dienste und Authentifizierung werden an getrennten Stellen geprüft:

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

Mindestens erforderlich sind:

SSL VPN in den Zonen, aus denen der Tunnel aufgebaut werden darf;
VPN Portal nur in den tatsächlich benötigten Zonen;
DNS in der VPN-Zone nur, wenn die Firewall als Resolver dient;
passende VPN portal authentication methods;
passende SSL VPN authentication methods;
MFA für Portal und Tunnel.

Sind innerhalb einer Authentication Method mehrere Server ausgewählt, fragt SFOS sie in der angezeigten Reihenfolge ab. Pro Methode sind höchstens 20 Server möglich. Besonders bei gleichnamigen Benutzern oder einem Fallback sollte man daher kontrollieren, welcher Server die Anfrage tatsächlich verarbeitet.

Normale Firewall-Regeln steuern diese lokalen Dienste nicht. Engere Quellnetze, einzelne IP-Adressen oder Länder werden über Local Service ACL Exception Rules umgesetzt. Der vollständige Sicherheitsablauf steht unter Device Access und Local Service ACL.

Ein Sonderfall ist der Web Proxy der Firewall: HTTP- und HTTPS-Anfragen, die über ihn laufen, gelten für lokale Dienste als intern. Benutzer mit Proxyzugriff können dadurch das VPN Portal erreichen, obwohl es für ihre Ursprungszone nicht aktiviert ist. Wer den Proxy nutzt, prüft diese Erreichbarkeit deshalb separat und verlässt sich nicht allein auf die Zonenmatrix unter Device Access.

Third-party Threat Feeds können auch systemgerichteten Zugriff auf VPN-Dienste blockieren. Damit lassen sich bekannte unerwünschte Quellen zusätzlich sperren; Einrichtung und Grenzen erklärt Threat Feeds auf Sophos Firewall.

VPN portal authentication methods steuern die Anmeldung am Portal und den Profildownload, SSL VPN authentication methods die eigentliche Tunnelanmeldung. WebAdmin ist eine separate Administrationsoberfläche und muss für SSL VPN nicht aus der WAN-Zone freigegeben werden.

Bei Microsoft Entra ID muss derselbe Entra-Server für VPN Portal und SSL VPN gewählt werden. Die vollständige Einrichtung steht unter Microsoft Entra ID SSO für Sophos Connect.

Für das SFOS-eigene OTP werden unter Authentication > Multi-factor authentication die Zielbenutzer oder -gruppen gewählt und unter Require MFA for sowohl VPN portal als auch SSL VPN remote access aktiviert. Bei Generate OTP token with next sign-in muss der Benutzer den QR-Code zuerst im VPN Portal scannen; erst danach kann der Tunneltest beginnen.

Das VPN Portal unterstützt keine RADIUS-Authentifizierung mit Challenge-MFA. Sophos Connect unterstützt ebenfalls keine OTP-Challenge, sondern sendet Passwort und OTP gemeinsam; Call- und Push-Verfahren werden unterstützt. Das gewählte Verfahren muss mit einem normalen Pilotbenutzer getestet werden. Weitere Grundlagen stehen unter MFA für Sophos Firewall.

Clientprofil verteilen und aktualisieren

Ändern sich profilrelevante globale Werte, muss auch eine manuell importierte .ovpn am Client aktualisiert werden. Dazu gehören insbesondere Protokoll, Port, Interface, Serverzertifikat und Override hostname. In Sophos Connect wird zuerst Update policy ausgeführt. Ist die Funktion nicht verfügbar oder schlägt sie fehl, lädt man die aktuelle .ovpn erneut aus dem VPN Portal herunter und importiert sie. Ein Sophos-Connect-Softwareupdate ersetzt kein veraltetes Profil.

Nach einer Änderung an Override hostname oder Port wird im Client geprüft, ob das neu importierte Profil tatsächlich den neuen Gatewaynamen und Port verwendet.

Bei Änderungen an Policy members, Permitted network resources oder der IP-Adresse eines FQDN-Ziels reicht normalerweise ein Disconnect und Reconnect. Diese Ressourcen stehen nicht statisch in der .ovpn, sondern werden von SFOS beim Tunnelaufbau benutzerspezifisch hinzugefügt. Ein neuer .ovpn-Download ist daher nicht nötig.

Eine .pro-Provisioning-Datei wird nur unter Windows 10 und 11 unterstützt. Sie lädt die für den Benutzer verfügbaren IPsec- und SSL-VPN-Konfigurationen sowie spätere Änderungen automatisch.

Ändern sich der Provisioning-gateway oder vpn_portal_port, muss die .pro angepasst und neu verteilt werden. Das ältere Feld user_portal_port wird nur noch aus Kompatibilitätsgründen akzeptiert. Bei der ersten Bereitstellung mit OTP oder einer anderen MFA-Methode kann die Anmeldung zweimal erscheinen: zuerst für den Profildownload und danach für den Tunnelaufbau.

Liefert .pro nur eine IPsec-Verbindung oder keine SSL-VPN-Konfiguration, werden zuerst Policy members, Gruppenmitgliedschaft, VPN-Portal-Erreichbarkeit und Authentifizierung geprüft.

Die vollständige JSON-Struktur, MFA-Felder, Gateway-Auswahl und GPO-Verteilung beschreibt Sophos Connect Provisioning mit .pro und GPO.

Nach Aktivierung oder Änderung von Microsoft Entra ID SSO muss der Client eine aktuelle Konfiguration verwenden. Entra SSO in Sophos Connect ist ein Windows-Szenario ab Clientversion 2.4.

Profilnamen sollten eindeutig sein, alte Verbindungseinträge nach Gateway- oder Benutzerwechsel entfernt und die Verteilung mit einem normalen Zielbenutzer geprüft werden. Hinweise zu Clientversionen stehen unter Sophos Connect sicher aktualisieren.

Sophos Connect unterstützt SSL VPN unter Windows 10/11 und macOS 13 oder neuer. Unter Linux, iOS und Android wird dafür ein kompatibler OpenVPN-Client verwendet.

Unter Current activities > Remote users lassen sich angemeldete Remote-Benutzer nach Connection date, Username, Source IP address und Leased IP address filtern. Die Spalte Mode unterscheidet drei Zustände:

SSL VPN (remote access): aufgebauter Remote-Access-Tunnel
User portal (clientless access): Portal-Anmeldung eines Mitglieds einer Clientless-SSL-VPN-Policy
User portal: Portal-Anmeldung ohne solche Mitgliedschaft

Ein Portal-Eintrag beweist somit noch keinen SSL-VPN-Tunnel. Mit Disconnect wird die ausgewählte Sitzung beendet. Vor einem Support- oder Abnahmetest sollte man Benutzer, Adressen, Modus und Zeitpunkt dokumentieren.

Konfiguration testen und Fehler eingrenzen

Abnahmetest

Ein vollständiger Test verwendet einen normalen Pilotbenutzer und ein konkretes internes Ziel:

Benutzer sieht im VPN Portal genau die erwartete SSL-VPN-Konfiguration.
MFA mit richtigem und falschem Faktor testen.
.ovpn oder .pro importieren und die zugewiesene Lease-Adresse prüfen.
Bei Split Tunnel die Route zu LAN_Server und DNS_Internal kontrollieren.
Internes Ziel zuerst per IP-Adresse, danach per Hostname testen.
Erlaubten Dienst aufrufen und Firewall Rule ID im Log Viewer prüfen.
Einen nicht erlaubten Zugriff erzeugen und den Drop bestätigen.
Bei Full Tunnel zusätzlich öffentlichen Internetzugriff, DNS, Web Policy und IPv4-SNAT prüfen.
Nach Policy- oder FQDN-Änderung trennen, neu verbinden und denselben Test wiederholen.

Jeder Test sollte Uhrzeit, Benutzer und Gruppe, Clientplattform und -version, Quellnetz, Ziel und Dienst enthalten. Wenn nur ein Administrator getestet wird, bleiben Gruppen-, MFA- und Policyfehler leicht unentdeckt.

Logs nach Fehlerphase

Zuerst wird geklärt, ob der Fehler beim Portalzugriff, bei der Authentifizierung, beim Tunnelaufbau oder erst beim Zielzugriff entsteht:

VPN Portal: vpnportal.log
Normale Authentifizierung: access_server.log
Microsoft Entra SSO: oauth_sso_vpn.log
Benutzerspezifische SSL-VPN-Zertifikate: peruser_cert_sslvpn.log
SSL-VPN-Dienst: sslvpn.log
Aktive Verbindungen: openvpn-status*.log
Zieltraffic: Firewall-Log, Rule ID und bei Bedarf Packet Capture

Im Packet Capture beweist Incoming nur, dass die Firewall das Paket empfangen hat. Bei Forwarded ohne Antwort werden Rückroute, NAT, Zielsystem und dessen lokale Firewall geprüft.

Bei TUN-Traffic zeigt SFOS in den Logs mitunter die TUN-Interface-Adresse als Quelle und die geleaste Clientadresse als Ziel. Das bedeutet nicht, dass die Adressen vertauscht sind. Für die Einordnung müssen Benutzer, Lease, Richtung, Rule ID und Testzeit zusammenpassen.

Die Zuordnung weiterer Prozesse und Dateien steht unter Sophos Firewall Services und Logs.

Kein Benutzer kann einen Tunnel aufbauen: Dienst und Flood-Limits

Wenn alle Benutzer betroffen sind, führen Sie zuerst ausschließlich lesende Prüfungen durch, bevor Sie Richtlinien, Flood-Limits oder Dienste ändern. Notieren Sie Testzeitpunkt, konfiguriertes SSL-VPN-Protokoll und -Port, die aktuellen DoS-Einstellungen und ob mindestens eine SSL-VPN-Richtlinie vorhanden ist.

Melden Sie sich an der CLI an, wählen Sie 5. Device management und anschließend 3. Advanced shell. Prüfen Sie den Dienststatus mit dem von Sophos dokumentierten Befehl:
```
service -S | grep sslvpn
```
Der Dienst muss Running anzeigen. UNREGISTERED bedeutet, dass keine SSL-VPN-Richtlinie registriert ist; vergewissern Sie sich, dass mindestens eine SSL-VPN-Richtlinie vorhanden ist. Ist eine Richtlinie vorhanden, der Dienst aber weiterhin nicht Running, gleichen Sie sslvpn.log mit dem Testzeitpunkt ab und untersuchen Sie diese Abweichung, statt Dienste ohne dokumentiertes Verfahren neu zu starten.
Prüfen Sie unter Intrusion prevention > DoS & spoof protection > DoS settings die aktivierten Flood-Optionen und Grenzwerte für UDP, TCP und ICMP/ICMPv6. Verwenden Sie für den Tunnelverkehr das konfigurierte SSL-VPN-Protokoll. SFOS verwirft SSL-VPN-Verkehr und Ping-Anfragen, sobald der zugehörige Flood-Grenzwert überschritten wird; ein fehlgeschlagener Ping allein belegt dies nicht. Ordnen Sie den Verbindungsversuch den Drop-Nachweisen zu, bevor Sie eine Ausnahme anlegen.
Nur bei einem bestätigten Treffer auf ein Flood-Limit: Dokumentieren Sie die vorhandene Konfiguration und erstellen Sie unter DoS bypass rules eine möglichst eng gefasste temporäre Inbound-Regel. Das Sophos-Beispiel verwendet die relevante Quell-IP/Netzmaske (oder nur falls unvermeidbar *), die Adresse der zulässigen Netzwerkressource als Ziel, das tatsächliche Protokoll TCP oder UDP, Quellport Any und den konfigurierten SSL-VPN-Zielport (standardmäßig 8443). Grenzen Sie Quelle und Ziel weiter ein, sofern der Test dies zulässt; deaktivieren Sie den Flood-Schutz nicht global.
Wiederholen Sie denselben zeitlich erfassten Verbindungs- und Ressourcentest. Erklärt die Bypass-Regel den Drop nicht, entfernen Sie sie sofort. Entfernen Sie die temporäre Regel nach der Diagnose oder genehmigen und dokumentieren Sie die eng gefasste Ausnahme formell. Stellen Sie separat geänderte Flood-Limits auf die notierten Werte zurück und wiederholen Sie anschließend die positiven und negativen Zugriffstests.

Anfrage erreicht den Server, aber die Antwort fehlt

Erreicht die Anfrage des SSL-VPN-Clients nachweislich die erlaubte interne Ressource, die Antwort aber nicht den Client, wird der Rückweg in zwei Abschnitten geprüft: zuerst von der Ressource zur Firewall und danach von der Firewall zur geleasten SSL-VPN-Adresse. Ein grüner Tunnelstatus grenzt diesen Fehler nicht ein.

Auf der internen Ressource oder ihrem Router prüfen, ob der Rückweg zum SSL-VPN-Lease-Bereich über die Sophos Firewall führt. Eine spezifische Rückroute ist transparenter als SNAT. SNAT nur eng begrenzt einsetzen, wenn sich der Rückweg nicht routen lässt und die dadurch veränderte Quelladresse akzeptiert ist.
Mit Packet Capture bestätigen, dass die Antwort auf der Firewall ankommt. Quelladresse, geleaste Zieladresse, Dienst und Testzeit müssen zum ursprünglichen Zugriff passen.
Unter Routing > SD-WAN routes die aktuelle Route Precedence und breite SD-WAN-Routen prüfen. SSL VPN gehört zur Kategorie static. Steht sdwan_policyroute davor, kann eine Route mit der internen Ressource oder Any als Quelle sowie Any als Ziel und Dienst die Antwort vom Tunnel weglenken.
Die betroffene SD-WAN-Route bevorzugt so eingrenzen, dass der SSL-VPN-Lease-Bereich nicht mehr als Ziel erfasst wird. Sophos nennt alternativ eine Service-Ausnahme für Port und Protokoll von SSL VPN; diese Variante muss zum tatsächlichen Regel- und Trafficdesign passen.
Die globale Route Precedence nur nach Auswirkungsprüfung ändern. Sie betrifft nicht nur diese Verbindung. Ausgangsreihenfolge, Managementzugang und Rollback werden wie unter Route Precedence auf Sophos Firewall vorbereitet.
Den Zugriff erneut ausführen und im Capture den Eingang von der Ressource sowie die Weiterleitung zur geleasten Adresse prüfen. Danach mit derselben Anwendung nach einem Reconnect nochmals testen.

⚠️ Eine breite Any-Regel, eine pauschale SNAT-Regel oder eine globale Änderung der Route Precedence kann den sichtbaren Einzelfehler verlagern und andere VPN-, WAN- oder Managementpfade stören. Stoppen, wenn der Rückweg zur Firewall oder die tatsächlich matchende SD-WAN-Route nicht belegt ist.

Heimnetz und internes Zielnetz überlappen

Verwendet der externe Client beispielsweise 192.168.1.0/24 und liegt die erlaubte interne Ressource ebenfalls in 192.168.1.0/24, behandelt das Betriebssystem das Ziel meist als lokal. Das Paket erreicht den SSL-VPN-Tunnel dann gar nicht. Die saubere dauerhafte Lösung ist, eines der beiden Netze umzuadressieren.

Ist das nicht sofort möglich, dokumentiert Sophos einen eng begrenzten DNAT-Ausweichweg. Dafür wird eine freie virtuelle Zieladresse gewählt, die mit keinem lokalen, internen, VPN-, Static- oder SD-WAN-Netz kollidiert. Bei Split Tunnel muss diese Adresse als Permitted network resource zum Client gelangen; danach ist ein Reconnect nötig. Die DNAT-Regel verwendet den SSL-VPN-Lease-Bereich als Original source, Original als Translated source, die virtuelle Adresse als Original destination und den echten internen Host als Translated destination. Services und zugehörige Firewall-Regel von VPN zur Zielzone bleiben auf den wirklich benötigten Zugriff begrenzt.

Der Benutzer greift anschliessend auf die virtuelle Adresse oder einen dafür vorgesehenen DNS-Namen zu. Im Log Viewer müssen die erwartete Firewall Rule ID und NAT Rule ID erscheinen; ein Packet Capture bestätigt die Übersetzung und den Rückweg. Keine ganze Ersatz-Range anlegen, wenn nur ein Host benötigt wird. Stoppen, wenn die virtuelle Adresse nicht eindeutig frei ist oder eine breite NAT-Regel nötig wäre.

Typische Fehlerbilder

Keine oder leere .ovpn im VPN Portal: Fehlenden oder leeren OVPN-Download beheben trennt Policy-, User-ID-, Zertifikats-, Speicher-, Firmware- und HA-Fehler. Gastkonten sind nicht zulässig. Sophos Connect unterstützt nur ASCII-Benutzernamen; Benutzername und Domain dürfen zusammen höchstens 51 Zeichen lang sein.
Login schlägt fehl: access_server.log, vpnportal.log oder oauth_sso_vpn.log mit der Testzeit abgleichen. Bei Entra denselben Server für Portal und SSL VPN sowie die vollständige Zertifikatskette prüfen.
Tunnel steht, interne Ziele fehlen: Route am Endpoint, Permitted Resources bei Split Tunnel, Firewall-Regel, Rückroute, Ziel-Firewall und Kollision mit dem lokalen Heimnetz prüfen.
IP-Adresse funktioniert, Hostname nicht: DNS-Server, Suchdomain, Split-Tunnel-Route, DNS-Firewall-Regel, lokales DoH oder Endpoint-DNS und gegebenenfalls Device Access für DNS prüfen.
Nur einzelne Benutzer sind betroffen: Gruppenmitgliedschaft, Policy-Zuordnung, MFA, statische IP, Simultaneous logins und geladenes Profil vergleichen.
Nur alte Clients sind betroffen: Bei globalen Änderungen aktuelles .ovpn importieren. Bei reinen Policy- oder FQDN-Änderungen zuerst reconnecten und das geladene Routing prüfen.
Full Tunnel ohne Internet: Regel von VPN nach WAN, IPv4-SNAT, DNS und angewendete Web-/Security-Policies kontrollieren.
Grosse Transfers hängen: Wenn kleine Zugriffe funktionieren, MTU und MSS entlang des tatsächlichen Pfads prüfen. Dafür gibt es den Ablauf MTU und MSS bei VPN-Problemen.
Verbindung endet nach längerer Zeit: Start- und Abbruchzeit mit Idle Timeout, Disconnect idle clients und Key Lifetime vergleichen. Statische IP und Simultaneous logins prüfen, bei Bedarf einen Pilotbenutzer dynamisch adressieren und sslvpn.log sowie openvpn-status*.log zur Testzeit auswerten.
Tunnel kommt bei keinem Benutzer zustande: Neben Device Access und Portfreigabe nach einer breiten DNAT-Regel mit Original destination: Any und Services: Any oder dem SSL-VPN-Port suchen, die den Verbindungsaufbau vorher abfängt.
WAF, Portal oder SSL VPN kollidieren: WAN-IP, Port und Protokoll aller lokalen Dienste und WAF-Regeln vergleichen. Geteilte Kombinationen können zusätzliche Portalexposition oder fehlende Login-Security verursachen.

Im laufenden Betrieb sollten Gruppen, MFA, statische IP-Zuweisungen, Zertifikatsablauf, Lease-Bereich, Device Access, Firewall-Regeln, Profilverteilung und Logs regelmässig geprüft werden. Neue SFOS- und Sophos-Connect-Versionen werden zuerst mit einem Pilotbenutzer sowie positivem und negativem Zieltest abgenommen.