Route-based IPsec mit zwei Internetleitungen ausfallsicher einrichten

Eine zweite Internetleitung macht einen IPsec-Tunnel noch nicht automatisch redundant. Für ein belastbares Failover braucht jede Leitung eine eigene route-based Verbindung, ein eigenes adressiertes XFRM-Interface und einen überwachten Routingpfad. Erst dann kann Sophos Firewall beim Ausfall von ISP1 gezielt über ISP2 weiterleiten und nach der Wiederherstellung wieder zum bevorzugten Pfad zurückkehren.

Dieser Ablauf behandelt route-based Any-to-Any-IPsec zwischen zwei Sophos Firewalls unter SFOS 22.0. Er folgt dem von Sophos beschriebenen Aufbau mit zwei Internetleitungen. Policy-based Tunnel und route-based Tunnel mit konkreten Traffic Selectors verwenden stattdessen eine IPsec-Failover-Gruppe.

⚠️ Die aktuelle Sophos-Hilfe widerspricht sich bei zwei Any-to-Any-Verbindungen. Die spezielle Zwei-ISP-Anleitung baut zwei solche Tunnel ohne Failover-Gruppe auf. Die allgemeine IPsec-Fehlerdiagnose sagt dagegen, mehrere Verbindungen mit gleichen Local und Remote Subnets – ausdrücklich auch Any-Any – funktionierten nur in derselben Failover-Gruppe. Eine IPsec-Failover-Gruppe verändert jedoch DPD und Failback-Verhalten. Deshalb wird hier keine Gruppe hinzuerfunden: Den Aufbau zuerst auf dem installierten SFOS-22-Maintenance-Release abnehmen und bei abweichendem Verhalten vor dem Produktiveinsatz mit Sophos Support klären.

Kurzablauf

1. Auf beiden Firewalls je einen Any-to-Any-Tunnel über ISP1 und ISP2 einzeln abnehmen.
2. Jedem der vier XFRM-Interfaces eine eindeutige Transferadresse geben.
3. Auf jeder Firewall für beide Peer-XFRM-Adressen ein Custom Gateway mit bewusst gewähltem Health Check erstellen.
4. Zum gleichen entfernten LAN zwei statische Routen anlegen: Primary mit kleinerer, Backup mit höherer Administrative Distance.
5. Die globale Route Precedence sichern und nur bei passendem Gesamtdesign auf static vpn sdwan_policyroute setzen.
6. Firewall-Regeln und Rückwege für beide XFRM-Pfade prüfen.
7. ISP1 kontrolliert unterbrechen, echten Anwendungsverkehr über ISP2 testen und danach das Failback zu ISP1 abnehmen.

⚠️ Route Precedence gilt für die ganze Firewall. Eine Änderung kann auch vorhandene Static-, VPN- und SD-WAN-Pfade beeinflussen. Vorher den aktuellen Wert, alle überlappenden Routen, ein Konfigurationsbackup und einen unabhängigen Managementzugang sichern.

Design und Voraussetzungen

Das Failover-Modell verstehen

Die beiden IPsec-Verbindungen bleiben eigenständige Tunnel. Die Route mit der kleineren Administrative Distance ist der bevorzugte Datenpfad. Wird ihr überwachtes XFRM-Gateway als nicht erreichbar bewertet, kann die Route über den zweiten Tunnel übernehmen.

Das sind zwei getrennte Zustände:

• Der Tunnel ist aktiv: IKE und Child SA wurden aufgebaut.
• Der Pfad ist nutzbar: Gateway, Route, Firewall-Regel, NAT-Erwartung, Gegenstelle und Rückweg funktionieren für den echten Traffic.

Ein grüner Tunnel allein ist deshalb kein Failover-Nachweis. Ebenso wenig genügt normales WAN-Failover: Der WAN link manager erstellt keine zweite IPsec-Verbindung und keine passende Route auf der Gegenstelle.

Für Any-to-Any wird keine zusätzliche VPN-Failover-Gruppe angelegt. Die Auswahl erfolgt über die adressierten XFRM-Interfaces, Gateways und Routen. Die vollständige Grundkonfiguration eines solchen Tunnels steht unter Site-to-Site IPsec VPN einrichten.

SFOS 22 erlaubt für Any-to-Any-XFRM-Interfaces statische, SD-WAN- oder dynamische Routen. Der spezielle Zwei-ISP-Aufbau verwendet ausdrücklich zwei statische Routen. Dieser Ablauf folgt diesem Static-Route-Design; eine SD-WAN-Route zum gleichen Ziel wird nur ergänzt, wenn ihr Zusammenspiel und ihre Priorität separat geplant und getestet wurden.

Beispieltopologie planen

Das Beispiel verbindet eine Zentrale mit einer Filiale:

• Zentrale: 172.16.16.0/24
• Filiale: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• ISP1-XFRM-Netz: 10.255.1.0/30
• ISP2-XFRM-Netz: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Die Adressen sind Dokumentationswerte und werden durch eigene, nicht überlappende Transfernetze ersetzt. Jedes XFRM-Paar braucht ein separates Netz. Die öffentlichen ISP-Adressen, Local und Remote IDs, Profile und Listening Interfaces müssen pro Tunnel spiegelbildlich zur Gegenstelle passen.

Tunnel, Gateways und Routen konfigurieren

Zwei Tunnel vorbereiten

Auf jeder Firewall werden zwei Verbindungen unter Site-to-site VPN > IPsec angelegt. Beide verwenden Route-based (Tunnel interface) und Any bei Local subnet sowie Remote subnet. In einem typischen Zentrale-Filiale-Aufbau steht die Zentrale auf Respond only, die Filiale auf Initiate the connection.

Der erste Tunnel verwendet die WAN-Schnittstelle von ISP1, der zweite die WAN-Schnittstelle von ISP2. Beide Verbindungen werden vor der Failover-Konfiguration einzeln getestet. Dazu wird jeweils nur der vorgesehene Tunnel aktiviert und ein festgelegter Datenfluss in beide Richtungen geprüft.

Auf beiden Firewalls klappt man unter Network > Interfaces jeweils die WAN-Schnittstelle auf, die für die betreffende IPsec-Verbindung verwendet wird. Darunter liegen die automatisch erzeugten XFRM-Interfaces als untergeordnete Schnittstellen. So lässt sich das jeweilige XFRM dem Tunnel über ISP1 oder ISP2 zuordnen, bevor man seine Transferadresse vergibt.

Unter Network > Interfaces erhalten die automatisch erzeugten XFRM-Interfaces diese Beispieladressen:

• Zentrale: 10.255.1.1/30 für ISP1 und 10.255.2.1/30 für ISP2
• Filiale: 10.255.1.2/30 für ISP1 und 10.255.2.2/30 für ISP2

Ein XFRM-Interface wird nicht umadressiert, solange andere Routen oder Dienste davon abhängen. Object usage, Tunnelstatus und vorhandene Routingobjekte werden vor jeder Änderung geprüft.

XFRM-Gateways überwachen

Unter Routing > Gateways wird auf jeder Seite pro Tunnel ein Gateway zur Peer-XFRM-Adresse erstellt. Auf der Zentrale sind dies 10.255.1.2 und 10.255.2.2, in der Filiale 10.255.1.1 und 10.255.2.1.

Pro Gateway werden mindestens Name, Gateway IP und Interface gesetzt. Gateway IP ist die Peer-XFRM-Adresse, Interface das zugehörige XFRM. Health check ist standardmässig aus und muss für die Pfadüberwachung eingeschaltet werden. SFOS 22 zeigt dafür Interval (Default 60 Sekunden), Time-out (Default 2 Sekunden), Retries (Default 3) und mindestens eine Monitoring condition mit Protocol, bei TCP zusätzlich Port, sowie IP address.

Die Probe-IP muss ein Host hinter dem Gateway sein. Soll der vollständige nachgelagerte Pfad bewertet werden, nimmt man einen stabilen, erlaubten Endpunkt hinter der Gegenstelle. Ein Ping nur zur Peer-XFRM-Adresse beweist lediglich die unmittelbare Tunnelstrecke. Mehrere Bedingungen können mit AND oder OR verbunden werden; AND verlangt alle Antworten, OR prüft von oben nach unten bis zum ersten erfolgreichen Ziel.

Die Auswahl von Protokoll, Ziel und Intervallen ist eine Betriebsentscheidung: Das Ziel muss dauerhaft antworten, darf nicht während normaler Wartung verschwinden und benötigt die passende Freigabe. Die Defaults sind Ausgangswerte, keine zugesicherte Umschaltzeit. Eine Änderung wird erst nach gemessener Erkennungs-, Failover- und Failback-Zeit übernommen. Custom Gateway erstellen und prüfen erklärt Health Check, Status und Stop-Bedingungen im Detail.

Statische Primary- und Backup-Routen anlegen

Auf der Zentrale werden unter Routing > Static routes zwei IPv4-Unicast-Routen zum Filialnetz 192.168.10.0/24 angelegt:

• über 10.255.1.2 und das ISP1-XFRM mit Administrative distance 1
• über 10.255.2.2 und das ISP2-XFRM mit Administrative distance 2

Auf der Filiale entstehen spiegelbildlich zwei Routen zum Zentralnetz 172.16.16.0/24:

