Create IPsec Route on Sophos Firewall

Normally, the Sophos Firewall automatically detects which IPsec tunnel a target network is reachable through. In a classic policy-based IPsec tunnel, local and remote networks are part of the tunnel configuration. In route-based IPsec, traffic is routed into the tunnel via XFRM interfaces, static routes, SD-WAN routes, or dynamic routing.

A manual IPsec Route is therefore not standard for every tunnel. It is a tool for specific policy-based scenarios, especially when forwarded traffic needs to work with NAT or a special assignment to the tunnel. If such a route is set incorrectly, traffic can run into the wrong tunnel or make an existing connection harder to trace.

For new site-to-site tunnels, first set up Sophos Firewall Site-to-Site IPsec VPN. For general IPsec troubleshooting, see Sophos Firewall IPsec VPN Troubleshooting. For route-based VPNs, XFRM, and interface planning, see Configure Sophos Firewall Zones and Interfaces.

When an IPsec Route is Useful

An IPsec Route is particularly relevant when a policy-based IPsec tunnel exists, but the expected traffic is not properly assigned to the tunnel.

Typical cases:

• A host or network should specifically run over a certain policy-based tunnel.
• There are multiple tunnels, overlapping target networks, or historically grown VPN configurations.
• Traffic is translated via DNAT or SNAT and must then be assigned to an existing IPsec tunnel.
• After an upgrade to SFOS 22, it should be checked whether old policy-based special cases still work as expected.
• Route Lookup, Log Viewer, or Packet Capture show that traffic is going towards WAN or the wrong path.

Not all of these cases are solved by ipsec_route. First, firewall rules, NAT rules, route precedence, local gateways, and return routes must be checked.

Policy-based, Route-based, and SFOS 22

The most important difference:

• Policy-based IPsec: Sophos Firewall performs IPsec lookups in the background local/remote networks in the IPsec connection, firewall rules, ipsec_route if needed.
• Route-based IPsec: Traffic is routed to the tunnel interface XFRM interface, static route, SD-WAN route, or dynamic routing.

For new or larger site connections, route-based IPsec is often clearer because routing changes do not change the tunnel selectors every time. For simple site-to-site connections or existing environments, policy-based IPsec remains relevant.

SFOS 22 has worked on IPsec behaviour in several areas. The SFOS-22.0-MR1 release notes document several resolved issues around policy-based IPsec, ipsec_route, SD-WAN, SNAT, and route lookup. For admins, this means: After an upgrade, policy-based special cases should be specifically tested, especially if NAT, MPLS, SD-WAN, or manual IPsec routes are involved.

Prerequisites

Before making a change, these points should be clear:

• Access to the Device Console, for example via SSH.
• Name of the IPsec tunnel.
• Target host or target network to be reached through the tunnel.
• Active or correctly configured IPsec connection.
• Appropriate firewall rules for the expected direction.
• Clarity on whether NAT is involved.
• Current state of existing IPsec routes is documented.

If console access is not yet set up, Connect Sophos Firewall via SSH explains how to establish an SSH connection to the firewall and open the Device Console.

⚠️ An incorrect IPsec Route can disrupt productive traffic. Before making changes, the tunnel name, target network, NAT, return path, and existing routes should be documented.

Check Before Making Changes

An IPsec Route should not be set as the first step. This order is sensible:

1. Check tunnel status: IPsec connection is active and the expected networks are negotiated.
2. Check firewall rules: Source zone, Destination zone, Source, Destination, Service, and Logging match.
3. Check NAT: It is clear whether original IP addresses or translated addresses should go through the tunnel.
4. Check route precedence: Static, SD-WAN, and VPN routes are evaluated in the expected order. If multiple routing types compete, Securely Change Sophos Firewall Route Precedence helps.
5. Check the peer: The peer knows the return path and expected source address.
6. Use Packet Capture: Verify whether traffic arrives, where it is forwarded, and whether responses return.

For general rule checking, see Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture. For NAT basics, see Understand NAT on Sophos Firewall.

Display Existing IPsec Routes

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

system ipsec_route show

The output should be documented before any changes. This way, you can later see if a route has been newly added and if it needs to be removed again.

Additionally, the IPsec routing table may be relevant for analysis:

ip route show table 220

This check is performed in the Advanced Shell and is more intended for troubleshooting. For normal changes to ipsec_route, the Device Console remains the correct place.

Create IPsec Route for a Host

If only a single host should be reachable through a specific tunnel, use host.

Syntax:

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

Example:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Afterwards, you should not only test with Ping but also check the actual application traffic. An ICMP test may work while TCP, NAT, or return path are still incorrect.

Create IPsec Route for a Network

If a complete network should be reachable through the tunnel, use net.

Syntax:

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

Example:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

With network routes, special caution is needed. A too large network can draw more traffic into the tunnel than planned. With overlapping networks, it must be clear in advance which side sees which addresses and whether NAT is used.

