Sophos Firewall Site-to-Site IPsec VPN einrichten

Ein Site-to-Site IPsec VPN verbindet zwei Standorte oder eine Sophos Firewall mit einer Drittanbieter-Firewall über einen verschlüsselten Tunnel. In der Praxis scheitert ein solcher Tunnel selten an einem einzelnen Haken in der Oberfläche. Häufiger sind unklare Netze, unterschiedliche IPsec-Profile, fehlende Firewall-Regeln, NAT-Sonderfälle oder ein Rückweg, der auf einer Seite vergessen wurde.

Der Artikel erklärt den sauberen Aufbau eines Site-to-Site-IPsec-Tunnels auf der Sophos Firewall. Der Fokus liegt auf Planung, Umsetzung und Abnahmetest. Wenn ein bestehender Tunnel bereits grün ist, aber kein Traffic fliesst, ist zusätzlich Sophos Firewall IPsec VPN Troubleshooting der bessere Anschlussartikel.

Wann dieser Artikel passt

Der Artikel passt für klassische Standortverbindungen, zum Beispiel:

• Hauptstandort zu Filiale
• Sophos Firewall zu Sophos Firewall
• Sophos Firewall zu Drittanbieter-Firewall
• Sophos Firewall zu Cloud-Gateway, wenn kein spezieller Cloud-Assistent genutzt wird
• Migration von einfachen alten policy-based Tunneln auf eine dokumentierte aktuelle Konfiguration

Nicht gemeint ist Remote Access für einzelne Benutzer. Dafür passen die Artikel Sophos Connect auf Sophos Firewall konfigurieren, Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt? und Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren.

Policy-based oder route-based IPsec

Vor der Konfiguration muss entschieden werden, ob der Tunnel policy-based oder route-based aufgebaut wird. In aktuellen SFOS-Versionen sind diese Begriffe deutlicher getrennt als in älteren Anleitungen, die teilweise noch von Site-to-Site oder Tunnel Interface sprechen.

Für kleine, stabile Verbindungen ist policy-based IPsec oft am schnellsten verständlich. Für grössere oder dynamische Standortnetze ist route-based IPsec meist sauberer, weil Routing und VPN-Verhandlung besser getrennt sind. Wenn mehrere Netze, SD-WAN, BGP, OSPF oder Cloud-Netze beteiligt sind, sollte route-based IPsec bevorzugt geprüft werden.

Voraussetzungen

Vor dem Einrichten sollten diese Informationen dokumentiert sein:

⚠️ Site-to-Site VPN sollte nicht ohne dokumentierten Rückweg umgesetzt werden. Wenn die lokale Firewall Traffic in den Tunnel sendet, die Gegenstelle aber keine Route zurück kennt oder NAT anders erwartet, sieht der Tunnel oft gesund aus, obwohl Anwendungen nicht funktionieren.

Vor der Konfiguration planen

Netze eindeutig halten

Lokale und entfernte Netze dürfen sich nicht ungewollt überschneiden. Besonders problematisch sind häufige Standardnetze wie 192.168.0.0/24, 192.168.1.0/24 oder mehrfach verwendete Filialnetze. Wenn sich Netze überschneiden, braucht es ein bewusstes NAT-Design. Einfach denselben Adressbereich auf beiden Seiten zu verwenden und später “irgendwie” zu übersetzen, erzeugt schwer wartbare Tunnel.

Für neue Standorte lohnt sich deshalb ein sauberes IP-Adresskonzept. Wenn VLANs oder Zonen noch nicht sauber modelliert sind, hilft Sophos Firewall Zonen und Interfaces konfigurieren.

IPsec-Profil abstimmen

Beide Seiten müssen bei Phase 1 und Phase 2 kompatible Parameter verwenden. Dazu gehören Verschlüsselung, Authentifizierung, DH-Gruppe, PFS und Lebensdauer. Bei Verbindungen zu Drittanbieter-Firewalls ist es oft am einfachsten, zuerst ein gemeinsames Profil schriftlich festzuhalten und danach beide Seiten zu konfigurieren.

Wenn ein Tunnel nicht hochkommt, sind NO_PROPOSAL_CHOSEN, ID-Fehler oder Authentifizierungsfehler typische Hinweise. Die strukturierte Analyse steht in Sophos Firewall IPsec VPN Troubleshooting.

