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.

Kurzablauf: Tunneltyp wählen, Profil und IDs abgleichen, Verbindung anlegen, bei route-based Any-to-Any das XFRM-Interface routen, Firewall- und NAT-Regeln setzen und den Tunnel mit echtem Traffic, Logs und Packet Capture abnehmen.

Der Ablauf passt für Sophos-zu-Sophos- und Drittanbieter-Verbindungen zwischen Hauptstandort, Filiale oder Cloud-Gateway. Für Microsoft Azure und AWS gelten zusätzliche Providerdetails: Sophos Firewall mit Azure VPN Gateway verbinden und Sophos Firewall mit AWS Site-to-Site VPN verbinden. Für Remote Access einzelner Benutzer hilft stattdessen die Entscheidung zwischen Sophos Connect und SSL VPN. Wenn ein bestehender Tunnel bereits grün ist, aber kein Traffic fliesst, passt Sophos Firewall IPsec VPN Troubleshooting.

Wenn ausschliesslich zwei Sophos Firewalls verbunden werden und die Filiale den Tunnel als Client zu einer statisch erreichbaren Zentrale aufbauen soll, ist SSL Site-to-Site VPN eine einfachere Alternative. Für Drittanbieter, Redundanz, dynamisches Routing oder wachsende Netze bleibt route-based IPsec die flexiblere Wahl.

Bei mehreren von Sophos Fusion (ehemals Sophos Central) verwalteten Firewalls kann eine SD-WAN Connection Group die route-based Tunnel, XFRM-Interfaces, Routen und optionalen Regeln automatisch erzeugen. Das ersetzt weder die Topologieplanung noch den lokalen Traffic-Test.

Policy-based oder route-based wählen

Vor der Konfiguration muss entschieden werden, ob der Tunnel policy-based oder route-based aufgebaut wird. Route-based wird ausserhalb der Sophos-Oberfläche oft auch tunnel-based genannt. Gemeint ist in beiden Fällen ein Tunnel mit eigener XFRM-Schnittstelle. Der gelegentlich verwendete Begriff “root-based” ist dagegen keine VPN-Betriebsart.

Sophos empfiehlt route-based VPN für neue Designs. Any-to-Any ist bei wachsenden Netzen besonders flexibel, weil Änderungen an Routen den Tunnel nicht trennen. Änderungen an Subnetzen oder Traffic Selectors unterbrechen dagegen bestehende Verbindungen. Beide Tunnelenden müssen denselben Typ verwenden: Policy-based an einem Ende und route-based am anderen wird nicht unterstützt.

Für OSPF oder BGP über den Tunnel ist route-based Any-to-Any mit adressierten XFRM-Interfaces der nachvollziehbare Aufbau. Wer von einer älteren policy-based Lösung aktualisiert, sollte vorher prüfen, ob VPN-Netze über redistribute kernel angekündigt werden; SFOS 22: IPsec-Routen und redistribute kernel erklärt die Versionsänderung und den sicheren Migrationsrahmen.

Was ein grüner Tunnel wirklich bestätigt

Ein Status wie Established bestätigt, dass die Peers IKE und mindestens eine Child SA ausgehandelt haben. Er bestätigt nicht, dass eine Route gewählt wird, die Firewall-Regel passt, NAT korrekt ist, die Gegenstelle einen Rückweg kennt oder der Zielhost antwortet. Deshalb kann ein Tunnel grün sein und trotzdem keinen nutzbaren Standortverkehr transportieren.

Sophos Firewall verwendet ESP im Tunnelmodus. ESP schützt die Datenintegrität, authentifiziert den Ursprung der Nutzdaten und bietet Anti-Replay-Schutz gegen erneut eingespielte Pakete.

Als Denkmodell sieht der Datenpfad so aus:

Policy-based
Quelle -> Firewall-Regel -> Local/Remote Selector -> Child SA -> Peer -> Rückroute und Regel -> Ziel

Route-based Any-to-Any
Quelle -> Route oder SD-WAN Route -> Firewall-Regel -> XFRM -> Child SA -> Peer -> Rückroute und Regel -> Ziel

Das ist ein Prüfmodell und keine vollständige Darstellung der internen SFOS-Verarbeitungsreihenfolge. Für die Abnahme ist die Unterscheidung trotzdem entscheidend: Bei policy-based bestimmt das Netzpaar in der IPsec-Verbindung, welcher Traffic zum Tunnel gehört. Bei route-based Any-to-Any trifft die Routing- oder SD-WAN-Entscheidung diese Auswahl.

