Sophos Firewall Route Precedence sicher ändern

Die Route Precedence legt global fest, ob die Sophos Firewall zuerst Static Routes, SD-WAN Policy Routes oder VPN-Routen auswertet. Die Reihenfolge gilt, wenn mehrere dieser Kategorien zum selben Paketfluss passen. Eine wichtige Ausnahme: vpn vor static verdrängt statische oder lokale Routen nur bei Zielen in der WAN-Zone.

Warum die Routing-Priorität nötig ist

Die Sophos Firewall führt Static, SD-WAN und VPN nicht in einer einzigen gemeinsamen Routing-Liste. Es sind getrennte Kategorien, in denen gleichzeitig ein passender Weg zum selben Ziel vorhanden sein kann. Die Route Precedence entscheidet, welche Kategorie zuerst nach einer passenden Route durchsucht wird.

Ein typisches Beispiel: Ein Client im LAN soll das entfernte Netz 10.20.0.0/16 über einen policy-based IPsec-Tunnel erreichen. Gleichzeitig existiert eine SD-WAN Route mit dem Ziel Any, die denselben Traffic ebenfalls erfasst.

• Bei static sdwan_policyroute vpn prüft die Firewall zuerst Static. Findet sie dort keinen passenden Weg, trifft anschliessend die breite SD-WAN Route zu und der Traffic kann statt in den VPN-Tunnel zum WAN-Gateway gehen.
• Bei static vpn sdwan_policyroute prüft die Firewall nach Static zuerst die VPN-Routen. Die Route zum entfernten Netz gewinnt damit vor der allgemeinen SD-WAN Route.

Das Beispielnetz 10.20.0.0/16 wird durch das tatsächliche entfernte Netz ersetzt. Entscheidend ist nicht, welche Reihenfolge generell «besser» klingt, sondern welcher Routing-Typ für den konkreten Paketfluss gewinnen soll.

Die Route Precedence ordnet nur die Kategorien. Sie verändert nicht die Reihenfolge einzelner Static Routes oder SD-WAN Routes innerhalb ihrer Kategorie. Bevor man sie ändert, sollten deshalb drei Fragen beantwortet sein:

1. Welcher konkrete Traffic nimmt aktuell den falschen Weg?
2. Welche der drei Kategorien enthalten dafür eine passende Route?
3. Welche Kategorie soll für genau diesen Traffic Vorrang erhalten?

Passt nur eine Kategorie, löst eine andere Route Precedence das Problem nicht. Dann muss die betreffende Route, SD-WAN Policy, VPN-Konfiguration, NAT-Regel oder der Rückweg korrigiert werden. Route Precedence erlaubt zudem keinen Verkehr zwischen Zonen; dafür bleibt eine passende Firewallregel erforderlich.

Route Precedence direkt anzeigen und ändern

Die Befehle werden unter Device Console ausgeführt, nicht in der Advanced Shell. Nach der SSH-Anmeldung wählt man dafür Menüpunkt 4. Falls der Zugang noch nicht eingerichtet ist, hilft die Anleitung Sophos Firewall per SSH verbinden.

Zuerst wird die aktuelle Reihenfolge vollständig notiert. Daraus entsteht der Rollback-Befehl; der heutige Sophos-Default ist dafür kein Ersatz, weil migrierte oder bewusst angepasste Firewalls eine andere Ausgangslage haben können.

⚠️ Wichtig: Die Änderung ist global. Vor dem set-Befehl müssen die Ausgangsreihenfolge und ein unabhängiger Managementzugang feststehen. Eine unpassende Reihenfolge kann produktiven Traffic sowie WebAdmin- und SSH-Zugriff beeinflussen.

Das folgende Beispiel setzt Static zuerst, VPN an zweiter Stelle und SD-WAN zuletzt:

system route_precedence show
system route_precedence set static vpn sdwan_policyroute
system route_precedence show

Der erste Befehl zeigt die aktuelle Reihenfolge, der zweite ändert sie und der dritte kontrolliert das Ergebnis. Die Position der Werte bestimmt die Priorität. Nach dem letzten Befehl muss die Ausgabe static, vpn, sdwan_policyroute in genau dieser Reihenfolge zeigen; anschliessend wird der tatsächliche Paketfluss getestet.

Die aktuelle Sophos-Standardreihenfolge lautet:

system route_precedence set static sdwan_policyroute vpn

