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.

Der Artikel erklärt, 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. Wenn ein neuer Standorttunnel erst geplant oder eingerichtet wird, passt zuerst Sophos Firewall Site-to-Site IPsec VPN einrichten. Für allgemeine CLI-Grundlagen hilft zusätzlich Sophos Firewall CLI Troubleshooting: wichtige Befehle.

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:

• Tunnelname: zum Beispiel azure-vpn
• Lokales Gateway: WAN-Adresse oder FQDN der Sophos Firewall
• Remote Gateway: öffentliche IP oder FQDN der Gegenstelle
• IKE-Version: IKEv1 oder IKEv2
• Authentifizierung: Preshared Key oder Zertifikat
• Lokale ID / Remote ID: IP-Adresse, FQDN oder E-Mail-ähnlicher Identifier
• Lokale Netze: zum Beispiel 172.16.10.0/24
• Remote Netze: zum Beispiel 10.20.30.0/24
• VPN-Typ: policy-based oder route-based
• Erwarteter Traffic: Source, Destination, Port und Richtung

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.

Wenn der Tunnel steht und kleine Tests funktionieren, grössere Übertragungen aber hängen bleiben, sollte man zusätzlich MTU und MSS prüfen. Der Ablauf dafür steht in Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

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

Welche Ebene ist betroffen?

Vor Debug-Logs sollte man das Problem grob einordnen. Dadurch wird schneller klar, ob man bei IKE, Phase 2, Routing oder Paketfluss suchen muss.

• Tunnel bleibt down: Wahrscheinlich liegt das Problem bei IKE, Gateway, IDs, PSK, Zertifikat oder Proposal. strongswan.log live prüfen und Phase 1 vergleichen.
• Tunnel wechselt ständig zwischen up und down: Fokus auf Rekey, DPD, WAN-Stabilität oder Proposal. Zeitstempel, DPD, Lifetime und WAN-Events vergleichen.
• Phase 1 steht, aber keine Child SA: Fokus auf Traffic Selectors, Phase-2-Proposal oder PFS. Lokale und entfernte Netze spiegelbildlich prüfen.
• Tunnel ist grün, aber Byte-Zähler bleiben leer: Traffic erreicht den Tunnel wahrscheinlich nicht. Firewall-Regel, NAT, Route und Client-Gateway prüfen.
• Nur ausgehende Bytes steigen: Rückweg oder Gegenstelle fehlt. Remote-Firewall, Remote-Route und Zielsystem prüfen.
• Packet Capture zeigt Pakete ohne passende Regel: Regelreihenfolge, Zone oder Service passt nicht. Log Viewer, Policy Test und Rule ID vergleichen.

Diese Einordnung ersetzt keine Detailanalyse. Dadurch wird aber verhindert, dass man einen Phase-2-Fehler mit Firewall-Regeln sucht oder bei einem Rückwegproblem unnötig den Preshared Key neu setzt.

Logs sammeln

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

• strongswan.log: wichtigste IPsec-Logdatei für IKE, Authentifizierung und Child SAs.
• charon.log: Log des IKE-Daemons, je nach Version und Situation hilfreich.
• strongswan-monitor.log: Monitoring des IPsec-Dienstes.
• dgd.log: Dead Gateway Detection und VPN-Failover.

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.

SFOS 22: Policy-based IPsec und NAT bewusst prüfen

Bei Upgrades auf SFOS 22 sollte policy-based IPsec besonders sorgfältig geprüft werden. Sophos weist in den SFOS-22-Release-Notes auf ein geändertes Verhalten bei policy-based IPsec VPN hin. Zusätzlich ist in den behobenen Problemen NC-170917 dokumentiert: Policy-based IPsec Traffic konnte fehlschlagen, wenn die Default-SNAT-Regel mit einer statischen IP-Adresse statt MASQ konfiguriert war.