Voraussetzungen und Planungsdaten

Vor dem Einrichten werden mindestens diese Angaben dokumentiert:

• Lokaler Endpunkt: WAN-Interface der Sophos Firewall und die Adresse, über welche die Gegenstelle dieses Interface erreicht.
• Remote Gateway: öffentliche IP oder DNS-Hostname der Gegenstelle.
• Gateway type: Zentrale meistens Respond only, Filiale meistens Initiate the connection.
• IP version: IPv4, IPv6 oder Dual. Dual ist nur für route-based Tunnel-Interfaces mit Any-to-Any als lokale und entfernte Subnetze verfügbar. Bei Dual müssen IPv4- und IPv6-Firewall-Regeln separat geplant werden.
• Lokale Netze: zum Beispiel 172.16.10.0/24 und 172.16.20.0/24.
• Remote Netze: zum Beispiel 10.20.30.0/24.
• VPN-Typ: policy-based oder route-based. Der Connection type Host-to-host existiert ebenfalls, ist aber nicht der Fokus dieser Standortanleitung.
• Listening interface: WAN-Interface der lokalen Firewall. Ein Bridge-Interface kann dafür nicht verwendet werden.
• IKE-Version: bevorzugt IKEv2, falls die Gegenstelle es unterstützt.
• Authentication type: Preshared key, Digital certificate oder RSA key.
• Local ID und Remote ID: besonders wichtig bei FQDN, dynamischen Gegenstellen, NAT-T oder Wildcard-Gateway.
• IPsec-Profil: Encryption, Authentication, DH Group, PFS und Key life.
• Firewall-Regeln: erlaubte Quellen, Ziele und Dienste.
• NAT: kein NAT, SNAT/DNAT wegen überlappenden Netzen oder Provideranforderung.
• Betrieb: Owner, Wartungsfenster, Testplan, Monitoring und Rückfallweg.

Durchgängiges Beispiel für beide Firewalls

Die folgenden Dokumentationswerte machen die späteren Schritte nachvollziehbar. Sie werden vollständig durch die eigenen WAN-Adressen, Netze und Namen ersetzt:

Die beiden LAN-Netze werden zuerst unter Hosts and services > IP host als Netzwerkobjekte angelegt. Auf der Zentrale ist 10.10.10.0/24 das Local subnet und 10.20.20.0/24 das Remote subnet; auf der Filiale werden diese Werte vertauscht. Dasselbe gilt für die IDs: Die Local ID einer Seite muss als Remote ID der Gegenstelle erwartet werden. Das Transfernetz 10.255.0.0/30 wird nur bei route-based Any-to-Any verwendet und darf mit keinem produktiven, VPN- oder Managementnetz kollidieren.

⚠️ 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.

Netze, Profil, IDs und Zertifikate

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.

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.

Bei IKEv2 kann Sophos eindeutige Preshared Keys pro Local-/Remote-ID-Kombination verwenden. Bei IKEv1 ist dieses Verhalten eingeschränkter, weil pro Gateway-Kombination nur ein PSK greift. In Umgebungen mit mehreren Tunneln zur gleichen Gegenstelle sollte deshalb IKEv2 mit sauberen IDs bevorzugt werden.

⚠️ Bei IKEv1 verwendet die Firewall für dieselbe Kombination aus lokalem und entferntem Gateway den PSK der zuletzt konfigurierten Verbindung. Das gilt für Site-to-Site- und Remote-Access-IPsec-Konfigurationen. Wird später eine Verbindung für diese Gateway-Kombination mit einem anderen PSK konfiguriert, kann die Authentifizierung bestehender Verbindungen bei einer folgenden Aushandlung fehlschlagen. Vor dem Anlegen einer solchen Verbindung oder einer PSK-Änderung alle betroffenen IKEv1-Konfigurationen prüfen und den PSK mit den jeweiligen Gegenstellen vor der nächsten Aushandlung abgleichen.

NAT Traversal ist auf der Sophos Firewall immer aktiv. Wenn eine Seite hinter einem Router oder Provider-NAT steht, werden IDs wichtiger, weil die öffentliche Gateway-Adresse den Peer nicht eindeutig beschreibt. Die Local ID einer Seite muss zur erwarteten Remote ID der Gegenstelle passen. DNS-, IP- oder E-Mail-IDs müssen nicht öffentlich auflösbar sein, aber Format und Wert müssen kreuzweise übereinstimmen.

