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.

Laut Sophos-FAQ hängt die Zahl paralleler SSL-VPN-Instanzen von den CPUs des Firewallmodells ab. Jede Instanz erstellt ein tun0-Interface und benötigt ein eigenes Subnetz für Routing und interne Verteilung. SFOS teilt den konfigurierten Pool dafür auf; dieser Adressbedarf fällt vor der Vergabe von Client-Leases an. Als Illustration nennt die FAQ 192.168.0.0/27 mit acht gleichzeitigen Instanzen und nur einer verbleibenden leasbaren IP-Adresse. Das ist kein allgemeiner Kapazitätswert oder empfohlenes Beispielnetz: Die tatsächlich verfügbaren Leases auf dem Ziel-Build und Modell prüfen; der oben beschriebene Konflikt zwischen Feldhilfe und FAQ bleibt bestehen.

SFOS 23: Der auswählbare IPv4-Bereich hängt vom Firewallmodell ab; grössere Modelle unterstützen Subnetze mit mehr IP-Adressen. Die SFOS-23-Hilfe nennt /24 als kleinstes auswählbares Subnetz. Das ist eine modellabhängige Auswahlgrenze, keine Zusage einer bestimmten Zahl von Client-Leases. Die CPU-abhängige interne Aufteilung erklärt den Adressbedarf, aber nicht die unterstützten Auswahlbereiche. Der SFOS-22-Konflikt und die nicht als Konfigurationsempfehlung gedachte /27-Illustration bleiben davon unberührt.

Vor einer Änderung dokumentiert man SFOS-Build, Modell, bisherigen Bereich und statische Zuweisungen und bewahrt die bisherigen Werte für den Rollback auf. Nur einen auf dem Zielmodell unterstützten Bereich in der Oberfläche wählen, statische Benutzeradressen innerhalb des daraus resultierenden statischen Bereichs halten und die tatsächlich verfügbaren Leases kontrollieren. Anschliessend einen Pilotbenutzer neu verbinden und Lease, DNS sowie erlaubte und gesperrte Ziele prüfen. Bei fehlgeschlagener Abnahme die bisherigen Werte und Zuweisungen wiederherstellen und erneut testen. Widersprechen sich Build, Oberfläche, Hilfe oder FAQ, stoppt der davon abhängige Kapazitätsrollout bis zur Klärung mit dem Support; keine Maske erzwingen.

SFOS 23 XML API – Status 551: Die rohe Statuszeile für Configure SSLVPN Tunnel Access verweist auf den nicht aufgelösten Laufzeitbezeichner Message.SSLVPNInvalidLeaseIPv4Mask. Daraus lassen sich weder ein bestätigter Meldungstext noch eine feststehende Ablehnungsursache oder ein neuer unterstützter Maskenbereich ableiten. Liefert die API 551, bewahrt man die vollständige Antwort und die bisherigen Einstellungen auf. Vor jeder Änderung prüft man StartIP, SubnetMask und die vom installierten Build und Modell unterstützte Pool-Auswahl anhand der dafür freigegebenen Hilfe oder mit Sophos Support; keine Maske erzwingen.

Nach einer unterstützten Korrektur kontrolliert man die API-Antwort, die tatsächlich gespeicherten Einstellungen auf der Zielfirewall und die Lease eines neu verbundenen Pilotbenutzers. Die bisherigen Werte und Zuweisungen bleiben für den oben beschriebenen Rollback erhalten. Bleiben Diagnose oder Meldungswortlaut für die Freigabe wesentlich und ungeklärt, bleibt das Deployment ausstehend.

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.

XML-API-Grenze für SFOS 22/23: Die Legacy-API-Dokumentation zu Configure SSLVPN Tunnel Access nennt für DisconnectDeadPeerAfter den Default 300 Sekunden, den Bereich 60 bis 1800 und im Beispiel 180, ohne protokollspezifische Zuordnung. Das belegt weder einen TCP-/UDP-Laufzeitdefault noch einen neuen GUI-Standard. Die oben beschriebenen TCP-/UDP-Werte deshalb nicht anhand dieser API-Tabelle überschreiben; den tatsächlich gespeicherten Timer unter Remote access VPN > SSL VPN > SSL VPN global settings auf dem installierten Build prüfen.

