Sophos Firewall IPsec-Failover-Gruppe einrichten und testen

Eine IPsec-Failover-Gruppe ordnet mehrere Site-to-Site-IPsec-Verbindungen nach Priorität. Fällt der primäre Tunnel aus, aktiviert Sophos Firewall die nächste verfügbare Verbindung. Damit die Umschaltung wirklich hilft, müssen aber beide Tunnel bereits einzeln funktionieren und dieselben produktiven Netze, Regeln, NAT-Erwartungen und Rückwege abdecken.

Kurzablauf: Zwei IPsec-Verbindungen einzeln testen, Remote IDs und Reihenfolge prüfen, unter Site-to-site VPN > IPsec > Failover group zur Gruppe zusammenfassen, eine geeignete Failover Condition wählen und danach Failover sowie Failback mit einem festen Testfluss abnehmen.

Die Anleitung setzt eine vorhandene Site-to-Site-IPsec-Konfiguration voraus. Sie erklärt die Redundanzsteuerung, nicht nochmals den vollständigen Tunnelaufbau.

Wann eine IPsec-Failover-Gruppe passt

Die Gruppe passt vor allem zu policy-based IPsec und route-based IPsec mit konkreten Traffic Selectors. Mehrere Verbindungen mit identischen Local und Remote subnets müssen gemeinsam in einer Failover-Gruppe liegen oder eindeutig unterschiedliche Selektoren verwenden. Andernfalls können sich die Tunnel gegenseitig beeinflussen.

Bei einem vollständig routengesteuerten route-based Any-to-Any-Design ist die Entscheidung anders: Die XFRM-Interfaces erhalten Transferadressen, und statische, dynamische oder SD-WAN Routes bestimmen den Datenpfad. Sophos dokumentiert für dieses Design mehrere XFRM-Gateways mit SD-WAN Profile und SLA-Prüfungen ohne zusätzliche VPN-Failover-Gruppe. Ausserhalb dieses Designs warnt Sophos jedoch auch bei mehreren Any-to-Any-Verbindungen mit identischen Selektoren vor einer fehlenden gemeinsamen Failover-Gruppe.

Den vollständigen Aufbau mit zwei Providern, getrennten XFRM-Gateways, statischen Primary- und Backup-Routen sowie kontrolliertem Failover erklärt Route-based IPsec mit zwei Internetleitungen ausfallsicher einrichten.

Auch ein normales WAN-Failover ersetzt die Gruppe nicht. Der WAN link manager kann eine Internetleitung wechseln, erstellt aber keine zweite IPsec-Verbindung mit eigener Gateway Address, Listening Interface und Gegenstellenkonfiguration.

`system link_failover` ist ein separater CLI-Mechanismus

SFOS 22 veröffentlicht zusätzlich einen Device-Console-Befehl, der einen VPN- oder GRE-Tunnel als Backup für einen Primary Link einträgt. Die publizierte Grammatik lautet:

system link_failover add [primarylink] [portname] [backuplink] [vpn] [gre] [tunnel] [tunnelname] [monitor PING host] [monitor TCP host] [ipaddress] [portnumber]

Bei monitor TCP host muss der zu prüfende TCP-Port angegeben werden; bei monitor PING host entfällt der Port. Das Ziel muss nicht nur antworten, sondern den relevanten Pfad sinnvoll abbilden. Ein erfolgreicher Monitor beweist noch keine funktionierende Anwendung, Firewall-Regel, Route oder Rückrichtung.

Dieser Befehl ist nicht dasselbe wie die im WebAdmin konfigurierte IPsec-Failover-Gruppe und auch nicht das XFRM-/SD-WAN-Design. Die öffentliche SFOS-22-Seite dokumentiert nur add, aber keinen Status-, Lösch- oder Rückbaubefehl und keine Angaben zur Wechselwirkung mit bestehenden Routes oder SD-WAN Policies. Ohne einen für den installierten Build bestätigten Rückweg ist das deshalb kein Copy-and-paste-Verfahren. Für neue Konfigurationen bieten die dokumentierten WebAdmin- oder XFRM-Verfahren den besser nachvollziehbaren Ausgangspunkt.

FQDN mit mehreren WAN-Adressen ist kein Failover