Für die Praxis heisst das: Wenn ein policy-based Tunnel nach dem Upgrade grün ist, aber kein oder nur einseitiger Traffic fliesst, sollte NAT nicht als Nebenthema behandelt werden. Eine alte, breite oder ungewöhnlich angepasste Default-SNAT-Regel kann genau den Traffic verändern, den die Gegenstelle mit den ursprünglichen Netzen erwartet.

Typische Prüfpunkte nach einem SFOS-22-Upgrade:

• Ist der Tunnel wirklich policy-based? Bei policy-based IPsec sind lokale und entfernte Netze Teil der Aushandlung. NAT kann diese Erwartung brechen.
• Wurde die Default-SNAT-Regel angepasst? Eine statische SNAT-IP statt MASQ kann nach einem Upgrade andere Auswirkungen haben als erwartet.
• Gibt es spezifische VPN-NAT-Regeln? Diese müssen oberhalb allgemeiner SNAT- oder MASQ-Regeln stehen und zur Richtung des Traffics passen.
• Stimmen Traffic Selectors und NAT-Objekte überein? Die Gegenstelle muss entweder die Originalnetze oder die übersetzten Netze erwarten, nicht beides zufällig.
• Zeigt Packet Capture die erwartete Source-IP? So erkennt man, ob die Firewall vor dem Tunnel eine andere Quelladresse verwendet.

Ein sauberer Testfall besteht aus einer Quelle, einem Ziel und einem Dienst. Danach prüft man nacheinander Firewall-Regel, NAT-Regel, ipsec statusall, ip route show table 220, Packet Capture und Gegenstelle. Wenn der Test nur mit deaktivierter oder verschobener NAT-Regel funktioniert, liegt das Problem nicht beim Tunnelaufbau, sondern beim Pfad in den Tunnel.

Für die Upgrade-Planung passt zusätzlich Sophos Firewall vor SFOS 22 Upgrade prüfen. Für die NAT-Grundlagen und Regelreihenfolge ist NAT auf Sophos Firewall verstehen der bessere Einstieg.

SFOS 22: PPPoE-WAN mit Alias-Interface und IPsec Acceleration

Wenn nach einem Upgrade auf SFOS 22.0 GA oder SFOS 22.0 MR1 ein IPsec-Tunnel verbunden ist, aber kein Traffic weitergeleitet wird, kann es in bestimmten Setups einen zusätzlichen Sonderfall geben. Sophos führt in der Known-Issues-Liste NC-181526: Auf XGS-Hardware können IPsec-Tunnel auf Alias-Interfaces eines PPPoE-WAN-Ports zwar aufgebaut werden, aber keinen Nutztraffic weiterleiten, wenn IPsec acceleration aktiv ist.

Dieser Punkt sollte erst geprüft werden, wenn die normalen Ursachen nicht passen. Ein grüner Tunnel ohne Traffic ist meistens weiterhin ein Regel-, Routing-, NAT- oder Rückwegproblem. Der SFOS-22-Sonderfall wird wahrscheinlicher, wenn alle folgenden Punkte zusammenkommen:

• Sophos Firewall läuft auf SFOS 22.0 GA oder SFOS 22.0 MR1.
• Es handelt sich um XGS-Hardware.
• Der betroffene Tunnel nutzt ein Alias-Interface auf einem PPPoE-WAN-Port.
• Der Tunnel baut sich auf, aber Nutztraffic bleibt aus.
• Firewall-Regeln, NAT, Routen, Rückweg und Packet Capture erklären das Verhalten nicht.
• IPsec acceleration ist aktiv.

Als Workaround ist das Deaktivieren von IPsec acceleration dokumentiert:

system ipsec-acceleration off

Das sollte man nicht als generischen IPsec-Tuning-Befehl verwenden. Die Änderung gehört in ein Wartungsfenster oder einen dokumentierten Supportablauf, mit Vorher-/Nachher-Test und klarer Zuordnung zum betroffenen Fehlerbild. Sophos listet SFOS 22.0.2 MR2 als Fix-Version für dieses Known Issue. Wenn diese Version für die betroffene Umgebung freigegeben ist, ist ein geplantes Update sauberer als ein dauerhaft vergessener Workaround.

