Sophos Firewall Route Precedence sicher ändern

Die Route Precedence legt fest, ob die Sophos Firewall zuerst Static Routes, SD-WAN Policy Routes oder VPN-Routen auswertet. Die Einstellung wirkt global und kann produktiven Traffic sowie den administrativen Zugriff sofort beeinflussen.

Kurzantwort

Die Standardreihenfolge lautet:

1. static
2. sdwan_policyroute
3. vpn

Sie passt für viele Umgebungen, weil direkt verbundene Netze und statische Routen dadurch nicht von einer breiten SD-WAN Route übersteuert werden. Ändern sollte man die Reihenfolge nur, wenn im konkreten Paketfluss mehrere Routing-Arten zum gleichen Ziel konkurrieren.

Vor jeder Änderung gilt: aktuelle Reihenfolge dokumentieren, unabhängigen Managementzugang sicherstellen, betroffene Routen prüfen und den exakten Rollback vorbereiten. Eine normale SD-WAN Route wird in Sophos Firewall SD-WAN Route einrichten und testen erklärt.

Welche Reihenfolge passt?

Standard und Versionsunterschied

Die Standardreihenfolge ist unter SFOS 21.5 und 22.0 identisch. Die Zuordnung von ipsec_route hat sich jedoch geändert:

• SFOS 21.5: static umfasst direkt verbundene Netze, ipsec_route, Unicast Routes, Dynamic Routes und SSL VPN. Automatisch erzeugte policy-based IPsec-Routen gehören zu vpn.
• SFOS 22.0: static umfasst direkt verbundene Netze, Unicast Routes, Dynamic Routes und SSL VPN. vpn umfasst automatisch erzeugte policy-based IPsec-Routen und ipsec_route.

Das ist bei Upgrades wichtig: Eine Empfehlung für ipsec_route unter SFOS 21.5 darf nicht unverändert auf SFOS 22.0 übertragen werden. Unter SFOS 22.0 verarbeitet die Firewall policy-based IPsec-Routen intern. Automatisch erzeugte policy-based VPN-Routen und mit ipsec_route definierte Routen sind in der Routing-Tabelle nicht sichtbar. Für systemgenerierten Traffic ist ipsec_route nicht erforderlich. Eine manuelle IPsec Route ist nur für den passenden, versionsabhängigen Sonderfall sinnvoll.

Bei migrierten Firewalls zählt nicht der dokumentierte Default, sondern die tatsächliche Ausgabe. Eine Migration kann beispielsweise sdwan_policyroute vpn static übernehmen. Migrierte SD-WAN Routes können zudem noch an die ID ihrer ursprünglichen Firewall-Regel gebunden sein und beim Löschen dieser Regel verschwinden.

Static zuerst

static sdwan_policyroute vpn ist meist die richtige Ausgangslage für LAN, DMZ, VLAN, SSL VPN und normale SD-WAN-Internetpfade. Direkt verbundene Netze werden dabei wie statische Routen behandelt.

Das schützt interne Ziele vor zu breiten SD-WAN Routes. Steht sdwan_policyroute vor static und verwendet eine SD-WAN Route beispielsweise das Ziel Any, kann interner oder administrativer Traffic unerwartet Richtung WAN-Gateway laufen.

SD-WAN zuerst

sdwan_policyroute static vpn ist sinnvoll, wenn Policy Routing bewusst Vorrang vor statischen Routen erhalten soll. Das muss anhand konkreter Quellen, Ziele und Dienste geplant werden. Für Reply Packets und systemgenerierten Traffic greifen SD-WAN Routes nur, wenn die entsprechenden CLI-Optionen aktiviert sind.

Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen erklärt diese beiden Optionen im Detail.

VPN zuerst

vpn static sdwan_policyroute ist eine gezielte Ausnahme, beispielsweise für dokumentierte L2TP-Szenarien. Die Priorität von vpn vor static greift dabei nur für Traffic, dessen konkurrierende Route in die WAN-Zone führt. Sie ist kein pauschaler Fix für jeden IPsec-Tunnel.

