Sophos Firewall: IPsec-VPN systematisch diagnostizieren

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.

Globale Advanced-Einstellungen wie Session-Bereinigung bei Failover, Anti-Replay-Fenster, IKEv2-Cookie-Schwelle oder die Verwendung bereits aufgelöster Peer-Adressen werden nicht als erster Diagnoseversuch verändert. Ihre Wirkung, Ausgangskontrolle und Rücknahme beschreibt Globale VPN-Einstellungen sicher verwenden.

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.

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.

Vor der CLI-Diagnose zeigt Current activities > IPsec connections nur die aktuell aufgebauten IPsec-Verbindungen. Die Liste lässt sich nach Connection name, Local server name, Local subnet, Username, Remote server/host oder Remote subnet filtern und mit Refresh neu laden. Disconnect trennt die ausgewählte Verbindung aktiv und ist deshalb keine harmlose Aktualisierung: erst Zeitpunkt und Zustand dokumentieren, dann nur in einem geplanten Testfenster trennen. Die Momentaufnahme ersetzt weder Child-SA-, Log- noch Trafficprüfung.

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 festhalten:

service -S | grep strongswan

Zeigt die Ausgabe bereits einen aktiven Debug-Zustand, den Umschaltbefehl nicht erneut ausführen. Zuerst Eigentümer und Zweck der laufenden Diagnose klären; der folgende Ein-/Ausschaltablauf gilt nur, wenn Debug anfangs inaktiv war. Die genaue Statusdarstellung kann je nach Build abweichen.

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

Wenn Debug noch nicht aktiv ist, den Befehl einmal ausführen und den neuen Zustand kontrollieren:

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

Danach strongswan.log in einem zweiten Terminal verfolgen, den Fehler genau einmal reproduzieren und tail mit Ctrl+C beenden:

tail -f /log/strongswan.log

Zum Abschluss denselben Umschaltbefehl einmal ausführen. Die zweite Zeile muss bestätigen, dass der zuvor notierte normale Zustand ohne Debug wiederhergestellt ist:

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. Zuerst IDs und den hinterlegten PSK auf beiden Seiten vergleichen. Wenn der PSK neu gesetzt werden muss, geschieht dies koordiniert auf beiden Peers in einem Wartungsfenster; 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.

Bei Remote peer is refusing our Phase 1 proposals die Phase-1-Werte sowie Gateway address und Listening interface beider Seiten vergleichen. Stimmen die Werte überein, muss der Peer-Admin die Konfiguration und die zeitgleichen Logs der ablehnenden Gegenstelle prüfen. Bei Remote peer reports we failed to authenticate dort zusätzlich bestätigen, ob der erwartete ID-Typ abweicht, etwa IP-Adresse statt DNS-Name. Local und Remote ID müssen kreuzweise in Typ und Wert passen; nur die bestätigte Abweichung korrigieren und den Aufbau erneut prüfen. Vor einer Änderung die bisherigen Werte sichern und die Anpassung mit dem Peer-Admin im Wartungsfenster abstimmen; ohne Verbesserung den dokumentierten Zustand wiederherstellen. PSKs nicht in Logs oder Support-Paketen weitergeben.

Die Meldungen Error on decryption of the exchange oder Information field of the IKE request is malformed or not readable sprechen zunächst für unterschiedliche Preshared Keys. Ist der PSK auf beiden Seiten bestätigt identisch und bleibt der Fehler bestehen, nennt Sophos als seltenere Ursache beschädigte Pakete beim ISP oder auf einem vorgeschalteten Router beziehungsweise einer Firewall. Mit dem Provider oder dem zuständigen Admin den betroffenen Pfad anhand zeitgleicher, eng gefilterter Captures prüfen und die WAN-MTU-/MSS-Werte mit den Providerangaben vergleichen. Ein einzelner Capture beweist keine Paketbeschädigung. Die bestehende Anleitung zu MTU und MSS zeigt Ausgangskontrolle, sicheren Test und Rücknahme; Werte nicht auf Verdacht global reduzieren. TCP-MSS ist kein Mittel zur Reparatur der IKE-Aushandlung. Captures vor der Weitergabe auf sensible Daten prüfen.

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.

