Sophos Firewall IPsec VPN Troubleshooting

IPsec Site-to-Site VPNs sind oft unauffällig, solange sie funktionieren. Wenn ein Tunnel aber nicht hochkommt, nach einem Reconnect instabil bleibt oder zwar als verbunden angezeigt wird, aber keinen Traffic transportiert, braucht man eine saubere Reihenfolge für die Analyse. Sonst springt man schnell zwischen PSK, Routen, Firewall-Regeln und Logs hin und her, ohne die eigentliche Ursache zu sehen.

Diese Anleitung zeigt, wie man IPsec-Verbindungen auf der Sophos Firewall systematisch prüft: zuerst den Tunnelaufbau, danach die ausgehandelten Netze und am Schluss den tatsächlichen Paketfluss. Für allgemeine CLI-Grundlagen hilft zusätzlich Sophos Firewall Troubleshooting: Tipps & Tricks für die CLI.

Vor dem Troubleshooting

Zuerst sollte man die Ausgangslage kurz dokumentieren. Das wirkt banal, spart aber viel Zeit, weil viele IPsec-Probleme durch asymmetrische Annahmen entstehen: Die eine Seite glaubt, sie verbindet Netz A mit Netz B, die andere Seite erwartet aber andere IDs, andere Subnetze oder eine andere IKE-Version.

Wichtige Punkte:

Bei policy-based IPsec sind die lokalen und entfernten Netze Teil der Tunnelverhandlung. Bei route-based IPsec ist zusätzlich wichtig, welche Routen zur Tunnel-Schnittstelle zeigen. Wenn Traffic trotz aktivem Tunnel in die falsche Richtung läuft, sind häufig IPsec Routes, statische Routen, SD-WAN Policy Routes oder die Route Precedence der Sophos Firewall beteiligt.

⚠️ Debug-Logs und Packet Captures können sensible Daten enthalten, etwa öffentliche IP-Adressen, interne Netze, Hostnamen oder Nutzdaten. Solche Daten sollten nur gezielt und zeitlich begrenzt gesammelt sowie vor einer Weitergabe geprüft werden.

Diagnosepfad

Für die Praxis hilft eine einfache Reihenfolge:

1. Kommt der Tunnel hoch? Wenn nein, zuerst IKE-Version, IPsec-Profil, IDs, PSK/Zertifikat, NAT-T und Erreichbarkeit der Gegenstelle prüfen.
2. Wird Phase 2 aufgebaut? Wenn nein, Traffic Selectors, lokale und entfernte Netze, PFS und Phase-2-Proposals prüfen.
3. Ist eine Security Association installiert? Wenn ja, ipsec statusall prüfen und auf Byte-Zähler achten.
4. Läuft Traffic durch den Tunnel? Wenn nein, Firewall-Regeln, NAT, Routing, Route Precedence, IPsec Routes und Rückweg prüfen.
5. Sieht man Pakete? Wenn unklar, Log Viewer und Packet Capture kombinieren.

Ein häufiger Denkfehler: Ein grüner Tunnelstatus beweist nur, dass IPsec grundsätzlich ausgehandelt wurde. Er beweist nicht, dass die Firewall-Regeln passen, dass die Routen korrekt sind oder dass die Gegenstelle den Rückweg kennt.

Logs sammeln

Sophos Firewall verwendet StrongSwan für IPsec. Die wichtigsten Logs liegen in /log:

Man öffnet per SSH die Advanced Shell und wechselt bei Bedarf ins Logverzeichnis:

cd /log

Das Live-Log lässt sich direkt verfolgen:

tail -f /log/strongswan.log

Wenn mehrere Tunnel aktiv sind, sollte man filtern. Das kann über den Tunnelnamen, eine Peer-IP oder einen typischen Fehlertext erfolgen:

tail -f /log/strongswan.log | grep -i azure-vpn

Für bestehende Logdateien ist less oft angenehmer:

less /log/strongswan.log

In less kann man mit /suchbegriff innerhalb der Datei suchen. Alternativ filtert grep direkt:

grep -i "no proposal" /log/strongswan.log

StrongSwan-Debug aktivieren

