Use NAT for overlapping IPsec networks on Sophos Firewall

If head office and branch use the same real subnet, neither firewall can decide from the destination address alone whether a packet should remain local or pass through the IPsec tunnel. The tunnel may be green while no unambiguous data path exists. The solution is a translation plan coordinated on both sides: each site appears to the peer under a unique translated network.

The tunnel type determines the method. Policy-based IPsec and route-based IPsec with specific traffic selectors use the NAT settings directly in the IPsec connection. Route-based Any-to-Any instead uses DNAT and SNAT rules plus a route to the translated remote network. Set up a Site-to-Site IPsec VPN explains the general tunnel-type decision.

Choose the correct method

Sophos supports 1:1, 1:n or n:n translation for policy-based IPsec. With n:n, the original and translated networks must be the same size. A /24, for example, must map to another /24, not to a /25.

Three questions are enough to choose:

• Are specific Local and Remote subnets entered in the IPsec connection? Use Network address translation (NAT) in the connection.
• Are both subnets set to Any on a route-based tunnel? Use DNAT with a reflexive SNAT rule and a route over XFRM.
• Do the networks not overlap at all? NAT is normally unnecessary and makes logs, rules and troubleshooting harder.

⚠️ Do not mix the two methods. Before the change, save both tunnel configurations, NAT and firewall rules, routes, DNS responses and independent administrator access. A broad MASQ rule or an improvised translated address is not a safe workaround.

Create an address plan for both sites

In the example, head office and branch both use the real network 192.168.2.0/24. Each side receives its own virtual network for the tunnel:

HQ real:            192.168.2.0/24  → visible to branch as 192.168.1.0/24
Branch real:        192.168.2.0/24  → visible to HQ as 192.168.3.0/24

A client at head office therefore contacts a branch server through its address in 192.168.3.0/24. A branch client uses the corresponding address from 192.168.1.0/24 for a head-office server. The real address 192.168.2.x remains local at each site.

The three networks are documentation values and must be replaced together with free networks from the actual address plan. Both translated networks must be unique, must not collide with any LAN, VLAN, VPN, cloud or home network, and must be documented identically on both firewalls. If applications use names instead of IP addresses, DNS at each site must return the translated address of the remote system.

Configure policy-based IPsec with NAT

Policy-based IPsec requires three IP host objects on each firewall: the real local network, the local translated network and the peer’s translated network. In the head-office example these are HO_LAN_REAL_192.168.2.0, HO_LAN_NAT_192.168.1.0 and BO_LAN_NAT_192.168.3.0.

Configure head office

Under Site-to-site VPN > IPsec > Add, create the connection as Policy-based with Gateway type Respond only. Profile, authentication, WAN interface and peer address must match the remote side. Use these network assignments:

• Local subnet: HO_LAN_NAT_192.168.1.0
• Remote subnet: BO_LAN_NAT_192.168.3.0
• Network address translation (NAT): enabled
• Original subnet: HO_LAN_REAL_192.168.2.0

The firewall translates its real local network to its local translated network before sending it. Incoming traffic to the translated network maps back to the real network.

Configure the branch as a mirror

At the branch, create the Policy-based connection with Gateway type Initiate the connection. Mirror the assignment completely:

• Local subnet: BO_LAN_NAT_192.168.3.0
• Remote subnet: HO_LAN_NAT_192.168.1.0
• Network address translation (NAT): enabled
• Original subnet: BO_LAN_REAL_192.168.2.0

Local and Remote subnet therefore contain the translated networks, while Original subnet contains the real local network. If network size or direction differs, phase 2 may still form, but user traffic is translated incorrectly or has no return path.

Review automatic firewall rules

With Create firewall rule, SFOS creates inbound and outbound VPN rules. Review them under Rules and policies > Firewall rules in the Automatic VPN rules group. The rules must allow the translated networks in the correct direction and only the services actually required. An existing general VPN rule can be adjusted; a separate broad rule is not mandatory for every tunnel.

Rules are evaluated from top to bottom. Check Rule ID, source and destination zones, source and destination networks, services and logging during a real test. Create firewall rules on Sophos Firewall explains the general rule logic.

Configure route-based Any-to-Any with DNAT and SNAT

This method requires a working route-based Any-to-Any tunnel. The XFRM interface has a unique transit address, matching LAN-to-VPN and VPN-to-LAN rules exist, and a static, SD-WAN or dynamic route points to the translated network of the peer. Only then is NAT added.