Zeigt derselbe DNS-A-Record gleichzeitig auf die primäre und die nur im Ausfall aktive WAN-Adresse, kann die entfernte Gegenstelle auch die inaktive Adresse auswählen. DNS-Round-Robin kennt weder WAN-Status noch Tunnelzustand. Eine lokale IPsec-Failover-Gruppe korrigiert diese entfernte DNS-Auswahl nicht automatisch.

Für eingehend initiierte Tunnel benötigt die Gegenstelle deshalb entweder zwei ausdrücklich konfigurierte Verbindungen oder einen FQDN, der durch gesundheitsabhängiges DNS beziehungsweise DDNS nur auf die aktuell erreichbare Adresse zeigt. Lässt sich weder die Gegenstelle noch die DNS-Aktualisierung kontrollieren, ist eingehendes Failover mit diesem Aufbau nicht verlässlich umsetzbar. Zwei gleichzeitig publizierte Adressen gelten nicht als getestetes Failover.

Eine VPN-Failover-Gruppe ist ausserdem etwas anderes als ein HA-Cluster. Die Gruppe wechselt zwischen Tunneln. HA wechselt zwischen zwei Firewall-Nodes. In einer kritischen Umgebung müssen deshalb WAN-, VPN- und mögliche HA-Ausfälle getrennt geplant und getestet werden.

Was die Gruppe überwacht

Sophos Firewall prüft die Gegenstelle mit der Failover condition der Gruppe. Das Intervall stammt aus dem globalen Wert Gateway failover time-out unter:

Network > WAN link manager

Der gleiche Wert beeinflusst auch das allgemeine WAN-Gateway-Monitoring. Er sollte deshalb nicht nur für einen einzelnen VPN-Tunnel geändert werden. Ein zu kurzer Wert reagiert schneller, kann bei kurzem Paketverlust aber unnötig umschalten. Ein zu langer Wert toleriert Störungen länger, verlängert jedoch den Ausfall vor dem Wechsel.

Der Health Check bestätigt nur, dass die Remote-Gegenstelle unter der gewählten Ping- oder TCP-Bedingung antwortet. Er beweist nicht, dass DNS, eine Business-Anwendung, NAT, Routing und der komplette Rückweg funktionieren. Diese Punkte werden nach der Umschaltung separat getestet.

Zwei Tunnel für die Gruppe vorbereiten

Im folgenden Beispiel verbinden zwei Tunnel eine Zentrale mit einer Filiale:

Zentrale: 10.10.0.0/16
Filiale: 10.20.0.0/16
primäre Verbindung: HQ-Branch-ISP1
sekundäre Verbindung: HQ-Branch-ISP2
primäre Peer-Adresse: 198.51.100.20
sekundäre Peer-Adresse: 203.0.113.20
gemeinsame Remote ID der Filiale: 10.255.255.2
Failover-Gruppe: HQ-Branch-Zurich

Die Adressen 198.51.100.0/24 und 203.0.113.0/24 sind Dokumentationsnetze und werden durch die echten öffentlichen Peer-Adressen ersetzt. Auch die Netze, Namen und Remote ID sind Beispielwerte. Entscheidend ist das Prinzip: Die Gateway addresses dürfen unterschiedlich sein, die IP-Adresse der Remote ID muss für alle Gruppenmitglieder gleich sein. Auf der Gegenstelle muss diese Remote ID jeweils zur Local ID passen.

Vor dem Gruppieren werden beide Verbindungen einzeln geprüft:

Beide Verbindungen sind unter Site-to-site VPN > IPsec aktiv.
Jede Verbindung kann für sich aufgebaut werden und transportiert den gleichen festgelegten Testfluss.
Local und Remote subnets beziehungsweise Traffic Selectors sind spiegelbildlich zur Gegenstelle.
Firewall-Regeln erlauben den benötigten Traffic über die VPN-Zone in beide Richtungen.
NAT ist auf beiden Pfaden gleich und bewusst konfiguriert.
Die Gegenstelle kennt über beide Tunnel einen Rückweg.
Die Profile passen zur jeweiligen Gegenstelle. Die Bedeutung von DPD, Rekeying und Lifetimes erklärt IPsec-Profile auf Sophos Firewall.
Ein alternativer Admin-Zugang und ein Wartungsfenster sind vorhanden.