Auch das Lease-Schema bleibt bedingt ungeklärt: LeaseMode erlaubt IPv4, obwohl IPv6Lease und IPv6Prefix als Pflichtfelder aufgeführt sind und im Beispiel leer bleiben; für den Präfix nennt die Tabelle 64 bis 112. Daraus folgt weder eine Erlaubnis, leere IPv6-Felder zu senden, noch fehlende Dual-Stack-Unterstützung. EndIP und CompressSSLVPNTraffic erscheinen nur im Beispiel und liefern keinen validierten Schreibvertrag oder eine Kompressionsempfehlung. Vor einer davon abhängigen Automatisierung muss Sophos Support oder die für den Ziel-Build freigegebene Dokumentation die bedingten Pflichtfelder und Schreibwerte klären; bis dahin keine daraus abgeleitete XML-Änderung ausführen. Für unterstützte Änderungen zuvor die tatsächlichen globalen Timer-, Lease- und DNS-Werte sowie betroffene SSL-Site-to-Site-Peers sichern, danach Antwort, gespeicherte Werte und die Lease eines neu verbundenen Pilotbenutzers prüfen. Bei fehlgeschlagener Abnahme genau die notierten Ausgangswerte und zugehörigen Peer-Konfigurationen wiederherstellen und dieselben Zugriffstests wiederholen.

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.

XML-API-Grenze bei der Policy: Die Add/Edit-Beispiele für SFOS 22/23 trennen innerhalb von SSLVPNPolicy die Zweige TunnelPolicy und ClientlessPolicy, jeweils mit eigenem Name und PolicyMembers/Member. Tunnelzugriff auf Netzressourcen und die clientlose Veröffentlichung sind unterschiedliche Aufgaben mit getrennten Policy-Namen und Mitgliedszuordnungen. WebAccessibleResources enthält BookmarkGroups und Bookmarks, keine Tunnel-IP-Ressourcen. Eine Änderung nicht als gemeinsame Änderung beider Teilpolicies behandeln; Bookmark-Freigaben nicht in Tunnelressourcen umdeuten.

Die Tabelle nennt ausserdem das Pflichtfeld Web Access mit den Werten 1 und 6, ohne entsprechendes Feld im Beispiel oder bestätigte Zuordnung zu GUI-Modi. Bei UseAsDefaultGateway steht als Default SplitTunnel, bei DisconnectIdleClients UseGlobalSettings, obwohl beide nur Off und On als zulässige Werte nennen. Daraus keine numerische Moduszuordnung, keinen sendbaren Default, keine Wirkung ausgelassener Felder oder Member-Serialisierung ableiten. Die davon abhängige API-Änderung bis zur Klärung für den Ziel-Build zurückhalten; die oben beschriebene GUI-Konfiguration bleibt der sichere Weg. Full Tunnel benötigt weiterhin enge Firewall-Regeln, und der Policy-Idle-Wert kann die globale Grenze nur verkürzen.

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.

Eine SSL-VPN-Policy sicher ausser Betrieb nehmen

Eine nicht mehr benötigte Policy wird gezielt entfernt, nicht durch das Trennen einer Sitzung ersetzt. Vor dem Löschen muss feststehen, welcher Zugang entfallen soll und welche Freigaben weiterhin benötigt werden.

