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. Entscheidend ist die Reihenfolge von links nach rechts: Der erste passende Routing-Typ gewinnt.

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:

Welcher konkrete Traffic nimmt aktuell den falschen Weg?
Welche der drei Kategorien enthalten dafür eine passende Route?
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 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.

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. Ein set-Befehl enthält immer alle drei Werte. Die Reihenfolge wird nicht mit Nummern angegeben, sondern allein durch die Position der Werte bestimmt.

⚠️ Wichtig: Die Änderung wirkt sofort und global. Vor dem set-Befehl sollte die vollständige Ausgangsreihenfolge dokumentiert und ein unabhängiger Managementzugang geprüft werden. Eine falsche Reihenfolge kann produktiven Traffic sowie WebAdmin- und SSH-Zugriff beeinflussen.

Die Sophos-Standardreihenfolge stellt man so wieder her:

system route_precedence set static sdwan_policyroute vpn

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. Unter SFOS 22.0 gehören auch mit ipsec_route definierte Routen zu dieser Kategorie.

Bei ipsec_route ist die SFOS-Version wichtig: Unter SFOS 21.5 gehört der Befehl noch zur Kategorie static, unter SFOS 22.0 zu vpn. Die vollständige Einordnung erklärt der Artikel zur IPsec Route auf Sophos Firewall.

SSL VPN gehört immer 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.

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 in dokumentierten Szenarien für route-based VPN-Failover 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. Sophos verlangt diese Reihenfolge beispielsweise für L2TP Remote Access. 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.

Route Precedence sicher ändern

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

Aktuelle Reihenfolge mit system route_precedence show vollständig sichern und daraus den Rollback-Befehl erstellen.
Quelle, Ziel, Dienst, Zone und beteiligte Interfaces bestimmen. Static Routes, SD-WAN Routes, VPN-Routen und XFRM-Interfaces auf konkurrierende Ziele prüfen.
Einen unabhängigen Rückweg zur Firewall testen, beispielsweise eine lokale Konsole, ein separates Management-Interface oder ein nicht betroffener Admin-Pfad.
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 sind nicht Teil der Route Precedence, können ihre Wirkung aber verstärken. 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.

FAQ

Gehört SSL VPN bei Route Precedence zu vpn oder static?

SSL-VPN-Verbindungen gehören zur Kategorie static. Der Wert vpn steht hier vor allem für automatisch erzeugte policy-based IPsec-Routen und unter SFOS 22.0 auch für ipsec_route.

Muss man Route Precedence für jedes VPN anpassen?

Nein. Die Einstellung ist global und sollte nur geändert werden, wenn mehrere Routing-Kategorien im konkreten Paketfluss konkurrieren. Für ein einzelnes Ziel ist eine spezifische Route oder korrigierte VPN-Konfiguration meist sicherer.