Sophos Firewall WAN-Failover einrichten und testen

Eine zweite Internetleitung wird auf der Sophos Firewall nicht automatisch zur Reserveleitung. Ein neu angelegtes WAN-Gateway ist standardmässig Active und nimmt damit am Load Balancing teil. Für ein klassisches Primary/Backup-Design wird das zweite Gateway im WAN link manager deshalb auf Backup umgestellt.

Der schnelle Weg für eine Haupt- und eine Reserveleitung:

Beide WAN-Interfaces unter Network > Interfaces vollständig konfigurieren und einzeln testen.
Unter Network > WAN link manager das Hauptgateway als Active und die Reserve als Backup festlegen.
Beim Backup-Gateway Activate this gateway: If active gateway fails: ANY wählen.
Für beide Gateways zuverlässige Failover rules konfigurieren.
Failover und Failback – also die Rückkehr zur Hauptleitung – mit echtem DNS-, HTTPS- und Anwendungstraffic testen.

Für dieses einfache Default-Internet-Failover braucht es keine eigene SD-WAN-Route. SD-WAN wird benötigt, wenn bestimmter Traffic gezielt andere Pfade verwenden oder die Pfadwahl anhand von Latenz, Jitter und Paketverlust erfolgen soll.

Active, Backup und Load Balancing richtig einordnen

Der Gateway-Typ bestimmt, ob eine Leitung normal am Internetverkehr teilnimmt:

Active: Stehen mehrere aktive Gateways zur Verfügung, verteilt die Firewall neue Sessions anhand der konfigurierten Gewichte.
Backup: Das Gateway übernimmt erst, wenn seine Aktivierungsbedingung erfüllt ist.

Mindestens ein WAN-Gateway muss Active bleiben. Sind alle Gateways nur als Backup markiert, fehlt der normale Default-WAN-Pfad; insbesondere firewall-eigener Traffic kann dann nicht weitergeleitet werden.

Das Weight beschreibt keine Bandbreite. Im Modus weighted round-robin bedeutet ein Verhältnis von 2 zu 1, dass die Firewall zwei neue Sessions dem ersten und die nächste dem zweiten Gateway zuordnet. Ein einzelner Download wird dadurch nicht auf beide Leitungen aufgeteilt, und die übertragene Datenmenge kann deutlich von diesem Verhältnis abweichen.

Standardmässig verwendet Sophos Firewall Session Persistence. Dabei bleibt nicht nur eine einzelne bestehende Verbindung am gleichen WAN-Link: Je nach Persistence-Faktor werden beispielsweise auch weitere Sessions derselben Source-IP wieder diesem Link zugeordnet. Die aktuelle Methode sieht man nach der Anmeldung in Option 4: Device Console mit einem lesenden Befehl:

show routing wan-load-balancing

Der Befehl verändert nichts. Er zeigt, ob Session Persistence oder weighted round-robin aktiv ist und hilft damit, eine unerwartete Pfadverteilung einzuordnen. Für ein reines Active/Backup-Design ist die Methode meist zweitrangig, weil im Normal- und Fehlerfall jeweils nur ein vorgesehener Pfad verfügbar ist.

WAN-Failover ist nicht dasselbe wie ein HA-Failover. Der WAN link manager wechselt den Internetpfad auf derselben Firewall. Ein Sophos Firewall HA-Cluster übernimmt dagegen beim Ausfall eines Geräts oder eines überwachten Ports.

WAN-Failover vorbereiten

Beide Provideranschlüsse müssen zuerst unabhängig funktionieren. Die Grundlagen zu WAN-Zone, IP-Zuweisung und Gateway stehen unter Sophos Firewall Zonen und Interfaces planen.

Ein einfaches Beispiel sieht so aus:

WAN1 Fiber: Hauptleitung, Gateway gw-fiber, Type: Active, Weight: 1
WAN2 DSL: Reserveleitung, Gateway gw-dsl, Type: Backup
Aktivierung der Reserve: If active gateway fails: ANY
Aktion bei Aktivierung: Inherit weight of the failed active gateway
Aktion bei Rückkehr: Serve new connections through restored gateway

Die Namen sind frei wählbar und sollten den Anschluss eindeutig beschreiben. Gateway-Typ und Aktionen sind dagegen funktionale Einstellungen. Vor der Umschaltung sollte das Backup-Gateway bereits einen grünen Status haben und echter Clienttraffic über die Leitung erfolgreich getestet worden sein.