Den exakt gespeicherten Name und den vorgesehenen Policy-Zweig auswählen: TunnelPolicy für Tunnelzugriff oder ClientlessPolicy für clientlosen Zugriff. Nicht allein nach einem ähnlichen Anzeigenamen entscheiden.
Policy members, tatsächliche Gruppenmitgliedschaften und die zugeordneten Netzressourcen beziehungsweise Bookmarks und Bookmark-Gruppen prüfen. Bestätigen, dass die Stilllegung freigegeben ist und keine weiterhin benötigte Nutzung von dieser Policy abhängt. Bei unklaren Zuordnungen stoppen und zuerst die Abhängigkeiten klären; eine Neuzuordnung kann Mitglieder aus einer älteren Policy entfernen.
Namen, Zweig, Mitglieder und alle zugehörigen Einstellungen geschützt und wiederherstellbar sichern. Unter Remote access VPN > SSL VPN nur die ausgewählte Policy mit dem für den installierten Ziel-Build unterstützten Löschablauf entfernen. Ist dieser Ablauf nicht eindeutig bestätigt, vor der Änderung die freigegebene Dokumentation oder Sophos Support heranziehen.
Soll der Zugriff sofort enden, aktive Sitzungen separat unter Current activities > Remote users anhand von Benutzer, Adressen und Mode prüfen und betroffene Sitzungen gezielt mit Disconnect beenden. Das Trennen ersetzt nicht den Entzug der Berechtigung; aus dem Löschen keine automatische Tunnelbeendigung ableiten.
Gespeicherte Policies und Mitgliedszuordnungen erneut prüfen. Mit einem betroffenen normalen Benutzer die erwartete Konfiguration im VPN Portal und die Berechtigung bei einem neuen Verbindungsversuch kontrollieren. Bisher über die stillgelegte Policy gewährter Zugriff muss entfallen; weiterhin genehmigter Zugriff über andere Policies muss erhalten bleiben. Tatsächlich erlaubten und gesperrten Traffic samt Firewall-Logs prüfen, bei clientlosem Zugriff auch die erwarteten Bookmark-Freigaben. Unerwartete Ergebnisse vor weiteren Löschungen klären; die gesicherten Einstellungen nur nach Freigabe für einen gezielten Rückweg verwenden.

Dokumentarische Grenze: Die Delete-Seiten der Legacy-XML-API für SFOS 22/23 nennen Name als Pflichtparameter, bestätigen aber keinen vollständigen XML-Löschvertrag, keine Kaskadenwirkung und keine Ergebnis- oder Sitzungsemantik. Deshalb hieraus weder ein Delete-Payload noch Statuscodes, Meldungswortlaut oder eine sofortige Zugriffssperre ableiten.

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.

SSO nach SFOS-Version: Unter SFOS 22 wird Microsoft Entra ID mit Server type: Microsoft Entra ID SSO eingerichtet. Unter SFOS 23 öffnet man Authentication > Servers > Add, wählt Server type: OpenID Connect und anschliessend IdP vendor: Microsoft Entra ID oder IdP vendor: Google Workspace. Die Einrichtung von App, Server, Redirect URIs und Gruppen steht in Microsoft Entra ID SSO für Sophos Connect beziehungsweise Google Workspace OIDC auf Sophos Firewall. Diese Versionszweige sind keine Aussage zur GA-Verfügbarkeit eines Builds.