Firewall-Regeln nicht vergessen

Ein IPsec-Tunnel erlaubt noch keinen produktiven Zugriff. Traffic durch den Tunnel braucht weiterhin passende Firewall-Regeln. Bei policy-based Verbindungen sind das meistens Regeln zwischen LAN und VPN oder zwischen eigenen Zonen. Bei route-based Designs hängt es davon ab, welcher Zone das XFRM-Interface beziehungsweise der relevante Pfad zugeordnet ist.

Für die Einführung sollte Log firewall traffic in den betroffenen Regeln aktiviert werden. Sonst fehlt später genau die Information, welche Regel einen Test erlaubt oder blockiert hat. Der allgemeine Prüfablauf steht in Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Automatisch erstellte Regeln bewusst prüfen

Beim Erstellen einer Site-to-Site-IPsec-Verbindung kann die Option Create firewall rule helfen, einen ersten Regelsatz anzulegen. Das ersetzt aber keine Sicherheitsprüfung. Sophos Firewall erstellt diese Regeln an oberster Stelle der Firewall-Regelliste. In aktuellen SFOS-Versionen entstehen dafür getrennte Regeln für eingehenden und ausgehenden Traffic mit den Präfixen Incoming und Outgoing.

Für den Betrieb ist deshalb wichtig:

⚠️ Automatisch erstellte Firewall-Regeln sind ein Startpunkt, kein fertiges Sicherheitsdesign. Besonders bei Standorttunneln zu Servernetzen sollte man nach dem ersten Test die Dienste, Quellen und Ziele reduzieren.

Bei route-based IPsec mit Any-zu-Any-Subnetzen muss man besonders sauber arbeiten. Für solche route-based Designs können keine automatischen Firewall-Regeln erstellt werden. Bei Dual-IP-Versionen sind IPv4- und IPv6-Regeln getrennt zu planen. In diesen Szenarien sollten Firewall-Regeln, XFRM-Interface, Routen und Tests bewusst manuell aufgebaut werden.

Policy-based IPsec einrichten

Policy-based IPsec ist die klassische Variante für einfache Site-to-Site-Verbindungen. Die lokalen und entfernten Netze werden direkt in der IPsec-Verbindung definiert.

1. IPsec-Profil prüfen oder erstellen

Menüpfad:

Profiles > IPsec profiles

Zuerst prüfen, ob ein vorhandenes Profil zur Gegenstelle passt. Wenn ein eigenes Profil benötigt wird, sollte es eindeutig benannt werden, zum Beispiel IPsec_IKEv2_AES256_G14. Der Name muss später verständlich bleiben, wenn mehrere Tunnel und Gegenstellen existieren.

Zu dokumentieren sind mindestens:

• IKE-Version
• Phase-1-Encryption und Authentication
• DH Group
• Phase-2-Encryption und Authentication
• PFS
• Key lifetime

Bei Drittanbieter-Firewalls sollte die Gegenstelle dieselben Werte schriftlich bestätigen. Ein Screenshot allein ist oft nicht genug, weil einzelne Felder je nach Hersteller anders benannt sind.

2. IPsec-Verbindung hinzufügen

Menüpfad:

Site-to-site VPN > IPsec

Eine neue IPsec-Verbindung erstellen und als Connection type Policy-based wählen. Danach die Grunddaten setzen:

• Name des Tunnels, zum Beispiel branch-zurich
• Lokales Gateway beziehungsweise Listening interface
• Remote Gateway als IP-Adresse oder FQDN
• Authentication type: Preshared Key oder Zertifikat
• Local ID und Remote ID, falls benötigt
• IPsec profile
• Local subnet
• Remote subnet

Bei Preshared Keys sollte ein starker, eindeutiger Schlüssel verwendet und sicher dokumentiert werden. Ein gemeinsam genutzter alter Standardschlüssel über mehrere Standorte ist ein unnötiges Betriebsrisiko.

3. Tunnel aktivieren

Beim Speichern kann Activate on save gesetzt werden. Bei produktiven Umgebungen sollte das in einem definierten Wartungsfenster passieren, wenn die Gegenstelle erreichbar ist und beide Seiten Logs prüfen können.