Zusätzlich braucht es einen sicheren Rückweg für die Administration. Wird die Firewall aus der Ferne geändert, sollte WebAdmin nicht ausschliesslich über die Leitung erreichbar sein, die im Test getrennt wird. Ein aktuelles Konfigurationsbackup, ein Wartungsfenster und eine Person vor Ort oder ein unabhängiger Managementpfad verhindern, dass ein einfacher Failover-Test zum längeren Ausfall wird.

Vorab sollte man auch alle Dienste notieren, die an eine öffentliche IP-Adresse gebunden sind. Dazu gehören DNAT-Veröffentlichungen, IPsec-Gegenstellen, Remote Access, Provider-Allowlisten, Mailserver und externe Monitoring-Systeme. Ausgehender Internetzugriff kann bereits funktionieren, während diese Dienste über die neue öffentliche Adresse noch nicht erreichbar oder freigegeben sind.

Primary/Backup konfigurieren

WAN-Interfaces und Gateway-Status prüfen

Unter Network > Interfaces beide WAN-Ports mit der vom Provider vorgegebenen statischen, DHCP- oder PPPoE-Konfiguration einrichten. Beim Speichern entsteht das zugehörige physische WAN-Gateway automatisch im WAN link manager.

Ein neues Gateway ist zunächst Active. Nach dem Hinzufügen einer reinen Reserveleitung sollte man den Typ daher sofort anpassen, bevor produktiver Traffic ungewollt über beide Provider verteilt wird.

Custom Gateways aus Routing > Gateways, beispielsweise für XFRM, RED oder MPLS, erscheinen nicht im WAN link manager. Sie gehören in ein anderes Routingdesign und werden nicht als physisches ISP-Gateway für dieses einfache Szenario behandelt.

Backup-Gateway einstellen

Unter Network > WAN link manager das Gateway der Reserveleitung bearbeiten und folgende Werte setzen:

Type: Backup
Activate this gateway: If active gateway fails
Bei einer Hauptleitung: ANY
Action on activation: Inherit weight of the failed active gateway
Action on failback: Serve new connections through restored gateway
Speichern und den Gateway-Status prüfen.

Bei genau einem aktiven Gateway haben ANY und ALL praktisch dieselbe Wirkung. Der Unterschied wird bei mehreren aktiven Leitungen wichtig:

ANY: Das Backup wird aktiviert, sobald eines der aktiven Gateways ausfällt. Das passt, wenn verlorene Kapazität sofort ersetzt werden soll.
ALL: Das Backup wird erst aktiviert, wenn alle aktiven Gateways ausgefallen sind. Das passt eher zu einer langsamen oder teuren Notleitung.

Action on activation bestimmt die Gewichtung des Backup-Gateways, wenn es neben anderen verfügbaren Gateways aktiv wird. Inherit weight of the failed active gateway ist für ein einfaches Ersatzszenario nachvollziehbar. Use configured weight ist sinnvoll, wenn die Reserve eine bewusst kleinere oder grössere Kapazität hat und zusammen mit verbleibenden aktiven Leitungen arbeitet.

Beim Failback ist Serve new connections through restored gateway die betrieblich schonendere Wahl. Neue Sessions verwenden wieder die Hauptleitung, bestehende Sessions bleiben bis zum Timeout oder ihrer Trennung auf dem Backup-Pfad. Serve all connections through restored gateway baut bestehende Verbindungen neu auf und kann sie unterbrechen. Bei SD-WAN-Routen gilt diese Aktion nur, wenn WAN link load balance als Primary Gateway gewählt ist. Bei einem einzelnen Active-WAN-Link als Primary werden nur neue Verbindungen über das wiederhergestellte Gateway geführt.

Failover-Regeln sinnvoll wählen

Die Failover rules bestimmen, wann ein Gateway als nicht erreichbar gilt. Zur Auswahl stehen:

Testing method: Ping oder TCP
IP address
bei TCP zusätzlich Port
Verknüpfung mehrerer Fehlerbedingungen mit AND oder OR

