Sophos Firewall Custom Gateway erstellen und prüfen

Ein Custom Gateway beschreibt auf Sophos Firewall einen Next Hop auf einem vorhandenen Interface. Das Objekt ist besonders für MPLS-, RED-, GRE- und adressierte XFRM-Pfade nützlich, weil es einen eigenen Health Check und eine Zone erhalten und danach in einer SD-WAN Route verwendet werden kann.

Kurzantwort

Ein Custom Gateway wird hier erstellt:

Routing > Gateways > Add

Für einen MPLS-Pfad über Port4 trägt man beispielsweise ein:

Name: MPLS_Zurich_GW
Gateway IP: 192.0.2.2
Interface: Port4-192.0.2.1
Zone: MPLS
Health check: On
Monitoring condition: PING auf 10.20.0.10

Danach muss das Gateway in einer passenden SD-WAN Route ausgewählt und mit Firewall-Regel, Rückweg, Log Viewer und echtem Traffic geprüft werden. Ein grünes Statussymbol bestätigt nur den Health Check, nicht die Funktion der gesamten Verbindung.

⚠️ Ein Custom Gateway ist kein zusätzliches physisches WAN-Gateway. Es erscheint nicht unter Network > WAN link manager und nimmt auch mit der Zone WAN nicht am WAN-Load-Balancing teil.

Custom Gateway, Route und Interface unterscheiden

Für einen funktionierenden Pfad erfüllen mehrere Objekte unterschiedliche Aufgaben:

Das Interface verbindet die Firewall mit dem Transitnetz, beispielsweise Port4, RED oder XFRM.
Die Gateway IP ist der direkt erreichbare nächste Router auf diesem Pfad.
Das Custom Gateway verbindet Gateway IP, Interface, Zone und optionalen Health Check in einem wiederverwendbaren Objekt.
Die SD-WAN Route entscheidet, welcher Traffic dieses Gateway verwendet.
Die Firewall-Regel erlaubt die geplanten Zonen, Netze und Dienste.
Die Gegenstelle benötigt einen passenden Rückweg.

Eine normale statische Route kann die Gateway IP direkt enthalten und benötigt dafür kein separates Gateway-Objekt. Ein Custom Gateway wird interessant, wenn SFOS den Pfad überwachen, in einer SD-WAN Route auswählen oder über eine Gateway-Zone sicherheitlich einordnen soll.

Physische WAN-Gateways entstehen dagegen beim Konfigurieren eines WAN-Interfaces automatisch und werden im WAN link manager als Active oder Backup verwaltet. Diese Trennung verhindert, dass ein interner MPLS- oder Tunnelpfad versehentlich als Internetleitung behandelt wird.

Beispieltopologie planen

Das durchgängige Beispiel verbindet ein Clientnetz über einen MPLS-Router mit einem entfernten Servernetz:

Lokales Clientnetz: 10.10.0.0/24
Testclient: 10.10.0.10
Firewall-Interface: Port4 mit 192.0.2.1/30
MPLS-Router: 192.0.2.2
Entferntes Netz: 10.20.0.0/24
Stabiler Monitoring- und Testhost: 10.20.0.10
Testdienst: TCP 443
Eigene Zone: MPLS vom Typ LAN

192.0.2.0/24 ist ein Dokumentationsnetz und wird nicht produktiv verwendet. Für die eigene Umgebung ersetzt man Interface-IP und Gateway IP gemeinsam durch das reale Transitnetz. Das entfernte Netz und der Monitoring Host müssen wirklich hinter diesem Gateway liegen. Die Zone MPLS wird vorab unter Network > Zones erstellt und nach der Vertrauensstufe des Pfads abgesichert; die Grundlagen erklärt Zonen und Interfaces auf Sophos Firewall.

Vor der Änderung werden die bestehende Route, Firewall-Regeln, NAT-Erwartung und der Rückweg dokumentiert. Bei einer Remote-Änderung gehören ein Konfigurationsbackup, ein Wartungsfenster und ein unabhängiger Managementzugang dazu.

Custom Gateway erstellen

Gateway-Grundwerte eintragen

Routing > Gateways öffnen.
Unter IPv4 auf Add klicken.
Als Name MPLS_Zurich_GW eintragen. Der Name ist frei wählbar, sollte aber Standort und Pfad erkennen lassen.
Als Gateway IP 192.0.2.2 eintragen. Das ist der direkt erreichbare MPLS-Router, nicht das entfernte Zielnetz.
Als Interface Port4-192.0.2.1 wählen. Gateway IP und Interface müssen zum selben erreichbaren Transitpfad gehören.
Als Zone MPLS wählen.