Praktischer Prüfablauf:

1. Tunnelstatus und ipsec statusall dokumentieren.
2. Packet Capture mit engem Source-/Destination-Filter ausführen.
3. Prüfen, ob der Tunnel wirklich ein Alias-Interface auf einem PPPoE-WAN-Port verwendet.
4. Aktive SFOS-Version und Hardwaremodell notieren.
5. Änderung an IPsec acceleration nur gezielt und dokumentiert testen.
6. Nach dem Test Byte-Zähler, Packet Capture, Log Viewer und Anwendungstest vergleichen.

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:

• 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

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:

• Kein Paket kommt auf der Sophos Firewall an: Client, Gateway, VLAN, Switch oder lokales Routing prüfen.
• Paket kommt an, wird aber nicht weitergeleitet: Firewall-Regel, NAT, Route oder Security Feature prüfen.
• Paket wird in den Tunnel gesendet, Antwort fehlt: Rückroute, Gegenstelle, Remote-Firewall oder Remote-Host prüfen.
• Nur ausgehende Bytes in ipsec statusall: Rückweg oder Remote-Policy prüfen.
• Nur eingehende Bytes: lokale Route, lokale Firewall-Regel oder Zielsystem prüfen.

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

• no IKE config found: IKE-Version, Gateway, IDs oder Profil passen nicht. IKE-Version, Local/Remote ID und Proposals vergleichen.
• NO_PROPOSAL_CHOSEN: Proposal-Mismatch. Encryption, Authentication, DH Group, PFS und Lifetime prüfen.
• peer authentication failed: ID oder Authentifizierung passt nicht. Local/Remote ID und PSK beziehungsweise Zertifikat prüfen.
• AUTH_FAILED: Preshared Key, Zertifikat oder ID passt nicht. PSK neu setzen, Zertifikatkette und IDs prüfen.
• traffic selectors ... inacceptable: Lokale und entfernte Netze passen nicht. Subnetze und Hostobjekte spiegelbildlich vergleichen.
• failed to establish CHILD_SA: Phase-2-Netze oder ESP-Proposals passen nicht. Traffic Selectors, PFS, ESP-Profil und Lifetimes prüfen.
• Tunnel grün, keine Bytes: Traffic erreicht den Tunnel nicht. Firewall-Regel, Route, NAT und Client-Gateway prüfen.
• Ausgehende Bytes, keine eingehenden: Gegenstelle oder Rückweg fehlt. Remote-Regeln, Remote-Route und Zielsystem prüfen.
• Grosse Transfers hängen trotz aktivem Tunnel: Fokus auf MTU/MSS, Paketverlust oder Path-MTU-Discovery. MTU und MSS bei VPN-Problemen prüfen.
• SFOS 22, policy-based IPsec, Tunnel grün, Traffic fehlt: NAT, Default-SNAT oder Traffic Selectors passen nach dem Upgrade nicht sauber zusammen. Default-SNAT, VPN-NAT-Regeln, MASQ, Packet Capture und Gegenstelle prüfen.
• SFOS 22, PPPoE-WAN-Alias, Tunnel grün, kein Traffic: Mögliches Known Issue mit IPsec acceleration. Interface-Typ, SFOS-Version und system ipsec-acceleration off nur gezielt testen.
• Reconnects oder häufige Rekeys: Fokus auf Lifetime, DPD, instabile Leitung oder Proposal-Thema. Rekey-Zeiten, DPD, WAN-Stabilität und Logs prüfen.

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.
• Bei SFOS 22 mit policy-based IPsec Default-SNAT, spezifische VPN-NAT-Regeln und erwartete Source-IP prüfen.
• Bei SFOS 22 mit PPPoE-WAN-Alias prüfen, ob das IPsec-Acceleration-Known-Issue passt.
• 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