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 to policy-based IPsec. For new or growing designs, route-based Any-to-Any with XFRM and explicit routing is often more flexible. The choice is explained in Set up a site-to-site IPsec VPN.

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.

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 documented return path and maintenance window.

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. Without the correct return path and NAT, the tunnel may 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
• 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.

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.

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. Packet capture shows request and reply packets over the tunnel and head office WAN.
6. System-generated traffic uses the previously selected local or central path.

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.

For rollback, first disable Branch_LAN_to_WAN_drop and restore the previously allowed local internet path in a controlled manner. Then remove the VPN-to-WAN and MASQ rules only if no other flow needs them. Restore route precedence and the system-traffic option exactly to their documented previous values, then retest both sites.

FAQ