Sophos Firewall priorisiert die Gateway-Zone gegenüber der Interface-Zone. Sie wirkt jedoch nur auf Traffic, wenn das Gateway in einer passenden SD-WAN Policy Route ausgewählt ist. Für eine reine statische Route bleibt die Zonenwirkung daher getrennt zu prüfen. Die Zone VPN kann einem Custom Gateway nicht zugeordnet werden.

Bei SD-WAN Policy Routes, die aus SFOS 18.0 MR1 oder älter migriert wurden, wird die Gateway-Zone nicht angewendet. In diesem Fall darf eine bestehende Regel nicht allein wegen des sichtbaren Zonenfelds als korrekt gelten. Route, Zonenmatch und echten Traffic zuerst in einem Wartungsfenster prüfen.

Health Check passend zum Pfad wählen

Health check ist standardmässig ausgeschaltet. Für einen überwachten MPLS-, RED- oder XFRM-Pfad wird er aktiviert und zunächst mit den dokumentierten Standardwerten begonnen:

Interval: 60 Sekunden
Time-out: 2 Sekunden
Retries: 3
Protocol: PING
IP address: 10.20.0.10

Der Monitoring Host liegt bewusst hinter dem Gateway. Würde man nur die direkt benachbarte Gateway IP prüfen, könnte der Router antworten, obwohl der nachgelagerte MPLS- oder Tunnelpfad unterbrochen ist. Sophos nennt für Custom Gateways auf route-based VPN, RED und MPLS ausdrücklich einen Host hinter dem Gateway als Prüfziel.

Alternativ kann TCP mit einem konkreten Port verwendet werden. Das ist sinnvoll, wenn nicht nur IP-Erreichbarkeit, sondern ein stabiler Antwortdienst geprüft werden soll. Ein TCP-Check auf Port 443 erklärt einen ausgefallenen Webdienst jedoch zum Gateway-Ausfall, obwohl das Routing noch funktionieren kann. Das Prüfziel und Protokoll müssen deshalb zum beabsichtigten Failover-Signal passen.

Bei mehreren Monitoring Conditions gilt:

AND: Alle Bedingungen müssen erfüllt sein. Das ist streng, kann aber bei einem einzelnen ausgefallenen Ziel unnötig umschalten.
OR: SFOS prüft die Bedingungen von oben nach unten, bis eine erfüllt ist. Das reduziert Fehlalarme, kann aber einen Teilausfall verdecken.

Interval, Time-out und Retries werden nicht auf Verdacht verkürzt. Zuerst misst man normale Latenz und kurzfristigen Paketverlust des realen Pfads. Zu aggressive Werte können einen instabilen Wechsel zwischen aktiv und inaktiv erzeugen.

Nach dem Speichern zeigt Routing > Gateways mit einem Statussymbol, ob der Health Check das Gateway als aktiv oder inaktiv bewertet.

Gateway im Routingdesign verwenden

SD-WAN Route für den Beispieltraffic erstellen

Ein Gateway-Objekt leitet für sich allein noch keinen Traffic. Für das Beispiel wird eine SD-WAN Route erstellt:

Routing > SD-WAN routes > IPv4 > Add öffnen.
Als Name Clients_to_Branch_MPLS eintragen.
Das interne Interface als Incoming interface wählen.
Als Source networks 10.10.0.0/24 festlegen.
Als Destination networks 10.20.0.0/24 festlegen.
Als Services zunächst nur HTTPS beziehungsweise TCP 443 auswählen.
Unter Link selection settings die Option Primary and backup gateways verwenden.
MPLS_Zurich_GW als Primary gateway wählen.
Einen echten Backup-Pfad nur eintragen, wenn er vollständig konfiguriert und getestet ist.
Route only through specified gateways bewusst setzen: Aktiviert verwirft SFOS den Traffic, wenn kein angegebener Pfad verfügbar ist; deaktiviert kann eine andere SD-WAN Route oder die Default Route übernehmen.
Route speichern und ihre Position prüfen. Die erste passende SD-WAN Route gewinnt.

Die Netze und der Dienst sind Umgebungswerte. Eine breite Route mit Any als Quelle, Ziel und Service kann viel mehr Traffic erfassen als geplant. Für den ersten Test bleibt der Match deshalb eng und wird erst nach erfolgreicher Abnahme bewusst erweitert.

Firewall-Regel und Rückweg ergänzen

