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. Policy-based Tunnel und route-based Tunnel mit konkreten Traffic Selectors verwenden stattdessen eine IPsec-Failover-Gruppe.

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 überwachtes Gateway 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.

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.

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.

Als Interface wird das jeweilige XFRM gewählt. Das Monitoring Target sollte einen stabilen, erlaubten Endpunkt hinter der Gegenstelle prüfen, wenn damit der vollständige nachgelagerte Pfad bewertet werden soll. Ein Ping nur zur Peer-XFRM-Adresse beweist lediglich die unmittelbare Tunnelstrecke.

Die Auswahl des Ziels ist eine Betriebsentscheidung: Es muss dauerhaft antworten, darf nicht während normaler Wartung verschwinden und benötigt die passende Freigabe. 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.

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.

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.

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. Ein aktiver Tunnel verspricht nicht, dass bestehende TCP-Sessions oder Routingzustände ohne Unterbruch fortbestehen.

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. Für die IKE- und XFRM-Ebene helfen strongswan.log und xfrmi.log; die sichere Diagnose erklärt IPsec VPN Troubleshooting.

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