Auf Sophos Firewall gibt es dafür keinen separat auswählbaren NAT-T-Schalter: Die Geräte erkennen NAT automatisch. Ohne NAT laufen IKE-Aushandlungen über UDP 500 und der Nutztraffic als ESP über IP protocol 50. Erkennt die Firewall ein NAT-Gerät, kapselt sie die weiteren IKE- und Phase-2-Aushandlungen sowie ESP-Pakete in UDP 4500.

Wenn auf dem IPsec-Pfad ein NAT-Gerät liegt und die Gegenstelle eine Drittanbieter-Firewall ist, muss NAT-T auch dort aktiviert sein. Die Einstellung wird anhand der Dokumentation dieser Gegenstelle geprüft; auf Sophos Firewall ist kein zusätzlicher Schalter nötig.

Die Peers erkennen ein NAT-Gerät während des Phase-1-IKE-Austauschs und vereinbaren dann NAT-T. ESP ist ein Layer-3-Protokoll ohne Layer-4-Portinformationen, während PAT zusätzlich Ports übersetzen kann. Die UDP-Kapselung über Port 4500 gibt dem NAT-Pfad deshalb eine zuordenbare UDP-Hülle; die Gegenstelle entfernt diese Hülle und verarbeitet das ursprüngliche IPsec-Paket.

Steht die Sophos Firewall selbst hinter einem Router, benötigt dieser eine DNAT- oder Portweiterleitung von der öffentlichen Adresse auf das private Listening interface der Firewall. Für den NAT-T-Pfad müssen UDP 500 und UDP 4500 durchgelassen werden; IP protocol 50 wird nur auf einem Pfad ohne NAT als natives ESP benötigt. Dies ist nicht dasselbe wie die spätere SNAT- oder DNAT-Planung für überlappende Netze oder übersetzten Nutztraffic.

Bei Digital certificate müssen Zertifikatsformate und Rollen beider Seiten genau zusammenpassen. Sophos unterstützt für IPsec-Verbindungen keine ECDSA-Zertifikate; dafür werden RSA-Zertifikate benötigt. Eine öffentliche CA sollte nicht pauschal als Remote CA Certificate verwendet werden, weil dadurch zu viel Vertrauen in fremde Zertifikate entsteht. RSA key ist ein separater Authentication type: Beide Firewalls tauschen ihre öffentlichen Schlüssel aus und müssen dasselbe Format PKCS1 oder DNS verwenden.

Wird die lokale Default CA einer Sophos Firewall geändert, ist das ein Trust-Anchor-Wechsel und keine kosmetische Zertifikatsänderung. Peers mit importierter Default.pem sowie lokal signierte Zertifikate müssen kontrolliert migriert werden. Inventur, Wartungsfenster, Tests und Rückweg beschreibt Sophos Firewall Default CA kontrolliert erneuern.

Wenn Digital certificate gewählt wird, reicht die Auswahl im Verbindungsformular nicht aus. CA-Vertrauen, lokale Zertifikate, Peer-Zertifikate und Certificate IDs müssen vorher vorbereitet sein. Der vollständige Ablauf steht unter IPsec Site-to-Site mit Zertifikaten einrichten. Wenn die CA Zertifikate vor ihrem Ablauf sperrt, gehört auch die aktuelle Sperrliste in den Betriebsplan. Der Ablauf für CRL-Import, nextUpdate und kontrollierten Negativtest auf Sophos Firewall wird getrennt beschrieben.

Wenn ein Tunnel nicht hochkommt, sind NO_PROPOSAL_CHOSEN, ID-Fehler oder Authentifizierungsfehler typische Hinweise. Der Abschnitt Tunnel testen und Fehler beheben beginnt mit der passenden Eingrenzung.

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 Branch-Zurich-IKEv2. 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 life

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.

Wie Phase 1, Phase 2, PFS, Lifetimes, Rekeying und DPD zusammenspielen, erklärt IPsec-Profile auf Sophos Firewall verstehen und sicher konfigurieren. Vor dem Aktivieren wird Dead peer detection geprüft: Für den antwortenden Peer dokumentiert Sophos Hold oder Disconnect, für den Initiator Re-initiate. Eine IPsec-Failover-Gruppe verändert dieses Verhalten und wird nicht nach derselben DPD-Logik betrieben.

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
• IP version, meistens IPv4
• Gateway type, zum Beispiel Respond only in der Zentrale oder Initiate the connection in der Filiale
• Listening interface als lokales WAN-Interface
• Gateway address der Gegenstelle als IP-Adresse oder DNS-Hostname
• Authentication type: Preshared key, Digital certificate oder RSA key
• Local ID und Remote ID, falls benötigt
• IPsec profile
• Local subnet
• Remote subnet