Bleibt nach erfolgreicher Phase 1 NO_PROPOSAL_CHOSEN oder Remote peer reports INVALID_ID_INFORMATION bestehen, obwohl Phase-2-Encryption, Authentication, PFS-/DH-Gruppe und spiegelbildliche Subnetze abgeglichen sind, den Peer-Admin die zeitgleichen Aushandlungslogs auf der Gegenstelle prüfen lassen. Tunnelname, Zeitpunkt, angebotene Selector-Werte und den INSTALLED-Status der betroffenen Child SA beziehungsweise des betroffenen Selectors aus ipsec statusall mitgeben; ausdrücklich festhalten, ob diese SA fehlt, statt aus dem Fehler auf das Fehlen aller SAs zu schliessen. ip xfrm policy ergänzt die Prüfung der Policies, nicht den Nachweis installierter SAs. Vor einer Änderung bisherige Werte und Rückweg dokumentieren und ein Wartungsfenster abstimmen. Danach nur die belegte Abweichung koordiniert ändern und Aufbau sowie denselben Testfluss erneut kontrollieren; ohne Verbesserung den vorherigen Zustand wiederherstellen.

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 bei null oder steigen nicht, 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.

Packet Capture verwendet einen begrenzten Puffer und stoppt, sobald er voll ist. Die Ansicht zeigt unter anderem Rule ID, NAT ID, Status und Reason. Während eines Standard-Captures wird beschleunigter FastPath-Traffic normalerweise vorübergehend über den SlowPath geführt; ein leerer oder abgebrochener Capture wird deshalb zuerst gegen Pufferstatus, Filter und Testzeitpunkt geprüft, nicht als alleiniger Beweis für fehlenden Traffic gewertet.

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 legt SFOS die VPN-Routen im Backend an. Sie erscheinen nicht in der normalen Routingansicht. Manuelle IPsec Routes und die Route Precedence lassen sich in der Device Console lesen:

system ipsec_route show
system route_precedence show

Die Standardreihenfolge lautet static, sdwan_policyroute, vpn. Ein fehlender Eintrag in der normalen Routingansicht beweist deshalb keinen Routingfehler. Für den konkreten Testfluss zusätzlich Diagnostics > Tools > Route lookup, Firewall-Log und Packet Capture gemeinsam auswerten.

Bei route-based IPsec hängt der Routingweg vom Typ des XFRM-Interfaces ab:

Any/Any oder Dual: Das XFRM-Interface erhält IP-Adressen. Eine statische, SD-WAN- oder dynamische Route muss den entfernten Verkehr auf dieses Interface lenken.
Konkrete Traffic Selectors: SFOS legt die statische Route automatisch an. Dem XFRM-Interface lassen sich keine IP-Adresse und keine zusätzliche Route zuweisen.

Das XFRM-Interface unter Network > Interfaces und 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

Bei mehreren adressierten XFRM-Interfaces zusätzlich die Transitnetze vergleichen: Jedes Interface benötigt ein eigenes, nicht überlappendes Netz. Unterschiedliche einzelne IP-Adressen genügen nicht. xfrm1 mit 192.168.0.1/24 und xfrm2 mit 192.168.0.6/24 liegen beide in 192.168.0.0/24; auch 192.168.0.1/16 auf xfrm1 überlappt mit 192.168.0.6/24 auf xfrm2, weil das /16 das /24 einschliesst. Diese Beispiele zeigen einen Fehler, keine empfohlenen Adressen. Gemeint sind die Interface-Transitnetze, nicht die geschützten LAN-Netze in den Traffic Selectors.