• über 10.255.1.1 und das ISP1-XFRM mit Administrative distance 1
• über 10.255.2.1 und das ISP2-XFRM mit Administrative distance 2

Die kleinere Administrative Distance gewinnt, solange der zugehörige Gateway verfügbar ist. Gleiche Zielnetze und unterschiedliche Distanzen bilden damit Primary und Backup. Das ist etwas anderes als ECMP mit gleicher Priorität. Die allgemeine Route- und Rückweglogik erklärt Statische Route einrichten und testen.

Die spezielle Sophos-Anleitung schreibt diesem Aufbau automatisches Failover und Failback zu. Die allgemeine Static-Route-Referenz bestätigt zwar die Priorität durch Administrative Distance, beschreibt aber nicht separat, wie ein fehlgeschlagener Custom-Gateway-Health-Check die Route aus der Auswahl nimmt. Genau deshalb gehört die beobachtete aktive Route in die Abnahme und nicht nur der Gatewaystatus.

Route Precedence kontrolliert setzen

Sophos dokumentiert für diesen Aufbau Static vor VPN und SD-WAN. Zuerst wird in der Device Console der vorhandene Zustand gesichert:

system route_precedence show

Nur wenn diese Reihenfolge zum gesamten Routingdesign passt, wird sie auf beiden Firewalls gesetzt:

system route_precedence set static vpn sdwan_policyroute

Danach wird der Wert nochmals mit system route_precedence show kontrolliert. Diese Änderung ist kein allgemeiner IPsec-Fix. Sie beeinflusst auch andere überlappende Static-, VPN- und SD-WAN-Routen. Route Precedence sicher ändern beschreibt die globale Wirkung und den Rollback.

Die SFOS-22-Hilfe nennt als Default dagegen static, sdwan_policyroute, vpn. Das ist kein Widerspruch: Der Default gilt allgemein, die Zwei-ISP-Anleitung fordert für genau diesen Aufbau static vpn sdwan_policyroute. Bei der Rückkehr zum Vorzustand wird deshalb nicht blind der Default gesetzt, sondern exakt die zuvor mit show protokollierte Reihenfolge.

Regeln, NAT und Rückweg abgleichen

Auf beiden Firewalls braucht es passende Regeln zwischen LAN und VPN. Quelle, Ziel und Dienste werden auf die echten Standortnetze und Anwendungen begrenzt; Log firewall traffic bleibt während der Einführung aktiv.

Für normal gerouteten Standortverkehr ist üblicherweise kein SNAT erforderlich. Gibt es bereits NAT-Ausnahmen oder gezielte Übersetzungen, müssen sie auf beiden Pfaden gleich funktionieren. Eine breite MASQ-Regel wird nicht als Failover-Abkürzung ergänzt.

Das ist von NAT Traversal zu unterscheiden: NAT-T ist auf Sophos Firewall automatisch aktiv und nutzt bei erkanntem NAT UDP 4500; ohne NAT laufen IKE über UDP 500 und ESP über IP-Protokoll 50. Befindet sich eine Firewall hinter einem vorgeschalteten Router, müssen dessen DNAT und Freigaben zum jeweiligen Listening Interface für beide ISP-Pfade passen. Für überlappende Standortnetze sind dagegen passende SNAT- und DNAT-Regeln für den Nutztraffic erforderlich.

Die Route auf der Gegenseite ist genauso wichtig wie der Hinweg. Ein Tunnel kann aktiv sein, obwohl die Antwort über den falschen ISP oder eine allgemeinere Route zurückläuft. Deshalb werden Route Lookup, aktive Route, Firewall Rule ID, NAT Rule ID und Packet Capture gemeinsam ausgewertet.

Failover abnehmen und betreiben

Failover und Failback abnehmen

Vor dem Ausfalltest werden beide Tunnel einzeln mit demselben Anwendungsfluss geprüft. Danach bleibt eine dauerhafte Testverbindung sichtbar, zusätzlich werden während des Tests neue Sessions aufgebaut.

Im Wartungsfenster wird ausschliesslich der ISP1-Pfad kontrolliert unterbrochen. Nicht beide WAN-Ports oder beide Tunnel gleichzeitig deaktivieren. Die Abnahme beantwortet vier Fragen:

1. Wird der Gateway von ISP1 als nicht verfügbar erkannt?
2. Wird die Route mit Administrative Distance 2 über das ISP2-XFRM aktiv?
3. Erreichen neue Verbindungen die Gegenstelle, und laufen die Antworten über ISP2 zurück?
4. Wird nach Wiederherstellung von ISP1 wieder die Route mit Administrative Distance 1 verwendet?