Remove IPsec Route

If the route is no longer needed or was set incorrectly, it can be deleted.

Remove host route:

system ipsec_route del host <host-ip>

Remove network route:

system ipsec_route del net <network>/<netmask>

Then check the list again:

system ipsec_route show

If the route affected productive traffic, the affected connection should be tested again after removal and the Log Viewer entries compared.

NAT and Policy-based IPsec

NAT is not fundamentally wrong with IPsec. However, it must be carefully planned because NAT changes the address seen by the peer.

Sophos distinguishes among others these cases with IPsec:

• NAT directly in the IPsec configuration, for example with overlapping networks.
• Independent NAT rules under Rules and policies > NAT rules.
• ipsec_route for forwarded traffic when translated traffic needs to be assigned to a policy-based tunnel.
• sys-traffic-nat for system-generated traffic of the firewall itself.

A NAT rule doesn’t automatically change the firewall’s routing decision. If an existing policy-based tunnel is used with DNAT/SNAT for additional hosts, a matching IPsec route to the remote network is still required. With reflexive SNAT rules, the translated source address must exist as an IP host object; you can’t simply translate directly to an interface.

The direction is important: If policy-based IPsec traffic is to be translated via SNAT, the appropriate SNAT rule must work with Outbound interface set to Any. If the rule instead points to specific WAN interfaces, it will not apply to policy-based IPsec traffic. Such details often lead to tunnels that are green but do not transport the expected user traffic.

System-generated Traffic is a Special Case

ipsec_route doesn’t solve every traffic problem on its own. For forwarded client or server traffic, the command can be directly relevant. System-generated traffic from the firewall itself, such as authentication requests or DHCP-related cases, also needs the right source NAT and routing logic.

Without specific configuration, system-generated traffic usually uses a gateway from Network > WAN link manager. A green IPsec tunnel is therefore not enough to automatically send firewall-generated requests into the tunnel. DHCP relay should also be considered separately: for policy-based IPsec, the DHCP relay must specifically enable the Relay through IPsec option. Route-based VPNs don’t need this option; there, DHCP traffic is routed like normal traffic via static, SD-WAN, or dynamic routes to the remote side, provided local and remote subnets are set to Any and matching routes exist on both ends.

Practically, this means:

• Client or server traffic through the firewall can be an ipsec_route issue.
• With policy-based IPsec, firewall-generated requests may require a combination of ipsec_route, sys-traffic-nat, and matching local or remote subnets.
• With route-based IPsec, these cases more often use SD-WAN routes to the XFRM interface and sys-traffic-nat.
• One should not attempt to solve every system traffic problem generally with ipsec_route.

For system-generated traffic and SD-WAN context, see SD-WAN Routing for Reply Packets and System Traffic.

Test the Change

After creating or removing an IPsec Route, the affected traffic should be specifically tested.

Practical procedure:

1. Define test case: Source, Destination, Service, Direction, and expected tunnel.
2. Enable firewall rule logging for the affected rule.
3. Document system ipsec_route show.
4. Generate test traffic exactly once.
5. Filter Log Viewer on Source, Destination, and Firewall Rule.
6. Execute Packet Capture with a narrow filter.
7. Check if bytes in ipsec statusall increase in both directions.
8. Check the peer for return route, NAT, and local firewall.

If larger transfers hang despite routing and NAT appearing correct, additionally check MTU and MSS in VPN Problems.

Typical Errors

• Tunnel green, no traffic: Rule, NAT, return route, or IPsec assignment is often missing. Check Log Viewer, Packet Capture, and ipsec statusall.
• Traffic goes towards WAN: Route precedence or IPsec assignment doesn’t match. Check Route Lookup, SD-WAN routes, and ipsec_route show.
• SNAT doesn’t apply with policy-based IPsec: The SNAT rule likely has the wrong outbound interface. Check the SNAT rule for Any.
• One host works, a network doesn’t: Netmask, object, or traffic selector doesn’t match. Compare local and remote networks.
• Different behaviour after SFOS 22 upgrade: An old special case with policy-based IPsec, NAT, or SD-WAN may be involved. Check release notes, test case, and peer.
• Firewall’s own traffic doesn’t go through the tunnel: System traffic is routed differently. Check SD-WAN, route precedence, and sys-traffic-nat.

Checklist

Before the change:

• Documented tunnel name and peer.
• Target host or target network is clear.
• Checked firewall rules and NAT rules.
• Checked route precedence and SD-WAN context.
• Secured existing IPsec routes.
• Planned maintenance window or controlled test time.

After the change:

• Checked system ipsec_route show again.
• Log Viewer shows the expected rule.
• Packet Capture shows the expected path.
• Peer sees the expected source address.
• Return path works.
• Documented change and reason.

FAQ