⚠️ Eine Änderung der XFRM-Adressierung kann den Tunnelpfad und den Managementzugang unterbrechen. Vorher IP-Adressen, Präfixe und abhängige Routen auf beiden Seiten sichern und einen unabhängigen Managementzugang sowie ein Wartungsfenster vorbereiten. Nur die betroffenen adressierten Interfaces unter Network > Interfaces auf freie, nicht überlappende Transitnetze umstellen und die abhängige Peer-Adressierung und Routen koordiniert anpassen. Danach Route lookup, denselben Testfluss und Byte-Zähler in beide Richtungen prüfen. Ohne Verbesserung die dokumentierten Adressen, Präfixe und Routen auf beiden Seiten wiederherstellen. Bei konkreten Traffic Selectors gilt weiterhin: keine XFRM-IP-Adresse oder zusätzliche Route zuweisen.

Nutzen mehrere Verbindungen dieselben lokalen und entfernten Netze als alternative Pfade, müssen Auswahl und Failover-Design eindeutig sein. Policy-based und route-based Verbindungen mit konkreten Traffic Selectors werden dafür einer gemeinsamen IPsec-Failover-Gruppe zugeordnet. Any/Any-XFRM-Tunnel können stattdessen über SD-WAN-Routen umgeschaltet werden; der verlinkte Ablauf erklärt Gruppenreihenfolge, Health Check und kontrollierten Umschalttest.

NAT nach Tunneltyp prüfen

NAT ist erlaubt, ersetzt aber keine Route. Zuerst muss der unübersetzte oder übersetzte Zielpfad den richtigen Tunnel wählen; danach wird geprüft, ob die Gegenstelle die tatsächlich verwendeten Adressen erwartet.

Sind lokale und entfernte Netze identisch, reicht ein einzelner SNAT-Hinweis nicht. Der vollständige spiegelbildliche Adress-, Tunnel-, Regel- und Routingablauf steht unter IPsec bei überlappenden Netzen mit NAT.

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: Das XFRM-Interface besitzt eine IP-Adresse und braucht eine explizite Route. Ob und wie übersetzt wird, muss aus der treffenden NAT-Regel und Packet Capture hervorgehen; keine Übersetzung allein aus dem Tunneltyp ableiten.
Route-based mit konkreten Traffic Selectors: SFOS erstellt die Route automatisch, dem XFRM-Interface wird keine IP-Adresse zugewiesen. Eine MASQ-Annahme auf eine vermeintliche XFRM-IP ist daher kein belastbarer Diagnoseweg; stattdessen Original- und übersetzte Source sowie die treffende NAT Rule ID prüfen.

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.
Bei policy-based IPsec beendet ein Idle-Timeout auf der entfernten Firewall die Verbindung nach Inaktivität. Mit dem Peer-Admin den Timeout der betroffenen VPN-Verbindung und den Abbruchzeitpunkt vergleichen. Vor einer Änderung den bisherigen Wert und Geltungsbereich notieren; bei bestätigter Ursache den Idle-Timeout dieser Verbindung auf der Gegenstelle in einem vereinbarten Testfenster deaktivieren. Die Verbindung kann dadurch bei Inaktivität bestehen bleiben. Anschliessend den zuvor problematischen Leerlauf abwarten und denselben Testfluss samt Tunnelstatus und Byte-Zählern prüfen. Ohne Verbesserung den bisherigen Peer-Wert wiederherstellen. Das ist keine Änderung globaler SFOS-Timeouts, der Key Lifetimes oder von DPD.
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.
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 Respin Build 411 oder MR1 auf bestimmten 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 zuvor dokumentierten Ausgangszustand wiederherstellen. War Acceleration vor dem Test aktiv, gilt:

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

Nur den in diesem Ablauf eingeschalteten StrongSwan-Debug danach wieder ausschalten. Einen bereits vorher aktiven Debug-Zustand nicht ungeklärt verändern. 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.