Sophos Firewall Route Precedence sicher ändern

Die Route Precedence der Sophos Firewall legt fest, in welcher Reihenfolge unterschiedliche Routing-Arten bei der Routenauswahl berücksichtigt werden. Das klingt nach einer kleinen Einstellung, kann aber produktiven Traffic sofort beeinflussen. Besonders relevant ist sie, wenn sich Static Routes, SD-WAN Policy Routes und VPN-Routen überschneiden.

Der Artikel erklärt, wann eine Änderung sinnvoll ist, wann man zuerst andere Ursachen prüfen sollte und wie man die Änderung über die Device Console sauber dokumentiert, testet und bei Bedarf zurückrollt. Wenn zuerst eine normale SD-WAN Route geplant oder getestet werden soll, passt Sophos Firewall SD-WAN Route einrichten und testen.

Wann Route Precedence wichtig ist

Route Precedence wird dann wichtig, wenn mehrere Routing-Mechanismen theoretisch zum gleichen Ziel passen. Die Firewall muss dann entscheiden, welche Routing-Art zuerst ausgewertet wird.

Typische Situationen:

• Ein internes Zielnetz ist über eine statische Route und zusätzlich über eine SD-WAN Policy Route erreichbar.
• Ein route-based IPsec VPN nutzt XFRM-Interfaces und wird gleichzeitig von SD-WAN-Regeln beeinflusst.
• Ein policy-based IPsec-Sonderfall arbeitet mit manuellen IPsec Routes.
• Systemgenerierter Traffic oder Reply Packets nehmen nach einer SD-WAN-Änderung einen unerwarteten Weg.
• Nach einem Firmware-Upgrade oder einer Migration verhalten sich bestehende Routen anders als erwartet.

Für IPsec-Sonderfälle ist Route Precedence nicht automatisch die beste Lösung. Häufig muss man zuerst verstehen, ob ein klassisches Routingproblem, eine IPsec Route, eine SD-WAN-Regel, NAT oder eine Firewall-Regel beteiligt ist.

Voraussetzungen

• Sophos Firewall im Gateway-Modus.
• Zugriff auf die Device Console, zum Beispiel per SSH.
• Aktuelle Dokumentation der betroffenen statischen Routen, SD-WAN Policy Routes und VPN-Verbindungen.
• Wartungsfenster oder zumindest ein Rückfallweg, wenn produktiver Traffic betroffen sein kann.
• Zugriff auf Log Viewer und, falls nötig, Packet Capture.

Falls der Konsolenzugriff noch nicht eingerichtet ist, erklärt Sophos Firewall per SSH verbinden, wie man die Device Console erreicht. SSH sollte nur aus vertrauenswürdigen Netzen erlaubt werden.

⚠️ Wichtig: Eine Änderung der Route Precedence wirkt global. Betroffen ist nicht nur ein einzelner Tunnel oder eine einzelne Route, sondern die Reihenfolge der Routing-Arten auf der Firewall. Deshalb sollte man nie mehrere Routing-, NAT- und SD-WAN-Änderungen gleichzeitig durchführen.

Standard-Reihenfolge

Die aktuelle Dokumentation beschreibt folgende Standardreihenfolge:

1. Static
2. SD-WAN
3. VPN

Die Werte in der Device Console lauten:

• static
• sdwan_policyroute
• vpn

Wichtig: SSL-VPN-Verbindungen gehören zur Kategorie static. Das ist vor allem dann relevant, wenn Remote-Access-Traffic, statische Routen und SD-WAN-Regeln zusammen betrachtet werden.

Ebenfalls wichtig: Direkt verbundene Netze werden in diesem Zusammenhang wie statische Routen behandelt. Wenn sdwan_policyroute vor static steht und eine SD-WAN Route mit sehr breitem Ziel wie Any arbeitet, kann auch interner Traffic plötzlich Richtung WAN-Gateway laufen. Genau deshalb ist static vor sdwan_policyroute in vielen Umgebungen die sichere Ausgangslage.

Welche Reihenfolge passt?

Es gibt nicht die eine richtige Reihenfolge für jedes Design. Die Route Precedence muss zum Routing-Modell passen.

Typische Zielbilder:

• Normales LAN, DMZ, VLAN, Remote Access und SD-WAN-Internetpfade: Häufig passt static sdwan_policyroute vpn. Direkt verbundene Netze und statische Routen sollen nicht von breiten SD-WAN Routes übersteuert werden.
• Policy-based IPsec überschneidet sich mit statischen oder SD-WAN-Routen: Möglich ist vpn static sdwan_policyroute. Das sollte nur verwendet werden, wenn die VPN-Netze wirklich zuerst ausgewertet werden müssen. Danach NAT, Firewall-Regeln und Rückweg prüfen.
• Route-based IPsec oder WAN-Failover wird bewusst über SD-WAN gesteuert: Die Reihenfolge ist designabhängig, oft mit SD-WAN vor einer anderen Routingart. XFRM-Interface, SD-WAN-Kriterien, Gateway-Status, NAT und Route Precedence gemeinsam testen.
• MTA, Spezialrouting oder einzelne Sophos-How-to-Szenarien: Die Reihenfolge muss zum geprüften Szenario passen. Nicht blind aus einem Beispiel übernehmen, sondern immer auf lokale Netze und Rückwege abgleichen.

Wenn ein Sophos-Beispiel eine andere Reihenfolge zeigt, ist das nicht automatisch ein neuer Standard. Viele Beispiele lösen ein konkretes Spezialproblem. Für eine produktive Firewall zählt, welche Quell- und Zielnetze tatsächlich konkurrieren.

Vor der Änderung eingrenzen

Route Precedence sollte nicht der erste Reflex sein, wenn ein Zielnetz nicht erreichbar ist. Zuerst sollte man den betroffenen Paketfluss eingrenzen.

Prüfen:

1. Welche Quelle und welches Ziel sind betroffen?
2. Welche Zone und welches Interface sind beteiligt?
3. Gibt es eine passende statische Route?
4. Gibt es eine SD-WAN Policy Route, die breiter matcht als geplant?
5. Ist eine VPN-Route oder ein XFRM-Interface beteiligt?
6. Greift NAT oder MASQ?
7. Wird die erwartete Firewall-Regel im Log Viewer getroffen?
8. Zeigt Packet Capture den erwarteten Ein- und Ausgangspfad?

Für die praktische Prüfung helfen Sophos Firewall Regel testen mit Log Viewer und Packet Capture und Sophos Firewall Packet Capture im WebAdmin verwenden. Bei NAT-Fragen passt NAT auf Sophos Firewall verstehen.

Aktuelle Route Precedence anzeigen

Die Befehle werden in der Device Console ausgeführt, nicht in der Advanced Shell.

Aktuelle Reihenfolge anzeigen:

system route_precedence show

Die Ausgabe sollte vor jeder Änderung dokumentiert werden. Am besten notiert man zusätzlich Datum, Anlass, betroffene Netze und erwartetes Verhalten. Wenn ein Rollback nötig ist, muss exakt diese Reihenfolge wieder gesetzt werden.

Im WebAdmin sieht man die aktuelle Route Precedence zusätzlich unter:

Routing > SD-WAN routes

Dort wird sie im Routing-Hinweisbereich angezeigt. Geändert wird die Reihenfolge aber über die Device Console.

Route Precedence ändern

Die Syntax ist:

system route_precedence set [sdwan_policyroute] [static] [vpn]

Die Reihenfolge der drei Werte legt die Priorität fest. Ein typisches Beispiel setzt statische Routen vor SD-WAN Policy Routes und VPN-Routen:

system route_precedence set static sdwan_policyroute vpn

Wenn diese Reihenfolge bereits aktiv ist, liegt das Problem wahrscheinlich nicht an Route Precedence. Dann sollte man gezielt Route Lookup, SD-WAN Policy Routes, IPsec-Konfiguration, NAT, Firewall-Regeln und Rückwege prüfen.

Ein anderes Beispiel setzt SD-WAN Policy Routes vor statische Routen:

system route_precedence set sdwan_policyroute static vpn

Das kann in bestimmten SD-WAN-Designs gewollt sein, ist aber riskant, wenn breite SD-WAN-Regeln mit Any oder grossen Netzbereichen arbeiten. In solchen Fällen können Managementzugriffe, interne Netze oder Rückpakete unerwartet über SD-WAN geroutet werden. Der Artikel Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen erklärt diese Wechselwirkungen genauer.

Für policy-based IPsec-Sonderfälle kann auch vpn an erster Stelle nötig sein:

system route_precedence set vpn static sdwan_policyroute

Das sollte man nur tun, wenn statische oder SD-WAN-Routen die entfernten IPsec-Netze übersteuern. Bei route-based IPsec mit XFRM-Interfaces ist dagegen oft eine saubere SD-WAN- oder statische Route der bessere Hebel als pauschal vpn an die erste Stelle zu setzen.

Änderung testen

Nach der Anpassung zuerst die neue Reihenfolge prüfen:

system route_precedence show

Danach den betroffenen Traffic gezielt testen. Ein grüner VPN-Status oder eine vorhandene Route reicht nicht als Beweis.

Prüfen:

• Verbindung zum Zielnetz mit Ping, TCP-Test oder Anwendungstest.
• Log Viewer auf Quelle, Ziel und Firewall-Regel filtern.
• Packet Capture auf Eingangs- und Ausgangsinterface ausführen.
• Route Lookup oder betroffene SD-WAN-Regel prüfen.
• NAT-Regel und übersetzte Source-IP kontrollieren.
• Rückweg der Gegenstelle prüfen.
• Managementzugriff auf WebAdmin und SSH aus relevanten Admin-Netzen testen.

Wenn mehrere Standorte betroffen sind, sollte man nicht nur einen Testclient prüfen. Besser sind mindestens ein Client pro relevantem Netz, ein Serverziel und ein Remote-Access- oder VPN-Test, falls diese Pfade von der Änderung berührt werden.

Rollback

Ein Rollback besteht nicht aus einem geratenen Standardwert, sondern aus der zuvor dokumentierten Reihenfolge.

Beispiel:

system route_precedence set static sdwan_policyroute vpn

oder:

system route_precedence set sdwan_policyroute static vpn

Nach dem Rollback wieder prüfen:

system route_precedence show

Danach dieselben Tests wie nach der Änderung wiederholen. Wenn der ursprüngliche Fehler dadurch zurückkommt, ist das ein starker Hinweis, dass die Route Precedence tatsächlich beteiligt ist. Wenn sich nichts ändert, liegt die Ursache wahrscheinlich an anderer Stelle.

Häufige Fehler

SD-WAN-Regel ist zu breit

Wenn eine SD-WAN Policy Route sehr breite Quellen oder Ziele matcht, kann sie mehr Traffic erfassen als geplant. Besonders gefährlich ist das, wenn SD-WAN vor static priorisiert wird. Dann können auch Managementzugriffe oder interne Zielnetze unerwartet über eine WAN-Route laufen.

Typisches Muster:

• Route Precedence steht auf sdwan_policyroute static vpn.
• Eine SD-WAN Route nutzt als Ziel Any.
• Systemgenerierter Traffic oder Reply Packets werden ebenfalls über SD-WAN ausgewertet.

Dann kann der Zugriff auf WebAdmin oder SSH aus einem internen Subnetz verloren gehen, obwohl die Firewall aus anderen Netzen noch erreichbar ist.

VPN-Status wird mit Routing verwechselt

Ein aktiver IPsec-Tunnel beweist nur, dass der Tunnel ausgehandelt wurde. Er beweist nicht, dass die Firewall den Traffic in den Tunnel routet, dass NAT passt oder dass die Gegenstelle den Rückweg kennt.

Bei policy-based IPsec ist besonders wichtig, ob statische oder SD-WAN-Routen ebenfalls auf die entfernten Subnetze passen. Wenn ja, kann vpn static sdwan_policyroute nötig sein. Bei route-based IPsec sollte man zuerst XFRM-Interface, Route, SD-WAN Route und Firewall-Regeln prüfen.

NAT wird übersehen

Routing entscheidet, wohin ein Paket gesendet wird. NAT entscheidet, ob Quell- oder Zieladresse verändert werden. Wenn eine Route korrekt ist, der Rückweg aber nicht funktioniert, ist häufig NAT oder die Rückroute beteiligt.

Mehrere Änderungen gleichzeitig

Wenn Route Precedence, SD-WAN-Regeln, NAT, Firewall-Regeln und VPN-Parameter gleichzeitig geändert werden, lässt sich der Effekt kaum sauber zuordnen. Besser ist eine Änderung, dann Test, dann nächste Änderung.

Checkliste

• Aktuelle Route Precedence mit system route_precedence show dokumentiert.
• Betroffene Quellen, Ziele, Netze und Dienste notiert.
• Statische Routen, SD-WAN Policy Routes und VPN-Routen geprüft.
• Direkt verbundene Netze und interne Managementpfade berücksichtigt.
• Breite SD-WAN Routes mit Any identifiziert.
• NAT und Firewall-Regeln geprüft.
• Wartungsfenster oder Rückfallweg definiert.
• Änderung mit exakter Reihenfolge gesetzt.
• Nach der Änderung Log Viewer, Packet Capture und Anwendungstest durchgeführt.
• Managementzugriff aus Admin-Netzen geprüft.
• Rollback-Reihenfolge dokumentiert.

FAQ