Bei policy-based IPsec darf höchstens eine Seite der Traffic Selectors auf Any stehen. Bei mehreren konkreten lokalen und entfernten Netzen erzeugt Sophos eine Phase-2-SA für jede Kombination.

Bei Respond only kann eine Wildcard-Adresse * sinnvoll sein, wenn mehrere Filialen oder dynamische Gegenstellen zur Zentrale verbinden. Dann muss mindestens eine Local ID oder Remote ID gesetzt sein; für eine eindeutige Zuordnung sind beide IDs meist sinnvoll. Die Local ID einer Seite entspricht der erwarteten Remote ID der anderen. Initiate the connection unterstützt keine Wildcard-Adresse, deshalb wird die Gegenstelle dort als IP-Adresse oder DNS-Hostname definiert.

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.

Danach wird die Verbindung auf der Gegenstelle spiegelbildlich angelegt. Im Beispiel wartet die Zentrale mit Respond only auf 203.0.113.20; ihr Local/Remote-Netz ist 10.10.10.0/24 beziehungsweise 10.20.20.0/24. Die Filiale verwendet Initiate the connection, die Gateway-Adresse 198.51.100.10 und vertauscht Local/Remote-Netz sowie Local/Remote-ID. Profil, Authentisierung und PSK müssen kompatibel sein. Erst wenn beide Einträge gespeichert und die Regeln geprüft sind, wird die Verbindung aktiviert.

Die erweiterten Einstellungen für User authentication mode gehören nur zu IKEv1-Profilen mit XAuth-Logik, etwa sehr alten Client-Server-Designs. Für normale Site-to-Site-Verbindungen mit IKEv2 sollte man daraus keinen zusätzlichen Authentifizierungsschritt ableiten. Ebenso sollten veraltete Idle-Connection-Settings nicht als modernes Betriebsdesign eingeplant werden.

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 Routenauswahl. Bei Any-to-Any stellt SFOS ein eigenes, adressierbares XFRM-Interface bereit. Bei konkreten Traffic Selectors widerspricht sich die aktuelle SFOS-22-Dokumentation zur Interface-Erzeugung, wie unten erläutert.

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.

2. Any-to-Any oder Traffic Selectors umsetzen

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

Network > Interfaces

Ein erzeugtes XFRM-Interface bleibt immer der VPN-Zone zugeordnet. Die beiden Varianten werden unterschiedlich konfiguriert.

Any-to-Any mit IPv4, IPv6 oder Dual

Wenn Local subnet und Remote subnet beide auf Any stehen, erzeugt SFOS das XFRM-Interface für die route-based IPsec-Verbindung automatisch. Ein separates XFRM-Interface wird nicht hinzugefügt. Unter Network > Interfaces klappt man das als Listening interface gewählte physische Interface auf und öffnet das erzeugte XFRM-Interface. Im Beispiel erhält die Zentrale 10.255.0.1/30, die Filiale 10.255.0.2/30. Bei Dual werden zusätzlich getrennte IPv4- und IPv6-Firewall-Regeln benötigt.

Der editierbare Name ist der Anzeigename. Er ist nicht mit den von SFOS zugewiesenen Werten zu verwechseln: Hardware ist der Name des Datensatzes, IPsec connection die zugehörige route-based Verbindung und Network zone immer VPN. Nur die Adressfelder der in der IPsec-Verbindung gewählten IP-Version konfigurieren:

• IPv4/netmask: geplante IPv4-Transferadresse eingeben und Subnetz wählen.
• IPv6/prefix: geplante IPv6-Transferadresse und Präfix eingeben.
• Bei Dual beide Adressfamilien konfigurieren. Ist die Verbindung nur IPv4 oder nur IPv6, wendet SFOS Werte für die jeweils andere Version nicht an.

Unter Advanced settings > Interface settings den Standardwert für MTU beibehalten oder einen gezielt getesteten Wert eintragen. SFOS berechnet den Standard, indem es den maximalen IPsec-Overhead von der MTU des physischen Interfaces abzieht. Override MSS nur aktivieren und einen Wert eintragen, wenn das Netz einen vom Firewall-Standard abweichenden Wert benötigt; keinen nicht dokumentierten Zahlenwert als Standard annehmen.

