Sophos Firewall IPsec Remote Access Timeout nach 4 Stunden beheben

Wenn Sophos Connect mit IPsec Remote Access und OTP nach ungefähr vier Stunden trennt, kann das dokumentierte IKEv1-Rekeying des Standardprofils die Ursache sein. Beim Phase-1-Rekey fordert die Firewall erneut ein OTP an; der bestehende Tunnel geht dabei herunter. Sophos nennt für das Standardprofil ein Intervall von ungefähr vier Stunden.

Der Artikel erklärt, wie man das Verhalten einordnet, welche Logs dazu passen und wie man den Wert sauber über ein eigenes IPsec-Profil anpasst. Für die Grundkonfiguration von Sophos Connect passt zuerst Sophos Connect auf Sophos Firewall konfigurieren. Für die Entscheidung zwischen IPsec, SSL VPN, mobilen Clients und ZTNA ist Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt? der bessere Einstieg.

⚠️ Wichtig: Diese Ursache betrifft Remote Access IPsec mit IKEv1 und OTP. Ein SSL-VPN-Abbruch, ein konfigurierter Idle Timeout oder eine instabile Internetverbindung wird durch eine längere IKE-Lebensdauer nicht behoben.

Zuerst die Ursache eingrenzen

Das Rekey-Problem ist wahrscheinlich, wenn mehrere Indizien zusammenpassen:

• Sophos Connect trennt regelmässig nach ungefähr vier Stunden.
• Benutzer müssen nach der Trennung erneut OTP oder MFA bestätigen.
• Die Verbindung ist vorher stabil und funktioniert nach erneuter Anmeldung wieder.
• Andere VPN-Profile oder SSL-VPN-Verbindungen zeigen das Verhalten nicht.
• Die Zeitpunkte passen zum Phase-1-Rekey des zugewiesenen IPsec-Profils.
• Im VPN-Log erscheinen zur Trennung passende IKE-, Authentifizierungs- oder Rekey-Meldungen.

Zuerst unter Remote access VPN > IPsec prüfen, welches IPsec profile ausgewählt ist und ob Disconnect when tunnel is idle aktiviert wurde. Ein Idle Timeout beendet nur inaktive Verbindungen nach dem konfigurierten Idle session time interval. Das ist ein anderes Verhalten als ein wiederkehrender OTP-Abbruch bei aktiver Nutzung.

Wenn die Verbindung zufällig abbricht, nur in bestimmten Netzen nicht funktioniert oder direkt nach dem Aufbau keinen Traffic transportiert, ist eher allgemeines IPsec VPN Troubleshooting nötig.

Zuerst Legacy Remote Access IPsec ausschliessen

Vor allem bei älteren Umgebungen sollte man zuerst klären, welche IPsec-Remote-Access-Variante überhaupt im Einsatz ist. Dieser Artikel behandelt die aktuelle Remote-Access-IPsec-Konfiguration mit Sophos Connect und IPsec-Profilen. Er ist nicht der richtige Einstieg, wenn noch Legacy Remote Access IPsec vorhanden ist oder ein Upgrade auf SFOS 22.0 MR1 blockiert wird.

Praktische Einordnung:

• Verbindung trennt nach ähnlicher Laufzeit und baut danach wieder auf: Dieser Artikel ist der richtige nächste Schritt.
• Upgrade auf SFOS 22.0 MR1 oder neuer wird wegen Legacy IPsec blockiert: Zuerst Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren.
• Tunnel ist verbunden, aber interne Ziele sind nicht erreichbar: Besser mit Sophos Firewall IPsec VPN Troubleshooting weitermachen.
• Benutzer sollen von IPsec auf SSL VPN, ZTNA oder ein anderes Modell wechseln: Dafür passt Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.

Diese Abgrenzung ist wichtig, weil ein Key-Life-Tuning kein Migrationskonzept ersetzt. Wenn eine alte Legacy-Konfiguration noch auf der Firewall liegt, sollte sie vor einem grösseren Firmware-Upgrade sauber dokumentiert, ersetzt und entfernt werden.

Warum IKEv1-Rekeying mit OTP den Tunnel trennt

Sophos Connect verwendet für Remote Access IPsec ein IKEv1-Profil. In vielen Umgebungen ist DefaultRemoteAccess zugewiesen. Dieses Profil bestimmt unter anderem die Lebensdauer der Phase-1-Security-Association und den Zeitpunkt, an dem die Neuaushandlung beginnt.

Für den Zeitpunkt sind drei Felder relevant:

• Key life: maximale Lebensdauer der Phase-1-SA in Sekunden.
• Re-key margin: Zeitraum vor Ablauf der Key life, in dem die Neuaushandlung beginnt.
• Randomize re-keying margin by: prozentuale Streuung des Rekey-Zeitpunkts, damit nicht alle Tunnel gleichzeitig neu aushandeln.