⚠️ Das Hinzufügen zu einer Failover-Gruppe trennt bereits aufgebaute Verbindungen. Die Änderung deshalb nicht während einer unbegleiteten Remote-Sitzung oder ohne getesteten Rückfallweg durchführen.

Eine Verbindung kann nur Mitglied einer Failover-Gruppe sein. Solange sie einer Gruppe zugeordnet ist, lässt sie sich nicht löschen. Remote-Access-IPsec-Verbindungen können nicht als Gruppenmitglied verwendet werden.

Geeignete Failover Condition wählen

Sophos unterstützt Ping oder TCP mit einem definierten Port. Die Bedingung wird auf beiden Firewalls bewusst freigegeben:

Ping: einfach zu prüfen, benötigt aber Ping/Ping6 für die WAN-Zone unter Administration > Device access. Sophos dokumentiert diese Zonenfreigabe als Voraussetzung. Bei festen Peer-Adressen kann eine enge Local Service ACL Exception als Härtung geprüft werden; sie muss die tatsächlich verwendete Quelladresse des Peers erfassen. Die Umsetzung erklärt Device Access und Local Service ACL.
TCP 22: benötigt SSH über die VPN-Zone. WAN-SSH sollte dafür nicht geöffnet werden. Ein Managementdienst ist kein guter allgemeiner Health Check, wenn er nur für die Überwachung exponiert werden müsste.
Anderer TCP-Port: benötigt passende eingehende und ausgehende Firewall-Regeln. Der Dienst muss dauerhaft verfügbar sein und darf nicht allein vom Zustand einer zufälligen Anwendung abhängen.

Die Bedingung soll einen stabil erreichbaren Antwortdienst beziehungsweise Pfad der Remote-Gegenstelle abbilden. Antwortet der für TCP verwendete Dienst wegen einer Wartung, eines lokalen Ausfalls oder einer Host-Firewall nicht, kann die Gruppe umschalten, obwohl der IPsec-Pfad selbst noch verfügbar wäre.

IPsec-Failover-Gruppe konfigurieren

Der Menüpfad lautet:

Site-to-site VPN > IPsec > Failover group > Add

Unter Name einen eindeutigen Namen eintragen, im Beispiel HQ-Branch-Zurich.
Unter Member connections mindestens zwei Site-to-Site-IPsec-Verbindungen auswählen. Nur Verbindungen mit aktivem Status nehmen tatsächlich am Failover teil; deshalb alle vorgesehenen Mitglieder vor der Inbetriebnahme aktivieren und einzeln prüfen.
Die Verbindungen in die gewünschte Reihenfolge bringen: HQ-Branch-ISP1 zuerst, HQ-Branch-ISP2 danach. Die erste Verbindung ist der primäre Tunnel.
Mail notification aktivieren, wenn Verbindungsfehler per E-Mail gemeldet werden sollen. Dafür müssen die Notification settings und VPN-Benachrichtigungen bereits funktionieren.
Automatic failback aktivieren, wenn die Gruppe nach der Wiederherstellung zum bevorzugten Tunnel zurückkehren soll.
Eine passende Failover condition mit Ping oder TCP und Port festlegen.
Mit Save speichern.
Den Statusschalter der Gruppe aktivieren. Erst dadurch wird die Gruppe aktiv und versucht, die primäre Verbindung aufzubauen.

Bei zwei Sophos Firewalls werden auf beiden Seiten Verbindungseigenschaften, Member-Reihenfolge, Remote IDs und Health-Check-Freigaben geprüft. Eine einseitig korrekte Gruppe ersetzt keine passende Gegenstellenkonfiguration.

Was mit DPD und Key negotiation tries passiert

Sobald eine Verbindung Mitglied der Gruppe ist, schaltet SFOS für diese Verbindung Dead Peer Detection aus und verwendet 3 für Key negotiation tries. Die Failover Condition übernimmt die Überwachung.

Nach dem Entfernen aus der Gruppe verwendet die Verbindung wieder die DPD- und Key-negotiation-Werte ihres zugeordneten IPsec-Profils. Dieses Verhalten gehört in den Rollback-Test, auch wenn das Profil selbst nicht bearbeitet wurde.

Failover und Failback kontrolliert testen

Vor dem Ausfalltest wird ein konkreter Datenfluss festgelegt, beispielsweise:

Source: 10.10.10.25
Destination: 10.20.20.15
Service: TCP 443
erwartete Firewall-Regel: HQ-to-Branch-HTTPS

Danach folgt der Test in klarer Reihenfolge:

Gruppenstatus, Member-Reihenfolge, Firmware-Build und Gateway failover time-out dokumentieren.
Primären Tunnel auf beiden Seiten im WebAdmin prüfen. Mit echtem HTTPS-Traffic bestätigen, dass Hin- und Rückweg funktionieren.
Den Zustand in der Advanced Shell mit ipsec statusall sichern.
Den primären WAN- oder Upstream-Pfad im Wartungsfenster kontrolliert unterbrechen. Nicht die ganze Failover-Gruppe ausschalten, weil dadurch alle aktiven Gruppentunnel deaktiviert werden.
Länger als den konfigurierten Gateway failover time-out beobachten und den Zeitpunkt der Umschaltung notieren.
Prüfen, ob HQ-Branch-ISP2 aufgebaut wird und der gleiche HTTPS-Test in beide Richtungen funktioniert.
Firewall-Regel, NAT, Rückweg und Anwendungsfunktion kontrollieren. Ein grüner Tunnel allein ist kein Erfolgskriterium.
Den primären Pfad wiederherstellen und Automatic failback beobachten.
Nach dem Rückwechsel denselben Test erneut ausführen und die tatsächlich gemessene Unterbrechung dokumentieren.

Bestehende TCP-Sessions können beim Wechsel abbrechen. Der neue Tunnel besitzt andere Security Associations und kann über eine andere öffentliche Adresse laufen. Die Anwendung muss daher häufig eine neue Sitzung aufbauen. IPsec-Failover verbessert die Verfügbarkeit, garantiert aber keine unterbrechungsfreie Sitzung.

Automatic failback endet nach fünf erfolglosen Versuchen

Wird die primäre Gegenstelle wieder erreichbar, versucht SFOS bei aktiviertem Automatic failback bis zu fünfmal, die bevorzugte Verbindung wiederherzustellen. Gelingt dies nicht, bleibt der sekundäre Tunnel aktiv. Die Firewall prüft den primären Tunnel danach nicht unbegrenzt weiter; ein neuer Rückwechsel erfolgt erst, wenn der sekundäre Pfad ausfällt. Enthält die Gruppe mehr als zwei Verbindungen, fällt SFOS auf die erste verfügbare Verbindung in der Reihenfolge Member connections zurück.

Die Gruppe lässt sich manuell aus- und wieder einschalten, um den primären Aufbau erneut anzustossen. Dabei entsteht Downtime. Vorher deshalb Logs, Gegenstelle, Profil, IDs und Pfad prüfen.

Logs lesend prüfen

Für die Gruppenentscheidung ist dgd.log wichtig, für den eigentlichen IPsec-Aufbau strongswan.log. Die folgenden Befehle laufen in der Advanced Shell und verändern keine Konfiguration:

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

Bei Bedarf ergänzt man charon.log und das verbindungsspezifische Aktionslog. Bei der Bezeichnung des Monitor-Logs widersprechen sich die offiziellen SFOS-22-Seiten: Die allgemeine Logreferenz nennt ipsec_monitor.log, die IPsec-Troubleshooting-Seite strongswan-monitor.log. Deshalb nur die auf dem installierten Build vorhandene Datei lesen. In der letzten Zeile wird HQ-Branch-ISP1 durch den echten Verbindungsnamen ersetzt:

tail -n 200 /log/charon.log
for log in /log/ipsec_monitor.log /log/strongswan-monitor.log; do [ -f "$log" ] && tail -n 200 "$log"; done
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Zeitstempel aus dgd.log, IPsec-Status, WAN-Ereignis und Anwendungstest werden miteinander verglichen. Ein fehlgeschlagener Health Check ohne passenden Tunnel- oder Anwendungsfehler beweist noch keine Providerstörung. Der vollständige Diagnosepfad steht unter Sophos Firewall IPsec VPN Troubleshooting.

Typische Fehler und sichere Rückkehr

Gruppe lässt sich nicht sauber aktivieren