Vor der Änderung aktuellen Namen, Adressen, MTU, Status und Wert von Override MSS sowie abhängige Routen oder Gateways dokumentieren. Nach dem Speichern das Interface erneut öffnen und prüfen, dass Hardware, IPsec connection und VPN-Zone unverändert zugewiesen sind. Danach auf beiden Peers Route lookup und echten Traffic in beide Richtungen testen, bei einer MTU- oder MSS-Änderung auch einen grossen Transfer. Für den Rollback die dokumentierten Feldwerte und bisherigen Routen oder Gateways wiederherstellen. Bei einer neu bereitgestellten Verbindung diese deaktivieren und nur ihre abhängigen Routen und Regeln entfernen; das automatisch erzeugte XFRM-Interface nicht eigenständig löschen oder neu erstellen.

Danach wird auf beiden Seiten die Route zum entfernten LAN angelegt. Für einen einfachen statischen Aufbau öffnet man Routing > Static routes > IPv4 unicast route > Add:

• Zentrale: Destination 10.20.20.0/24, Interface das lokale XFRM-Interface.
• Filiale: Destination 10.10.10.0/24, Interface das lokale XFRM-Interface.

Alternativ kann eine SD-WAN Route oder dynamisches Routing über BGP beziehungsweise OSPF verwendet werden. Bei einer SD-WAN Route wird bewusst entschieden, ob ein anderer Pfad als Rückfall erlaubt ist. Wenn Traffic bei ausgefallenem Tunnel nicht über eine andere Route abfliessen darf, wird Route only through specified gateways aktiviert und dieser Ausfall separat getestet.

Routen und Firewall-Regeln entscheiden, welcher Traffic in den Tunnel geht. Eine einfache statische Route kann direkt auf das XFRM-Interface zeigen. Für mehrere Leitungen, SLA-Prüfungen oder bestimmte Failoverdesigns wird zusätzlich ein Custom Gateway mit der Peer-XFRM-IP angelegt und in einer SD-WAN Route verwendet.

Any-to-Any-Tunnel können mehrere XFRM-Gateways direkt über SD-WAN und SLA-Prüfungen steuern; dafür ist keine zusätzliche VPN-Failover-Gruppe nötig. Policy-based Tunnel und route-based Tunnel mit Traffic Selectors verwenden für redundante Verbindungen dagegen eine IPsec-Failover-Gruppe. Der verlinkte Ablauf erklärt Reihenfolge, Health Check, Automatic failback und den kontrollierten Ausfalltest. Die Gruppe deaktiviert DPD für die zugeordneten Verbindungen und setzt Key negotiation tries auf 3.

Nach dem Speichern vier Punkte prüfen:

1. XFRM-Interface unter Network > Interfaces sichtbar und mit der geplanten Transfer-IP adressiert.
2. Route zum Remote-Netz zeigt direkt auf das XFRM-Interface oder bei einem Gateway-/SD-WAN-Design auf den passenden XFRM-Gateway.
3. Diagnostics > Tools > Route lookup liefert für einen echten Host im entfernten LAN das erwartete XFRM-Interface beziehungsweise den erwarteten XFRM-Gateway. Derselbe Test wird auf der Gegenstelle durchgeführt.
4. Firewall-Regeln erlauben nur die geplanten Richtungen und Dienste.

Traffic Selectors

Bei konkreten Subnetzen ist das SFOS-22-Verhalten in diesem Sonderfall nicht eindeutig: Einerseits soll kein XFRM-Interface entstehen, andererseits kann die Firewall eines pro Traffic-Selector-Konfiguration erzeugen. Deshalb unter Network > Interfaces das Listening Interface aufklappen und den tatsächlichen Zustand des installierten Builds prüfen; ein vorhandenes XFRM-Interface lässt sich auch unter Diagnostics > Packet capture auswählen. Wird ein XFRM-Interface angezeigt, ihm weder IP-Adresse noch Routen zuweisen. Die statische Route entsteht automatisch, sobald der Tunnel established ist. Any auf nur einer Seite und ein konkreter Selector auf der anderen werden nicht unterstützt.

Diese Variante eignet sich für kleine, klar definierte Netze. Ist das Interface sichtbar, damit wie dokumentiert ausgehenden Traffic unter Diagnostics > Packet capture bestätigen; zusätzlich automatische Route, Child SAs, Logs und Traffic in beide Richtungen prüfen. WAF über route-based IPsec mit Traffic Selectors wird nicht unterstützt.