Vor dem Profildownload muss unter Authentication > Services derselbe konfigurierte IdP-Server für VPN portal authentication methods und SSL VPN authentication methods gewählt und mit Apply je Dienst übernommen sein; unter SFOS 22 ist das derselbe Entra-Server. Die vollständige Redirect URI beim gewählten Anbieter mit FQDN, Port und Pfad abgleichen und die erforderlichen Login-Endpunkte prüfen. Erfolgreiches SSO ersetzt weder Gruppenmitgliedschaft noch Policy members oder enge Firewall-Regeln. Vor der Umstellung Dienstzuweisungen, Serverreihenfolge und funktionierende Profile sichern. Nach SSO-Änderungen die aktuelle Konfiguration neu herunterladen und importieren, mit einem normalen Pilotbenutzer Portal, Tunnel, IdP-MFA, DNS sowie erlaubte und gesperrte Ziele testen. Bei Fehlern die dokumentierten Dienstzuweisungen, Reihenfolge und zugehörigen Profile wiederherstellen und dieselben Tests wiederholen; den bisherigen Zugang nicht vor erfolgreicher Abnahme entfernen.

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 wie Protokoll, Port, Interface, Serverzertifikat oder Override hostname, die aktuelle .ovpn erneut aus dem VPN Portal herunterladen, geschützt verteilen und bei manueller Bereitstellung erneut im Client importieren. Update policy ist hier nicht der erste Schritt und kein Ersatz für den manuellen Neuimport. Die dokumentierte Verwendung betrifft eine über .pro provisionierte Verbindung: Nach Änderung von SSL-VPN-Port oder Protokoll dort Update policy ausführen; weitere Konfigurationsänderungen ruft dieser Provisioning-Pfad automatisch ab. Bei Änderungen etwa an Port, Gateway, Serverzertifikat oder Protokoll kann eine erneute Anmeldung erforderlich sein. Ein Sophos-Connect-Softwareupdate ersetzt kein veraltetes Profil. Das bekannte funktionierende Profil und die zugehörigen globalen Firewall-Werte sicher für den Rollback aufbewahren; den neuen Import vor der breiten Verteilung mit einem normalen Pilotbenutzer auf Gateway/Port, Authentisierung/MFA, Routen, DNS sowie erlaubte und gesperrte Ziele prüfen. Bei fehlgeschlagener Abnahme die zusammengehörigen alten Werte und das bekannte funktionierende Profil wiederherstellen und dieselben Prüfungen wiederholen.

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.

.pro lädt IPsec (.scx) und die für den Benutzer berechtigten SSL-VPN-Konfigurationen (.ovpn) über das VPN Portal und ruft spätere Änderungen ab; die Datei ist selbst kein Tunnelprofil. Unterstützt sind passende Windows-Clients sowie Sophos Connect für macOS ab 2.1, nicht macOS 2.0 oder ältere Clients. IPsec-Provisioning benötigt Sophos Connect 2.1 oder neuer. Bei 2.0 auf macOS bleiben direkte Importe und kontrollierte manuelle Aktualisierung erforderlich.

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

Für SSO-Provisioning mit .pro unter Windows ab Sophos Connect 2.4 beschreibt SFOS 22 Entra ID; SFOS 23 unterstützt die dafür unterstützten OpenID-Connect-IdPs (OIDC), nicht beliebige Identitätsanbieter. Unter Authentication > Services müssen VPN Portal, IPsec VPN und SSL VPN denselben konfigurierten IdP-Server verwenden. gateway enthält nur den Firewall-FQDN oder die IP-Adresse aus dem Bereich Redirect URI dieses Servers, nicht die vollständige Callback-URI; der Portalport steht separat in vpn_portal_port. macOS ab Sophos Connect 2.1 bleibt für SSO hier auf Entra ID begrenzt, nicht auf allgemeines OIDC erweitert; die unten genannte Supportklärung vor dem Rollout bleibt erforderlich. Die provider- und versionsabhängigen Voraussetzungen erklärt der folgende Provisioning-Artikel.

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

Für Google Workspace SSO gilt hier Windows mit Sophos Connect 2.4 oder neuer; Entra-Hinweise zu macOS lassen sich nicht auf Google übertragen. Bei Entra nennen die Übersichtsseiten macOS ab 2.1, nicht 2.0, während die Anforderungsseiten nur Windows ab 2.4 nennen. Dieser Widerspruch bleibt auch im verlinkten Detailartikel offen: Vor einem macOS-Rollout stoppen, bis Support für den Ziel-Build, die Clientplattform/-version und den benötigten VPN-Typ separat bestätigt und getestet ist. Für jeden freigegebenen Pfad sind passende SFOS-Einstellungen, aktuelle Clientkonfiguration, Authentifizierungsmethoden und Redirect URI zu prüfen; MFA wird beim IdP getestet. Ein identischer Browserablauf oder die Übertragbarkeit der Windows-GPO-Verteilung auf macOS wird nicht zugesagt.

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.

