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.

Für die IDs im Beispiel auf beiden Firewalls Local ID type = DNS und Remote ID type = DNS setzen. In der Zentrale Local ID vpn-hq.example.invalid, Remote ID vpn-branch.example.invalid eintragen; in der Filiale genau umgekehrt. Diese Werte identifizieren die Peers, sie dienen nicht zur DNS-Auflösung ihrer Gateway-Adressen. Bei anderem ID-Typ müssen auch Typ und Format kreuzweise passen.

Für die IPv4-Netzwerkobjekte jeweils Add, IP version = IPv4, Type = Network, Netzadresse und Subnetzmaske /24 wählen und speichern. Sinnvolle Namen sind HQ_LAN für 10.10.10.0/24 und Branch_LAN für 10.20.20.0/24; beide Objekte werden auf beiden Firewalls benötigt. Ein Hostobjekt ist dagegen für eine einzelne Test- oder Monitoringadresse gedacht.

Die Filiale als Initiator verteilt Wiederholungsversuche auf die Filialen und ist bei wechselnder Filial-WAN-IP sinnvoll. Soll ein Initiator einen Peer mit dynamischer WAN-IP erreichen, muss dessen Gateway address einen DNS-Hostnamen enthalten, der tatsächlich auf die aktuelle öffentliche Peer-Adresse auflöst. Dynamic DNS auf Sophos Firewall einrichten und prüfen beschreibt Registrierung und Auflösungstest. Ein blosses DNS-ID ist keine erreichbare Gateway-Adresse. DDNS allein auf der Zentrale macht die dynamische Filialadresse nicht auffindbar.

⚠️ 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. Im durchgängigen Beispiel kann die Router-WAN-Adresse der Zentrale 198.51.100.10 sein, während das Firewall-WAN 172.31.255.2 verwendet. Dann wählt die Zentrale ihr privates WAN als Listening interface; die Filiale verbindet weiter zu 198.51.100.10, nicht zu 172.31.255.2. Der Router übersetzt das Ziel von seiner öffentlichen Adresse auf 172.31.255.2. Die LAN-Selectors bleiben Zentrale Local 10.10.10.0/24, Remote 10.20.20.0/24 und in der Filiale genau umgekehrt.

Für NAT-T müssen UDP 500 und UDP 4500 durchgelassen werden. Die SFOS-22- und SFOS-23-Anleitung für die Firewall hinter einem Router nennt zusätzlich IP protocol 50, nicht TCP-/UDP-Port 50. Bei ausgehandeltem NAT-T liegt ESP innerhalb von UDP 4500; natives ESP verwendet Protokoll 50. Die Routerliste und die NAT-T-Erklärung dürfen deshalb nicht als identische Paketpfade behandelt werden. Vor dem Change Routerfunktionen und bestehende Weiterleitungen dokumentieren und anhand von IKE-Logs sowie Packet Capture prüfen, welcher Pfad tatsächlich verwendet wird. Eine bestehende ESP-Freigabe nicht ungeprüft entfernen; zusätzliche Freigaben auf die geplanten Peer-Adressen begrenzen. Bei ausbleibender Aushandlung die dokumentierte Routerkonfiguration wiederherstellen. Dies ist getrennt von SNAT/DNAT für überlappende LANs 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. Local certificate gehört zur lokalen Firewall, Remote certificate zur Gegenstelle und Remote CA certificate ist die Vertrauensbasis für deren Zertifikat. Keine öffentliche CA als Remote CA certificate verwenden: Ein Angreifer mit einem gültigen Zertifikat dieser CA könnte sonst unberechtigten Zugang erlangen. Beim ID-Typ DER.ASN1 DN (X.509) wird der Distinguished Name des jeweiligen Zertifikats verwendet; als Remote ID ist der DN des Peer-Zertifikats einzutragen.

RSA key ist ein separater Authentication type, nicht die Auswahl eines RSA-Zertifikats. Die Firewall erzeugt das Schlüsselpaar automatisch und zeigt unter Local RSA key nur den öffentlichen Schlüssel. Diesen in Remote RSA key der Gegenstelle kopieren und deren öffentlichen Schlüssel in die lokale Remote RSA key einfügen. Beide Seiten müssen dasselbe Format PKCS1 oder DNS verwenden. Private Schlüssel werden nicht zwischen den Firewalls übertragen.

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