Ein Any-to-Any-Tunnel lässt sich nicht direkt auf konkrete Traffic Selectors umstellen. Dafür wird die Verbindung geklont oder neu erstellt und anschliessend kontrolliert umgeschaltet.

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, NAT und Device Access

Firewall-Regeln und automatische Regeln

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:

• Lokales Netz zu entferntem Netz: zum Beispiel LAN nach VPN.
• Entferntes Netz zu lokalem Servernetz: zum Beispiel VPN nach Server.
• Management oder Monitoring: nur definierte Admin- oder Monitoring-Systeme erlauben.
• DNS, AD, RDP, HTTPS: nur benötigte Dienste freigeben, nicht pauschal Any.

XFRM-Interfaces gehören immer zur VPN-Zone. Wenn beide Richtungen genutzt werden, braucht es passende inbound und outbound Regeln. Getrennte Regeln mit Logging zeigen bei der Abnahme klarer, welche Seite welche Dienste erreichen darf. Der allgemeine Aufbau ist unter Sophos Firewall-Regeln erstellen und sicher prüfen beschrieben.

Eingehende IPsec-Pakete werden zuerst entkapselt und entschlüsselt. Danach wendet die passende Firewall-Regel ihre Sicherheitsrichtlinien auf den Nutztraffic an, bevor dieser zum Ziel weitergeleitet wird. Ausgehend greift die passende Firewall-Regel vor der Kapselung und Verschlüsselung.

Die Option Create firewall rule erzeugt getrennte Regeln mit den Präfixen Incoming und Outgoing an der Spitze der Regelliste. Danach:

• Regelposition kontrollieren.
• Source und Destination enger setzen.
• Any auf die benötigten Services reduzieren.
• Log firewall traffic für Einführung und Fehleranalyse aktivieren.
• IPS, Web, Application Control und weitere Security Features bewusst wählen.
• Regel verständlich benennen, zum Beispiel LAN_to_Branch_Zurich.

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

Für route-based Any-to-Any kann Sophos keine Regeln automatisch erzeugen. Bei Dual werden IPv4- und IPv6-Regeln separat angelegt. Wenn Internettraffic einer Filiale über die Zentrale laufen soll, braucht es zusätzlich ein eigenes NAT- und Sicherheitsdesign.

NAT nach Tunneltyp 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. NAT ersetzt keine Route und ändert die Routingentscheidung nicht: SFOS muss unabhängig von der Übersetzung eine passende VPN-, statische, SD-WAN- oder dynamische Route zum Ziel auswählen können.

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?

Die NAT-Logik unterscheidet sich je nach VPN-Typ:

• Bei policy-based IPsec und route-based VPN mit Traffic Selectors kann NAT direkt in der IPsec-Verbindung für überlappende Netze konfiguriert werden.
• Bei route-based Any-to-Any werden SNAT- und DNAT-Regeln unter Rules and policies > NAT rules verwendet.
• Bei überlappenden Netzen müssen beide Seiten denselben Übersetzungsplan verstehen. Einseitiges NAT ohne Rückplanung erzeugt oft grüne Tunnel ohne nutzbaren Verkehr.

⚠️ Bei route-based IPsec mit Traffic Selectors die NAT-Einstellung in der IPsec-Verbindung verwenden und einem vom installierten Build angezeigten XFRM-Interface weder IP-Adresse noch manuelle Route zuweisen. Den vollständigen spiegelbildlichen Adress-, DNS- und NAT-Aufbau zeigt IPsec bei überlappenden Netzen mit NAT.

Trifft der Traffic eines route-based VPN mit Traffic Selectors auf eine SNAT-Regel mit Translated source = MASQ, verwirft die Firewall die Pakete, weil diesen XFRM-Interfaces keine IP-Adressen zugewiesen sind. Das kann einen grünen Tunnel ohne nutzbaren Verkehr erklären. Für den betroffenen Testfluss die passende NAT-Regel und ihre Reihenfolge prüfen und nur die kollidierende Regel gezielt korrigieren; MASQ nicht pauschal für andere Verbindungen deaktivieren. Danach denselben Testfluss mit Log Viewer und Packet Capture erneut in beide Richtungen prüfen.

Soll policy-based IPsec-Nutztraffic über eine separate SNAT-Regel übersetzt werden, muss deren Outbound interface auf Any stehen. Eine Regel, die dort nur bestimmte WAN-Ports enthält – darunter üblicherweise die Default-SNAT-Regel – greift für diesen VPN-Traffic nicht. Mit Any verwendet die Firewall den in der passenden SNAT-Regel konfigurierten Translated source. Dieses Verhalten gilt auch dann, wenn Override source translation (SNAT) für bestimmte ausgehende Interfaces aktiviert ist.

