Change Sophos Firewall Route Precedence safely

The Route Precedence of the Sophos Firewall determines the order in which different routing types are taken into account when selecting the route. This sounds like a small adjustment, but it can immediately impact productive traffic. It is particularly relevant when Static Routes, SD-WAN Policy Routes and VPN Routes overlap.

The article explains when a change makes sense, when you should check other causes first and how to properly document the change using the Device Console, test it and roll it back if necessary. If you want to plan or test a normal SD-WAN route first, Sophos Firewall Setup and Test SD-WAN Route fits.

When Route Precedence is important

Route Precedence becomes important when multiple routing mechanisms theoretically fit the same destination. The firewall must then decide which type of routing is evaluated first.

Typical situations:

• An internal target network can be reached via a static route and additionally via a SD-WAN policy route.
• A route-based IPsec VPN uses XFRM interfaces and is simultaneously influenced by SD-WAN rules.
• A policy-based IPsec special case works with manual IPsec routes.
• System generated traffic or reply packets take an unexpected route after a SD-WAN change.
• After a firmware upgrade or migration, existing routes behave differently than expected.

For IPsec special cases, Route Precedence is not automatically the best solution. Often you first need to understand whether a classic routing problem, a IPsec Route, a SD-WAN rule, NAT or a firewall rule is involved.

Requirements

• Sophos Firewall in Gateway mode.
• Access to the Device Console, for example via SSH.
• Current documentation of affected static routes, SD-WAN policy routes and VPN connections.
• Maintenance window or at least a fallback path when productive traffic may be affected.
• Access to Log Viewer and, if necessary, Packet Capture.

If console access is not yet set up, Connect Sophos Firewall via SSH explains how to access the Device Console. SSH should only be allowed from trusted networks.

⚠️ Important: A change to the Route Precedence has a global effect. It is not just a single tunnel or route that is affected, but the order of routing types on the firewall. Therefore, you should never make multiple routing, NAT and SD-WAN changes at the same time.

Default order

The current documentation describes the following standard order:

1. Static
2. SD-WAN
3. VPN

The values in the Device Console are:

• static
• sdwan_policyroute
• vpn

Important: SSL VPN connections belong to the static category. This is particularly relevant when remote access traffic, static routes and SD-WAN rules are considered together.

Also important: Directly connected networks are treated like static routes in this context. If sdwan_policyroute is in front of static and a SD-WAN route with a very wide destination like Any works, internal traffic can suddenly go towards the WAN gateway. This is exactly why static is the safe starting point in many environments before sdwan_policyroute.

Which order is correct?

There is no one right order for every design. The Route Precedence must fit the routing model.

• Normal LAN, DMZ, VLAN, Remote Access and SD-WAN Internet Paths: static sdwan_policyroute vpn Directly connected networks and static routes should not be overridden by wide SD-WAN routes.
• Policy-based IPsec overlaps with static or SD-WAN routes: vpn static sdwan_policyroute Only use if the VPN networks really need to be evaluated first. Then check NAT, firewall rules and return path.
• Route-based IPsec or WAN failover is deliberately controlled via SD-WAN: design dependent, often with SD-WAN before another type of routing Test XFRM interface, SD-WAN criteria, gateway status, NAT and Route Precedence together.
• MTA, special routing or individual Sophos how-to scenarios: according to tested scenario Don’t blindly copy from an example. Always check for local networks and return routes.

If a Sophos example shows a different order, that is not automatically a new standard. Many examples solve a concrete, special problem. What counts for a productive firewall is which source and target networks are actually competing.

Limit before change

Route Precedence should not be the first reaction when a target network cannot be reached. First you should narrow down the affected packet flow.

Check:

1. Which source and destination are affected?
2. Which zone and which interface are involved?
3. Is there a suitable static route?
4. Is there a SD-WAN policy route that matches wider than planned?
5. Is a VPN route or an XFRM interface involved?
6. Does NAT or MASQ apply?
7. Is the expected firewall rule met in the Log Viewer?
8. Does Packet Capture show the expected input and output path?

Sophos Firewall test rule with Log Viewer and Packet Capture and Sophos Firewall use Packet Capture in WebAdmin help for the practical exam. For NAT questions, Understand NAT on Sophos Firewall fits.

View current Route Precedence

The commands are executed in the Device Console, not in the Advanced Shell.

