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- 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. SFOS unterstützt Custom Gateways für IPv4 und IPv6; das durchgängige Beispiel verwendet IPv4.

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.

Bei diesen automatisch erzeugten Gateways lässt sich die Zone unter Routing > Gateways nicht ändern. Das Default Gateway ist fest der Zone WAN zugeordnet. Die frei wählbare Gateway-Zone aus dem folgenden Ablauf gilt für Custom Gateways, nicht für das Default Gateway.

Für die Failover-Regeln eines Cellular-WAN-Gateways ist Network > WAN link manager zuständig. Einrichtung, Mobilfunk-Prüfziele und Umschalttest erklärt Cellular WAN und 4G/5G-Failover.

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

1. Routing > Gateways öffnen.
2. Unter IPv4 auf Add klicken.
3. Als Name MPLS_Zurich_GW eintragen. Der Name ist frei wählbar, sollte aber Standort und Pfad erkennen lassen.
4. Als Gateway IP 192.0.2.2 eintragen. Das ist der direkt erreichbare MPLS-Router, nicht das entfernte Zielnetz.
5. Als Interface Port4-192.0.2.1 wählen. Gateway IP und Interface müssen zum selben erreichbaren Transitpfad gehören.
6. 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. Bei einer reinen statischen Route wird die Gateway-Zone nicht angewendet; dort bestimmen die tatsächlichen Interface-Zonen und die passende Firewall-Regel den Zonenmatch. 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.

Bestehende Custom Gateways lassen sich unter Routing > Gateways auch bearbeiten, klonen und löschen. Vor dem Löschen werden die Abhängigkeiten geprüft, wie im Rollback-Ablauf weiter unten beschrieben.

Health Check passend zum Pfad wählen

Health check ist standardmässig ausgeschaltet. SFOS dokumentiert für die Zeitsteuerung folgende Standardwerte:

• Interval: Abstand zwischen den Health-Check-Probes; standardmässig 60 Sekunden.
• Time-out: Frist, innerhalb derer eine Probe beantwortet werden muss, damit das Gateway als aktiv gilt; standardmässig 2 Sekunden.
• Retries: 3

Retries gibt die Anzahl aufeinanderfolgender Prüfversuche an. Bleiben diese Versuche ohne Antwort, bewertet SFOS das Gateway als nicht erreichbar. Sophos nennt keine vollständige Formel für die genaue Ausfallerkennungszeit; deshalb werden Interval, Time-out und Retries gemeinsam betrachtet. Protocol und IP address sind dagegen Designentscheidungen. Für dieses Beispiel wird PING auf 10.20.0.10 gewählt.

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 verlangt allgemein einen dauerhaft verfügbaren Host hinter dem Gateway als Prüfziel. Das offizielle Any-to-Any-XFRM-Beispiel folgt ebenfalls diesem Prinzip.

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.

Für eine weitere Monitoring Condition unter Operator AND oder OR auswählen und auf das Add-Symbol klicken. Anschliessend Protokoll, Ziel-IP und bei TCP den Port der zusätzlichen Bedingung festlegen. Für die Verknüpfung 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:

1. Routing > SD-WAN routes > IPv4 > Add öffnen.
2. Als Name Clients_to_Branch_MPLS eintragen.
3. Das interne Interface als Incoming interface wählen.
4. Als Source networks 10.10.0.0/24 festlegen.
5. Als Destination networks 10.20.0.0/24 festlegen.
6. Als Service zunächst nur HTTPS beziehungsweise TCP 443 auswählen.
7. Unter Link selection settings die Option Primary and backup gateways verwenden.
8. MPLS_Zurich_GW als Primary gateway wählen.
9. Einen echten Backup-Pfad nur eintragen, wenn er vollständig konfiguriert und getestet ist.
10. 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.
11. 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.

Der SFOS-22-Standard für Route Precedence lautet static, SD-WAN, VPN. Steht SD-WAN vor Static und verwendet eine SD-WAN Route Any als Ziel, kann sie auch internen oder direkt verbundenen Traffic erfassen und den Managementzugang unterbrechen. Die enge Destination des Beispiels schützt vor diesem Fehler. Benötigt das Design mehr als Primary und Backup, kann stattdessen ein SD-WAN Profile mit bis zu acht Gateways verwendet werden.

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 zones: LAN
• Source networks and devices: 10.10.0.0/24
• Destination zones: MPLS
• Destination networks: 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 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.