Wenn das normale Log nicht reicht, kann man den StrongSwan-Dienst in den Debug-Modus setzen:

service strongswan:debug -ds nosync

Danach prüfen, ob der Dienst im Debug-Modus läuft:

service -S | grep strongswan

Die Ausgabe sollte bei strongswan den Zustand RUNNING,DEBUG zeigen. Anschliessend den Tunnel neu verbinden oder den Fehler gezielt reproduzieren und das Log beobachten:

tail -f /log/strongswan.log

Der gleiche Debug-Befehl deaktiviert den Debug-Modus wieder:

service strongswan:debug -ds nosync

⚠️ Debug nur so lange laufen lassen, wie er wirklich benötigt wird. IPsec-Debug kann sehr schnell grosse Logdateien erzeugen und unnötig Speicherplatz auf der Firewall belegen.

Phase 1: IKE, IDs und Authentifizierung

Wenn der Tunnel gar nicht aufgebaut wird, liegt die Ursache meistens vor oder während Phase 1. Dann verhandeln die Gateways noch keine Nutzdaten-Netze, sondern zuerst IKE, Authentifizierung und die Identitäten der beiden Seiten.

Typische Ursachen:

• IKE-Version passt nicht zusammen
• IPsec-Profil oder Proposal passt nicht zusammen
• lokale oder entfernte ID ist anders als erwartet
• Preshared Key ist falsch
• Gegenstelle erreicht die falsche öffentliche IP
• NAT-T oder Portweiterleitung auf UDP 500 und 4500 ist nicht sauber
• Zertifikate, CA oder Gültigkeit passen bei zertifikatsbasierter Authentifizierung nicht

No IKE config found

Ein Logeintrag wie no IKE config found oder NO_PROPOSAL_CHOSEN bedeutet häufig, dass die Sophos Firewall keine passende IKE-Konfiguration für das ankommende Paket findet. Das kann an der IKE-Version, am Gateway, an den IDs oder am IPsec-Profil liegen.

Prüfen:

• Stimmt IKEv1 oder IKEv2 auf beiden Seiten?
• Passt die Gegenstelle zur konfigurierten Remote Gateway-Adresse oder zum FQDN?
• Stimmen lokale und entfernte ID?
• Sind Encryption, Authentication, DH Group und Lifetime kompatibel?
• Verwendet die Gegenstelle eventuell eine andere öffentliche IP als dokumentiert?

Peer authentication failed

peer authentication failed, AUTH_FAILED oder no matching peer config found weist oft auf nicht passende IDs oder Authentifizierungsdaten hin. Bei Preshared Key wird gerne zuerst der Schlüssel verdächtigt. Das ist oft richtig, aber nicht immer. Wenn die ID nicht passt, prüft die Firewall unter Umständen gar nicht gegen die erwartete Peer-Konfiguration.

Prüfen:

• Local ID der einen Seite entspricht Remote ID der anderen Seite.
• Remote ID der einen Seite entspricht Local ID der anderen Seite.
• Schreibweise, Gross- und Kleinschreibung, FQDN und IP-Adressen stimmen exakt.
• Preshared Key wurde ohne Leerzeichen am Anfang oder Ende eingetragen.
• Bei mehreren Tunneln zur gleichen Gegenstelle ist eindeutig, welche Verbindung matchen soll.

Invalid HASH_V1 payload oder decryption failed

Bei IKEv1 deuten Meldungen wie invalid HASH_V1 payload length oder decryption failed häufig auf einen falschen Preshared Key hin. Bei IKEv2 sieht man eher AUTHENTICATION_FAILED oder AUTH_FAILED.

In der Praxis sollte man den Preshared Key auf beiden Seiten neu setzen, statt ihn nur visuell zu vergleichen. Copy-Paste aus Passwortmanagern, unsichtbare Leerzeichen oder unterschiedliche Sonderzeichen sind klassische Zeitfresser.

Phase 2: Traffic Selectors und Security Associations

Wenn Phase 1 erfolgreich ist, aber Phase 2 nicht zustande kommt, geht es meist um die Netze und die Child SA. Die Sophos Firewall muss mit der Gegenstelle aushandeln, welche lokalen und entfernten Subnetze durch den Tunnel dürfen.

