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.0.2.0/24. Each side receives its own virtual network for the tunnel:

HQ real:            192.0.2.0/24  → visible to branch as 198.51.100.0/24
Branch real:        192.0.2.0/24  → visible to HQ as 203.0.113.0/24

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

The three networks come from the IPv4 blocks reserved for examples by RFC 5737 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

Under Hosts and services > IP host > Add, policy-based IPsec requires three network 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.0.2.0, HO_LAN_NAT_198.51.100.0 and BO_LAN_NAT_203.0.113.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:

• Activate on save: enabled
• Create firewall rule: enabled
• Local subnet: HO_LAN_NAT_198.51.100.0
• Remote subnet: BO_LAN_NAT_203.0.113.0
• Network address translation (NAT): enabled
• Original subnet: HO_LAN_REAL_192.0.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

This role assignment is particularly useful when the branch has a dynamic IP address and head office has no reliably addressable peer to initiate a connection to: the branch then initiates toward the reliably reachable head-office endpoint. A dynamic address is not an absolute obstacle, however, if the peer address can be resolved reliably and the design allows head office to initiate. As more branches are added, connection establishment scales better when each branch retries its own connection rather than head office having to retry every branch connection.

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

• Activate on save: enabled
• Create firewall rule: enabled
• Local subnet: BO_LAN_NAT_203.0.113.0
• Remote subnet: HO_LAN_NAT_198.51.100.0
• Network address translation (NAT): enabled
• Original subnet: BO_LAN_REAL_192.0.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. Place these VPN rules above any broader conflicting rule, then 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.

Establish the connection when needed

Check the tunnel status only after both sites are configured and the firewall rules have been reviewed. Activate on save activates the configuration entry but does not prove that the tunnel is established. If the tunnel is not yet established and manual establishment is needed, go to Site-to-site VPN > IPsec on the initiating side – the branch in this example – and click the status button in the Connection column for the relevant connection.

Do not disconnect or re-establish an existing production SA for this step; no such click is required at the responding head office. A green connection indicator confirms tunnel establishment, not a working data path: next, perform the service, Child SA and capture checks described below in both directions.

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. This is a separate procedure documented by Sophos and must not be mixed with the DNAT/SNAT rules for Any-to-Any.

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 203.0.113.0/24
• Translated source: Original
• Original destination: head-office translated network 198.51.100.0/24
• Translated destination: real head-office network 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• 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 198.51.100.0/24 and use the branch translated network 203.0.113.0/24 as Original destination.

NAT at the branch

Mirror the same principle at the branch:

• Original source: head-office translated network 198.51.100.0/24
• Translated source: Original
• Original destination: branch translated network 203.0.113.0/24
• Translated destination: real branch network 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: enabled
• Load balancing method: One-to-one

The reflexive rule must translate the real branch network outbound to 203.0.113.0/24. Any for both interfaces is intentional in this documented pattern; do not replace it with WAN merely because IPsec uses a WAN peer. The translated-address objects and the firewall rules provide the narrow scope. A more general SNAT or MASQ rule above these rules must not capture the traffic first.

SFOS matches a NAT rule on the original, pre-NAT source, destination and service and on the inbound and outbound interfaces. It applies NAT only to the first packet of a connection, so every test after a NAT edit must use a new connection (a new five-tuple). 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.

Match the Any-to-Any firewall rules exactly

A NAT rule does not allow traffic. Under Rules and policies > Firewall rules > Add firewall rule > New firewall rule, create narrowly scoped rules for each required direction. At head office, use these mappings:

• outbound: Source zone LAN, Source network real head-office network, Destination zone VPN, Destination network branch translated network;
• inbound: Source zone VPN, Source network branch translated network, Destination zone LAN, Destination network real head-office network;
• set Services only to the business service under test and turn on Log firewall traffic for acceptance testing.

Mirror head office and branch at the branch firewall. The different destination objects are intentional: for outbound traffic, SFOS evaluates the firewall rule before SNAT. For inbound traffic, it resolves DNAT first and then evaluates the firewall rule against the translated destination and its zone. This NAT processing order therefore determines the rule objects.

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. Check the established connection under Current activities > IPsec connections and IPsec usage under Reports > VPN. Under Diagnostics > Packet capture > Configure, a BPF string such as host 203.0.113.10 limits capture to the test host. 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. In Packet Capture, In interface, Out interface, NAT ID, Rule ID, Status and Reason show ingress, translation, XFRM egress and the return path.
5. The destination server sees the planned source address and replies over the same path.

As a negative control, address the identical real address 192.0.2.10: it must remain local and must not appear on the XFRM interface in the capture. Only after the positive and negative tests produce the planned result in both directions 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. Also record the names, IDs, order and enabled state of every affected rule and route, together with the previous DNS and application values. During migration, disable old rules only after their exact previous state is recorded.

If validation fails, first restore the recorded DNS and application values. For Any-to-Any, disable only the newly created firewall rules, DNAT/reflexive-SNAT pair and translated-network route. For policy-based IPsec, restore the saved Local, Remote and Original subnet fields. Then restore previous rules and routes to their original order and enabled state, and test new connections in both directions. Existing sessions retain their first-packet NAT mapping and are not proof of rollback: let unrelated sessions continue, and if immediate proof is required, terminate only the affected test sessions before retesting. Do not flush all connections. Remove XFRM addresses and objects only after Object usage shows no remaining dependency. 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