Route branch internet through the head office over IPsec

When a branch office’s internet traffic must be inspected centrally and leave through the head office WAN connection, Sophos Firewall can use a policy-based site-to-site IPsec tunnel. Branch clients then send traffic through the tunnel instead of directly to the local WAN. The central firewall, NAT, and security rules apply at the head office.

Branch LAN → Branch firewall → policy-based IPsec → Head office → MASQ → Internet

This design requires more than a green VPN tunnel. Route precedence, traffic selectors, rule order, and the return path must work together. If the tunnel or head office fails, the branch normally has no automatic local internet breakout in this design.

⚠️ This workflow applies only to policy-based IPsec. The peer must not be route-based. For new or growing designs, use route-based Any-to-Any: both peers use Any selectors, each receives an XFRM interface, and explicit static, SD-WAN, or dynamic routes are required. Do not mix those steps with the policy-based workflow below. Set up a site-to-site IPsec VPN explains the choice.

Example and prerequisites

The example uses branch network 10.20.0.0/24. The head office has a working WAN connection and an already planned policy-based tunnel. 10.20.0.0/24 is a documentation value and must be replaced by the actual branch network.

For this design, global route precedence must be VPN, Static, SD-WAN. Before changing it, save the current value and identify all other static, VPN, and SD-WAN paths that may be affected. The controlled workflow is described in Change route precedence safely.

SFOS 22 defaults to Static, SD-WAN, VPN. This design differs because Remote subnet: Any creates an automatic policy-based VPN route for all destinations at the branch. Do not delete the existing static 0.0.0.0/0 default route to the local WAN: it remains available for firewall-generated traffic when VPN use is disabled and for a controlled rollback. Read the current value in Device Console with system route_precedence show; the route-precedence article provides the set command, impact analysis, and recovery path.

The following must also be in place before the change:

• a working policy-based IPsec tunnel between both firewalls;
• tested administrative access to both sites;
• sufficient internet and firewall capacity at the head office;
• DNS, web policies, IPS, Application Control, and intended exceptions;
• a current configuration backup and change record containing the original selectors, route precedence, system-traffic option, and firewall and NAT IDs;
• a documented return path and maintenance window.

For HA, record the active node, healthy cluster state, and management access to the peer at each site before the change. HA replaces neither a second head-office WAN nor a second site. Treat failover as a separate test case rather than inferring it from a green tunnel.

Set the IPsec selectors

At the head office, set Local subnet to Any and Remote subnet to the branch LAN. At the branch, use the opposite values: the local branch network and remote Any.

Then test the tunnel with an internal destination at the head office. Only enable the internet path after site traffic works in both directions. This keeps an IPsec failure distinguishable from a NAT or firewall-rule problem.

Create firewall and NAT rules

Create the rules under Rules and policies > Firewall rules. Automatically generated VPN rules are not a complete design for this internet path.

Head office: VPN to WAN

A rule named Branch_VPN_to_WAN allows branch traffic to the internet:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: only the services that are actually required
• Log firewall traffic: enabled
• Create linked NAT rule > Translated source (SNAT): MASQ

Select the web policy, IPS, Application Control, and TLS inspection deliberately. The linked MASQ rule translates branch clients to the head office public address. SFOS evaluates the firewall rule before SNAT for outgoing traffic, so verify NAT order too: an earlier matching NAT rule takes precedence over the linked rule. NAT also doesn’t create a route, and NAT changes apply only to new connections.

The return path has two parts: MASQ returns internet replies to the head office WAN address; the head office then uses its automatically created policy-based VPN route for the translated destination 10.20.0.0/24. If the branch LAN is behind another router, document and test that router’s forward and return paths as well. Otherwise, the tunnel can be green while internet connections receive no reply.

Branch office: allow LAN to VPN

The Branch_LAN_to_VPN rule sits above any local LAN-to-WAN allow rule:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: only the services that are actually required
• Log firewall traffic: enabled

Follow it with a targeted Branch_LAN_to_WAN_drop rule for the same branch network from LAN to WAN. This prevents an overly broad local internet rule from bypassing the planned tunnel path. Do not accidentally include other networks or explicitly required local services.