Typische Loghinweise:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi und TSr zeigen andere Netze als erwartet

Prüfen:

• Lokale und entfernte Netze sind auf beiden Seiten spiegelbildlich konfiguriert.
• Netzmaske und einzelne Hostobjekte stimmen exakt.
• Es gibt keine ungewollten Überschneidungen mit anderen Tunneln.
• Mehrere Phase-2-Netze sind auf beiden Seiten gleich abgebildet.
• PFS, ESP-Encryption, Authentication und Lifetime passen zusammen.

Beispiel: Wenn die Sophos Firewall lokal 172.16.10.0/24 und remote 10.20.30.0/24 erwartet, muss die Gegenstelle genau spiegelbildlich 10.20.30.0/24 nach 172.16.10.0/24 anbieten. Ein /24 auf der einen Seite und ein einzelner Host oder ein grösseres Netz auf der anderen Seite kann bereits reichen, damit die Child SA nicht installiert wird.

Tunnel steht, aber kein Traffic läuft

Wenn der Tunnel als verbunden angezeigt wird, aber kein Traffic durchkommt, ist IPsec selbst nicht automatisch die Ursache. Dann geht es meistens um Routing, Firewall-Regeln, NAT oder den Rückweg.

Zuerst den IPsec-Status in der Advanced Shell prüfen:

ipsec statusall

Interessant sind vor allem:

• Ist die IKE SA ESTABLISHED?
• Ist die Child SA INSTALLED?
• Welche lokalen und entfernten Netze werden angezeigt?
• Steigen die Byte-Zähler in beide Richtungen?
• Sieht man nur ausgehende Bytes, aber keine eingehenden?
• Wird regelmässig neu verbunden oder rekeyed?

Wenn die Child SA installiert ist, aber die Byte-Zähler leer bleiben, erreicht der erwartete Traffic den Tunnel wahrscheinlich nicht. Dann prüft man den Weg vor und nach IPsec.

Firewall-Regeln

Für Traffic durch den Tunnel braucht es passende Firewall-Regeln. Je nach Zonenmodell ist das zum Beispiel LAN nach VPN, VPN nach LAN oder eine eigene Zone. Die Regel muss Source, Destination, Service und Richtung korrekt abdecken.

Wichtig:

• In den relevanten Regeln Log firewall traffic aktivieren.
• Regelposition prüfen, damit keine allgemeinere Regel vorher greift.
• Source- und Destination-Zonen korrekt wählen.
• Bei mehreren VPNs keine zu breiten Objekte verwenden, wenn sie den falschen Tunnel matchen könnten.
• Security Features wie IPS, Webfilter oder Application Control bewusst prüfen, falls sie auf dem Traffic aktiv sind.

Einen allgemeinen Prüfablauf beschreibt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Routing und IPsec Routes

Wenn die Firewall den Traffic nicht in den Tunnel sendet, prüft man die Routen. Bei policy-based IPsec kann zusätzlich die IPsec-Routing-Tabelle relevant sein:

ip route show table 220

Wenn eine manuelle Zuordnung nötig ist, kann eine IPsec Route auf der Sophos Firewall helfen. Wenn mehrere Routing-Arten konkurrieren, sollte man zusätzlich die Routing Priorität der Sophos Firewall prüfen.

Prüfen:

• Gibt es eine spezifischere statische Route, die den Traffic abfängt?
• Greift eine SD-WAN Policy Route vor der VPN-Route?
• Zeigt das Client-Gateway wirklich zur Sophos Firewall?
• Hat die Gegenstelle eine Rückroute zum lokalen Netz?
• Gibt es überlappende lokale und entfernte Netze?

NAT

NAT ist bei IPsec nicht grundsätzlich falsch, aber es muss bewusst konfiguriert sein. Unbeabsichtigtes MASQ oder eine zu breite SNAT-Regel kann dazu führen, dass die Gegenstelle den Traffic nicht mehr dem erwarteten Netz zuordnet.

Prüfen:

• Greift eine generische MASQ-Regel vor einer spezifischen VPN-NAT-Regel?
• Erwartet die Gegenstelle Original-IP-Adressen oder übersetzte Adressen?
• Ist NAT auf beiden Seiten dokumentiert?
• Passt die NAT-Regel zur Richtung des Traffics?

Wenn NAT beteiligt ist, hilft der Artikel NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Log Viewer und Packet Capture kombinieren

Der Log Viewer zeigt, welche Regel oder welches Modul eine Verbindung bewertet hat. Packet Capture im WebAdmin zeigt dagegen, ob Pakete wirklich ankommen, weitergeleitet, verworfen oder von der Firewall selbst verarbeitet werden.

Für IPsec-Troubleshooting sollte man einen möglichst engen Test definieren:

Danach:

1. In der Firewall-Regel Logging aktivieren.
2. Log Viewer mit Source IP, Destination IP und Modul Firewall filtern.
3. Packet Capture mit engem Filter starten, zum Beispiel host 172.16.10.25 and host 10.20.30.15.
4. Test genau einmal reproduzieren.
5. Prüfen, ob Pakete ankommen, weitergeleitet werden und ob Antworten zurückkommen.

Interpretation:

Für längere Mitschnitte oder Supportfälle kann es sinnvoll sein, Logs gezielt zu sammeln. Der Artikel Sophos Firewall Logs für Support und Analyse sichern beschreibt den sauberen Export.

Typische Fehlerbilder

Praktische Checkliste

Sofort prüfen:

• Tunnelstatus und letzte Fehlermeldung im WebAdmin notieren.
• tail -f /log/strongswan.log starten und Tunnel neu verbinden.
• IKE-Version, Local ID, Remote ID und Preshared Key prüfen.
• Traffic Selectors beziehungsweise lokale und entfernte Netze spiegelbildlich vergleichen.
• ipsec statusall auf ESTABLISHED, INSTALLED und Byte-Zähler prüfen.

Wenn der Tunnel steht:

• Firewall-Regeln in beide Richtungen prüfen.
• Logging auf den betroffenen Regeln aktivieren.
• Log Viewer mit Source, Destination und Rule ID filtern.
• Packet Capture mit engem Filter ausführen.
• NAT-Regeln und Route Precedence prüfen.
• Rückroute auf der Gegenstelle bestätigen.

Für Support oder längere Analyse:

• Debug nur kurz aktivieren und danach wieder deaktivieren.
• Relevante Logs sichern.
• Uhrzeit, Tunnelname, Peer-IP, Source, Destination und Testablauf dokumentieren.
• Sensible Daten vor der Weitergabe prüfen.

FAQ

Warum ist der IPsec Tunnel grün, aber es läuft kein Traffic?

Ein grüner Tunnelstatus bedeutet nur, dass IPsec ausgehandelt wurde. Firewall-Regeln, NAT, Routing, Route Precedence, IPsec Routes und der Rückweg der Gegenstelle können trotzdem falsch sein.

Welches Log ist für IPsec auf Sophos Firewall am wichtigsten?

In der Praxis ist strongswan.log die wichtigste Datei. Je nach Fehlerbild können zusätzlich charon.log, strongswan-monitor.log und dgd.log helfen.

Wann sollte man StrongSwan-Debug aktivieren?

Debug ist sinnvoll, wenn das normale Log nicht genügend Informationen liefert. Er sollte aber nur gezielt und kurz aktiviert werden, weil deutlich mehr Logdaten entstehen.

Was bedeutet traffic selectors inacceptable?

Die Netze, die beide Seiten für Phase 2 aushandeln wollen, passen nicht zusammen. Man sollte lokale und entfernte Subnetze, Hostobjekte und mehrere Phase-2-Einträge exakt vergleichen.

Was bedeutet AUTH_FAILED?

AUTH_FAILED weist auf ein Authentifizierungsproblem hin. Häufig sind Preshared Key, Local ID, Remote ID oder Zertifikate nicht identisch zur Erwartung der Gegenstelle.

Quellen

• Sophos Community: Troubleshooting site-to-site IPsec VPN issues
• Sophos Support: KBA-000006520
• Sophos Docs: Packet capture