Ein physischer Kabelausfall wird bereits am Interface erkannt. Die standardmässig angelegte Ping-Prüfung der Gateway-IP kontrolliert zusätzlich, ob das direkt angeschlossene Providergerät oder der erste Provider-Hop erreichbar ist. Sie kann aber grün bleiben, obwohl hinter dem erreichbaren Providerrouter kein Internetzugriff mehr funktioniert. Sophos empfiehlt für WAN-/ISP-Gateways deshalb ein bekanntes öffentliches IP-Ziel, beispielsweise 8.8.8.8 oder 8.8.4.4.

Für IPv6 nennt Sophos 2001:4860:4860::8888 als öffentliches Beispiel. Soll das Upstream-Gerät geprüft werden, verwendet man die IPv6-Adresse des Gateways und nicht dessen Link-Local-Adresse.

Ein einzelnes Ziel ist ebenfalls keine vollständige Zustandsprüfung. Für einen robusteren Start kann man zwei dauerhaft erreichbare, organisatorisch erlaubte öffentliche IP-Adressen verwenden:

AND: Erst der Ausfall aller verknüpften Prüfungen löst Failover aus. Das reduziert Fehlumschaltungen wegen eines einzelnen nicht erreichbaren Ziels.
OR: Bereits eine fehlgeschlagene Prüfung kann Failover auslösen. Das reagiert empfindlicher, erhöht aber das Risiko unnötiger Wechsel.

8.8.8.8 und 8.8.4.4 sind konkrete Sophos-Beispiele, gehören aber zum gleichen Betreiber und bilden keine vollständig unabhängigen Fehlerdomänen. In einer wichtigen Umgebung sind zwei freigegebene Ziele bei unterschiedlichen Betreibern besser. Ein Ping-Ziel muss ICMP zuverlässig beantworten; für TCP braucht es einen stabilen Dienst, dessen Port geprüft werden darf.

ANY/ALL beim Backup-Gateway und AND/OR bei den Prüfregeln lösen unterschiedliche Fragen. ANY/ALL bestimmt, wie viele aktive Gateways ausfallen müssen. AND/OR bestimmt, wie mehrere Prüfungen den Ausfall eines einzelnen Gateways bewerten.

Der globale Wert Gateway failover timeout im WAN link manager legt fest, wann die Firewall einen nicht reagierenden Link als ausgefallen behandelt. Einen universell richtigen Wert gibt es nicht. Ein zu kurzer Timeout reagiert zwar schneller, kann bei Paketverlust oder einer kurzen Störung des Prüfziels aber unnötig umschalten. Der Wert wird unter anderem auch als Health-Check-Intervall für IPsec-Failovergruppen verwendet und sollte deshalb nicht isoliert für einen einzelnen WAN-Link verändert werden. Ausgangswert dokumentieren, kontrolliert testen und erst danach anhand der gemessenen Umschaltzeit anpassen.

Failover und Failback kontrolliert testen

Ein Kabeltest prüft nur einen lokalen Linkausfall. Eine Providerstörung hinter einem weiterhin erreichbaren Router wird erst sichtbar, wenn auch die konfigurierten öffentlichen Prüfziele nicht mehr erreichbar sind. Idealerweise werden deshalb beide Fälle getrennt getestet.

Wartungsfenster, Rückfallplan und alternativen Admin-Zugang bestätigen.
Unter Network > WAN link manager Status von Haupt- und Backup-Gateway dokumentieren.
Von einem Testclient DNS, HTTPS und eine wichtige Anwendung prüfen. Zusätzlich die aktuell verwendete öffentliche Ausgangsadresse festhalten.
Für den Linktest das primäre WAN-Kabel kontrolliert trennen. Für den eigentlichen Monitoring-Test den Link zur Firewall aktiv lassen und den Upstream hinter dem Providergerät unterbrechen, sofern dies gefahrlos möglich ist.
Länger als den konfigurierten Gateway failover timeout warten.
Prüfen, ob das Hauptgateway als ausgefallen und das Backup-Gateway als aktiv angezeigt wird.
Neue DNS-, HTTPS-, VPN- und Anwendungssessions starten. Firewall-Regel, NAT, Zielerreichbarkeit und neue öffentliche Ausgangsadresse kontrollieren.
Gateway-Up/Down-Ereignisse im Log viewer prüfen. Für eine tiefere Analyse enthält dgd.log Ereignisse zum WAN-Gateway-Management und Link-Failover.
Hauptleitung wiederherstellen und bestehende sowie neue Sessions getrennt prüfen. So wird sichtbar, ob das konfigurierte Failback-Verhalten tatsächlich eintritt.
Abschlussstatus, Anwendungen und externe Erreichbarkeit dokumentieren.

