Sophos Firewall IPsec VPN Troubleshooting

Bei IPsec-Troubleshooting zählt die Reihenfolge: zuerst IKE und Child SA prüfen, danach Firewall-Regeln, NAT, Routing und Rückweg. Ein grüner Tunnel bestätigt nur die Aushandlung – nicht, dass Nutztraffic funktioniert.

Für einen neuen Tunnel passt zuerst Sophos Firewall Site-to-Site IPsec VPN einrichten. Die folgenden Schritte gelten für eine bereits konfigurierte Verbindung.

Diagnosepfad

Tunnel bleibt down: IKE-Version, IPsec-Profil, Gateway, Local/Remote ID, PSK oder Zertifikat in strongswan.log prüfen.
Phase 1 steht, aber keine Child SA: Traffic Selectors, Phase-2-Proposal, PFS und Subnetze vergleichen.
Tunnel ist grün: Mit ipsec statusall kontrollieren, ob die SA ESTABLISHED, die Child SA INSTALLED ist und Byte-Zähler steigen.
Nur eine Richtung zählt Bytes: Firewall-Regeln, NAT, Routing und insbesondere den Rückweg auf der Gegenstelle prüfen.
Ursache bleibt unklar: Einen einzelnen Testfluss mit Log Viewer und Packet Capture verfolgen.
Firewall stürzt bei Multicast über VPN wiederholt ab: Den Fehler nicht durch weitere Lasttests provozieren. Firmwarestand, Zeitpunkte und vorhandene Diagnosedaten sichern; NC-180433 ist mit SFOS 22.0 MR2 Build 546 behoben.

Vorher reichen wenige dokumentierte Werte: Tunnelname, Peer-IP oder FQDN, IKE-Version, Local/Remote ID, lokale und entfernte Netze, policy-based oder route-based, IPsec-Profil sowie ein Test mit Source, Destination und Service. Beispiel: Tunnel azure-vpn, lokal 172.16.10.0/24, remote 10.20.30.0/24.

Bei policy-based IPsec sind die Netze Teil der Aushandlung. Route-based IPsec verwendet ein XFRM-Interface und statische, SD-WAN- oder dynamische Routen. Bei falschem Pfad helfen die separaten Anleitungen zu IPsec Routes und Route Precedence.

⚠️ Logs und Packet Captures können öffentliche IP-Adressen, interne Netze, Hostnamen oder Nutzdaten enthalten. Nur gezielt und zeitlich begrenzt sammeln und vor der Weitergabe prüfen.

Logs und CLI prüfen

Unter Site-to-site VPN > IPsec zeigt Show additional properties unter anderem Local subnet, Remote subnet, Gateway type und Profile. Unter Profiles > IPsec profiles lassen sich Phase-1- und Phase-2-Werte ebenfalls direkt vergleichen.

Die wichtigsten Dateien in /log sind:

strongswan.log: IKE, Authentifizierung und Child SAs
charon.log: IKE-Daemon
ipsec_monitor.log: Überwachung des IPsec-Dienstes
/log/ipsec_conn/ipsec_<connectionname>.log: Connect-, Activate- und Deactivate-Aktionen im WebAdmin
xfrmi.log: XFRM-Interfaces
dgd.log: Dead Gateway Detection und VPN-Failover

Die aktuelle zentrale SFOS-22-Logliste nennt ipsec_monitor.log. Eine ältere Sophos-Troubleshooting-Seite führt noch strongswan-monitor.log; für aktuelle SFOS-22-Systeme ist die neuere Logliste massgebend.

In der Advanced Shell lässt sich das Hauptlog live verfolgen oder filtern. Falls der SSH- und Shell-Zugriff noch nicht vertraut ist, hilft Sophos Firewall CLI Troubleshooting: wichtige Befehle.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Die Zeilen sind Alternativen, kein zusammenhängender Ablauf. In less sucht /suchbegriff innerhalb der Datei.

StrongSwan-Debug

Wenn das normale Log nicht reicht, zuerst den aktuellen Zustand in der Advanced Shell prüfen:

service -S | grep strongswan

Steht bereits RUNNING,DEBUG, den Toggle nicht erneut als vermeintliche Aktivierung ausführen. Das vorhandene Debug verwenden und anschliessend wie unten beschrieben ausschalten.

⚠️ Debug nur kurz laufen lassen. Er kann schnell grosse Logdateien erzeugen und Speicherplatz belegen.

