FortiGate IPsec with Overlapping Subnets: NAT and Selectors

Give each remote site a unique translated subnet

Example: both sites use 10.60.0.0/24. A is represented across the tunnel by 192.0.2.0/24 and B by 198.51.100.0/24. These are documentation prefixes; reserve suitable non-overlapping ranges for a real deployment.

Clients address the remote service through its translated range. A DNS record pointing to the overlapping real address sends the client toward its own LAN. Fortinet’s overlapping-subnet design.

Create the tunnel with translated selectors

This example uses FortiOS 7.4.4 GUI fields. Both FortiGates already have a reachable WAN on wan1, a LAN on port2 with gateway 10.60.0.1/24, and policy NAT (central NAT disabled). Hosts use their local FortiGate as the gateway. A’s example public address is 203.0.113.10; B’s is 203.0.113.20. Replace these documentation addresses and interface names for deployment. The translated prefixes must not overlap any existing routed network, interface, VIP or pool.

At each site open VPN → IPsec Wizard, choose Custom and create the tunnel below. In its network settings select wan1 and the opposite site’s public IP. Use the same securely shared PSK, select IKEv2 and agree on the same phase 1 proposal/DH and phase 2 proposal/PFS at both peers. For example, if both peers permit AES256/SHA256 and DH14, select those values for phase 1 and phase 2 and enable PFS with group 14.

If these sites already have a suitable route-based tunnel, edit that existing tunnel’s phase 2 selectors instead of creating duplicate phase 1 objects. Save matching selector changes at both ends in the same change window; they interrupt affected traffic until NAT and policy are ready.

Route the remote translated range

Under Network → Static Routes → Create New, create A’s route to 198.51.100.0/24 on to-B and B’s route to 192.0.2.0/24 on to-A, with administrative distance 10. No gateway address is required for these IPsec interfaces.

Add a second route for the same remote prefix at each site with Interface: Blackhole and Administrative Distance: 200. The fallback drops remote traffic if the VPN route disappears.

Create the addresses and paired NAT mappings

Complete these objects at both sites before creating their policies. The host ranges end in .1–.254 on both sides of each mapping, so a host keeps its last octet.

1. Open Policy & Objects → Addresses → Create New → Address. Create local-real as IP/Netmask 10.60.0.0/24, interface port2. Create remote-translated as 198.51.100.0/24 on to-B at A, and 192.0.2.0/24 on to-A at B.
2. Open Policy & Objects → IP Pools → Create New. Name the pool local-translated, choose Fixed Port Range and set Internal IP Range to 10.60.0.1–10.60.0.254. Set External IP address/range to 192.0.2.1–192.0.2.254 at A or 198.51.100.1–198.51.100.254 at B. An overload pool does not supply this paired host mapping.
3. Open Policy & Objects → Virtual IPs → Create New → Virtual IP. Name it translated-to-local and bind Interface to the local VPN tunnel. Set External IP address/range to the same range as that site’s pool, and Map to IPv4 address/range to 10.60.0.1–10.60.0.254. Leave Port Forwarding disabled; this maps the address range. The firewall policy will limit services.

Permit the two initiation directions

At each site, open Policy & Objects → Firewall Policy → Create New and create the two policies below. Set Action: ACCEPT, Schedule: always, and Service: PING for this reachability example; add only the required application services afterward. Enable Log Allowed Traffic: All Sessions for the initial test.

Move these permits ahead of any earlier rule matching the same traffic that would deny it or apply the wrong NAT. The VPN-to-LAN policy must use the VIP as its destination, not the real-LAN address object. It permits new sessions from the remote site; replies use the original session’s reverse translations.

Verify both directions and DNS behavior

Under Dashboard → Network, expand the IPsec widget and confirm both tunnels are up; use Bring Up if needed. From A’s 10.60.0.10, ping B’s translated host 198.51.100.20. From B’s 10.60.0.20, ping A’s translated host 192.0.2.10. Allow ICMP in the test hosts’ firewalls.

In Log & Report → Forward Traffic, filter the test addresses and open each session’s details. Check the policy ID, interfaces and source/destination NAT fields against the four-address table above. If a translation or policy is wrong, edit that site’s specific pool, VIP or policy and start a new test session. For a missing session, use the flow trace and route checks.

If an application redirects to an overlapping real address, correct its advertised endpoint or DNS rather than expanding selectors.

Publish the remote service’s translated address in the DNS view used by the opposite site. For example, A’s record for B’s test host must resolve to 198.51.100.20.