Für dieses policy-based Beispiel werden auf beiden Seiten konkrete Netze gewählt. Die SFOS-22- und SFOS-23-Dokumentation ist bei Any nicht einheitlich formuliert: Die Policy-based-Übersicht sagt, Any könne nicht für lokale und entfernte Subnetze gewählt werden; die Anleitung Add an IPsec connection erlaubt Any auf höchstens einer Seite. Daraus keine Any-to-Any-policy-based Konfiguration ableiten. Ist ein einseitiges Any erforderlich, vor der Umsetzung die Option im installierten Build, die Gegenstellen-Selectors und das beabsichtigte Routing in einer isolierten Testkonfiguration prüfen. Bei unerwarteter SA oder Traffic-Zuordnung die neue Verbindung deaktivieren und die dokumentierten konkreten Selectors wiederherstellen. Bei mehreren konkreten lokalen und entfernten Netzen entsteht eine Phase-2-SA pro Kombination: zwei lokale und zwei entfernte Netze ergeben vier SAs. Alle policy-based Verbindungen teilen sich ein IPsec-Interface; ein Capture auf diesem Interface allein identifiziert daher nicht den Tunnel.

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.

Bei Authentication type = Preshared key den vereinbarten PSK eingeben und im Bestätigungsfeld wiederholen. Auf der Gegenstelle exakt denselben PSK eingeben und ebenfalls bestätigen; die spiegelbildlichen IDs ändern den gemeinsamen Schlüssel nicht. PSK nur über den vorgesehenen sicheren Kanal austauschen, nicht in Screenshots oder öffentliche Tickets übernehmen.

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.

Ohne Activate on save wird die gespeicherte Verbindung über ihre Status-Schaltfläche in Site-to-site VPN > IPsec aktiviert. Gateway type = Disable ist davon zu unterscheiden: Die Verbindung bleibt bis zur benutzerseitigen Initiierung inaktiv. Respond only wartet auf Anfragen; Initiate the connection startet die Aushandlung auch nach einem Neustart des VPN-Dienstes oder der Firewall. Nach einem blossen Disconnect kann ein Initiator erneut verbinden; für einen Rückbau muss deshalb zusätzlich die Verbindung deaktiviert werden.

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.

XML-API: Konfiguration und Steueraktionen trennen

Wer diesen Ablauf automatisieren möchte, darf GUI-Felder nicht einfach in einen XML-Request übersetzen. Die API-Referenz für SFOS 22 und SFOS 23 zeigt Einstellungen unter VPNIPSecConnection/Configuration und daneben die Steuerzweige Active, DeActive, Connection und DisConnection, jeweils mit Name. Laut Beispielkommentar funktionieren diese vier Zweige erst nach dem Erstellen der Verbindung. Im Konfigurationsbeispiel steht separat Status mit Active/Deactive; die Parameterzeile für ActivateOnSave nennt y/n. Speichern, Aktivieren, Verhalten nach einem Neustart und ein tatsächlich etablierter Tunnel sind daher keine austauschbaren Einstellungen oder Belege für einen ausführbaren API-Request.

Die ältere Darstellung enthält zudem Widersprüche zwischen Beispiel und Parameterzeilen:

• AliasLocalWANPort folgt im Beispiel einem Kommentar für einen Alias-WAN-Port, ist in der Tabelle aber als obligatorisches ARRAY aufgeführt. Auch Name und RemoteHost sind dort ARRAY; daraus ergeben sich weder eine sichere Mehrfach-Serialisierung noch die paarweise Zuordnung der Werte.
• UserAuthenticationMode zeigt im Beispiel AsServer/AsClient, in der Zeile dagegen EnableAsServer/EnableAsClient. Bei DisconnectOnIdleInterval steht der Default 0 ausserhalb des genannten Bereichs 120..21600; 600 ist nur der Beispielwert. Diese Angaben nicht still vereinheitlichen oder als IKEv2-Defaults übernehmen.
• Das ältere Feld AllowNATTraversal mit Enable/Disable belegt keinen heutigen NAT-T-Schalter. Die RemoteHost-Zeile verbietet * bei RSAKey; das ist eine Einschränkung dieser Referenz, keine hier bestätigte allgemeine Laufzeitregel für die GUI.

