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 route-based Any-to-Any ist die Entscheidung anders: Die XFRM-Interfaces erhalten Transferadressen, und statische, dynamische oder SD-WAN Routes bestimmen den Datenpfad. Mehrere XFRM-Gateways lassen sich dort direkt über ein SD-WAN Profile und SLA-Prüfungen priorisieren. Dafür ist keine zusätzliche VPN-Failover-Gruppe nötig.

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.

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, stoppt die Planung an dieser Stelle. Zwei gleichzeitig publizierte Adressen dürfen nicht als getestetes Failover gelten.

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:

1. Beide Verbindungen sind unter Site-to-site VPN > IPsec aktiv.
2. Jede Verbindung kann für sich aufgebaut werden und transportiert den gleichen festgelegten Testfluss.
3. Local und Remote subnets beziehungsweise Traffic Selectors sind spiegelbildlich zur Gegenstelle.
4. Firewall-Regeln erlauben den benötigten Traffic über die VPN-Zone in beide Richtungen.
5. NAT ist auf beiden Pfaden gleich und bewusst konfiguriert.
6. Die Gegenstelle kennt über beide Tunnel einen Rückweg.
7. Die Profile passen zur jeweiligen Gegenstelle. Die Bedeutung von DPD, Rekeying und Lifetimes erklärt IPsec-Profile auf Sophos Firewall.
8. 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. Bei festen Peer-Adressen ist eine enge Local Service ACL Exception besser als eine unnötig breite Freigabe. Die sichere 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

1. Unter Name einen eindeutigen Namen eintragen, im Beispiel HQ-Branch-Zurich.
2. Unter Member connections mindestens zwei aktive Site-to-Site-IPsec-Verbindungen auswählen.
3. Die Verbindungen in die gewünschte Reihenfolge bringen: HQ-Branch-ISP1 zuerst, HQ-Branch-ISP2 danach. Die erste Verbindung ist der primäre Tunnel.
4. Mail notification aktivieren, wenn ein Tunnelwechsel per E-Mail gemeldet werden soll. Dafür müssen die Notification settings und VPN-Benachrichtigungen bereits funktionieren.
5. Automatic failback aktivieren, wenn die Gruppe nach der Wiederherstellung zum bevorzugten Tunnel zurückkehren soll.
6. Eine passende Failover condition mit Ping oder TCP und Port festlegen.
7. Mit Save speichern.
8. 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, deaktiviert SFOS für diese Verbindung Dead Peer Detection und setzt Key negotiation tries effektiv auf 3. Die Failover Condition übernimmt die Überwachung. Die Werte in der Profilansicht allein zeigen deshalb nicht das gesamte wirksame Verhalten.

Nach dem Entfernen aus der Gruppe verwendet die Verbindung wieder die DPD- und Key-negotiation-Werte ihres zugeordneten IPsec-Profils. Das ist beim Rollback wichtig: Ein Tunnel kann sich nach der Gruppenauflösung anders verhalten, obwohl das Profil selbst nicht editiert 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:

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

Die Gruppe lässt sich manuell aus- und wieder einschalten, um den primären Aufbau erneut anzustossen. Das verursacht jedoch Downtime und ist kein unkritischer Refresh-Schalter. Vorher werden Logs, Gegenstelle, Profil, IDs und Pfad geprüft.

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, ipsec_monitor.log und das verbindungsspezifische Aktionslog. In der letzten Zeile wird HQ-Branch-ISP1 durch den echten Verbindungsnamen ersetzt:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
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 und aktiv sein. Prüfen, ob eine Verbindung 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 stimmt nach Drag-and-drop nicht

Sophos bestätigt für SFOS 22.0 GA den Fehler NC-178121: Nach einer Drag-and-drop-Änderung konnten Site-to-Site-IPsec-Verbindungen an der falschen Position innerhalb der Failover-Gruppe landen. Behoben ist dieser konkrete Fehler mit SFOS 22.0 MR2 Build 546.

Auf SFOS 22.0 GA die Reihenfolge vor und nach jeder Änderung dokumentieren und nicht allein auf die visuelle Verschiebung vertrauen. Für MR1 nennt die öffentliche Release Note keine eindeutige eigene Betroffenheits- oder Fixgrenze. Tritt ein ähnlicher Fehler auf MR2 Build 546 oder neuer auf, darf er nicht automatisch weiterhin NC-178121 zugeordnet werden.

Gruppe zurückbauen

Das Ausschalten einer Failover-Gruppe deaktiviert die aktiven Tunnel ihrer Mitglieder. Benötigte Einzelverbindungen werden danach separat wieder aktiviert. Für einen kontrollierten Rollback:

1. Ausgangszustand, Member-Reihenfolge und verwendete Profile sichern.
2. Wartungsfenster und alternativen Admin-Zugang bestätigen.
3. Gruppe ausschalten und den Unterbruch dokumentieren.
4. Verbindungen aus der Gruppe entfernen beziehungsweise die ursprüngliche Zuordnung wiederherstellen.
5. Benötigte Einzelverbindung aktivieren.
6. DPD- und Key-negotiation-Verhalten aus dem Profil erneut berücksichtigen.
7. 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