Wenn Debug noch nicht aktiv ist, den Toggle ausführen, den neuen Zustand kontrollieren und den Fehler genau einmal reproduzieren:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

Bei strongswan sollte RUNNING,DEBUG stehen. Danach schaltet derselbe Befehl den Debug-Modus wieder aus; der zweite Befehl bestätigt den Rückweg:

service strongswan:debug -ds nosync
service -S | grep strongswan

Tunnelaufbau prüfen

Phase 1: IKE, IDs und Authentifizierung

Wenn der Tunnel nicht hochkommt, passen meist IKE-Version, Gateway, IDs, Proposal, PSK oder Zertifikat nicht zusammen.

no IKE config found oder Remote peer is refusing our Phase 1 proposals: Die Firewall findet keine passende Verbindung beziehungsweise das Profil passt nicht. IKE-Version, Listening Interface, Peer-Adresse, Local/Remote ID und Profil prüfen.
peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found oder Remote peer reports we failed to authenticate: IDs und Authentifizierung passen nicht zur erwarteten Peer-Konfiguration.
invalid HASH_V1 payload length oder decryption failed: Bei IKEv1 häufig ein falscher PSK; bei IKEv2 erscheint eher AUTH_FAILED.
Die Gegenstelle erreicht eine andere öffentliche Adresse oder UDP 500/4500 wird durch NAT, Router oder Provider nicht korrekt weitergeleitet.
Bei Zertifikaten passen Zertifikatskette, ausstellende CA, Gültigkeit oder erwartete ID nicht zusammen.

Ist ein Zertifikat vor Ablauf gesperrt oder bleibt die Revocation-Wirkung unklar, werden Aussteller, Seriennummer, thisUpdate, nextUpdate und die dienstspezifische Ablehnung gemeinsam geprüft. Den sicheren Ablauf zeigt Certificate Revocation Lists auf Sophos Firewall importieren und testen.

Local ID der einen Seite muss zur Remote ID der anderen passen und umgekehrt. Der PSK sollte auf beiden Seiten neu gesetzt werden; unsichtbare Leerzeichen oder Copy-and-paste aus Passwortmanagern sind häufige Ursachen. Eine falsche ID kann die Peer-Zuordnung bereits verhindern, bevor der erwartete PSK geprüft wird.

Phase 2: Traffic Selectors und Child SA

Steht Phase 1, aber keine Child SA, sind meist Subnetze oder Phase-2-Werte unterschiedlich.

traffic selectors ... inacceptable
failed to establish CHILD_SA
received traffic selectors didn't match
Remote peer reports INVALID_ID_INFORMATION
abweichende Werte bei TSi und TSr
NO_PROPOSAL_CHOSEN nach Phase 1 is up und Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN allein reicht nicht zur Einordnung: Vor Phase 1 weist es auf IKE-/Phase-1-Werte, nach erfolgreicher Phase 1 auf ESP, PFS oder andere Phase-2-Werte hin.

Für den vollständigen Feldabgleich zwischen General settings, Phase 1, Phase 2 und DPD hilft IPsec-Profile auf Sophos Firewall verstehen und sicher konfigurieren.

Die Netze müssen spiegelbildlich sein. Erwartet die Sophos lokal 172.16.10.0/24 und remote 10.20.30.0/24, muss die Gegenstelle 10.20.30.0/24 nach 172.16.10.0/24 anbieten. Auch /24 gegen einen einzelnen Host oder unterschiedlich gepflegte Hostobjekte können die Child SA verhindern.

Tunnel steht, aber kein Traffic läuft

In der Advanced Shell zeigt dieser Befehl SAs, ausgehandelte Netze und Byte-Zähler:

ipsec statusall

Wichtig sind ESTABLISHED, INSTALLED und die Zähler in beiden Richtungen. Bleiben beide leer, erreicht der Testtraffic den Tunnel wahrscheinlich nicht. Steigt nur die ausgehende Seite, fehlt meist der Rückweg oder eine Regel auf der Gegenstelle; steigen nur eingehende Bytes, sind lokale Route, lokale Regel oder Zielsystem verdächtig.

Einen Testfluss verfolgen

Ein enger Test ist aussagekräftiger als mehrere parallele Pings:

Source IP: 172.16.10.25
Destination IP: 10.20.30.15
Service: ICMP oder TCP 443
erwartete Richtung: LAN nach VPN
erwartete Regel: LAN_to_VPN_Branch