Wie ein entfernter Standort über ein solches XFRM-Gateway und spiegelbildliche SD-WAN-Routen eine virtuelle IP erreicht, die per DNAT auf mehrere interne Server verteilt wird, zeigt Virtuelle IP über IPsec auf mehrere Server weiterleiten.

Route-based IPsec mit konkreten Traffic Selectors ist anders: Für diese Traffic Selectors wird keine zusätzliche manuelle Route angelegt, und das XFRM erhält keine eigene IP. Ein Any-to-Any-Gateway-Rezept darf nicht auf diese Variante übertragen werden.

Gateway und Traffic abnehmen

Status und Verwendung prüfen

1. Unter Routing > Gateways muss MPLS_Zurich_GW als aktiv erscheinen.
2. Object usage aktualisieren und prüfen, ob die erwartete SD-WAN Route das Gateway verwendet.
3. In der SD-WAN Route Match-Kriterien, Position und Gateway erneut kontrollieren.
4. Unter System services > Log settings prüfen, ob das Modul SD-WAN protokolliert wird. Danach im Log viewer die Gateway-, Health-Check- und Route-Ereignisse prüfen.
5. 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

1. Vom Testclient 10.10.0.10 eine neue HTTPS-Verbindung zu 10.20.0.10 starten.

2. Im Log viewer Source, Destination, Service, Firewall Rule ID, eine mögliche NAT Rule ID und den verwendeten Gateway prüfen.

3. Den Traffic Count der SD-WAN Route kontrollieren. OUT zählt Requests, IN Replies, soweit die jeweilige Richtung zu Source und Destination der Route passt; ein einseitiger Zähler ist daher allein noch kein Pfadfehler.

4. Unter Diagnostics > Packet capture einen engen BPF-Filter verwenden:

   host 10.20.0.10 and tcp port 443
   

5. Prüfen, ob Requests über Port4 austreten und Antworten über denselben geplanten Pfad zurückkommen.

6. 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. Wenn der Primary Gateway zurückkehrt, verwenden neue Verbindungen wieder den Primary; bestehende Verbindungen bleiben zunächst auf dem Backup.

SFOS 22 leitet Nicht-SNAT-Verbindungen bei einem Gateway- oder SLA-Wechsel standardmässig um. Für SNAT-Verbindungen gilt das nicht automatisch. Ein Rerouting mit SNAT setzt dieselbe übersetzte Source-IP auf beiden Pfaden und die separate Option reroute-snat-connection voraus; MASQ oder unterschiedliche Source-IPs verhindern deshalb häufig einen nahtlosen Wechsel. Ein unterbrechungsfreier Übergang wird im Abnahmetest 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.

XML API unter SFOS 23: Für Add Gateway Object und Update Gateway Object ist der API-Status 505 mit der Meldungskennung Message.GatewayIpNotInInterfaceIpRange dokumentiert. Gemeint ist der Status der API-Antwort, nicht ein HTTP-Statuscode; die Kennung ist kein garantierter Wortlaut der angezeigten Meldung. Bei diesem Ergebnis prüft man vor einem erneuten Versuch das Netz des ausgewählten Interfaces und die vorgesehene Next-Hop-Adresse (Gateway IP). Die Dokumentation des Status in SFOS 23 belegt nicht, dass die Adressprüfung erst mit dieser Version eingeführt wurde.

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:

1. Die neue SD-WAN Route deaktivieren oder den vorherigen Pfad wiederherstellen.
2. Mit einer neuen Clientverbindung prüfen, ob der Ausgangspfad wieder funktioniert.
3. Nur für den Test erstellte Firewall- oder NAT-Regeln entfernen, sobald keine Abhängigkeit mehr besteht.
4. Object Usage aktualisieren.
5. Das Custom Gateway erst löschen, wenn keine Route und kein Profil es mehr verwendet. Wird ein Backup Gateway gelöscht, setzt SFOS das Backup der Route auf None. Beim Löschen des Primary Gateway oder des gewählten SD-WAN Profile löscht SFOS die SD-WAN Route und verwendet danach die Default Route WAN link load balance.

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