Dieser Befehl ist nur dann ein Rollback, wenn system route_precedence show vor der Änderung genau diese Reihenfolge angezeigt hat.

Im WebAdmin ist die aktuelle Reihenfolge zusätzlich unter Routing > SD-WAN routes sichtbar. Ändern lässt sie sich jedoch nur über die Device Console.

Was Static, SD-WAN und VPN bedeuten

Die drei Werte stehen nicht für einzelne Routen, sondern für drei Routing-Kategorien:

• static umfasst direkt verbundene Netze, Unicast Routes, Dynamic Routes und SSL VPN.
• sdwan_policyroute umfasst die unter Routing > SD-WAN routes definierten Policy Routes.
• vpn umfasst automatisch erzeugte policy-based IPsec-Routen sowie unter SFOS 22.0 die mit ipsec_route definierten Routen.

Policy-based IPsec-Routen und ipsec_route-Einträge erscheinen nicht in der Routingtabelle des WebAdmin. Bei der Konfliktanalyse müssen sie deshalb aus der VPN-Konfiguration beziehungsweise Device Console mitgedacht werden. Die vollständige Einordnung erklärt der Artikel zur IPsec Route auf Sophos Firewall.

SSL VPN gehört zu static, nicht zu vpn. Route-based IPsec über XFRM-Interfaces wird wiederum über die konfigurierte statische, dynamische oder SD-WAN Route gesteuert. Dort entscheiden das XFRM-Interface, die Route und ihre Administrative Distance – nicht allein die Position von vpn. Findet keine konfigurierte Route einen passenden Weg, dient der WAN Link Manager als Default-Route.

Static, SD-WAN, VPN

system route_precedence set static sdwan_policyroute vpn

Das ist die Standardreihenfolge und für viele Umgebungen die richtige Ausgangslage. Direkt verbundene Netze, LAN, DMZ, VLAN und SSL VPN werden dadurch nicht von einer breiten SD-WAN Route übersteuert.

Static, VPN, SD-WAN

system route_precedence set static vpn sdwan_policyroute

Diese Reihenfolge hält Static an erster Stelle, wertet danach VPN-Routen aus und verwendet SD-WAN zuletzt. Sie passt beispielsweise, wenn statische beziehungsweise direkt verbundene Pfade Vorrang behalten sollen, eine konkurrierende policy-based VPN-Route aber vor SD-WAN geprüft werden muss. Sophos verwendet dieselbe Reihenfolge auch für route-based VPN-Failover mit zwei Internetanschlüssen und MTA mit mehreren WAN-Verbindungen.

SD-WAN, Static, VPN

system route_precedence set sdwan_policyroute static vpn

Diese Variante ist nur sinnvoll, wenn Policy Routing bewusst vor statischen Routen greifen soll. Besondere Vorsicht ist bei einer SD-WAN Route mit dem Ziel Any nötig: Sie kann dann auch interne Netze oder den Managementzugriff erfassen und zum WAN-Gateway senden. Eine normale SD-WAN Route sollte deshalb mit möglichst konkreten Zielen geplant und getestet werden.

VPN, Static, SD-WAN

system route_precedence set vpn static sdwan_policyroute

VPN an erster Stelle ist eine gezielte Ausnahme und kein allgemeiner Fix für IPsec-Probleme. Für L2TP Remote Access muss vpn zuerst stehen; static und sdwan_policyroute dürfen danach in beiden Reihenfolgen folgen. vpn vor static priorisiert VPN gegenüber Static jedoch nur, wenn die konkurrierende statische Route in die WAN-Zone führt. Für Ziele in anderen Zonen verwendet die Firewall weiterhin die statische oder lokale Route.

Genau diese Reihenfolge benötigt auch der policy-based Aufbau, wenn Internettraffic einer Filiale über die Zentrale geführt wird. Dort kommen Any-Selektoren, VPN-to-WAN-Regel, MASQ und eine eigene Entscheidung für systemgenerierten Traffic zusammen.

Route Precedence sicher ändern

Vor einer produktiven Änderung sollte man nicht nur den Befehl, sondern auch den betroffenen Paketfluss vorbereiten:

1. Aktuelle Reihenfolge mit system route_precedence show vollständig sichern und daraus den Rollback-Befehl erstellen.
2. Quelle, Ziel, Dienst, Zone und beteiligte Interfaces bestimmen. Static Routes, SD-WAN Routes, VPN-Routen und XFRM-Interfaces auf konkurrierende Ziele prüfen.
3. Einen unabhängigen Rückweg zur Firewall testen, beispielsweise eine lokale Konsole, ein separates Management-Interface oder ein nicht betroffener Admin-Pfad.
4. Nur die Route Precedence ändern. NAT-, Firewall-, VPN- und SD-WAN-Regeln nicht gleichzeitig anpassen, damit Ursache und Wirkung erkennbar bleiben.