Seit SFOS 22 erstellt policy-based IPsec die VPN-Route im Backend. Eine manuelle ipsec_route ist nur für bestimmte weitergeleitete Traffic-Szenarien relevant und kein Standardschritt; systemgenerierter Traffic benötigt sie nicht. Weitere NAT-Grundlagen stehen unter Sophos Firewall NAT-Regeln verstehen.

Device Access für eingehendes IPsec

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 WAN erlaubt sein, wenn die Firewall eingehende Anfragen annimmt, etwa mit Respond only. Das ersetzt keine Regeln für den Nutztraffic durch den Tunnel. Gleichzeitig sollte man prüfen, ob 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 und Fehler beheben

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

Abnahmematrix definieren

Vor dem ersten Test sollte eine kleine Abnahmematrix feststehen. Dadurch wird klar, welche Verbindung wirklich funktionieren muss und welche Verbindung bewusst nicht erlaubt sein soll.

Sinnvolle Testfälle:

• Lokales Clientnetz zu entferntem Servernetz: typischer Anwendungstest, zum Beispiel HTTPS, RDP, SMB, SQL oder ICMP nur als Basistest.
• Entferntes Clientnetz zu lokalem Servernetz: Gegenrichtung prüfen, wenn die Verbindung bidirektional genutzt wird.
• DNS oder AD über den Tunnel: nur testen, wenn diese Dienste wirklich über den Tunnel laufen sollen. Dabei Source, Zielserver und Port konkret festlegen.
• Monitoring oder Backup: prüfen, ob geplante Systeme aus der richtigen Richtung zugreifen und nicht versehentlich Any-Regeln benötigen.
• Nicht erlaubter Test: ein bewusst nicht freigegebener Port oder ein nicht erlaubtes Netz sollte blockiert werden. Sonst ist die Regelbasis zu breit.
• Grosse Übertragung: bei Dateiübertragung, RDP, VoIP oder Applikationsproblemen zusätzlich MTU/MSS und Fragmentierung beobachten.

Pro Testfall sollte man Source IP, Destination IP, Service, erwartete Firewall-Regel, erwartete NAT-Regel und erwartete Richtung notieren. Nach jedem Test werden Log Viewer, Packet Capture und Byte-Zähler verglichen. Wenn nur Ping getestet wird, ist der Tunnel noch nicht abgenommen.

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.

Unter Current activities > IPsec connections filtert man die tatsächlich etablierten Verbindungen nach Connection name, Local oder Remote subnet und aktualisiert die Anzeige mit Refresh. Disconnect trennt eine bestehende SA kontrolliert, etwa nachdem beide Seiten für eine Konfigurationsänderung bereit sind; die Aktion ersetzt nicht das Deaktivieren oder Zurückbauen der Verbindung.

Die erwartete Anzahl wird vor dem Test festgelegt: route-based Any-to-Any erzeugt pro XFRM-Interface eine Phase-2-Verbindung, Dual je eine für IPv4 und IPv6. Policy-based und route-based mit Traffic Selectors erzeugen je eine Verbindung für jede Kombination aus Local und Remote subnet.

Bei route-based Any-to-Any wird vor dem ersten Nutztraffic unter Diagnostics > Tools > Route lookup die reale Zielhostadresse geprüft. Das Ergebnis muss auf jeder Firewall zum vorgesehenen XFRM-Interface oder XFRM-Gateway zeigen.

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. Der Ablauf steht unter Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture. Wiederkehrende Rekeys, Disconnects und Verbindungsfehler werden in den IPsec-Logs geprüft, nicht aus dem aktuellen SA-Status abgeleitet.

3. Packet Capture und Advanced Shell

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

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

Advanced Shell

Für tieferes Troubleshooting per SSH 5. Device Management > 3. Advanced Shell öffnen und den aktuellen SA-Status prüfen:

ipsec statusall

Dabei sind unter anderem interessant:

• IKE SA established
• Child SA installed
• lokale und entfernte Traffic Selectors
• Byte-Zähler in beide Richtungen

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

Aktuelle IPsec-Logs

Die aktuelle SFOS-22-Logübersicht trennt die Aufgaben:

