Skip to content
Avanet

Create IPsec Route on Sophos Firewall

Sophos Firewall

A manual ipsec_route belongs to policy-based IPsec. It assigns a destination host or network to an existing policy-based tunnel. It does not, however, extend Traffic Selectors or replace firewall and NAT rules or the return path on the remote peer.

This command is wrong for route-based IPsec. With an Any-to-any tunnel, the XFRM interface receives an IP address; static, SD-WAN, or dynamic routes then determine the path. For a route-based tunnel with Traffic Selectors, SFOS creates the route automatically. You cannot assign an IP address or custom routes to the associated XFRM interface.

⚠️ A route that is too broad or assigned to the wrong tunnel can redirect production traffic. Capture the initial state before making the change and keep the exact delete command ready.

When a manual IPsec Route is appropriate

The typical case is forwarded traffic whose address is changed by DNAT or SNAT. NAT changes the address, but not the routing decision. An additional route to the remote network may therefore be required.

Check the following before running the command:

  • The connection under Site-to-site VPN > IPsec > IPsec connections is policy-based.
  • The local and remote Traffic Selectors include the addresses actually presented to IPsec processing after NAT.
  • The firewall and NAT rules match the defined test traffic. For SNAT with policy-based IPsec, Outbound interface is set to Any.
  • The remote peer expects the visible source address and has a return route through the same tunnel.
  • An existing static or SD-WAN Route and the global Route Precedence do not direct the destination to another path.

A manual route does not fix an incorrect netmask, a mismatched selector, or a blocking rule. Set up a Sophos Firewall Site-to-Site IPsec VPN explains the tunnel types.

Capture the initial state in the Device Console

In WebAdmin, open admin > Console and select 4. Device console. For SSH access, Connect to Sophos Firewall via SSH leads to the same menu.

First display the existing manual IPsec Routes and the global order:

system ipsec_route show
system route_precedence show

Save the output together with the tunnel name, Traffic Selectors, Firewall Rule ID, NAT Rule ID, and planned test flow. Under SFOS 22, automatically generated policy-based VPN routes and manual ipsec_route entries belong to the vpn category. These routes are not visible in the WebAdmin routing table, so ip route show table 220 is not reliable evidence to the contrary.

Do not change Route Precedence as a side task. It is global and affects other connections. If it genuinely must be changed, Change Sophos Firewall Route Precedence safely provides the separate procedure with value-based rollback.

Create the route using a controlled NAT example

Sophos documents this narrowly defined use case:

  • A policy-based tunnel HO_to_Branch connects local network 192.168.2.0/24 to remote network 192.168.3.0/24.
  • The actual local server 172.16.16.10 is outside the local selector.
  • The remote peer addresses it as 192.168.2.1. This substitute address belongs to the local selector and, in the example, is the firewall’s LAN interface address.
Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Replace the network, addresses, and tunnel name with your own values. The substitute address must match the local Phase 2 selection; the remote destination network must be covered by the existing tunnel.

1. Assign the remote network to the tunnel

Run this command in the Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

For net, SFOS expects the full dotted-decimal mask. Use the narrowest destination range the application requires. The corresponding rollback command is:

system ipsec_route del net 192.168.3.0/255.255.255.0

The delete command does not include a tunnel name. Before deleting, use system ipsec_route show to confirm that the destination is unambiguous. Do not delete ambiguous entries on suspicion alone.

For a single destination host, the console supports this form:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

A host route is narrower, but it is correct only when that exact host is the destination and the Traffic Selectors match.

2. Configure DNAT and reflexive SNAT

  1. Under Rules and policies > NAT rules > Add NAT rule > New NAT rule, create a DNAT rule. Original source is 192.168.3.0/24, Translated source remains Original, Original destination is 192.168.2.1, and Translated destination is 172.16.16.10.
  2. Enable Create reflexive rule.
  3. Open the generated rule Reflexive_NAT#_<DNAT_rule_name>. For Translated source, select an IP host object with 192.168.2.1. Create the object under Hosts and services > IP host > Add. Sophos cannot translate directly to an interface in this reflexive rule.
  4. Check the order, status, and logging of both NAT rules and the associated firewall rule.

Do not add a broad MASQ rule or additionally permit the actual server through the tunnel with its untranslated address. Understanding NAT on Sophos Firewall explains matching and rule order.

Validate the data path

A green tunnel and a ping prove neither the NAT translation nor the return path. For validation, define a real application flow, such as TCP from the remote client to the published server service.

  1. Run system ipsec_route show again. The destination network must be assigned exactly once to the intended tunnel.
  2. Generate one controlled connection from 192.168.3.0/24 to 192.168.2.1 on the permitted service.
  3. Filter Log viewer by Source, Destination, and Firewall Rule ID. In the detail view, src_trans_ip shows the actual translated source address more reliably than the summary view.
  4. Open Monitor & analyze > Diagnostics > Packet capture and filter for the client, substitute address, and actual server. Rule ID and NAT ID must match the documented rules; ingress and egress interfaces must show the intended path.
  5. On the remote peer, verify that replies from 192.168.2.1 are expected and returned through the same tunnel.
  6. Test a nearby host or service that is not permitted. This negative test must still fail and confirms that the route and rules are not too broad.

An active SA or increasing byte counters alone are not sufficient. For a complete investigation, see Sophos Firewall IPsec VPN Troubleshooting; for rule and capture analysis, see Test a firewall rule with Log Viewer, Policy Test, and Packet Capture.

Roll back the change completely

First end any new test sessions. Restore DNAT and reflexive SNAT individually to their documented previous state; changing the DNAT rule afterward does not automatically remove the reflexive rule.

Then delete only the newly created route:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Remove the new IP host object only when Object usage no longer shows a reference. Then repeat the original control flow and the negative test. The Route Precedence captured earlier must remain unchanged.

If only the route was deleted by mistake, the saved add command restores the exact entry:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Isolate common errors systematically

The route exists, but traffic goes to the WAN

Check system ipsec_route show, Route Precedence, and competing SD-WAN Routes. Under SFOS 22, a missing entry in the WebAdmin routing table or table 220 is not evidence against the IPsec Route. In Route Precedence, vpn takes priority over static only for traffic to the WAN zone, so the zones and actual destination path must also be checked.

The tunnel is active, but NAT does not apply

Compare the original and translated addresses with the Traffic Selectors. For policy-based SNAT, Outbound interface must be Any. Then check Firewall Rule ID, NAT ID, and src_trans_ip rather than relying only on tunnel status.

The outbound path works, but the reply is missing

The remote peer must know the translated address and return traffic through the same tunnel. Check its selector, firewall rule, and return route. A different return path cannot be fixed with a broader local ipsec_route.

System-generated traffic or DHCP is affected

Authentication, DNS, and DHCP requests generated by the firewall follow a separate process. Under SFOS 22, they normally do not require a manual IPsec Route. Use SD-WAN Routing for Reply Packets and System Traffic or the separate DHCP relay runbook rather than applying this forwarding procedure.

A dynamic advertisement is missing after the SFOS 22 upgrade

Under SFOS 22, policy-based VPN routes are not ordinary kernel routes. If OSPF or BGP previously advertised them through redistribute kernel, Why redistribute kernel no longer advertises IPsec routes after an SFOS 22 upgrade explains this separate migration issue.