Für den weitergeleiteten Stream wird eine geloggte Regel von der Quellzone des Clientnetzes zur Gateway-Zone MPLS erstellt. Quelle, Ziel und Dienst entsprechen der SD-WAN Route:

Source zone: LAN
Source network: 10.10.0.0/24
Destination zone: MPLS
Destination network: 10.20.0.0/24
Services: HTTPS
Log firewall traffic: aktiviert

Die Gateway-Zone ersetzt keine Firewall-Regel. Umgekehrt erzwingt eine Regel allein noch nicht den MPLS-Pfad. Beides muss mit der SD-WAN Route zusammenpassen. Den allgemeinen Regelaufbau erklärt Sophos Firewall-Regeln erstellen und sicher prüfen.

Der Router hinter dem entfernten Netz benötigt einen Rückweg zu 10.10.0.0/24. Bei einer normalen Standortvernetzung bleibt die originale Client-IP meist erhalten; eine pauschale MASQ-Regel würde sie verbergen und kann den Rückweg scheinbar reparieren, aber das Routingdesign verschlechtern.

XFRM, GRE und andere Tunnelpfade abgrenzen

Bei route-based IPsec mit Any-to-Any erhält das XFRM-Interface eine Transfer-IP. Ein Custom Gateway verwendet dann die Peer-XFRM-IP als Gateway IP, das lokale XFRM als Interface und einen stabilen Host im entfernten Netz als Monitoring Target. Die vollständige Tunnelkonfiguration bleibt im Artikel Site-to-Site IPsec VPN einrichten.

Route-based IPsec mit konkreten Traffic Selectors ist anders: SFOS erzeugt die Route automatisch, und das XFRM erhält keine eigene IP oder manuelle Route. Ein Any-to-Any-Gateway-Rezept darf nicht ungeprüft auf diese Variante übertragen werden.

Auch ein GRE-Pfad beginnt nicht mit dem Gateway-Objekt. Zuerst werden äussere Endpunkte, Tunnel-IPs und GRE-Funktion nach dem Ablauf GRE-Tunnel auf Sophos Firewall konfigurieren und testen abgenommen. Verlangt das Providerdesign danach eine SD-WAN-Auswahl, verwendet das Custom Gateway die Peer-Tunnel-IP als Gateway IP. Zone, Health Check und Regelmatch müssen zum konkreten Design passen; die Zone VPN bleibt für Custom Gateways nicht auswählbar.

Gateway und Traffic abnehmen

Status und Verwendung prüfen

Unter Routing > Gateways muss MPLS_Zurich_GW als aktiv erscheinen.
Object usage aktualisieren und prüfen, ob die erwartete SD-WAN Route das Gateway verwendet.
In der SD-WAN Route Match-Kriterien, Position und Gateway erneut kontrollieren.
Im Log viewer das Modul SD-WAN auf Gateway-, Health-Check- und Route-Ereignisse prüfen.
Bei tieferer Diagnose dgd.log als Dead-Gateway-Detection-Log heranziehen; die Einordnung steht unter Sophos Firewall Service- und Logdateien.

Der aktive Gateway-Status beweist nur, dass der Monitoring Host unter der gewählten Bedingung antwortet. Object Usage beweist nur die Konfigurationsreferenz. Erst der nächste Echttest bestätigt den Nutzpfad.

Echten Datenfluss testen

Vom Testclient 10.10.0.10 eine neue HTTPS-Verbindung zu 10.20.0.10 starten.
Im Log viewer Source, Destination, Service, Firewall Rule ID, eine mögliche NAT Rule ID und den verwendeten Gateway prüfen.
Den Traffic Count der SD-WAN Route kontrollieren.
Unter Diagnostics > Packet capture einen engen BPF-Filter verwenden:
```
host 10.20.0.10 and tcp port 443
```
Prüfen, ob Requests über Port4 austreten und Antworten über denselben geplanten Pfad zurückkommen.
Auf dem Zielsystem die echte Source-IP und den Rückweg kontrollieren.

Der Policy tester berücksichtigt SD-WAN Routes nicht. Er kann einen Firewall-Regel-Match prüfen, aber nicht den tatsächlich verwendeten Gateway. Für die kombinierte Prüfung hilft Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

Ein Failover-Test erfolgt nur mit vorhandenem, separat abgenommenem Backup-Pfad, in einem Wartungsfenster und mit unabhängigem Managementzugang. Das produktiv referenzierte Gateway wird dafür nicht gelöscht. Nach dem kontrollierten Pfadausfall werden neue Verbindung, Gateway-Status, Public beziehungsweise private Source-IP, Rückweg und Failback erneut geprüft. Ein unterbrechungsfreier Übergang wird nicht vorausgesetzt.

