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.

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:

SSL server certificate unter den globalen SSL-VPN-Einstellungen authentifiziert den Tunnelserver.
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.

Für IPv4 akzeptiert SFOS hier höchstens ein /24; kleinere Netze wie /25 sind nicht auswählbar. Der Zugriff wird nicht durch einen künstlich kleinen Pool, sondern über Policy und Firewall-Regeln begrenzt. In 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 DNS stattdessen unter Administration > Device access für die VPN-Zone erlaubt. 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.

SSL-VPN-Policy erstellen

Die Policy wird manuell oder über den Assistenten angelegt:

Remote access VPN > SSL VPN

Der Assistent zeigt die globalen Einstellungen nur zur Kontrolle an und kann sie nicht ändern. Er erstellt die Policy, setzt die gewählte Authentifizierung sowie Device Access für VPN Portal und SSL VPN und legt die Firewall-Regel an. In bestehenden Umgebungen ist Configure manually meist 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.
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.

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.

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.

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

Bei einer manuell importierten .ovpn-Datei müssen profilrelevante globale Änderungen erneut heruntergeladen und importiert werden. Dazu gehören insbesondere Protokoll, Port, Interface, Serverzertifikat und weitere Werte der globalen SSL-VPN-Konfiguration. Ein Sophos-Connect-Update 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.

Nach Änderungen an Policy members, Permitted network resources oder der IP-Adresse eines FQDN-Ziels genügt dagegen normalerweise ein Disconnect und Reconnect. Diese Änderungen erfordern keinen neuen .ovpn-Download.

Eine .pro-Provisioning-Datei wird nur auf Windows 10 und 11 unterstützt. Sie lädt die für den Benutzer verfügbaren IPsec- und SSL-VPN-Konfigurationen und spätere Änderungen automatisch. Ändern sich der Provisioning-gateway oder der VPN-Portal-Port, muss auch die .pro angepasst und neu verteilt werden. Bei der ersten Bereitstellung 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.

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.

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.

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

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.