Dann in dieser Reihenfolge prüfen:

Log firewall traffic in der betroffenen Regel aktivieren.
Log Viewer nach Source, Destination und Rule ID filtern.
Packet Capture mit host 172.16.10.25 and host 10.20.30.15 starten.
Den Test genau einmal ausführen.
Regel, NAT Rule ID, Weiterleitung, Antwort und Byte-Zähler vergleichen.
Auf der Gegenstelle Rückroute, Remote-Regel und Zielsystem prüfen.

Kommt auf der Sophos Firewall kein Paket an, liegt die Ursache davor, etwa bei Client-Gateway, VLAN oder lokalem Routing. Kommt es an, wird aber nicht weitergeleitet, passen Regel, NAT, Route oder ein Security Feature nicht. Der vollständige Regeltest steht unter Firewall-Regel mit Log Viewer, Policy Test und Packet Capture prüfen.

Routing und XFRM

Bei policy-based IPsec führt SFOS 22 die VPN-Routen im Backend. Manuelle IPsec Routes und Route Precedence werden in der Device Console geprüft:

system ipsec_route show
system route_precedence show

Der aus älteren Troubleshooting-Abläufen bekannte Befehl in der Advanced Shell ist unter SFOS 22 kein verlässlicher Nachweis für einen policy-based Tunnel:

ip route show table 220

Unter SFOS 22 sind policy-based VPN-Routen und manuelle ipsec_route-Einträge dort nicht sichtbar. Ein fehlender Eintrag beweist daher weder eine fehlende Route noch einen Routingfehler.

Bei route-based IPsec müssen eine statische, SD-WAN- oder dynamische Route zum XFRM-Interface und passende XFRM-Zustände vorhanden sein. Das XFRM-Interface unter Network > Interfaces sowie den Pfad unter Diagnostics > Tools > Route lookup prüfen; konfigurierte statische Routen zeigt die Device Console:

show static-route

Die XFRM-Zustände werden in der Advanced Shell geprüft:

ip xfrm state
ip xfrm policy

XFRM-Interfaces dürfen keine überlappenden Transfernetze verwenden. Verbindungen mit identischen lokalen und entfernten Subnetzen gehören in eine gemeinsame IPsec-Failover-Gruppe oder benötigen eine eindeutig andere Selektor- und Routinglogik. Der verlinkte Ablauf erklärt Gruppenreihenfolge, Health Check und den kontrollierten Umschalttest.

NAT nach Tunneltyp prüfen

NAT ist erlaubt, muss aber zum Tunneltyp und zu den Adressen passen, welche die Gegenstelle erwartet.

Policy-based mit SNAT: Die beabsichtigte SNAT-Regel benötigt Outbound interface Any. Die Default-SNAT-Regel mit konkreten WAN-Ports trifft policy-based IPsec-Traffic nicht.
Route-based mit Any/Any oder Dual: MASQ übersetzt die Source auf die XFRM-IP; diese ist in Packet Capture im inneren IP-Header sichtbar.
Route-based mit konkreten Traffic Selectors: Trifft eine MASQ-Regel, verwirft die Firewall den Traffic, weil solchen XFRM-Interfaces keine IP-Adresse zugewiesen ist.

Original- und übersetzte Source müssen dokumentiert und auf der Gegenstelle erlaubt sowie zurückgeroutet sein. Grundlagen und Regelreihenfolge erklärt NAT auf Sophos Firewall.

Instabilität und SFOS-22-Sonderfälle

Wenn Traffic erst später stoppt, Zeitstempel in Tunnelstatus, strongswan.log, dgd.log, WAN-Events und Anwendungstest vergleichen. Häufige Ursachen sind:

Der Drittanbieter verwendet traffic-based Rekeying; Sophos Firewall unterstützt time-based Rekeying.
Beide Seiten rekeyen gleichzeitig. Die Phase-1- und Phase-2-Key-Lifetimes von Initiator und Responder bewusst staffeln.
Das zugeordnete Interface wurde deaktiviert. Initiierende Tunnel trennen sofort, Responder spätestens nach Inaktivität oder DPD-Timeout.
Mehrere Verbindungen mit denselben Subnetzen liegen nicht in derselben Failover-Gruppe.
Grosse Transfers scheitern trotz funktionierendem Kleintest; dann MTU und MSS prüfen.

Wiederholte Firewall-Abstürze bei Multicast über VPN