SSL VPN mit Sophos Connect: Windows 10/11; macOS-Client 2.0 auf macOS 13+, ab Client 2.1 auf macOS 14+. Linux, iOS und Android verwenden einen kompatiblen OpenVPN-Client.

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.

Einrichtung vervollständigen und Diagnose vorbereiten

Für eine neue Umgebung: Unter Hosts and services > IP host > Add Namen und Netz beziehungsweise Hostadresse erfassen und Save wählen. Unter Authentication > Groups > Add die Gruppe SSLVPN_Users mit passender Surfing quota und Access time anlegen und speichern. Unter Authentication > Users > Add Benutzername, Anzeigename und diese Gruppe zuweisen und speichern. Unbegrenzter Internetzugang und zeitlich unbeschränkter Zugriff sind Beispielwerte, keine Sicherheitsvorgabe. Bei bestehenden Verzeichnisbenutzern die vorhandene Gruppenzuordnung prüfen, statt unnötig lokale Konten anzulegen.

Zusätzlich zu den oben beschriebenen globalen Werten prüfen:

Lease mode: IPv4 only vergibt nur IPv4; IPv4 and IPv6 both vergibt beide Adressfamilien. IPv6-Pool, Routen und Regeln müssen dazu passen. Use static IP addresses zeigt den automatisch aufgeteilten statischen Bereich; individuelle Adressen werden unter Authentication > Users zugewiesen.
IPv4 WINS: Primären und sekundären WINS-Server nur eintragen, wenn die Umgebung diesen Namensdienst benötigt. WINS ersetzt DNS nicht.
Encryption algorithm, Authentication algorithm und Key size: Verschlüsselung, Nachrichtenauthentifizierung und Schlüssellänge bewusst nach den freigegebenen Sicherheitsanforderungen wählen. Key lifetime wird in Sekunden angegeben. Für Fehlersuche nicht auf schwächere Kryptografie ausweichen.
Enable debug mode: Liefert ausführlichere SSL-VPN-Logs. Nur gezielt aktivieren, Logs geschützt behandeln und nach der Diagnose den vorherigen Zustand wiederherstellen.

Globale Änderungen mit Apply übernehmen. Bei einer extern signierten Zertifikatskette Serverzertifikat samt privatem Schlüssel sowie Zwischen- und Root-CA importieren. Auch Änderungen der Default CA bei ApplianceCertificate oder einem lokal signierten Zertifikat erfordern einen neuen manuellen .ovpn-Import. Keine UTF-8-Zeichen in Zertifikats- und CA-Feldern verwenden; Sonderzeichen in Benutzernamen können außerdem Portal, Dateinamen und Drittanbieterclients beeinträchtigen.

Bei einem einzelnen statischen öffentlichen WAN-IP kann Override hostname leer bleiben; bei mehreren Adressen entweder den gewünschten FQDN beziehungsweise eine bestimmte Interfaceadresse setzen oder die exportierten Einträge einzeln prüfen. Bei vorgeschaltetem NAT den öffentlichen Router-Endpunkt angeben und dessen Portweiterleitung prüfen; bei dynamischer Adresse zuerst Network > DDNS konfigurieren und den DDNS-FQDN verwenden. Im .ovpn die tatsächlichen Gatewayeinträge kontrollieren und die Namensauflösung separat testen.

Im Assistenten nach Prüfung der globalen Werte Next wählen, VPN name, Benutzer/Gruppen und Authentication servers festlegen. Die Optionen sind Same as VPN (IPsec, L2TP, PPTP), Same as firewall oder Set authentication method for SSL VPN. Tunnelmodus und Zonen getrennt auswählen; bei Split Tunnel die Ressourcen mit Apply selected items am Listenende bestätigen. Erst nach Prüfung Finish wählen und die erzeugten Regeln kontrollieren. Der Assistent ersetzt weder die Prüfung der SNAT-Regel noch die separate Einrichtung des IdP.