Order is part of the security outcome: specific exceptions, Branch_LAN_to_VPN, then Branch_LAN_to_WAN_drop, followed by broader rules. Don’t rely on existing sessions after rule or NAT changes; create new client connections for acceptance testing.

Create firewall rules safely explains how to verify rule position, Rule ID, and the linked NAT rule together.

Decide on system-generated traffic separately

The preceding rules control forwarded client traffic. DNS, NTP, updates, Central, and other connections generated by the branch firewall itself are system-generated traffic.

Separate DNS by origin too. A client using a public resolver follows the client path through the tunnel. A client using an internal resolver at the head office needs a selector, firewall rule, and return route that allow that destination. Only DNS requests generated by the branch firewall itself follow the system-traffic option below. This is why the test uses a public IP address and an FQDN separately.

The default is enable. Because an existing system may differ, first use this read-only Device Console command to show the current state:

show routing policy-based-ipsec-vpn system-generate-traffic

If only client traffic should use the head office, system-generated firewall traffic can leave directly through the branch WAN:

set routing policy-based-ipsec-vpn system-generate-traffic disable

⚠️ This change restarts all IPsec tunnels on the firewall. Record the status, maintenance window, and recovery path first. Do not run the command merely as a test or on suspicion.

Restore the documented previous state during rollback. If the option was enabled before, use:

set routing policy-based-ipsec-vpn system-generate-traffic enable

After either change, retest every IPsec connection and each required firewall service.

Validate the data path

A client from 10.20.0.0/24 first opens a public IP address and then an FQDN over HTTPS. The acceptance test proves several layers:

1. Branch_LAN_to_VPN matches at the branch; the local LAN-to-WAN drop rule does not match this successful flow.
2. Branch_VPN_to_WAN and the linked MASQ rule match at the head office.
3. The publicly visible source IP address belongs to the head office.
4. DNS, HTTPS, and a deliberately blocked destination behave according to the central policy.
5. Under Diagnostics > Packet capture, In interface, Out interface, Rule ID, NAT ID, Status, and Reason show request and reply packets over the tunnel and head office WAN.
6. System-generated traffic uses the previously selected local or central path.
7. Current activities > IPsec connections remains established during the test, and the Log viewer shows no unexpected drops.
8. For HA, perform an approved node failover separately and repeat the complete test. Do not claim HA redundancy without this test.

A speed test alone is not sufficient. Also test real applications, DNS, security logs, and a longer download. For performance problems, use the separate workflows for internet speed tests and VPN MTU and MSS.

Typical errors and rollback

• Branch client still uses the local WAN: Check rule order, source network, LAN-to-VPN rule, and drop rule. Do not add a broad exception as a quick fix.
• Tunnel is green but internet access fails: At the head office, check the VPN-to-WAN rule, Rule ID, MASQ, WAN gateway, DNS, and return path.
• Only the firewall itself uses the wrong path: Check policy-based-ipsec-vpn system-generate-traffic. Do not confuse client traffic with system-generated traffic.
• Other tunnels fail after the CLI change: Restarting all IPsec tunnels is documented behavior. Restore the previous state and validate every tunnel separately.
• Tunnel or head office fails: The standard design has no local internet breakout. Such a fallback requires a deliberately planned security and routing path.
• A public IP works but an FQDN doesn’t: Check the client’s DNS address, DNS rule, central resolver path, and reply packets. The system-traffic option matters only when the firewall generates the request.

For rollback, first prepare a temporary LAN-to-WAN allow rule above Branch_LAN_to_WAN_drop for one test client only. Then restore route precedence to the recorded value and use a new session from that client to verify the local WAN path. If the test fails, immediately restore the full-tunnel route precedence and rule state through independent management access. Only after a successful test should you enable the former regular LAN-to-WAN rule, disable Branch_LAN_to_WAN_drop, and remove the temporary rule.

Next, restore the system-traffic option to its previous value and, because this restarts the tunnels, verify every IPsec connection. Disable or remove Branch_LAN_to_VPN, VPN-to-WAN, and MASQ only after Rule ID, NAT ID, and usage show that no other flow needs them. Finally, restore the original IPsec selectors or remove a tunnel created only for this path. Keep the configuration backup and independent management access available until new DNS, HTTPS, and application sessions succeed at both sites.

FAQ