Treten die Abstürze zeitlich mit Multicast-Traffic durch einen VPN-Tunnel auf, zuerst Firmwarestand und Build, betroffenen Tunnel, Zeitpunkte sowie vorhandene Diagnose- oder Crashdaten sichern. Sophos bestätigt dieses Fehlerbild als NC-180433 und hat es mit SFOS 22.0 MR2 Build 546 behoben.

Die öffentliche Fehlerbeschreibung nennt weder einen bestimmten Tunneltyp oder Multicast-Aufbau noch einen CLI-Workaround. Auf einem älteren SFOS-22-Build deshalb den Upgradepfad prüfen, auf MR2 Build 546 oder eine neuere freigegebene Version aktualisieren und denselben Traffic danach kontrolliert erneut testen. Tunnelparameter, IPsec Acceleration oder Services nicht auf Verdacht verändern. Stürzt die Firewall auch auf MR2 oder neuer weiterhin ab, die gesicherten Daten an Sophos Support übergeben, statt den Fehler automatisch weiterhin NC-180433 zuzuordnen.

Den normalen Aufbau und die kontrollierte Abnahme erklärt Multicast Routing auf Sophos Firewall; der hier beschriebene Crash bleibt ein firmwaregebundener Sonderfall.

IKEv2-Pakete werden fragmentiert

Beim Known Issue NC-136352 kann das Default-IKEv2-Profil so viele DH-Gruppen anbieten, dass IKE-Pakete grösser als 1'500 Bytes werden. Verwirft eine Zwischenkomponente Fragmente oder PMTU-Informationen, sendet der Initiator wiederholt, während der Responder nichts sieht.

Bei genau diesem Fehlerbild den Peer in der Advanced Shell prüfen:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Danach im IPsec-Profil nur die tatsächlich benötigte DH-Gruppe beziehungsweise deutlich weniger Gruppen anbieten. Allgemeine tcpdump-Filter und PCAP-Export beschreibt Sophos Firewall tcpdump.

PPPoE-Alias und IPsec Acceleration

NC-181526 betrifft SFOS 22.0 GA Build 411 oder MR1 Build 490 auf bestimmten physischen XGS-Appliances: Der Tunnel verwendet ein Alias-Interface eines PPPoE-WAN-Ports, ist verbunden, transportiert bei aktiver IPsec Acceleration aber keine Nutzdaten. Ausgenommen sind XGS 88/88w, 108/108w, 118/118w und 128/128w.

Die aktuelle Sophos Known Issues List führt SFOS 22.0.2 MR2 Build 546 als Fixversion; in der veröffentlichten MR2-Fixliste erscheint NC-181526 jedoch nicht separat. Nach dem Update deshalb denselben Testfluss erneut prüfen, statt den Fix allein aus der Versionsangabe abzuleiten.

⚠️ Das Deaktivieren von IPsec Acceleration ist global, startet alle IPsec-Tunnel neu und verursacht eine Unterbrechung. Nur bei exakt passender Kombination aus Build, Hardware, PPPoE-Alias und Fehlerbild in einem Wartungsfenster testen.

Die folgenden Befehle laufen in der Device Console:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

Ohne Verbesserung den Ausgangszustand wiederherstellen:

system ipsec-acceleration enable

SFOS 22.0 MR2 behebt mit NC-180520 einen ähnlichen, aber anderen Alias-IP-Fall: Das XFRM-Gateway konnte bei aktiver Acceleration unerreichbar bleiben, wenn ESP über einen anderen WAN-Port einging. Die beiden Issue-IDs dürfen nicht gleichgesetzt werden. Weitere Vorher-/Nachher-Prüfungen bündelt der SFOS 22 Upgrade Check.

Abnahme und Eskalation

Nach jeder Änderung denselben einzelnen Testfluss wiederholen und mindestens diese Punkte dokumentieren:

Zeitpunkt, Tunnelname, Peer-IP, Source, Destination und Service
WebAdmin-Status sowie ipsec statusall vor und nach dem Test
zugeordnete Firewall- und NAT-Regel
Packet Capture und Zähler in beide Richtungen
Rückroute und Remote-Regel auf der Gegenstelle
Änderung, Ergebnis und vorbereiteter Rollback

StrongSwan-Debug danach ausschalten. Für Sophos Support relevante Logs gezielt sichern; Sophos Firewall Logs speichern beschreibt den Export. Grössere Logpakete und Captures vor der Weitergabe auf sensible Daten prüfen.