Create IPsec Route on Sophos Firewall

A manual IPsec Route is not standard for every tunnel. It is primarily relevant for policy-based IPsec when forwarded and translated traffic must be assigned to a specific tunnel.

Route-based IPsec: Do not create an ipsec_route. Traffic uses XFRM interfaces and static, SD-WAN, or dynamic routes. Policy-based IPsec without a special NAT case: Check the tunnel, firewall rules, NAT, and return path first. Policy-based IPsec with forwarded DNAT or SNAT traffic: The following steps help with verification and configuration.

⚠️ An incorrect IPsec Route can direct production traffic into the wrong tunnel. Capture the initial state and prepare an exact rollback before every change.

Check, create, and remove an IPsec Route

Run the commands for displaying, creating, and removing routes in the Device Console. If access has not yet been configured, Connect to Sophos Firewall via SSH explains how to open the Device Console.

Capture the initial state

The exact traffic path must be clear before running an add command:

• The connection is an active policy-based tunnel, not route-based IPsec.
• The destination host or network matches the tunnel selectors and the planned translation.
• The firewall and NAT rules match the defined test traffic; for SNAT, Outbound interface is set to Any.
• Route Precedence and competing routes have been checked.
• The remote peer expects the visible source address and has a return route.

First, document all manual IPsec Routes:

system ipsec_route show

For routing or NAT problems, also capture Route Precedence and system traffic NAT:

system route_precedence show
show advanced-firewall

This older troubleshooting view can also be useful in the Advanced Shell:

ip route show table 220

According to Sophos, policy-based IPsec Routes and ipsec_route entries are not visible there under SFOS 22. A missing entry therefore does not prove that no IPsec Route exists. system ipsec_route show, the configuration, and a traffic test remain authoritative.

Create a route for a host

Syntax:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Example for host 10.33.46.69 through tunnel Azure_CH:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Create a route for a network

Syntax:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Example for network 10.33.46.0/24:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

The netmask must match the intended destination exactly. A route that is too broad can unintentionally direct additional traffic into the tunnel.

Remove a route safely

⚠️ The delete commands do not include a tunnel name. Before deleting, use system ipsec_route show to verify that the host or network is unambiguous, and keep the complete add command ready for rollback. Do not delete ambiguous entries on suspicion alone.

Remove a host route:

system ipsec_route del host <host-ip>

Remove a network route:

system ipsec_route del net <network>/<netmask>

Then check the list again:

system ipsec_route show

If the test result becomes worse, restore the route with the add command captured earlier.

When ipsec_route is appropriate

Policy-based and route-based IPsec

With policy-based IPsec, the local and remote networks define the tunnel selectors. A manual ipsec_route can assign additional hosts or networks to an existing tunnel, but it does not replace matching selectors, firewall rules, or a return route.

With route-based IPsec, traffic is routed to the XFRM interface. Depending on the design, use a static route, an SD-WAN Route, or dynamic routing. An ipsec_route is the wrong tool here. Set up a Sophos Firewall Site-to-Site IPsec VPN and Configure Sophos Firewall Zones and Interfaces explain the fundamentals of both variants.

Difference between SFOS 21.5 and 22

The classification within Route Precedence has changed:

• Under SFOS 21.5, automatically created policy-based IPsec Routes belong to the vpn category, while manual ipsec_route entries belong to static.
• Under SFOS 22, both automatic and manual policy-based IPsec Routes belong to the vpn category. They do not appear as ordinary kernel routes and are processed internally using marks, zones, and flags.

After upgrading from SFOS 21.5, retest Route Precedence and existing special cases. The SFOS 22 Upgrade Check covers the general checks. Change Sophos Firewall Route Precedence safely explains the global order.

A manual route only makes sense when the tunnel, traffic selectors, firewall rule, NAT rule, and return path are correct. It does not fix an incorrect netmask, a missing route on the remote peer, or a blocking rule.

NAT for forwarded traffic

NAT changes addresses, but it does not automatically change the routing decision. If a policy-based tunnel carries additional traffic translated by DNAT or SNAT, a matching IPsec Route to the remote host or network may therefore be required.

For SNAT with policy-based IPsec, the matching NAT rule must use Any for Outbound interface. If it is restricted to a specific WAN interface, it does not match the IPsec traffic. Understanding NAT on Sophos Firewall explains processing order, matching, and the return path in more detail.