⚠️ Die Full-Tunnel-Anleitung behauptet einleitend, dass nur die in der Policy ausgewählten Ressourcen erreichbar seien; die Policy-Feldhilfe sagt ausdrücklich, dass Permitted network resources bei Use as default gateway nicht erzwungen werden. Auch eine ältere Diagnoseanleitung empfiehlt dort weiterhin Ressourcenauswahl. Diese widersprüchliche Aussage ist keine Zugriffsgarantie: für Full Tunnel ausschließlich explizite Firewall-Regeln als Zugriffskontrolle planen und erlaubte sowie gesperrte Ziele testen. Die breiten Any-Beispielregeln sind keine Pflicht; interne Freigaben und Internetzugang getrennt einschränken. Diese Anleitung ist dokumentarisch geprüft, nicht auf einer Kunden-Firewall ausgeführt.

Für den manuellen Clientweg im VPN Portal VPN öffnen, bei Bedarf Download for Windows oder Download for macOS wählen und installieren. Download configuration for Windows, macOS, Linux liefert .ovpn; im Client mit Import connection importieren und mit den Portal-Zugangsdaten oder dem vorbereiteten SSO anmelden. Alternativ kann der Administrator über Remote access VPN > SSL VPN > Download client den Installer beziehen. Der alte SSL-VPN-Client ist End-of-Life und wird im Portal nicht mehr angeboten.

Wenn nur einzelne Endpunkte scheitern, zuerst Internetzugang sowie OS-, Endpoint-Firewall- und Antivirus-Berechtigungen prüfen. Während eines Verbindungsversuchs unter Diagnostics > Packet capture den BPF-Filter port <SSL VPN port number> verwenden; Details im Sophos Connect Client zeigt die Verbindungsparameter. Fehlende Pakete beweisen keine ISP-Sperre. Erst andere Ursachen eingrenzen; eine erlaubte Port/Protokoll-Kombination nur nach Prüfung der WAF-/Portal-Konflikte und mit Profilverteilung und Rollback ändern. Der dokumentierte Android/OpenVPN-Kompressionsfehler betrifft SFOS 20.0 GA und früher, nicht pauschal SFOS 22/23.

Bei bestehendem Tunnel die Endpoint-Routingtabelle auf Zielnetz, TUN-Interface und geleaste Adresse prüfen. Fehlt die Route, zunächst reconnecten, Clientlog und Endpoint-Berechtigungen prüfen; ein erneuter Import hilft nur mit der passenden aktuellen Konfiguration. Unter Log viewer > Firewall nach In interface, Is, tun filtern und die Firewall rule-ID prüfen. Bei benutzergebundenen Regeln zusätzlich Match known users sowie User or groups kontrollieren. Zur Trennung von VPN- und internem Netzfehler unter Diagnostics > Tools die Erreichbarkeit vom Firewall-System zum Ziel testen; temporär erlaubtes Ping anschließend zurücknehmen. Bei Reconnect-Problemen auch Änderungen an Lease-, DNS-/WINS- und Domain-Werten prüfen und keine WAN-Interfaces als Permitted network resources verwenden. Policyänderungen beenden bestehende Tunnel nicht automatisch: Benutzer müssen getrennt neu verbinden.

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 unter SFOS 22: oauth_sso_vpn.log; für SFOS 23 die versionierten Loghinweise im jeweiligen Entra- oder Google-Detailartikel verwenden.
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. Wenn der Dienst UNREGISTERED anzeigt, 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. Verwenden Sie für diese Diagnoseausnahme 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 und vpnportal.log mit der Testzeit abgleichen; bei Entra unter SFOS 22 zusätzlich oauth_sso_vpn.log, unter SFOS 23 die versionierten OIDC-Loghinweise im jeweiligen Detailartikel verwenden. Denselben IdP-Server für Portal und SSL VPN, Redirect URIs 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.