Sophos Firewall SSL Site-to-Site VPN einrichten

Ein SSL Site-to-Site VPN verbindet die internen Netze zweier Sophos Firewalls über einen verschlüsselten Tunnel. Anders als bei IPsec haben beide Seiten eine feste Rolle: Die Client-Firewall baut die Verbindung immer auf, die Server-Firewall nimmt sie an.

Das passt besonders gut, wenn eine Filiale eine dynamische öffentliche IP-Adresse hat oder IPsec in einem vorgeschalteten Netz Schwierigkeiten bereitet. Die Zentrale mit statischer Adresse oder stabilem FQDN wird Server, die Filiale wird Client. Für wachsende Netze, dynamisches Routing, Redundanz oder eine Drittanbieter-Gegenstelle ist route-based IPsec meist flexibler; bei einer kleinen Sophos-zu-Sophos-Verbindung kann SSL Site-to-Site einfacher sein.

Diese Anleitung verwendet ein konkretes Beispiel:

Zentrale, Server: vpn.example.com, lokales Netz 10.10.0.0/24
Filiale, Client: dynamische öffentliche IP, lokales Netz 10.20.0.0/24
Verbindung: HQ-to-Branch
SSL-VPN-Port: 8443

vpn.example.com, die Objektnamen und beide Netze sind Platzhalter und werden durch die Werte der eigenen Umgebung ersetzt. 8443 ist der Standardport; er bleibt nur unverändert, wenn Portbelegung und Sicherheitsdesign dazu passen.

Der Kurzablauf lautet: Rollen und Netze festlegen, globale SSL-VPN-Werte prüfen, SSL VPN auf der Server-WAN-Zone erlauben, Serververbindung anlegen, .apc-Datei exportieren, auf der Client-Firewall importieren und danach Routen, Regeln und echten Nutztraffic kontrollieren.

⚠️ Die globalen SSL-VPN-Einstellungen werden auch von Remote-Access-SSL-VPN verwendet. Port, Protokoll, Zertifikat, Adressbereich oder Kryptografie deshalb nicht nur für diesen Tunnel ändern. Zuerst Auswirkungen auf bestehende Benutzerverbindungen und Profile prüfen.

Rollen, Netze und öffentlichen Zugang planen

Die Server-Firewall sollte die stabilere und bei unterschiedlichen Modellen die leistungsfähigere Appliance sein. Hat nur eine Seite eine statische öffentliche IP-Adresse, gehört diese Seite in die Serverrolle. Der Client kann hinter NAT oder an einem Anschluss mit dynamischer Adresse stehen, solange er den Server erreichen kann.

Vor der Konfiguration müssen folgende Punkte feststehen:

öffentliche IP oder FQDN der Server-Firewall;
Protokoll und Port für SSL VPN;
lokales Netz der Zentrale und lokales Netz der Filiale;
eindeutige, nicht überlappende Adressbereiche;
benötigte Dienste und erlaubte Verbindungsrichtungen;
Rückweg auf beiden Seiten;
alternativer Administrationszugang für den Change;
aktuelle SFOS-Versionen auf beiden Firewalls.

Überlappen sich die Netze, reicht diese Standardkonfiguration nicht. Dann braucht es ein bewusstes Übersetzungs- und Routingdesign; in der Praxis ist IPsec mit geplantem NAT dafür meist besser geeignet.

Kompatibilität vor dem Change prüfen

Seit SFOS 20.0 MR1 verwendet Sophos eine neuere OpenVPN-Komponente. SSL-Site-to-Site-Tunnel von SFOS 20.0 MR1 oder neuer verbinden sich nicht mit SFOS 18.5 oder älter und nicht mit UTM 9. In einer solchen Kombination müssen beide Sophos Firewalls aktualisiert oder stattdessen IPsec beziehungsweise ein RED-Tunnel verwendet werden.

Globale SSL-VPN-Einstellungen kontrollieren

Die gemeinsamen Einstellungen liegen auf der künftigen Server-Firewall unter:

Remote access VPN > SSL VPN > SSL VPN global settings

Für das Beispiel werden vor allem diese Werte geprüft:

Protocol: UDP ist meist die effizientere Ausgangswahl; TCP kann bei restriktiven Netzen helfen.
SSL server certificate: muss gültig und mit privatem Schlüssel sowie vollständiger Zertifikatskette importiert sein. Bei einem öffentlichen FQDN sollte das Zertifikat zu diesem Namen passen.
Override hostname: vpn.example.com, wenn die Clients genau diesen FQDN verwenden sollen.
Port: 8443, sofern kein bewusst geplantes anderes Portdesign besteht.
Assign IPv4 addresses: darf weder mit den beiden Standortnetzen noch mit anderen VPN-Pools kollidieren.
Cryptographic settings: bestehende Werte nicht ohne Kompatibilitäts- und Betriebstest ändern.

Steht die Server-Firewall hinter einem vorgeschalteten Router, muss dieser den gewählten Port und das Protokoll an die Firewall weiterleiten. Der FQDN zeigt dann auf die öffentliche Adresse des Routers. WAF und SSL VPN dürfen nicht dieselbe Kombination aus WAN-IP, Port und Protokoll verwenden.

