Kernaali ToolsWhen both sites use the same LAN prefix, routing the other site’s real address cannot distinguish it from a local host. Either renumber deliberately or present each site through a distinct translated prefix. A broad NAT checkbox or a 0.0.0.0/0 selector does not by itself solve that identity conflict.
Applies to: FortiGate-to-FortiGate route-based IPv4 IPsec, FortiOS 7.4.4 documentation, policy NAT with source pools and destination VIPs. Equal-sized, non-overlapping translated ranges are assumed. Central NAT, IPv6 translation and applications embedding literal private addresses need a separate design.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Define four address identities before touching policies
Synthetic topology: both sites use 10.60.0.0/24. Site A presents its hosts as 192.0.2.0/24 across the VPN; site B presents its hosts as 198.51.100.0/24. These documentation prefixes are only an example: an actual deployment must reserve non-overlapping translated ranges throughout its routing domain.
| Location in one A-to-B flow | Source | Destination |
|---|---|---|
| A client before translation | 10.60.0.10 | 198.51.100.20 |
| Inside the tunnel after A source translation | 192.0.2.10 | 198.51.100.20 |
| B LAN after B destination translation | 192.0.2.10 | 10.60.0.20 |
| Reply as seen by the A client | 198.51.100.20 | 10.60.0.10 |
This is an original address walk-through, not captured output. The FortiOS overlapping-subnet guide uses distinct virtual networks and requires users to address the remote site through its translated range. Plan DNS names accordingly; a name resolving to the overlapping real address still points the client toward its own LAN.
Align selectors, routes and translations
On A, the phase 2 local/remote identities for this design are A’s translated prefix and B’s translated prefix; on B, those roles reverse. Route the remote translated prefix through the intended tunnel, and review the documented fallback blackhole design so tunnel failure does not send that range toward an unrelated default route. See phase 2 selectors and routing behavior.
Create a private mapping table for the source-pool and VIP ranges at each site. Their host ranges and mapping behavior must agree. The official example uses fixed-port-range pools and matching VIP ranges; do not assume an arbitrary overload pool provides the same one-to-one identity. Check that no chosen translated address is already owned by another interface, pool or VIP.
Review policy using the address visible at that stage
| Policy direction | Design check |
|---|---|
| A LAN → tunnel | Real A source, translated B destination, intended service and A source pool |
| Tunnel → B LAN | Translated A source, B destination VIP, intended service and no accidental second source translation |
| New sessions initiated by B | Mirror the design deliberately; replies alone do not prove B can initiate |
| Management and unrelated VPN traffic | Keep outside the translation scope unless explicitly required |
Use only the needed service rather than copying the documentation example’s ALL service. Inspect existing policy order and NAT mode before adding entries. This guide supplies a review model, not a full paste-ready configuration: the correct interface bindings and dependencies belong to the actual deployment.
Validate one application and plan rollback at both sites
Stage on an isolated authorized target or use a coordinated maintenance window with independent management. Record every old selector, route, pool, VIP and policy value. Test one A client against B’s translated service address, verify the pre/post-NAT source and destination, and confirm the server reply returns through B. Then test the intended B-initiated flow and a disallowed service.
Check application payloads and DNS separately if TCP connects but the application redirects to a real overlapping address. Success is the completed application task with the intended identity, not a green tunnel or a successful address-list comparison.
For rollback, stop the test flows, restore the recorded policies/routes/selectors at both ends, and remove only the new translation objects after their references are removed. Restore the previous DNS records if changed. Do not leave one side translated and the other side reverted, or clear every firewall session to force convergence.
Check prefix overlap before selecting virtual ranges · Non-overlapping new-subnet diagnosis
Technical references
Found an issue? Send a correction with a reproducible example.