Mindestens zwei Verbindungen müssen ausgewählt sein. Nur aktive Verbindungen nehmen am Failover teil. Prüfen, ob ein vorgesehenes Mitglied deaktiviert ist, bereits einer anderen Gruppe angehört, als Remote Access angelegt wurde oder eine abweichende Remote ID verwendet. Danach beide Tunnel wieder einzeln testen, bevor die Gruppe erneut aktiviert wird.

Sekundärer Tunnel ist grün, aber Traffic fällt aus

Die Gruppenlogik hat dann wahrscheinlich funktioniert, der Datenpfad aber nicht. Firewall-Regeln, NAT, Local und Remote subnets, automatische oder manuelle Routen sowie den Rückweg auf der Gegenstelle prüfen. Der sekundäre Tunnel muss denselben produktiven Testfluss tragen können wie der primäre.

Gruppe schaltet zu früh oder zu spät

Failover Condition und Gateway failover time-out gemeinsam prüfen. Ein instabiles Ping- oder TCP-Ziel kann unnötige Wechsel auslösen. Ein langer globaler Timeout verzögert dagegen auch andere davon abhängige Gateway-Prüfungen. Nicht nur den Zahlenwert ändern, sondern Ursache, Paketverlust und tatsächliche Umschaltzeit dokumentieren.

Reihenfolge nach Drag-and-drop kontrollieren

Die aktuelle öffentliche SFOS-22-Hilfe nennt für eine fehlerhafte Reihenfolge nach Drag-and-drop keine belastbare Versions- oder Fixgrenze. Deshalb die gespeicherte Reihenfolge nach jeder Änderung erneut öffnen und mit der geplanten Priorität vergleichen.

Gruppe zurückbauen

Das Ausschalten einer Failover-Gruppe deaktiviert die aktiven Tunnel ihrer Mitglieder. Benötigte Einzelverbindungen werden danach separat wieder aktiviert. Sophos dokumentiert dagegen nicht, welche Nebenwirkungen das Löschen der Gruppe selbst hat. Deshalb die Gruppe im Wartungsfenster zuerst ausschalten, Zuordnungen kontrolliert lösen und keine automatische Reaktivierung voraussetzen. Für einen kontrollierten Rollback:

Ausgangszustand, Member-Reihenfolge und verwendete Profile sichern.
Wartungsfenster und alternativen Admin-Zugang bestätigen.
Gruppe ausschalten und den Unterbruch dokumentieren.
Verbindungen aus der Gruppe entfernen beziehungsweise die ursprüngliche Zuordnung wiederherstellen.
Benötigte Einzelverbindung aktivieren.
DPD- und Key-negotiation-Verhalten aus dem Profil erneut berücksichtigen.
Den gleichen Testfluss sowie Logs und Rückweg prüfen.

Betrieb

Failover und Failback nach Firmware-, Provider-, Peer-, Routing-, NAT- oder Profiländerungen erneut testen.
Member-Reihenfolge, Remote IDs, Profile, Health-Check-Bedingung und globalen Timeout dokumentieren.
Mail notification nur als Hinweis verwenden; die technische Abnahme erfolgt weiterhin mit Status, Logs und echtem Traffic.
Beide Tunnel in Monitoring, Wartungsplan und Gegenstellendokumentation aufnehmen.
Prüfen, ob der sekundäre Provider dieselben Allowlists, NAT-Abhängigkeiten und öffentlichen Erreichbarkeiten erfüllt.
Manuelles Aus- und Einschalten der Gruppe nur mit eingeplantem Unterbruch verwenden.

FAQ

Was ist der Unterschied zwischen WAN-Failover und einer IPsec-Failover-Gruppe?

WAN-Failover wechselt die Internetleitung der Firewall. Eine IPsec-Failover-Gruppe priorisiert dagegen mehrere vollständig konfigurierte Site-to-Site-IPsec-Verbindungen. Für einen redundanten Tunnel braucht es deshalb mehr als nur ein Backup-WAN.

Warum wechselt Automatic failback nicht mehr zum primären Tunnel zurück?

SFOS versucht die Wiederherstellung des primären Tunnels bis zu fünfmal. Bleiben diese Versuche erfolglos, läuft der sekundäre Tunnel weiter und der primäre wird erst wieder geprüft, wenn der sekundäre Pfad ausfällt. Ein manuelles Aus- und Einschalten der Gruppe startet einen neuen Versuch, verursacht aber Downtime.