Make the change during a maintenance window or with a controlled test case. The following values must be clear beforehand:

• original and translated source and destination addresses,
• local and remote networks of the IPsec connection,
• tunnel name and expected firewall rule,
• return route and permitted addresses on the remote peer.

Handle system-generated traffic separately

DNS, authentication, and other requests generated by the firewall do not automatically follow the same logic as forwarded client traffic. Under SFOS 22, an ipsec_route is not normally required for this traffic. Only the specific Sophos instructions for authentication requests mention it as a conditional fallback when the request demonstrably does not enter the policy-based tunnel because of the specific Route Precedence.

If necessary, use sys-traffic-nat to define the source address for this traffic. Example: The firewall must reach server 10.10.2.15 using the defined SNAT/interface address 10.10.1.1. This address must match the IPsec subnets and must be routed back by the remote peer.

Run the following commands in the Device Console:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1
show advanced-firewall

Rollback:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

If interface or netmask was also used when adding the entry, the same selectors must be specified when deleting it. Check SD-WAN Routing for Reply Packets and System Traffic contains further examples.

DHCP requires separate consideration:

• With policy-based IPsec, the relay requires Relay through IPsec, matching local and remote IPsec subnets, sys-traffic-nat, and the required rules and return paths on the remote peer. If the requests still do not enter the tunnel because of the specific routing configuration, an ipsec_route may be required as a verified fallback.
• With route-based IPsec, do not enable Relay through IPsec. A relay to the DHCP server side is supported over an XFRM interface with any-to-any subnets, static, SD-WAN, or dynamic routes, and matching rules on both firewalls. An ipsec_route does not belong in this path.
• If the firewall at the head office acts as the DHCP server for remote networks in a policy-based IPsec setup, Lease over IPsec must be enabled. According to Sophos, firewall interfaces acting as DHCP servers are not supported for this route-based setup.

Run this command in the Device Console as well:

system dhcp lease-over-IPSec enable

Older SFOS 21.5 procedures mentioned ipsec_route more frequently for authentication and DHCP. Review such configurations during an upgrade and do not reproduce them without verification.

Test and validate the change

A green tunnel or a successful ping is not sufficient proof. An ICMP test can succeed while TCP, NAT, or the return path is still incorrect.

1. Define source, destination, service, direction, and expected tunnel.
2. Enable logging on the affected firewall rule.
3. Capture system ipsec_route show before the test.
4. Generate the actual application traffic once in a controlled manner.
5. Filter Log Viewer by source, destination, and rule.
6. Run Packet Capture with a narrow filter on both sides of the path.
7. Check the source address, return route, and local firewall on the remote peer.
8. Document the result, change, and rollback command.

In the Advanced Shell, these commands show negotiated SAs, byte counters, and XFRM policies:

ipsec statusall
ip xfrm policy

However, these commands alone do not prove that NAT, the firewall rule, and the return path are correct. Test a firewall rule with Log Viewer, Policy Test, and Packet Capture helps with systematic analysis. If only larger transfers stall, also check MTU and MSS for VPN problems.

Troubleshoot and roll back

The tunnel is active, but no traffic flows

Check the firewall rule, NAT, traffic selectors, and return route. Then compare Log Viewer, Packet Capture, and the counters from ipsec statusall. Sophos Firewall IPsec VPN Troubleshooting provides the complete workflow.

Traffic goes to the WAN

Check Route Precedence, SD-WAN Routes, and system ipsec_route show. Under SFOS 22, a missing entry in table 220 must not be used as proof that no IPsec Route exists.

SNAT does not apply

For policy-based IPsec, verify that Outbound interface is set to Any and that the original and translated addresses match the tunnel and the remote peer.

One host works, but a network does not

Compare the netmask, host/network object, and traffic selectors on both sides. Do not create a broader route until the discrepancy is understood.

The path changes after the SFOS 22 upgrade

Recheck Route Precedence and all policy-based special cases involving NAT, SD-WAN, or MPLS. Do not automatically delete or recreate old routes.

Firewall-generated traffic does not reach the destination

First determine whether the issue affects authentication, DNS, DHCP, or another service. Then check Route Precedence, SD-WAN, sys-traffic-nat, and the corresponding SFOS 22 workflow.

If an error begins immediately after the change, remove the new route, verify with system ipsec_route show, and repeat the previous test. If the problem persists, fully restore the documented initial state.

FAQ