Solange die API-Darstellung des installierten Builds nicht geklärt ist, den oben beschriebenen WebAdmin-Ablauf verwenden und die Unklarheiten vor einer Automatisierung klären. Für den beschriebenen GUI-Ablauf gelten weiterhin die automatische NAT-T-Erkennung sowie die IKEv2-, RSA- und ID-Hinweise. Daraus folgt keine vollständige XML-Vorlage.

Route-based IPsec einrichten

Route-based IPsec trennt VPN-Verhandlung und Routenauswahl. Bei Any-to-Any stellt SFOS ein eigenes, adressierbares XFRM-Interface bereit. Die SFOS-22- und SFOS-23-Anleitungen beschreiben auch bei konkreten Traffic Selectors ein erzeugtes XFRM-Interface; anders als bei Any-to-Any darf es keine IP-Adresse oder manuell zugewiesene Route erhalten. Vor einer Migration werden installierte SFOS-Version, Interface-Zuordnung und tatsächlich erzeugte Route dokumentiert.

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.

Routes und Firewall-Regeln bestimmen, welcher Traffic in den Tunnel gelangt. Eine einfache statische Route kann direkt auf das XFRM-Interface zeigen. Für mehrere Leitungen, SLA-Prüfungen oder bestimmte Failover-Designs wird zusätzlich ein Custom Gateway mit der XFRM-IP der Gegenstelle erstellt und in einer SD-WAN Route verwendet.

Für die SD-WAN-Alternative unter Routing > SD-WAN routes IPv4 und Add wählen. Auf der Zentrale Source networks = HQ_LAN, Destination networks = Branch_LAN und unter Link selection settings Primary and backup gateways setzen. Bei Primary gateway > Add als Gateway IP 10.255.0.2 und als Interface das lokale XFRM mit 10.255.0.1/30 wählen. In der Filiale Source/Destination tauschen, Gateway IP 10.255.0.1 und das lokale XFRM mit 10.255.0.2/30 verwenden. Für Health check unter Monitoring condition einen tatsächlich antwortenden internen Peer-Host wählen, beispielsweise 10.20.20.15 in der Filiale oder 10.10.10.25 in der Zentrale. Die Probe muss selbst erlaubt sein und den vorgesehenen Tunnel benutzen. Für SLA-basierte Auswahl ein SD-WAN-Profil mit den Tunnel-Gateways auswählen. Statische Route und SD-WAN-Route sind hier Alternativen; nicht beide ungeprüft als konkurrierende Wege anlegen. Bestehende Route Precedence und Regeln vor der Änderung dokumentieren und bei Rückbau die vorherige Route/Gateway-Auswahl wiederherstellen.

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

Für konkrete Subnetze beschreiben die ausgewerteten SFOS-22- und SFOS-23-Anleitungen ein XFRM-Interface pro IPsec-Konfiguration. Unter Network > Interfaces das Listening interface über die blaue Markierung aufklappen. Dem erzeugten Interface weder IP-Adresse noch manuelle Route zuweisen: Die statische Route entsteht automatisch, sobald der Tunnel established ist. In der Zentrale Local HQ_LAN und Remote Branch_LAN wählen, in der Filiale Local Branch_LAN und Remote HQ_LAN. Gateway, Profil, Authentisierung und IDs werden wie bei den anderen Varianten gespiegelt. Any auf nur einer Seite und ein konkreter Selector auf der anderen werden bei route-based nicht unterstützt. Fehlt das dokumentierte Interface im installierten Build, erst Konfiguration, Version und Logs klären; nicht versuchen, ein Ersatz-XFRM oder eine Any-to-Any-Adressierung zu erzwingen.