Der vorhandene Screenshot zeigt für DefaultRemoteAccess eine Key life von 18000 Sekunden. Daraus darf jedoch keine universelle Vier-Stunden-Formel abgeleitet werden: Rekey margin, Randomisierung, Clientverhalten und Authentifizierung beeinflussen, wann die Unterbrechung sichtbar wird. Massgebend sind die Werte des tatsächlich zugewiesenen Profils und die Zeitstempel im konkreten Fehlerfall.

Wichtig ist die fachliche Entscheidung: Ein längerer Wert reduziert Re-Authentifizierungen, verlängert aber auch die Lebensdauer der IKE-SA. Das ist ein Betriebs- und Sicherheitsentscheid, kein reiner Komfortschalter.

Logs mit der Verbindungsdauer korrelieren

Im Log viewer den Bereich VPN öffnen und den Verbindungsaufbau sowie die spätere Trennung desselben Benutzers vergleichen. Dafür Startzeit, Benutzer, öffentliche Client-IP und Zeitpunkt der erneuten OTP-Anforderung notieren. Zusätzlich den Sophos-Connect-Clientstatus zum selben Zeitpunkt erfassen.

Meldungen wie invalid SPI können nach abgelaufenen oder bereits ersetzten Security Associations auftreten. Sie sind allein aber kein Beweis für dieses Problem. Belastbarer ist die Kombination aus regelmässiger Laufzeit, IKEv1-Profil, OTP-Anforderung und zeitlich passendem Phase-1-Rekey. Bei wiederkehrenden VPN-Problemen helfen zusätzlich Sophos Firewall Logs für Support und Analyse sichern und Sophos Firewall Troubleshooting: Services und Logs.

IPsec-Profil über die GUI anpassen

Die sauberere Methode ist, nicht direkt am Standardprofil zu arbeiten, sondern das Profil zu klonen und den neuen Wert bewusst für Remote Access zu verwenden.

Der aktuelle Menüpfad lautet:

Profiles > IPsec profiles

Vorgehen:

1. Bei DefaultRemoteAccess auf Clone klicken.
2. Neues Profil eindeutig benennen, zum Beispiel RemoteAccess_OTP_12h.
3. Key exchange auf IKEv1 belassen und Re-key connection aktiviert lassen.
4. Unter Phase 1 die Werte Key life, Re-key margin und Randomize re-keying margin by prüfen.
5. Die gewünschte Key life eintragen. Sophos dokumentiert für diesen Workaround höchstens 24 Stunden, also maximal 86400 Sekunden.
6. Unter Phase 2 prüfen, dass die dortige Key life kleiner als der Phase-1-Wert bleibt.
7. Unter Dead peer detection eine für Remote Access auswählbare Einstellung verwenden: deaktiviert oder When peer unreachable: Disconnect.
8. Profil speichern.
9. Unter Remote access VPN > IPsec das neue IPsec profile auswählen und die Konfiguration speichern.
10. Aktualisierte Sophos-Connect-Konfiguration bereitstellen und zuerst mit einem Pilotbenutzer testen.

Nach der Änderung reicht es nicht, nur die Firewall zu speichern. Bei manuell verteilten .scx-Dateien muss man unter Remote access VPN > IPsec mit Export connection eine aktuelle Datei exportieren und auf den Clients neu importieren. Wird bereits eine .pro-Provisionierungsdatei mit Sophos Connect 2.1 oder neuer verwendet, ruft der Client spätere Konfigurationsänderungen automatisch vom VPN Portal ab. Gateway-Adresse und VPN-Portal-Port dürfen dafür nicht zwischenzeitlich geändert worden sein.

Für Clientbetrieb und Versionen passt Sophos Connect Client Version prüfen und sicher aktualisieren. Für Windows-Installationen passt Sophos Connect Client auf Windows installieren, für macOS Sophos Connect Client auf macOS installieren.

Passende Lebensdauer festlegen

Es gibt keine belastbare Formel, mit der aus einer gewünschten OTP-Abfrage direkt ein einzelner ikekeylife-Wert berechnet werden kann. Key life ist die maximale SA-Lebensdauer; der Rekey beginnt bereits innerhalb der Re-key margin und kann zusätzlich randomisiert werden.

Als Beispiel entsprechen 43200 Sekunden zwölf Stunden Key life. Die Neuaushandlung beginnt je nach Re-key margin und Randomisierung davor. Der Wert sollte deshalb nicht als garantierte zwölfstündige Benutzersitzung beschrieben werden. Sophos nennt 24 Stunden als Obergrenze für diesen Workaround.

Vor der Änderung sollte geklärt werden:

• Welche maximale IKE-Schlüssellebensdauer und welches Rekey-Intervall sind aus Security-Sicht akzeptiert?
• Passt der Wert zu Arbeitszeiten, Schichtbetrieb und Helpdesk-Prozess?
• Wird OTP, RADIUS-MFA, Entra ID SSO oder eine andere Authentifizierung verwendet?
• Gibt es Compliance-Vorgaben für erneute Authentifizierung?
• Funktioniert Rekey beziehungsweise Reconnect mit dem aktuellen Sophos-Connect-Client zuverlässig?

Für MFA-Grundlagen auf der Firewall passt MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren. Wenn Microsoft Entra ID SSO im Einsatz ist, sollte zusätzlich Microsoft Entra ID SSO für Sophos Connect und VPN Portal einrichten berücksichtigt werden.

Warum keine direkte Datenbankänderung empfohlen wird

Ältere Runbooks enthalten teilweise direkte Änderungen in der Advanced Shell oder SQL-Befehle gegen die Firewall-Datenbank. Für den normalen Betrieb ist das nicht empfehlenswert.

Gründe:

• Der Eingriff umgeht die normale WebAdmin-Validierung.
• Fehlerhafte Werte können VPN-Profile oder Remote Access stören.
• Änderungen sind schlechter nachvollziehbar.
• Bei Supportfällen ist ein sauberer GUI-Change leichter zu erklären.
• Nach Updates kann sich internes Verhalten ändern.

Deshalb sollte man den Wert über ein eigenes IPsec-Profil im WebAdmin setzen. Direkte Datenbankänderungen gehören höchstens in einen klaren Sophos-Support-Kontext und nicht in eine normale Admin-Anleitung.

Änderung über das Rekey-Fenster testen

Nach der Anpassung sollte ein kleiner Test mit Pilotbenutzern erfolgen.

Prüfpunkte:

1. Neues Profil ist in Remote Access IPsec ausgewählt.
2. Die neue .scx-Datei wurde importiert oder die .pro-Provisionierung hat die Änderung abgerufen.
3. Verbindung baut erfolgreich auf.
4. Interne Ziele sind erreichbar.
5. DNS, Routing und Firewall-Regeln funktionieren.
6. Die Verbindung bleibt bis zum erwarteten Rekey-Fenster aktiv.
7. Beim Rekey tritt keine ungeplante Unterbrechung oder unklare OTP-Schleife auf.
8. VPN-Logs zeigen die erwartete Neuaushandlung ohne neue Fehler.

Wenn die Verbindung zwar aufgebaut wird, aber kein Traffic fliesst, liegt das Problem eher bei Routen, Firewall-Regeln, NAT oder DNS. Dann hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Typische Fehler

Typische Stolperfallen:

• Standardprofil direkt geändert: Andere Remote-Access-Szenarien können unbeabsichtigt betroffen sein. Besser ist ein geklontes Profil, das gezielt zugewiesen wird.
• Clientprofil nicht aktualisiert: Bei manueller .scx-Verteilung verwenden Benutzer weiterhin alte Einstellungen. Mit einer funktionierenden .pro-Provisionierung werden spätere Änderungen dagegen automatisch abgerufen.
• Zu langer Key-Life-Wert: Weniger Re-Authentifizierung bedeutet eine längere Lebensdauer der IKE-SA. Security- und Betriebsanforderungen sollten gemeinsam bewertet werden.
• Nur Client neu installiert: Das Firewall-Profil bleibt unverändert. Firewall-Profil und Clientkonfiguration müssen zusammen geprüft werden.
• invalid SPI als alleiniger Beweis verwendet: Die Meldung kann auch eine Folge bereits ersetzter SAs sein. Verbindungsdauer, IKE-Rekey und OTP-Anforderung müssen zeitlich zusammenpassen.
• Datenbank direkt geändert: Das erhöht das Risiko für Support- und Konfigurationsprobleme. Für den normalen Betrieb sollte das GUI-Profil verwendet werden.

Betriebscheckliste

• Betroffene Benutzer und Zeitpunkte erfassen.
• Prüfen, ob IPsec Remote Access mit Sophos Connect verwendet wird.
• VPN-Logs auf IKE-, SPI- und Re-Keying-Hinweise prüfen.
• Verwendetes IPsec-Profil identifizieren.
• DefaultRemoteAccess klonen statt direkt ändern.
• Phase-1-Werte für Key life, Re-key margin und Randomisierung erfassen.
• Zielwert bis höchstens 24 Stunden fachlich festlegen.
• Neues Profil in Remote Access IPsec zuweisen.
• Clientkonfiguration neu verteilen.
• Pilotbenutzer testen und Helpdesk informieren.
• Nach einigen Tagen prüfen, ob weniger OTP-Reconnect-Fälle auftreten.

FAQ