Im Log Viewer und in einem engen Packet Capture müssen die erwartete Firewall Rule ID, das aktive XFRM-Interface und der bidirektionale Datenfluss zusammenpassen. Ein Ping allein reicht nicht. Eine HTTPS-, RDP-, VoIP- oder andere reale Anwendung zeigt zusätzlich, ob Sessionaufbau, MTU und Rückweg funktionieren. Der kombinierte Prüfablauf steht unter Firewall-Regel mit Log Viewer und Packet Capture testen.

Bei einem HA-Cluster wird nach einem geplanten Failover eine neue Verbindung über beide ISP-Pfade geprüft. SFOS 22 stellt route-based IPsec-Tunnel zwar nahtlos wieder her, schränkt die Session-Übernahme für Traffic im Tunnel aber auf zustandslose Protokolle wie UDP und ICMP ein; TCP wird nicht unterstützt. Deshalb werden eine bestehende TCP-Verbindung und eine neue TCP-Verbindung getrennt bewertet. HA-Logs und -Reports liegen zudem nur auf dem Knoten, der den jeweiligen Traffic verarbeitet hat, und müssen auf beiden Geräten geprüft werden.

Fehler systematisch eingrenzen

Beide Tunnel sind grün, aber ISP2 übernimmt nicht

Gatewaystatus, Monitoring Target und beide statischen Routen prüfen. Zielnetz und Prefix müssen identisch sein, die Next Hops und XFRM-Interfaces dagegen verschieden. Danach Administrative Distance und aktuelle Route Precedence vergleichen.

ISP2 übernimmt, aber Anwendungen antworten nicht

Firewall-Regeln, NAT-Ausnahmen und Rückroute auf beiden Seiten prüfen. Packet Capture muss Request und Reply am ISP2-XFRM zeigen. Fehlt nur die Antwort, liegt der Fehler meist hinter der Gegenstelle oder im asymmetrischen Rückweg.

Failback schaltet zu früh oder gar nicht zurück

Health Check und Monitoring Target beobachten. Das Ziel darf den Tunnel nicht sporadisch als gesund melden, obwohl der Anwendungsweg noch gestört ist. Administrative Distance, aktive Route und echte neue Session gemeinsam prüfen; bestehende Verbindungen können noch an ihrem bisherigen Zustand hängen.

Nur eine Richtung funktioniert

Die spiegelbildliche Konfiguration vergleichen: XFRM-Adresse, Gateway, statische Route, Regel und Rückweg müssen auf beiden Firewalls vorhanden sein. Die aktuelle Sophos-Diagnose nennt unter /log strongswan.log, charon.log, strongswan-monitor.log und dgd.log; letzteres enthält Dead Gateway Detection und VPN-Failover-Ereignisse. In der Advanced Shell zeigt der lesende Befehl ip xfrm state, ob Transform States vorhanden sind. Die sichere Diagnose erklärt IPsec VPN Troubleshooting.

Tunnelstatus und Gatewaystatus widersprechen sich

DPD und Gateway Health Check messen nicht dasselbe. Dead Peer Detection wird unter Profiles > IPsec profiles konfiguriert und erkennt einen nicht antwortenden IKE-Peer, wenn der Phase-2-Tunnel inaktiv war; Sophos empfiehlt DPD zu aktivieren. Der Custom-Gateway-Health-Check prüft dagegen den gewählten Host hinter dem XFRM-Pfad. Deshalb DPD nicht deaktivieren, um einen fehlerhaften Probe-Host zu kaschieren. Falls Sophos Support wegen des oben genannten Dokumentationskonflikts eine Failover-Gruppe verlangt, beachten: Das Hinzufügen deaktiviert DPD im zugehörigen Profil, setzt Key negotiation tries auf 3 und bringt ein eigenes Automatic failback mit maximal fünf Wiederholungsversuchen mit. Diese Variante ist eine andere Betriebslogik und wird nicht ohne separate Abnahme mit diesem Ablauf vermischt.

Sicher zurückrollen

Vor der Änderung werden Backup, ursprüngliche Route Precedence, Tunnelstatus, XFRM-Adressen, Gateways, Regeln und Routen dokumentiert. Falls der redundante Pfad nicht zuverlässig funktioniert:

1. Die neuen Backup-Routen deaktivieren.
2. Die ISP2-Gateways und den zweiten Tunnel nur deaktivieren, nicht sofort löschen.
3. Die ursprüngliche Route Precedence auf beiden Firewalls wiederherstellen.
4. Regeln und NAT auf den dokumentierten Vorzustand setzen.
5. Den ursprünglichen ISP1-Pfad mit einer neuen Anwendungssession erneut testen.

XFRM-Adressen, Gateways oder Tunnel werden erst entfernt, wenn Object usage keine Abhängigkeit mehr zeigt. Den Backup- und Restore-Ablauf erklärt Sophos Firewall Backup und Restore.

FAQ