Diese Variante eignet sich für kleine, klar definierte Netze; Sophos empfiehlt sie gegenüber policy-based, auch für passende Drittanbieter-Verbindungen. Das XFRM-Interface unter Diagnostics > Packet capture zur Zuordnung des ausgehenden Traffics verwenden; zusätzlich automatische Route, jede erwartete Child SA, Logs und Traffic in beide Richtungen prüfen. WAF über route-based IPsec mit Traffic Selectors wird nicht unterstützt; dafür kommt eine passende Any-to-Any-route-based Konfiguration infrage. Bei einer fehlgeschlagenen Umstellung neue Verbindung und nur ihre neuen Regeln deaktivieren und die dokumentierte vorherige Verbindung wieder aktivieren.

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.

Die erzeugten Regeln stehen in der Gruppe Automatic VPN rules. Im Beispiel erlaubt die Zentrale ausgehend Source zone LAN, Source network HQ_LAN, Destination zone VPN, Destination network Branch_LAN; eingehend werden Zonen und Netze vertauscht. In der Filiale gilt dieselbe Spiegelung mit Branch_LAN als lokalem Netz. Services jeweils auf die freigegebenen Anwendungsports begrenzen und Log firewall traffic einschalten. Bestehende geeignete Regeln dürfen um die richtigen Source-/Destination-Netze ergänzt werden, statt pro Tunnel neue Regeln anzulegen. Vorher die Auswirkung auf alle anderen von dieser Regel erfassten Verbindungen prüfen. SFOS wertet von oben nach unten aus und stoppt beim ersten Treffer; eine neue Regel am Listenanfang kann daher bisherige Einschränkungen übersteuern.

⚠️ 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 NAT innerhalb der IPsec-Verbindung wird Network Address Translation (NAT) aktiviert. Translated subnet zeigt das in der Verbindung ausgewählte lokale, übersetzte Netz; unter Original subnet wird das tatsächliche überlappende lokale Netz ausgewählt. Für Netze ohne Übersetzung bleibt Not translated gesetzt. Vor dem Speichern Originalnetz, übersetztes Netz, Peer-Remote-Selector und DNS-Zieladresse tabellarisch abgleichen. Die Richtung nicht allein aus den Feldnamen erraten; der verlinkte NAT-Ablauf enthält das vollständige Beispiel. Für Any-to-Any diese Felder nicht als Ersatz für separate SNAT-/DNAT-Regeln verwenden.

⚠️ 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 kein Standardschritt, kann aber für bestimmte weitergeleitete Traffic-Szenarien relevant sein. Für systemgenerierte Authentifizierungsanfragen widersprechen sich die Sophos-Hilfetexte zu SFOS 22 und SFOS 23: Die Routing-/NAT-Übersicht sagt, dass dieser Traffic den Befehl nicht benötigt; die Authentifizierungsanleitung beschreibt dagegen eine policy-based Ausnahme, wenn die gewählte Route Precedence den Traffic nicht in den Tunnel sendet. Daraus folgt weder eine zusätzliche Route für jeden Systemtraffic noch eine pauschale Änderung der globalen Route Precedence.

Vor einer Änderung müssen Quelladresse, sys-traffic-nat, Traffic Selectors und Rückweg zum tatsächlich beobachteten Paketfluss passen. Die bestehende IPsec-Route-Anleitung und der Ablauf für systemgenerierte Authentifizierungsanfragen erklären die gezielten Prüfungen mit einer echten Anfrage und Packet Capture sowie den getrennten Rollback für NAT und Route. Bleibt das Verhalten auf dem installierten Build unklar, muss es vor einer Produktionsänderung mit Sophos Support geklärt werden. Die beschriebene Ausnahme muss zum konfigurierten Pfad passen und in der Abnahme gezielt kontrolliert werden. 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.