SSL-VPN-Verbindungen gehören zur Kategorie static, nicht zu vpn. Route-based IPsec über XFRM-Interfaces wird über die dafür konfigurierte statische, dynamische oder SD-WAN Route gesteuert. Entscheidend sind deshalb XFRM-Interface, Route, SD-WAN-Kriterien, NAT, Firewall-Regel und Rückweg.

Eine globale Änderung ist ungeeignet, wenn nur ein einzelnes Zielnetz falsch geroutet wird. Dann sind eine spezifischere statische oder SD-WAN Route, die VPN-Konfiguration oder eine versionsgerecht eingesetzte ipsec_route meist der präzisere Hebel.

Änderung sicher vorbereiten

Die Befehle werden in der Device Console ausgeführt, nicht in der Advanced Shell. Falls der Zugang noch nicht eingerichtet ist, hilft Sophos Firewall per SSH verbinden. SSH sollte nur aus vertrauenswürdigen Netzen erlaubt sein.

Vorbereitung:

1. Unabhängigen Rückweg zur Firewall sicherstellen und vor der Änderung aktiv testen, beispielsweise lokale Konsole, dediziertes Management-Interface oder einen bestätigten, nicht betroffenen Admin-Pfad.
2. Quelle, Ziel, Dienst, Zone und beteiligte Interfaces notieren.
3. Statische Routen, SD-WAN Policy Routes, VPN-Routen und XFRM-Interfaces prüfen.
4. Breite SD-WAN Routes mit Any sowie migrierte Regeln identifizieren.
5. NAT, Firewall-Regel und Rückweg der Gegenstelle prüfen.
6. Wartungsfenster, Abnahmetest und Rollback festlegen.

⚠️ Wichtig: Route Precedence wirkt global. Nicht gleichzeitig Routing-, NAT-, Firewall- und SD-WAN-Regeln ändern, sonst lässt sich der Effekt nicht zuverlässig zuordnen.

Aktuelle Reihenfolge anzeigen und exakt dokumentieren:

system route_precedence show

Die vollständige Ausgabe zusammen mit Datum, Anlass, betroffenen Netzen und erwartetem Verhalten festhalten. Aus allen drei Werten wird vor der Änderung der exakte Rollback-Command vorbereitet.

Im WebAdmin ist die aktuelle Reihenfolge zusätzlich hier sichtbar:

Routing > SD-WAN routes

Geändert wird sie über die Device Console. Wenn SD-WAN beteiligt ist, vorab auch den Status für systemgenerierten Traffic und Reply Packets erfassen:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Diese Werte dürfen nicht unbemerkt mit der Wirkung der Route Precedence vermischt werden. Eine besonders kritische Kombination liegt vor, wenn sdwan_policyroute vor static steht, eine passende SD-WAN Route das Ziel Any verwendet und SD-WAN sowohl für systemgenerierten Traffic als auch für Reply Packets aktiv ist. Dann können WebAdmin und SSH aus dem betroffenen internen Subnetz verloren gehen, während die Firewall aus anderen Subnetzen möglicherweise noch erreichbar ist.

Route Precedence ändern

Die Syntax enthält immer alle drei Werte:

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

Standardreihenfolge setzen:

system route_precedence set static sdwan_policyroute vpn

Wenn diese Reihenfolge bereits aktiv ist, liegt der Fehler wahrscheinlich an Route Lookup, SD-WAN-Kriterien, VPN-Konfiguration, NAT, Firewall-Regel oder Rückweg.

⚠️ Vor SD-WAN-First: Prüfen, ob breite SD-WAN Routes interne Netze oder den Managementzugriff erfassen. Den Befehl nur mit vorbereitetem Rückweg ausführen.

SD-WAN Policy Routes zuerst auswerten:

system route_precedence set sdwan_policyroute static vpn

⚠️ Vor VPN-First: Diese Reihenfolge nur für einen bestätigten VPN-Sonderfall verwenden. Sie löst keine fehlende Route, falsche Traffic Selectors, NAT- oder Rückwegprobleme.

VPN-Routen zuerst auswerten:

system route_precedence set vpn static sdwan_policyroute

Änderung testen und zurückrollen

Nach der Änderung zuerst bestätigen, dass die erwartete Reihenfolge aktiv ist:

system route_precedence show