Route-based connections with specific traffic selectors do not use this procedure. Like policy-based IPsec, they use the NAT settings in the IPsec connection. If their traffic instead matches a MASQ rule, SFOS may drop it because no IP address is assigned to these XFRM interfaces.

NAT at head office

Create a DNAT rule under Rules and policies > NAT rules > Add NAT rule > New NAT rule. It translates incoming packets addressed to the virtual head-office network to the real local network:

• Original source: branch translated network 192.168.3.0/24
• Translated source: Original
• Original destination: head-office translated network 192.168.1.0/24
• Translated destination: real head-office network 192.168.2.0/24
• Create reflexive rule: enabled
• Load balancing method: One-to-one

Use equal-sized network or IP range objects for the mapping. After saving, open the generated Reflexive_NAT#_<DNAT_rule_name> rule. Outbound, it must translate the real head-office network to 192.168.1.0/24 and use the branch translated network 192.168.3.0/24 as Original destination.

NAT at the branch

Mirror the same principle at the branch:

• Original source: head-office translated network 192.168.1.0/24
• Translated source: Original
• Original destination: branch translated network 192.168.3.0/24
• Translated destination: real branch network 192.168.2.0/24
• Create reflexive rule: enabled
• Load balancing method: One-to-one

The reflexive rule must translate the real branch network outbound to 192.168.3.0/24. A more general SNAT or MASQ rule above these rules must not capture the traffic first. Prove order and matching with NAT Rule ID and Packet Capture rather than inferring them from the rule list alone. Understand NAT on Sophos Firewall explains reflexive rules and first-match behavior.

Check routing, DNS and applications together

On each side, the route to the remote translated network must use the correct XFRM interface or its monitored gateway. A route to the identical real network would be ambiguous and could pull local traffic into the tunnel. If several routes exist, review Route Precedence, Administrative Distance and SD-WAN selection together.

The application must also use the translated destination. Static configurations, ACLs, DNS responses, monitoring and server logs must not continue to expect the real remote address. A NAT test using only ping therefore does not prove that the business application works.

Validate the data path in both directions

Start with one known host and a real TCP or UDP service on each side. From head office, access the translated branch address, then test the translated head-office address from the branch. For the same timestamp, verify:

1. The IPsec connection and Child SA are active.
2. The expected Firewall Rule ID allows the flow.
3. The expected NAT Rule ID translates original and destination addresses correctly.
4. Packet Capture shows ingress, translation, XFRM egress and the return path.
5. The destination server sees the planned source address and replies over the same path.

Only after both directions work should additional hosts, services and DNS names be added. Packet Capture on Sophos Firewall helps compare packets before and after NAT; Sophos Firewall IPsec troubleshooting covers the complete tunnel check.

Narrow down errors by symptom

Tunnel is green, but the destination responds locally

The client is probably using the real address, which also exists locally, instead of the remote translated network. Check the DNS response, hosts file, application configuration and destination route. The fault then occurs before the tunnel.

Forward path works, but the return path is missing

Translations must mirror each other on both firewalls. Compare Original and Translated source in the reflexive rule, Remote subnet in the IPsec connection, the server gateway and the rules in the reverse direction. A one-sided translation cannot produce a stable bidirectional flow.

The wrong NAT rule matches

Check NAT Rule ID and order. A broad MASQ, default SNAT or earlier DNAT rule may match before the specific VPN rule. Do not disable all NAT rules speculatively; first correlate the individual test flow by timestamp, then correct only the conflicting rule.

Some hosts work and others do not

With n:n, the original and translated ranges must have equal sizes and positions. Check IP range objects, subnet masks, excluded addresses, host firewalls and the offset actually addressed. Success for .10 does not prove the mapping for the entire range.

Rollback and operations

Before the change, prepare a configuration backup, screenshots or exports of the tunnel, NAT, firewall and routing configuration, and independent management access. During migration, disable old rules only when a clear rollback has been documented.

If validation fails, disable the new NAT rules and routes, restore the previous tunnel configuration and retest the original local traffic. Remove translated networks from DNS, monitoring and documentation only after no dependency remains.

In operation, manage the translated networks in the central IP address plan. Check new sites, cloud networks, remote-access pools and home networks against both original and translated networks. Otherwise, the overlap merely moves elsewhere.

Frequently asked questions