Soll ein Peer die Firewall selbst über den Tunnel anpingen, unter Ping/Ping6 die Zone VPN freigeben und Apply wählen. Das ist kein notwendiger globaler Schritt für das Anpingen eines LAN-Hosts: Dafür zählen die passenden Transitregeln und die Host-Firewall. Nur die für den Test benötigte lokale Dienstfreigabe setzen, ihre ursprüngliche Einstellung dokumentieren und nach dem Test wiederherstellen, sofern sie nicht dauerhaft benötigt wird. Ein Ping aus der Firewall-Shell hat zudem eine andere Quelladresse als ein LAN-Client; beide Tests nicht als gleichwertige Prüfung der Clientregel behandeln.

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 werden nur tatsächlich etablierte Verbindungen angezeigt. Filter sind Connection name, Local server name, Local subnet, Username, Remote server/host und Remote subnet; Refresh aktualisiert die Anzeige. 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.

Für das durchgängige Beispiel vom LAN-Client 10.10.10.25 einen tatsächlich vorhandenen Filialhost 10.20.20.15 testen, nicht die Netzadresse 10.20.20.0. Auf Windows startet ping 10.20.20.15 -t einen Dauertest; mit Ctrl+C beenden. Unter Diagnostics > Packet capture > Configure als BPF string host 10.10.10.25 and host 10.20.20.15 and proto ICMP setzen, speichern und Capture einschalten. Bei route-based den Ausgang auf dem zugehörigen XFRM und die Rückpakete prüfen. Im Log viewer nach der tatsächlichen Clientadresse suchen; über die Firewall rule ID und Filter firewall rule die treffende Regel öffnen. Danach auch einen geplanten Anwendungsport und die Gegenrichtung testen. Capture wieder ausschalten und temporäre Filter/Freigaben zurücknehmen; ein Dauercapture ist kein Betriebsmonitoring. Hinter einem Router zusätzlich in beiden Peer-Logs kontrollieren, dass NAT erkannt und NAT-T ausgehandelt wurde.

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: Das dokumentierte XFRM unter dem Listening interface, automatische Route, jede erwartete Child SA, Selectors, VPN-Zonenregeln und eine mögliche MASQ-Regel prüfen. Das XFRM für Packet Capture verwenden, aber weder IP-Adresse noch manuelle Route zuweisen. Fehlt es, Build und Konfiguration klären, statt ein Ersatzinterface anzulegen.
• 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.

Eine gespeicherte Verbindung gezielt entfernen

Das Löschen einer gespeicherten IPsec-Verbindung ist etwas anderes als Disconnect, Deaktivierung oder das Löschen einer Failover-Gruppe. Vor einer separat freigegebenen Entfernung den exakten bestehenden Name, Object Usage, Gruppenmitgliedschaften und einen vom Tunnel unabhängigen Managementzugang dokumentieren. Eine Verbindung nicht löschen, solange sie einer Failover-Gruppe zugeordnet ist; die kontrollierte Aufhebung der Zuordnung steht im verlinkten Failover-Ablauf.

Die XML-API-Löschreferenz für SFOS 22 und SFOS 23 nennt Name als obligatorisches ARRAY mit Datentyp STRING: erstes Zeichen A-Za-z, danach A-Za-z0-9_, höchstens 100 Zeichen, mehrere Werte erlaubt. Sie enthält aber kein Request-Beispiel. Daraus weder einen Mehrfach-Serializer noch einen Zielnamen aus dem GUI-Beispiel branch-zurich ableiten; einen gespeicherten Namen nicht zur vermeintlichen Anpassung umschreiben.

Die Referenz ordnet XML-Operationsstatus 200 dem Schlüssel Message.IPSecDeleteSuccess, 201 dem Schlüssel Message.IPSecConnInUse und 500 dem Schlüssel Message.IPSecDeleteFail zu. Die Meldungstexte werden dort über JavaScript eingesetzt und sind hier nicht aufgelöst: Das sind weder HTTP-Statuscodes noch bestätigte angezeigte Antworttexte. 201 nicht als erfolgreiche Löschung zählen, nur weil die Zahl mit 2 beginnt; bei Edit steht dieselbe Zahl für Message.IPSecUpdated. Nach einer freigegebenen Entfernung genau dieses Ziel erneut auslesen und die verbleibenden produktiven Pfade prüfen. Bei unklarem Ergebnis erst Zielzustand und Abhängigkeiten klären, nicht blind wiederholen.

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