Nach dem Speichern zeigt die Liste zwei relevante Zustände:

• ob die Verbindung aktiv ist
• ob der Tunnel tatsächlich established ist

Ein aktiver Eintrag ist nicht automatisch ein aufgebauter Tunnel. Bei mehreren lokalen oder entfernten Netzen kann es ausserdem mehrere Security Associations geben.

Route-based IPsec einrichten

Route-based IPsec trennt VPN-Verhandlung und Routing klarer. Sophos Firewall erstellt dabei ein XFRM-Interface. Danach entscheiden statische Routen, SD-WAN Routes oder dynamisches Routing, welcher Traffic durch den Tunnel läuft.

1. Verbindung als route-based erstellen

Menüpfad:

Site-to-site VPN > IPsec

Bei der Verbindung Route-based (Tunnel interface) wählen. Die Parameter für Gateway, Authentifizierung, IDs und IPsec-Profil müssen weiterhin zur Gegenstelle passen. Zusätzlich muss man verstehen, welches XFRM-Interface danach entsteht und wie es geroutet wird.

Sophos zeigt das erzeugte XFRM-Interface unter dem verwendeten physischen Interface in:

Network > Interfaces

Je nach Design braucht das XFRM-Interface eine IP-Adresse. Besonders bei Any-zu-Any-Designs, Dual-IP-Version oder komplexeren Routing-Szenarien sollte die Interface-Adressierung sauber geplant werden.

Wenn Any-zu-Any verwendet wird, entscheidet nicht mehr der Tunnel-Selector allein, welcher Traffic durch den Tunnel geht. Routen und Firewall-Regeln werden dann zur zentralen Steuerung. Das ist flexibel, aber auch fehleranfällig: Eine zu breite Regel kann mehr Traffic erlauben als beabsichtigt, eine fehlende Route kann den Tunnel grün zeigen lassen, ohne dass Nutztraffic fliesst.

2. Routing setzen

Bei route-based VPN reicht die IPsec-Verbindung allein nicht. Es braucht eine Route zum entfernten Netz:

• statische Route zum XFRM-Interface
• SD-WAN Route mit passendem Gateway oder Profil
• dynamische Route über BGP oder OSPF, wenn das Design dafür gebaut ist

Für einfache Setups ist eine statische Route oft ausreichend. Wenn mehrere WAN-Leitungen, SLA-Prüfungen oder Failoverpfade genutzt werden, ist eine SD-WAN Route sinnvoller. Der allgemeine Kontext zu SD-WAN, Reply Packets und systemgeneriertem Traffic steht in Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen.

3. XFRM und MTU beachten

Route-based VPNs sind anfälliger für Missverständnisse bei Routing, MTU und MSS. Wenn kleine Tests funktionieren, grössere Transfers aber hängen bleiben, sollte man nicht sofort das IPsec-Profil ändern. Zuerst MTU, MSS, Fragmentierung und den echten Pfad prüfen. Der passende Ablauf steht in Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Firewall-Regeln erstellen

Nach der IPsec-Konfiguration braucht es Regeln für den produktiven Traffic. Ohne passende Regeln bleibt der Tunnel zwar möglicherweise grün, Anwendungen funktionieren aber nicht.

Menüpfad:

Rules and policies > Firewall rules

Typische Regeln:

Gute Praxis:

• Regelname mit Tunnel oder Standort, zum Beispiel LAN_to_Branch_Zurich.
• Source und Destination so eng wie möglich setzen.
• Services konkret definieren.
• Logging während Einführung und Troubleshooting aktivieren.
• Regelposition prüfen.
• Schutzfunktionen bewusst setzen, statt sie zufällig zu übernehmen.

Wenn der Tunnel Internettraffic einer Filiale über die Zentrale führen soll, braucht es zusätzlich ein bewusstes NAT- und Sicherheitskonzept. Das ist ein anderes Design als eine einfache Standortverbindung für interne Netze.

NAT bewusst planen

NAT ist bei IPsec nicht verboten, aber es muss klar begründet sein. Typische Fälle sind überlappende Netze, Cloud-Vorgaben oder Drittanbieter, die nur bestimmte Quelladressen akzeptieren.

Menüpfad:

Rules and policies > NAT rules

Vor einer NAT-Regel sollten diese Fragen beantwortet sein:

