Overlapping Subnets After Branch Acquisition
Your FortiGate (FGT-HQ) has an internal interface on 10.10.0.0/16 and a site-to-site IPsec tunnel to a newly acquired branch whose LAN is also 10.10.0.0/16. The branch FortiGate advertises its LAN over the tunnel. Users at HQ cannot reach a critical server at 10.10.5.20 on the branch side; pings instead reach the HQ device at that address. You must provide HQ-to-branch access to that single server without renumbering either site, and without breaking existing HQ routing to its own 10.10.0.0/16 resources. Phase 2 selectors on both tunnels currently use 10.10.0.0/16 <-> 10.10.0.0/16.
1. Which FortiGate feature lets HQ reach the branch server at its overlapping address, and how do you configure the selectors and routing?
Read the worked answer
Use VIP with destination NAT combined with policy-based routing / a dedicated tunnel - the standard approach is an IP pool + VIP mapping an unused HQ-side address to the branch host, or more cleanly a second IPsec phase 2 / VDOM pair with NAT. The practical, exam-favored answer:
- Create a VIP on FGT-HQ: external IP = an unused HQ address (e.g., 192.168.250.20), mapped IP = 10.10.5.20, port forwarding as needed.
- Create an IP pool for outbound so return traffic is SNAT'd to a source the branch recognizes.
- Narrow the phase 2 selectors to the specific host (192.168.250.20/32 <-> 10.10.5.20/32) rather than /16-to-/16, so the tunnel only carries the translated flow.
- Add a firewall policy: src=HQ users, dst=VIP, action accept, with the IPsec tunnel as the outgoing interface and NAT enabled using the pool.
Because HQ's own 10.10.0.0/16 routes stay local, only the VIP-mapped address traverses the tunnel; the branch sees traffic sourced from the pool address and destined to 10.10.5.20. This avoids renumbering and preserves existing HQ routing.
2. A colleague suggests simply adding a static route for 10.10.5.20/32 pointing at the tunnel. Why does this fail, and what symptom would you see?
Read the worked answer
A static /32 pointing at the tunnel changes HQ's routing but not the addressing conflict. Two problems:
- Return path / asymmetry: The branch server replies to the HQ source address (still in 10.10.0.0/16), which the branch resolves locally to its own LAN - the reply never enters the tunnel.
- Selector mismatch: If phase 2 is /16-to-/16, the tunnel accepts the flow but the branch's own connected route for 10.10.0.0/16 wins over the tunnel for the return direction.
Symptom: One-way traffic - HQ sees SYN sent, no SYN-ACK; or the ping reaches the HQ device at 10.10.5.20 (local route wins over the more specific static depending on ordering) rather than the branch host. The fix requires address translation (VIP/SNAT) so at least one side sees non-overlapping addresses, not just a route.