Wenn SD-WAN beteiligt ist, sollte man zusätzlich prüfen, ob SD-WAN für systemgenerierten Traffic oder Reply Packets aktiviert ist:

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

Diese Optionen ändern nicht die Reihenfolge. Sie erweitern, auf welchen Traffic SD-WAN Routes angewendet werden: Reply-Packet-Routing gilt nicht, wenn der Hinweg nur die Default-Route des WAN Link Managers verwendet hat. Für systemgenerierten Traffic sollten SD-WAN-Kriterien nur Zielnetze und Dienste verwenden, weil Incoming Interface und Source Network nicht bekannt sind. Mindestens ein WAN-Link-Manager-Gateway muss Active sein; reine Backup-Gateways reichen nicht. Systemgenerierter RED-Traffic über UDP 3410 bleibt als Layer-2-Verkehr ausserhalb von SD-WAN Routing. Die Details erklärt Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen.

Nach dem set-Befehl wird zuerst die Reihenfolge erneut mit system route_precedence show kontrolliert. Danach folgen die Tests für den konkreten Anwendungsfall:

• Anwendung, TCP-Verbindung oder Ping zum Ziel testen.
• Route Lookup, Log Viewer und bei Bedarf Packet Capture prüfen.
• NAT und Rückweg der Gegenstelle kontrollieren.
• WebAdmin und SSH aus den relevanten Managementnetzen testen.

Ein grüner VPN-Status oder eine vorhandene Route beweist noch keinen funktionierenden Paketfluss. Praktische Prüfwege zeigen Sophos Firewall Regel testen mit Log Viewer und Packet Capture und Sophos Firewall Packet Capture im WebAdmin verwenden.

Rollback

Für den Rollback setzt man exakt die zuvor dokumentierte Ausgangsreihenfolge:

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

Alle drei Platzhalter müssen ersetzt werden. Aus dem ersten Wert allein lässt sich der frühere Zustand nicht ableiten, da insgesamt sechs Reihenfolgen möglich sind. Anschliessend werden system route_precedence show und dieselben Funktions- sowie Managementtests wiederholt.

Wenn die Änderung das Problem nicht löst

• Nur ein Zielnetz ist betroffen: Eine spezifischere statische Route, eine enger definierte SD-WAN Route oder eine korrigierte VPN-Konfiguration ist meist präziser als eine globale Änderung.
• Der VPN-Tunnel ist grün, Traffic fliesst aber falsch: Bei route-based IPsec zuerst XFRM-Interface und Route prüfen; bei policy-based IPsec zusätzlich Traffic Selectors und die versionsabhängige Behandlung von ipsec_route. Der Ablauf steht im IPsec VPN Troubleshooting.
• Der Hinweg stimmt, der Rückweg nicht: Routing bestimmt den Pfad, NAT verändert Quell- oder Zieladresse. Deshalb auch Rückroute und NAT-Konfiguration prüfen.
• Eine migrierte Firewall zeigt eine unerwartete Reihenfolge: Massgebend ist die Ausgabe von system route_precedence show, nicht der aktuelle Default. Migrierte SD-WAN Routes können zudem noch an ihre ursprüngliche Firewall-Regel gebunden sein und beim Löschen dieser Regel verschwinden.
• WebAdmin oder SSH sind nach einer SD-WAN-Änderung nicht erreichbar: Häufig treffen drei Dinge zusammen: SD-WAN steht vor Static, eine passende SD-WAN Route verwendet Any, und System Traffic oder Reply Packets sind für SD-WAN aktiviert. Über den vorbereiteten Managementpfad die Ausgangsreihenfolge wiederherstellen und die SD-WAN Route enger fassen.
• SSL-VPN-Anfrage erreicht das interne Ziel, die Antwort aber nicht den Client: SSL VPN gehört zu static. Steht SD-WAN davor, kann eine breite SD-WAN-Route die Antwort an den Lease-Bereich vom Tunnel weglenken. Die Route gezielt eingrenzen; der vollständige Prüfablauf steht unter SSL VPN Remote Access einrichten und testen.

FAQ