Safely change route precedence on Sophos Firewall

Route precedence determines whether Sophos Firewall evaluates Static Routes, SD-WAN Policy Routes or VPN routes first. The setting applies globally and can immediately affect production traffic and administrative access.

Short answer

The default order is:

1. static
2. sdwan_policyroute
3. vpn

This order suits many environments because directly connected networks and static routes cannot be overridden by a broad SD-WAN route. Change the order only when several routing types compete for the same destination in the specific packet flow.

Before every change, document the current order, ensure independent management access, check the affected routes and prepare the exact rollback. A standard SD-WAN route is explained in Set up and test an SD-WAN route on Sophos Firewall.

Which order is appropriate?

Default and version difference

The default order is identical in SFOS 21.5 and 22.0. However, the classification of ipsec_route has changed:

• SFOS 21.5: static includes directly connected networks, ipsec_route, Unicast Routes, Dynamic Routes and SSL VPN. Automatically generated policy-based IPsec routes belong to vpn.
• SFOS 22.0: static includes directly connected networks, Unicast Routes, Dynamic Routes and SSL VPN. vpn includes automatically generated policy-based IPsec routes and ipsec_route.

This matters during upgrades: Guidance for ipsec_route on SFOS 21.5 must not be applied unchanged to SFOS 22.0. On SFOS 22.0, the firewall processes policy-based IPsec routes internally. Automatically generated policy-based VPN routes and routes defined with ipsec_route are not visible in the routing table. ipsec_route is not required for system-generated traffic. A manual IPsec route is useful only for the appropriate version-specific special case.

On migrated firewalls, the actual output matters rather than the documented default. A migration may retain sdwan_policyroute vpn static, for example. Migrated SD-WAN routes can also remain tied to the ID of their original firewall rule and disappear when that rule is deleted.

Static first

static sdwan_policyroute vpn is usually the right starting point for LAN, DMZ, VLAN, SSL VPN and standard SD-WAN internet paths. Directly connected networks are treated like static routes.

This protects internal destinations from overly broad SD-WAN routes. If sdwan_policyroute precedes static and an SD-WAN route uses a destination such as Any, internal or administrative traffic can unexpectedly be sent toward the WAN gateway.

SD-WAN first

sdwan_policyroute static vpn is appropriate when policy routing should deliberately take priority over static routes. This must be planned using specific sources, destinations and services. SD-WAN routes apply to reply packets and system-generated traffic only when the corresponding CLI options are enabled.

Check Sophos Firewall SD-WAN routing for reply packets and system traffic explains both options in detail.

VPN first

vpn static sdwan_policyroute is a targeted exception, for example for documented L2TP scenarios. The priority of vpn over static applies only to traffic whose competing route points to the WAN zone. It is not a universal fix for every IPsec tunnel.

SSL VPN connections belong to the static category, not to vpn. Route-based IPsec through XFRM interfaces is controlled by the configured static, dynamic or SD-WAN route. The XFRM interface, route, SD-WAN criteria, NAT, firewall rule and return path are therefore decisive.

A global change is unsuitable when only one destination network is routed incorrectly. A more specific static or SD-WAN route, the VPN configuration or a version-appropriate ipsec_route is usually the more precise approach.

Prepare the change safely

Run the commands in the Device Console, not in the Advanced Shell. If access has not been configured, see Connect to Sophos Firewall using SSH. Allow SSH only from trusted networks.

Preparation:

1. Ensure and actively test an independent path back to the firewall before the change, such as a local console, dedicated management interface or a confirmed unaffected administrative path.
2. Record the source, destination, service, zone and interfaces involved.
3. Check static routes, SD-WAN Policy Routes, VPN routes and XFRM interfaces.
4. Identify broad SD-WAN routes with Any and migrated rules.
5. Check NAT, the firewall rule and the remote system’s return path.
6. Define the maintenance window, acceptance test and rollback.

⚠️ Important: Route precedence applies globally. Do not change routing, NAT, firewall and SD-WAN rules simultaneously, because the effect can no longer be attributed reliably.

Display and document the current order exactly:

system route_precedence show

Record the complete output together with the date, reason, affected networks and expected behavior. Prepare the exact rollback command from all three values before making the change.

