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 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. In aktuellen SFOS-Versionen sind diese Begriffe deutlicher getrennt als in älteren Anleitungen, die teilweise noch von Site-to-Site oder Tunnel Interface sprechen.

• Policy-based IPsec: passt für einfache Standortverbindungen mit klaren lokalen und entfernten Netzen. Gesteuert wird primär über lokale und entfernte Subnetze in der IPsec-Verbindung sowie über Firewall-Regeln. Sophos erstellt dabei einzelne Phase-2-Tunnel für die Kombinationen aus lokalen und entfernten Subnetzen.
• Route-based IPsec mit Traffic Selectors: nutzt ebenfalls lokale und entfernte Subnetze, erstellt aber ein eigenes XFRM-Interface. Sophos erzeugt die Route automatisch; dem XFRM-Interface dürfen weder IP-Adresse noch eigene Routen zugewiesen werden. WAF wird über diese Variante nicht unterstützt.
• Route-based IPsec Any-to-Any: ist die flexibelste Variante für wachsende Netze, SD-WAN, dynamisches Routing und Dual-Stack-Designs. Welche Pakete in den Tunnel gehen, entscheiden dann Routen und Firewall-Regeln, nicht mehr die Subnetze in der IPsec-Verbindung.

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.

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.

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

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.

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

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.

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 Datenpfad über ein eigenes XFRM-Interface. Ob man dieses Interface selbst adressiert und routet, hängt von der gewählten Variante ab.

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

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

Network > Interfaces

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

Any-to-Any und Dual

Wenn beide Subnetze auf Any stehen oder Dual verwendet wird, erhält das XFRM-Interface eine Transfer-IP. Danach braucht es eine statische Route, SD-WAN Route oder dynamische Route über BGP beziehungsweise OSPF. Bei Dual werden getrennte IPv4- und IPv6-Firewall-Regeln benötigt.

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 drei 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. Firewall-Regeln erlauben nur die geplanten Richtungen und Dienste.

Traffic Selectors

Bei konkreten Local und Remote subnets erzeugt Sophos ebenfalls ein XFRM-Interface, aber dem Interface dürfen weder IP-Adresse noch eigene Routen zugewiesen werden. 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 und erleichtert die XFRM-Diagnose. WAF über route-based IPsec mit Traffic Selectors wird jedoch 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.

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.

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 besitzt das XFRM-Interface keine IP-Adresse. Trifft dieser Traffic eine MASQ-SNAT-Regel, verwirft die Firewall die Pakete. Deshalb für überlappende Netze die NAT-Einstellung in der IPsec-Verbindung verwenden und sicherstellen, dass keine MASQ-SNAT-Regel diesen Traffic erfasst.

Seit SFOS 22 erstellt policy-based IPsec die VPN-Route im Backend. Eine manuelle ipsec_route ist nur für bestimmte übersetzte, weitergeleitete Verkehre 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.

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: Keine IP oder manuelle Route am XFRM konfigurieren. 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.

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 sind keine IP oder manuellen Routen am XFRM 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 definiert.
• 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