• Erwartet die Gegenstelle Original-IP-Adressen oder übersetzte Adressen?
• Gibt es überlappende Netze?
• Wird NAT in der IPsec-Verbindung oder über separate NAT-Regeln gelöst?
• Ist die Rückrichtung dokumentiert?
• Sieht der Log Viewer nach NAT die erwartete Source und Destination?

Für policy-based Sonderfälle mit NAT kann eine manuelle IPsec Route auf Sophos Firewall relevant werden. Das ist aber kein Standard-Schritt für jeden Tunnel.

Device Access und WAN-Zugriff

Für eingehende IPsec-Anfragen muss die Firewall IPsec-Traffic auf der passenden WAN-Zone annehmen können. Das wird nicht über eine normale LAN-zu-WAN-Regel gelöst, sondern über die lokalen Dienste der Firewall.

Menüpfad:

Administration > Device access

Dort muss IPsec für die benötigte Zone erlaubt sein. Gleichzeitig sollte man prüfen, ob andere lokale Dienste wie WebAdmin, SSH, User Portal oder VPN Portal unnötig breit erreichbar sind. Für die Härtung dieser lokalen Dienste ist Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren der zentrale Artikel.

Tunnel testen

Ein guter Abnahmetest prüft nicht nur den grünen Status. Er prüft den tatsächlichen Datenfluss.

1. Status prüfen

In der WebAdmin-Oberfläche:

Site-to-site VPN > IPsec

Prüfen:

• Verbindung ist aktiv.
• Tunnelstatus ist established.
• Bei mehreren Netzen sind alle erwarteten Child SAs aufgebaut.
• Keine wiederkehrenden Reconnects oder Fehler sichtbar.

2. Log Viewer prüfen

Menüpfad:

Log viewer

Testtraffic mit klarer Source, Destination und Service erzeugen. Danach im Log Viewer prüfen, welche Firewall-Regel matcht und ob NAT, Webfilter, IPS oder andere Module den Traffic beeinflussen.

3. Packet Capture verwenden

Wenn der Log Viewer nicht reicht, sollte Packet Capture mit engem Filter verwendet werden:

Diagnostics > Tools > Packet capture

Filterbeispiel:

host 172.16.10.25 and host 10.20.30.15

Bei VPN-Troubleshooting ist wichtig, beide Richtungen zu prüfen. Nur ausgehende Pakete ohne Antwort zeigen meistens ein Rückweg-, NAT- oder Gegenstellenproblem.

4. CLI nur gezielt verwenden

Für tiefere Analyse kann per SSH die Advanced Shell genutzt werden:

ipsec statusall

Dabei sind unter anderem interessant:

• IKE SA established
• Child SA installed
• lokale und entfernte Netze
• Byte-Zähler in beide Richtungen
• wiederkehrende Rekey- oder Disconnect-Meldungen

Wenn SSH noch nicht vorbereitet ist, hilft Sophos Firewall per SSH verbinden.

Typische Fehler

Checkliste

Vor dem Change:

• Lokale und entfernte Netze sind eindeutig.
• Policy-based oder route-based wurde bewusst entschieden.
• IPsec-Profil ist mit der Gegenstelle abgestimmt.
• Preshared Key oder Zertifikate sind sicher dokumentiert.
• Firewall-Regeln sind geplant, inklusive Richtung, Regelposition, Logging und Diensten.
• Bei Create firewall rule ist klar, welche automatisch erstellten Regeln nachbearbeitet werden müssen.
• Bei route-based Any-zu-Any sind manuelle Firewall-Regeln und Routen eingeplant.
• NAT ist entweder ausgeschlossen oder bewusst dokumentiert.
• Device Access für IPsec ist geprüft.
• Wartungsfenster, Gegenstelle und Rückfallweg sind bekannt.

Nach dem Change:

• Tunnelstatus ist established.
• Log Viewer zeigt die erwartete Firewall-Regel.
• Packet Capture zeigt Hin- und Rückrichtung.
• Interne DNS- und Anwendungszugriffe wurden getestet.
• Byte-Zähler steigen in beide Richtungen.
• NAT und Rückweg sind mit der Gegenstelle abgeglichen.
• Änderung ist in der Netzwerkdokumentation nachgeführt.

Häufige Fragen