• strongswan.log: IPsec-Dienst und Verbindungen.
• charon.log: IPsec-Dienst sowie NAT in IPsec-Verbindungen.
• ipsec_monitor.log: Überwachung des IPsec-Dienstes.
• /log/ipsec_conn/ipsec_<connectionname>.log: Aktivieren, Deaktivieren und Verbinden über WebAdmin.
• xfrmi.log: XFRM-Interfaces bei route-based IPsec.
• dgd.log: nur zusätzlich bei VPN-Failover, SD-WAN, DGD oder Link-Load-Balancing, nicht als allgemeines IPsec-Log.

Für die vollständige Log- und XFRM-Diagnose ist Sophos Firewall IPsec VPN Troubleshooting der passende Ablauf.

Typische Fehler

• Tunnel baut nicht auf: IKE-Version, Profil, PSK, Zertifikat, Local ID oder Remote ID passt wahrscheinlich nicht. strongswan.log, IPsec-Profil und Gegenstelle prüfen.
• Phase 1 steht, Phase 2 nicht: Lokale oder entfernte Netze beziehungsweise Phase-2-Proposal passen wahrscheinlich nicht. Traffic Selectors, Subnetze und PFS prüfen.
• Tunnel ist grün, aber kein Zugriff: Firewall-Regel, NAT, Routing oder Rückweg fehlt wahrscheinlich. Log Viewer, Packet Capture und Routing prüfen.
• Nur eine Richtung funktioniert: Die Gegenstelle kennt die Rückroute nicht oder NAT ist falsch. Gegenstelle, NAT-Regeln und Byte-Zähler prüfen.
• Kleine Pings funktionieren, Anwendungen hängen: MTU/MSS, Fragmentierung oder ein Security Feature ist wahrscheinlich beteiligt. MTU/MSS und Packet Capture prüfen.
• Route-based Any-to-Any funktioniert nicht: XFRM-IP, Gateway, Route oder Firewall-Regel passt wahrscheinlich nicht. Network > Interfaces, Routing und VPN-Zonenregeln prüfen.
• Route-based mit Traffic Selectors funktioniert nicht: Prüfen, ob der tatsächliche Build das XFRM-Interface unter dem Listening Interface zeigt. Falls ja, für Packet Capture verwenden, aber weder IP-Adresse noch Route zuweisen. Zusätzlich automatische Route, Selectors, VPN-Zonenregeln und eine mögliche MASQ-Regel prüfen.
• Mehrere Tunnel beeinflussen sich: Überlappende Netze oder ähnliche Selector-Konfigurationen sind wahrscheinlich. Tunnelobjekte, Failover-Gruppe und Routen prüfen.

Rückbau bei fehlgeschlagener Abnahme

Ein neuer Tunnel wird kontrolliert zurückgenommen, statt Regeln und Objekte auf Verdacht zu löschen:

1. Unter Current activities > IPsec connections die betroffene SA mit Disconnect trennen und die neue IPsec-Verbindung deaktivieren.
2. Nur die für diesen Change neu angelegten statischen oder SD-WAN-Routen, NAT-Regeln und Firewall-Regeln deaktivieren. Automatisch erzeugte VPN-Regeln gehören dazu. Ein vom Build angezeigtes, generiertes XFRM-Interface nicht eigenständig löschen; die Deaktivierung der Verbindung verwaltet dieses Interface.
3. Bei einer Migration der alten Verbindung das vorherige Profil wieder zuweisen und anschliessend die Verbindung sowie den alten Routingpfad wieder aktivieren.
4. Den ursprünglichen Testfluss und den lokalen Internet- beziehungsweise Standortverkehr mit Log Viewer und Packet Capture erneut prüfen.
5. Neue Objekte erst entfernen, wenn Object Usage keine weitere Abhängigkeit zeigt und der alte Pfad nachweislich wieder funktioniert.

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, Zertifikate oder RSA-Schlüssel 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-to-Any sind XFRM-IP, Gateway, manuelle Firewall-Regeln und Routen eingeplant.
• Bei route-based Traffic Selectors ist die tatsächliche XFRM-Sichtbarkeit dokumentiert; unabhängig von der Anzeige sind weder XFRM-IP noch manuelle Route vorgesehen.
• NAT ist entweder ausgeschlossen oder bewusst dokumentiert.
• Device Access für eingehendes IPsec ist geprüft.
• Wartungsfenster, Gegenstelle und Rückfallweg sind bekannt.

Nach dem Change:

• Tunnelstatus ist established.
• Abnahmematrix mit mindestens einem Test pro benötigter Richtung durchgeführt und bestanden.
• 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