Fehler systematisch eingrenzen

Gateway bleibt inaktiv

Gateway IP und Interface müssen denselben direkt erreichbaren Transitpfad beschreiben.
Monitoring Host muss wirklich hinter dem Gateway liegen und dauerhaft antworten.
Bei PING prüfen, ob ICMP auf dem gesamten Pfad erlaubt ist.
Bei TCP den richtigen Port und einen tatsächlich laufenden Dienst prüfen.
Mit Packet Capture kontrollieren, ob Probe und Antwort das erwartete Interface verwenden.
Interval, Time-out und Retries erst nach der Pfadprüfung verändern.

Gateway ist aktiv, aber der Nutztraffic funktioniert nicht

SD-WAN Route kann fehlen, zu tief stehen oder andere Source-/Destination-/Service-Werte matchen.
Source zone und Gateway-Zone der Firewall-Regel müssen zum echten Flow passen.
Route Precedence, NAT und Rückweg getrennt prüfen.
Der Monitoring Host kann erreichbar sein, obwohl ein anderer Zielhost oder Dienst ausfällt.
Ein aktives XFRM-Gateway beweist nicht automatisch, dass IPsec-SA, Firewall-Regel und Remote Route stimmen.

Gateway-Zone scheint ignoriert zu werden

Prüfen, ob das Gateway wirklich in der passenden SD-WAN Policy Route ausgewählt ist.
Bei einer reinen statischen Route die Interface-Zone und die tatsächlich gematchte Firewall-Regel prüfen.
Bei einer aus SFOS 18.0 MR1 oder älter migrierten SD-WAN Route gilt die Gateway-Zone nicht. Den Pfad nicht durch eine breite Regel kaschieren, sondern Route und Zonenmodell kontrolliert modernisieren.
Die Zone VPN ist für Custom Gateways nicht auswählbar; ein XFRM-Interface bleibt trotzdem ein VPN-Interface und benötigt ein bewusstes Regel- und Routingdesign.

Status wechselt unnötig zwischen aktiv und inaktiv

Probe Target auf reale Verfügbarkeit und Rate Limits prüfen.
Normale Latenz und Paketverlust vor einer Änderung messen.
Bei AND kann ein einzelnes Ziel den gesamten Gateway-Status auf inaktiv setzen.
Bei OR kann ein erreichbares Ersatzziel einen Teilfehler verdecken.
Kürzere Intervalle oder Time-outs nicht als allgemeinen Stabilitätsfix verwenden.

Sicher zurückrollen und betreiben

Vor dem Rollback werden Object Usage, ursprüngliche Route und ursprüngliche Firewall-Regeln dokumentiert. Dann:

Die neue SD-WAN Route deaktivieren oder den vorherigen Pfad wiederherstellen.
Mit einer neuen Clientverbindung prüfen, ob der Ausgangspfad wieder funktioniert.
Nur für den Test erstellte Firewall- oder NAT-Regeln entfernen, sobald keine Abhängigkeit mehr besteht.
Object Usage aktualisieren.
Das Custom Gateway erst löschen, wenn keine Route oder kein Profile es mehr verwendet.

Im Betrieb werden Owner, Gateway IP, Interface, Zone, Probe Targets, Protokoll, Interval, Time-out, Retries, verwendete Routen und der letzte Failover-Test dokumentiert. Nach Änderungen an MPLS, RED, XFRM, Zonen, SD-WAN oder dem Monitoring Host werden Status und echter Nutztraffic erneut geprüft.

FAQ

Warum erscheint mein Custom Gateway nicht im WAN link manager?

Das ist beabsichtigt. Der WAN link manager verwaltet automatisch erzeugte Gateways physischer WAN-Interfaces. Custom Gateways aus Routing > Gateways gehören zum Routingdesign und erscheinen dort auch mit Zone WAN nicht.

Kann ein Custom Gateway am WAN-Load-Balancing teilnehmen?

Nein. Sophos unterstützt dieses Load Balancing nur über Gateways physischer WAN-Interfaces. Mehrere Custom Gateways werden stattdessen bewusst über SD-WAN Routes oder SD-WAN Profiles ausgewählt.

Soll der Health Check die Gateway IP oder einen entfernten Host prüfen?

Für route-based VPN, RED und MPLS sollte das Prüfziel hinter dem Gateway liegen. So prüft man den relevanten nachgelagerten Pfad und nicht nur den direkt benachbarten Router. Das Ziel muss stabil erreichbar sein und zum beabsichtigten Failover-Signal passen.