Ein erfolgreicher Ping beweist nur, dass das Prüfziel antwortet. Er bestätigt weder DNS noch NAT, VPN, veröffentlichte Dienste oder eine Business-Anwendung. Für den tatsächlichen Paketpfad hilft Packet Capture im Sophos Firewall WebAdmin; die Einordnung von dgd.log und weiteren Dateien steht unter Sophos Firewall Service Logs.

Typische Fehler und Grenzen

Die Reserveleitung verteilt bereits produktiven Traffic: Das neue Gateway steht noch auf Active. Für eine reine Reserve auf Backup umstellen.
Das Backup wird bei einem Ausfall nicht aktiv: Gateway-Status, Typ, ANY/ALL, Failover-Regeln und Gateway failover timeout prüfen. Bei mehreren aktiven Gateways kann ALL die Aktivierung bewusst verhindern, solange noch ein aktiver Pfad verfügbar ist.
Das Gateway ist grün, aber Internet funktioniert nicht: Das Prüfziel ist erreichbar, während DNS, Routing, Firewall-Regel, NAT oder die Anwendung scheitert. Echten Traffic, Log Viewer und Packet Capture prüfen.
Die Firewall schaltet ohne echte Providerstörung um: Ein einzelnes Prüfziel antwortet nicht, OR ist zu empfindlich oder der Timeout ist für die Leitungsqualität zu kurz. Prüfziele und gemessenen Paketverlust kontrollieren.
Bestehende Sessions brechen beim Wechsel ab: Die öffentliche Quelladresse oder der NAT-Zustand ändert sich. Gegenstellen können die Verbindung deshalb verwerfen. WAN-Failover ist nicht automatisch Zero-Downtime.
Ausgehender Traffic funktioniert, eingehende Dienste aber nicht: Der zweite Provider braucht passende öffentliche Erreichbarkeit, DNS beziehungsweise Dynamic DNS, DNAT, Firewall-Regeln und gegebenenfalls Zertifikate. DNAT für veröffentlichte Server und NAT-Grundlagen helfen bei der Abgrenzung.
VPN funktioniert nur über die Hauptleitung: Remote Gateway, lokale Listening-Adresse, FQDN, Identitäten, Tunnelkonfiguration und Rückroute müssen auch zum Backup-Pfad passen. Einfaches WAN-Failover erstellt keine zweite VPN-Verbindung.

Wenn Anwendungen, Benutzergruppen oder Zielnetze unterschiedliche Leitungen verwenden sollen oder Latenz, Jitter und Paketverlust die Pfadwahl steuern sollen, gehört die Entscheidung in Sophos Firewall SD-WAN Routes und Profiles. Für eine Mobilfunkreserve kommen zusätzlich SIM, APN, Datenvolumen, CGNAT und Signalqualität hinzu; diese Punkte erklärt Cellular WAN und 4G/5G-Failover.

Betrieb

Gateway-Statusänderungen bei Bedarf per E-Mail melden. Dafür zuerst unter Administration > Notification settings Mailserver, Sender und Empfänger konfigurieren. Anschliessend unter System services > Notification list den globalen Schalter Email notifications aktivieren und unter System das Ereignis Gateway status auswählen. Eine ausgewählte Ereigniszeile allein versendet noch keine E-Mail.
Gateway-Status und dgd.log nach ungeplanten Umschaltungen prüfen.
Failover und Failback mindestens quartalsweise sowie nach Provider-, Interface-, NAT-, Routing- oder Firmwareänderungen testen.
Öffentliche IP-Abhängigkeiten, VPN-Gegenstellen, Allowlisten und eingehende Dienste dokumentieren.
Verantwortliche für Providerstörung, Eskalation und Rückkehr zum Normalbetrieb festlegen.
Prüfziele regelmässig kontrollieren; ein dauerhaft verändertes oder nicht mehr erreichbares Ziel darf nicht unbemerkt die Umschaltlogik bestimmen.
Bei mehreren aktiven Leitungen Gewichte und Session Persistence anhand realer Nutzung prüfen, nicht nur anhand nomineller Bandbreiten.