Danach den betroffenen Paketfluss testen:

• Anwendung, TCP-Verbindung oder Ping zum Ziel prüfen.
• Log Viewer nach Quelle, Ziel und Firewall-Regel filtern.
• Packet Capture auf Ein- und Ausgangsinterface durchführen.
• Route Lookup und die betroffene SD-WAN Route kontrollieren.
• NAT und übersetzte Source-IP prüfen.
• Rückweg der Gegenstelle bestätigen.
• WebAdmin und SSH aus den relevanten Admin-Netzen testen.

Ein grüner VPN-Status oder eine vorhandene Route ist kein Nachweis für einen funktionierenden Paketfluss. Praktische Schritte zeigen Sophos Firewall Regel testen mit Log Viewer und Packet Capture und Sophos Firewall Packet Capture im WebAdmin verwenden.

Sind mehrere Standorte oder Routing-Pfade betroffen, mindestens einen Client pro relevantem Netz, ein Serverziel und die berührten Remote-Access- oder VPN-Pfade testen.

Beim Rollback wird ausschliesslich die zuvor dokumentierte, vollständige Ausgangsreihenfolge gesetzt. Aus dem ersten Wert allein lässt sie sich nicht ableiten, weil sechs Kombinationen möglich sind. Den vorbereiteten Command nach diesem Muster verwenden:

system route_precedence set <erster Wert> <zweiter Wert> <dritter Wert>

Die Platzhalter werden mit allen drei Werten aus der zuvor gesicherten Ausgabe ersetzt. Anschliessend erneut prüfen:

system route_precedence show

Danach dieselben Funktions-, Routing- und Managementtests wiederholen. Kommt der ursprüngliche Fehler nach dem Rollback zurück, war Route Precedence wahrscheinlich beteiligt. Ändert sich nichts, liegt die Ursache an anderer Stelle.

Häufige Fehler

SD-WAN Route ist zu breit

Eine SD-WAN Route mit grossen Netzbereichen oder dem Ziel Any kann mehr Traffic erfassen als geplant. Steht SD-WAN vor Static, können interne Ziele und Managementzugriffe unerwartet zum WAN-Gateway laufen. Reply Packets und systemgenerierter Traffic sind betroffen, wenn die entsprechenden SD-WAN-Optionen aktiviert sind.

VPN-Status wird mit Routing verwechselt

Ein aktiver Tunnel bestätigt nur die Aushandlung. Er beweist nicht, dass Routing, Traffic Selectors, Firewall-Regeln, NAT und Rückweg stimmen. Bei route-based IPsec zuerst XFRM-Interface und Route prüfen; bei policy-based IPsec zusätzlich die versionsabhängige Behandlung von ipsec_route. Der Artikel Sophos Firewall IPsec VPN Troubleshooting führt systematisch durch die Analyse.

NAT wird übersehen

Routing bestimmt den Weg des Pakets, NAT verändert Quell- oder Zieladresse. Ist die Route korrekt, der Rückweg aber defekt, sind NAT oder die Rückroute häufig die Ursache. Dazu hilft NAT auf Sophos Firewall verstehen.

Mehrere Änderungen erfolgen gleichzeitig

Wer Route Precedence, SD-WAN, NAT, Firewall-Regeln und VPN-Parameter gleichzeitig ändert, kann Ursache und Wirkung nicht mehr sauber trennen. Besser ist: eine Änderung, vollständiger Test, nächste Änderung.

Checkliste

• Aktuelle Route Precedence dokumentiert.
• SFOS-Version und Zuordnung von ipsec_route berücksichtigt.
• Betroffene Quellen, Ziele, Netze und Dienste notiert.
• Static, SD-WAN, VPN und XFRM geprüft.
• Direkt verbundene Netze und Managementpfade berücksichtigt.
• Breite SD-WAN Routes mit Any identifiziert.
• Status für System Traffic und Reply Packets erfasst.
• NAT, Firewall-Regeln und Rückweg geprüft.
• Unabhängiger Managementzugang und Rollback vorbereitet.
• Änderung einzeln durchgeführt.
• Anwendung, Log Viewer, Packet Capture und Managementzugriff getestet.

FAQ