Ändern sich später Port, Protocol, SSL server certificate oder Override hostname, muss die Serverkonfiguration erneut heruntergeladen und auf der Client-Firewall neu importiert werden. Der bestehende .apc-Export kennt die neuen Werte nicht.

Die vollständigen Abhängigkeiten der globalen Einstellungen erklärt SSL VPN Remote Access auf Sophos Firewall. Änderungen werden dort mit Blick auf bestehende Benutzerprofile, Lease-Bereiche, DNS und öffentlich erreichbare Dienste geplant.

SSL VPN für die Server-WAN-Zone erlauben

Auf der Server-Firewall wird der lokale SSL-VPN-Dienst für die eingehende Zone freigegeben:

Administration > Device access

Hat die Client-Firewall eine dynamische oder nicht sinnvoll eingrenzbare öffentliche Adresse, wird unter VPN services SSL VPN für WAN aktiviert. Das erlaubt nur den Tunnelaufbau zur Firewall; es ersetzt keine Firewall-Regel für den Nutztraffic zwischen den Standorten.

Sind die öffentlichen Quellnetze der Clientseite stabil bekannt, bleibt SSL VPN in der WAN-Matrix deaktiviert. Stattdessen wird eine gezielte Accept Local Service ACL Exception mit Source zone WAN, den bekannten Source Networks/Hosts, der Server-WAN-Adresse als Destination host und dem Service SSL VPN angelegt. Eine Accept-Ausnahme verengt keine bereits aktive WAN-Matrixfreigabe. Die Planung beschreibt Device Access auf Sophos Firewall sicher konfigurieren.

Serververbindung in der Zentrale anlegen

Zuerst werden auf der Server-Firewall die beiden Netze als IP-Hostobjekte angelegt:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

Danach wird die Serververbindung erstellt:

Site-to-site VPN > SSL VPN öffnen.
Im Bereich Server auf Add klicken.
Als Namen HQ-to-Branch eintragen.
Unter Local networks HQ-LAN auswählen.
Unter Remote networks Branch-LAN auswählen.
Nur bei begründetem Bedarf Use static virtual IP address aktivieren und eine freie Adresse ausserhalb der globalen statischen und dynamischen SSL-VPN-Bereiche wählen.
Mit Save speichern.

Local networks sind aus Sicht der Server-Firewall die Netze der Zentrale. Remote networks liegen hinter der Client-Firewall. Diese Blickrichtung ist wichtig: Werden die Objekte vertauscht, kann der Tunnel grün werden, während Routen und Regeln nicht zur gewünschten Verbindung passen.

Serverkonfiguration sicher exportieren

In der Serverliste wird bei HQ-to-Branch Download gewählt. Der Export hat das Format .apc und enthält die Verbindungsdaten für die Client-Firewall.

Für einen sicheren Transfer wird Encrypt configuration file aktiviert und ein starkes temporäres Passwort gesetzt. Datei und Passwort werden über getrennte Kanäle übertragen. Die .apc-Datei gehört nicht in ein öffentliches Ticket, einen ungeschützten Chat oder ein dauerhaftes Downloadverzeichnis.

Konfiguration auf der Client-Firewall importieren

Auf der Filial-Firewall erfolgt der Import unter demselben Menüpfad:

Site-to-site VPN > SSL VPN öffnen.
Im Bereich Client auf Add klicken.
Als Namen Branch-to-HQ eintragen.
Unter Configuration file die exportierte .apc-Datei auswählen.
Bei verschlüsseltem Export das Passwort eingeben.
Use HTTP proxy server nur aktivieren, wenn die Filiale den Server tatsächlich über einen expliziten HTTP-Proxy erreicht.
Override peer hostname nur setzen, wenn die im Export enthaltene Serveradresse aus dem Clientnetz nicht routbar oder nicht auflösbar ist. Im Beispiel bleibt das Feld leer, weil bereits global vpn.example.com exportiert wird.
Mit Save speichern und die Verbindung aktivieren.

Der Status wird grün, sobald die Client-Firewall den Server erreicht und der Tunnel aufgebaut ist. Ein grüner Status bestätigt nur die Verbindung selbst, noch nicht den Zugriff auf Server, DNS oder Anwendungen.

Routen und Firewall-Regeln kontrollieren

Die unter Local networks und Remote networks gewählten Netze werden für das Tunnelrouting wirksam. Sie gehören zur Routing-Klasse static und müssen zur übrigen Routing-Konfiguration passen. Eine spezifischere statische, SD-WAN- oder VPN-Route kann sonst einen anderen Pfad ergeben als erwartet. Die Reihenfolge erklärt Routing-Priorität auf Sophos Firewall verstehen und anpassen.

Firewall-Regeln für den Nutztraffic werden auf beiden Firewalls bewusst erstellt oder gegen vorhandene Regeln geprüft. Im Beispiel, in dem die Filiale Verbindungen zur Zentrale initiiert, braucht es mindestens:

auf der Filial-Firewall eine enge Regel von LAN nach VPN für Branch-LAN zu den benötigten Zielen in HQ-LAN;
auf der Server-Firewall eine passende Regel von VPN nach LAN für Branch-LAN zu diesen Zielen;
nur die benötigten Dienste, beispielsweise DNS, RDP und HTTPS;
Log firewall traffic für die Abnahme;
keine SNAT- oder MASQ-Regel, die den Standorttraffic ohne fachlichen Grund verändert.

Soll auch die Zentrale neue Verbindungen zur Filiale aufbauen, werden die Gegenrichtungen separat freigegeben. Eine breite Any-Regel ist kein fertiges Sicherheitsdesign. Wie Regelposition, Rule ID und Packet Capture zusammen geprüft werden, zeigt Firewall-Regel testen.

Tunnel und Nutztraffic abnehmen

Der Test beginnt mit einem konkreten Client und einem konkreten Ziel. Im Beispiel greift ein Gerät aus 10.20.0.0/24 auf einen erlaubten Server in 10.10.0.0/24 zu.

Auf beiden Firewalls den grünen Status und steigende Byte-Zähler kontrollieren.
Ziel zuerst per IP-Adresse und danach per Hostname testen.
Einen tatsächlich erlaubten Dienst wie HTTPS oder RDP aufrufen.
Im Log Viewer die erwartete Firewall Rule ID und die unveränderten Quell- und Zieladressen prüfen.
Einen nicht erlaubten Dienst oder ein nicht freigegebenes Ziel testen und den Drop bestätigen.
Die Gegenrichtung separat prüfen, falls sie fachlich erlaubt sein soll.
Nach einem Neustart oder WAN-Wechsel kontrollieren, ob die Client-Firewall den Tunnel wieder aufbaut.

Ein erfolgreicher Ping genügt nicht. Er beweist weder DNS noch den benötigten Anwendungsdienst. Bei einem internen Zielsystem müssen Firewall-Regel, Rückweg und Endpoint-Firewall zum Test passen; Device Access ist nur relevant, wenn eine Adresse der Sophos Firewall selbst angepingt wird.

Logs bei einem Fehler lesen

Unter Site-to-site VPN > SSL VPN > Logs lässt sich die SSL-VPN-Protokollierung direkt öffnen. Für eine tiefere Prüfung meldet man sich per SSH an, wählt 5. Device Management > 3. Advanced Shell und liest das aktuelle Service-Log:

tail -n 200 /log/sslvpn.log

Der Befehl verändert keine Konfiguration. Zeitpunkt, Verbindungsname und Server-/Clientseite werden zusammen dokumentiert. Weitere OpenVPN-Statusdateien können je nach Anzahl der Prozesse als openvpn-status0.log, openvpn-status1.log und weitere Dateien vorhanden sein; die Zuordnung erklärt Sophos Firewall Service-Logs.

Typische Fehler gezielt eingrenzen

Tunnel bleibt rot: Öffentlichen FQDN, DNS, Portweiterleitung, Protokoll, Zertifikat und SSL VPN in Device Access auf der Server-WAN-Zone prüfen. Danach sslvpn.log zum gleichen Zeitpunkt lesen.
Nach einer globalen Änderung kommt der Tunnel nicht mehr hoch: Serverkonfiguration neu exportieren und auf dem Client erneut importieren. Besonders Port, Protokoll, Zertifikat und Override hostname sind exportabhängig.
Tunnel ist grün, aber kein Traffic fliesst: Tunnelrouting, Routing-Priorität, Regeln auf beiden Firewalls, Rule ID, Rückweg, NAT und Endpoint-Firewall prüfen. Danach einen einzelnen Flow per Packet Capture verfolgen.
Nur Namen funktionieren nicht: Zugriff per IP testen, DNS-Server und Suchdomain prüfen und sicherstellen, dass der DNS-Server über den Tunnel erreichbar und erlaubt ist.
FQDN-Hostobjekt zeigt noch auf die alte Adresse: FQDN-Hosts und -Gruppen sind als lokale und entfernte Netze unterstützt. Nach einer DNS-Änderung den Tunnel kontrolliert trennen und neu verbinden und danach Route sowie Nutztraffic zur neu aufgelösten IP prüfen. Fehlende Auflösung ist zuerst ein Traffic- oder Routingfehler, nicht automatisch ein Fehler beim Tunnelaufbau.
Client erreicht den Server nur über einen Proxy: Use HTTP proxy server mit den freigegebenen Proxywerten verwenden; keine zufälligen Proxyangaben als allgemeinen Workaround eintragen.
Eine Seite läuft auf SFOS 18.5 oder UTM 9: Nicht weiter an Port oder Zertifikat suchen. Mit einer aktuellen Gegenstelle ist diese Kombination inkompatibel; beide Seiten aktualisieren oder IPsec beziehungsweise RED einsetzen.

Wenn der Tunnel nach einem kontrollierten Test weiterhin unklar bleibt, werden SFOS-Version und Build beider Firewalls, Uhrzeit mit Zeitzone, Verbindungsname, sslvpn.log, Rule IDs und ein kurzer Packet Capture gesichert. Erst danach sollten Regeln, Netze oder globale SSL-VPN-Werte weiter verändert werden.