Show current order:

system route_precedence show

The output should be documented before any changes. It is best to also note the date, reason, affected networks and expected behavior. If a rollback is necessary, this exact order must be set again.

In the WebAdmin you can also see the current Route Precedence under:

Routing > SD-WAN routes

There it will be displayed in the routing advice area. The order is changed via the Device Console.

Route Precedence change

The syntax is:

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

The order of the three values determines the priority. A typical example puts static routes in front of SD-WAN policy routes and VPN routes:

system route_precedence set static sdwan_policyroute vpn

If this order is already active, the problem is probably not with Route Precedence. Then you should specifically check route lookup, SD-WAN policy routes, IPsec configuration, NAT, firewall rules and return routes.

Another example puts SD-WAN Policy Routes before static routes:

system route_precedence set sdwan_policyroute static vpn
```This may be intentional in certain SD-WAN designs, but is risky when broad SD-WAN rules work with `Any` or large network areas. In such cases, management access, internal networks or return packets may be unexpectedly routed via SD-WAN. The article [Sophos Firewall SD-WAN Check routing for reply packets and system traffic](/en/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/) explains these interactions in more detail.

For policy-based IPsec special cases, `vpn` may also be necessary in the first place:

```shell
system route_precedence set vpn static sdwan_policyroute

This should only be done if static or SD-WAN routes override the remote IPsec networks. With route-based IPsec with

Test change

After adjusting, first check the new order:

system route_precedence show

Then test the affected traffic specifically. A green VPN status or an existing route is not enough evidence.

Check:

• Connection to the target network with ping, TCP test or application test.
• Filter Log Viewer on source, destination and firewall rule.
• Run Packet Capture on input and output interface.
• Check route lookup or affected SD-WAN rule.
• Check NAT rule and translated source IP.
• Check the return path of the remote station.
• Test management access to WebAdmin and SSH from relevant admin networks.

If multiple locations are affected, you should not just check one test client. It is better to have at least one client per relevant network, a server target and a remote access or VPN test if these paths are affected by the change.

Rollback

A rollback does not consist of an advised default value, but of the previously documented order.

Example:

system route_precedence set static sdwan_policyroute vpn

or:

system route_precedence set sdwan_policyroute static vpn

Check again after rollback:

system route_precedence show

Then repeat the same tests as after the change. If this causes the original error to return, that is a strong indication that the Route Precedence is indeed involved. If nothing changes, the cause is probably somewhere else.

Common errors

SD-WAN rule is too broad

If a SD-WAN policy route matches very broad sources or destinations, it may capture more traffic than planned. This is particularly dangerous if SD-WAN is prioritized over static. Management access or internal target networks can then unexpectedly run via a WAN route.

Typical pattern:

• Route Precedence is on sdwan_policyroute static vpn.
• A SD-WAN route uses Any as its destination.
• System-generated traffic or reply packets are also evaluated via SD-WAN.

Access to WebAdmin or SSH from an internal subnet can then be lost, although the firewall can still be reached from other networks.

VPN status is confused with routing

An active IPsec tunnel only proves that the tunnel has been negotiated. It does not prove that the firewall routes the traffic into the tunnel, that NAT is correct or that the remote station knows the way back.

With policy-based IPsec, it is particularly important whether static or SD-WAN routes also fit the remote subnets. If yes, vpn static sdwan_policyroute may be necessary. For route-based IPsec you should first check the XFRM interface, route, SD-WAN route and firewall rules.

NAT is overlooked

Routing decides where a packet is sent. NAT decides whether the source or destination address is changed. If a route is correct but the return route doesn’t work, NAT or the return route is often involved.

Multiple changes at once

If Route Precedence, SD-WAN rules, NAT, firewall rules and VPN parameters are changed at the same time, the effect can hardly be clearly attributed. It’s better to make a change, then test, then make the next change.

Checklist

• Current Route Precedence documented with system route_precedence show.
• Affected sources, destinations, networks and services noted.
• Static routes, SD-WAN policy routes and VPN routes checked.
• Directly connected networks and internal management paths taken into account.
• Wide SD-WAN routes identified with Any.
• NAT and firewall rules checked.
• Maintenance window or fallback path defined.
• Change set with exact order.
• After modification Log Viewer, Packet Capture and application test performed.
• Management access from admin networks checked.
• Rollback order documented.

FAQ