The current order is also visible here in WebAdmin:

Routing > SD-WAN routes

Change it through the Device Console. If SD-WAN is involved, also record the status for system-generated traffic and reply packets beforehand:

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

These values must not be conflated with the effect of route precedence. A particularly critical combination occurs when sdwan_policyroute precedes static, a matching SD-WAN route uses the destination Any, and SD-WAN is enabled for both system-generated traffic and reply packets. In that case, WebAdmin and SSH may become inaccessible from the affected internal subnet while the firewall may remain accessible from other subnets.

Change route precedence

The syntax always contains all three values:

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

Set the default order:

system route_precedence set static sdwan_policyroute vpn

If this order is already active, the error is probably related to route lookup, SD-WAN criteria, VPN configuration, NAT, the firewall rule or the return path.

⚠️ Before SD-WAN-First: Check whether broad SD-WAN routes capture internal networks or management access. Run the command only with a prepared recovery path.

Evaluate SD-WAN Policy Routes first:

system route_precedence set sdwan_policyroute static vpn

⚠️ Before VPN-First: Use this order only for a confirmed VPN special case. It does not resolve a missing route, incorrect traffic selectors, NAT or return-path problems.

Evaluate VPN routes first:

system route_precedence set vpn static sdwan_policyroute

Test and roll back the change

After the change, first confirm that the expected order is active:

system route_precedence show

Then test the affected packet flow:

• Test the application, TCP connection or ping to the destination.
• Filter Log Viewer by source, destination and firewall rule.
• Run Packet Capture on the inbound and outbound interfaces.
• Check route lookup and the affected SD-WAN route.
• Check NAT and the translated source IP.
• Confirm the remote system’s return path.
• Test WebAdmin and SSH from the relevant administrative networks.

A green VPN status or an existing route is not proof of a working packet flow. Practical steps are covered in Test Sophos Firewall rules with Log Viewer and Packet Capture and Use Packet Capture in Sophos Firewall WebAdmin.

If multiple sites or routing paths are affected, test at least one client per relevant network, one server destination and any affected remote-access or VPN paths.

For rollback, set only the previously documented complete original order. It cannot be derived from the first value alone because six combinations are possible. Use the prepared command following this pattern:

system route_precedence set <first value> <second value> <third value>

Replace the placeholders with all three values from the previously saved output. Then check again:

system route_precedence show

Repeat the same functional, routing and management tests. If the original error returns after rollback, route precedence was probably involved. If nothing changes, the cause lies elsewhere.

Common errors

The SD-WAN route is too broad

An SD-WAN route with large network ranges or the destination Any can capture more traffic than intended. If SD-WAN precedes Static, internal destinations and management access may unexpectedly be sent to the WAN gateway. Reply packets and system-generated traffic are affected when the corresponding SD-WAN options are enabled.

VPN status is confused with routing

An active tunnel confirms only that negotiation succeeded. It does not prove that routing, traffic selectors, firewall rules, NAT and the return path are correct. For route-based IPsec, check the XFRM interface and route first; for policy-based IPsec, also check the version-dependent handling of ipsec_route. Sophos Firewall IPsec VPN troubleshooting provides a systematic analysis.

NAT is overlooked

Routing determines the packet’s path; NAT changes its source or destination address. If the route is correct but the return path is broken, NAT or the return route is often the cause. See Understanding NAT on Sophos Firewall.

Multiple changes are made simultaneously

If route precedence, SD-WAN, NAT, firewall rules and VPN parameters are changed at the same time, cause and effect can no longer be separated cleanly. A better approach is one change, a complete test, then the next change.

Checklist

• Current route precedence documented.
• SFOS version and classification of ipsec_route considered.
• Affected sources, destinations, networks and services recorded.
• Static, SD-WAN, VPN and XFRM checked.
• Directly connected networks and management paths considered.
• Broad SD-WAN routes with Any identified.
• Status for system traffic and reply packets recorded.
• NAT, firewall rules and return path checked.
• Independent management access and rollback prepared.
• Change performed in isolation.
• Application, Log Viewer, Packet Capture and management access tested.

FAQ