IPsec Up but Branch Subnet Overlaps HQ
Headquarters uses a FortiGate 300F with LAN 10.10.0.0/16; the subnet 10.10.20.0/24 is a local VLAN for the HQ lab. A branch FortiGate 60F uses 10.10.20.0/24 for its user LAN. A route-based IPsec tunnel connects the two, with phase 2 selectors 0.0.0.0/0 on both ends, and static routes point HQ 10.10.0.0/16 and branch 10.10.20.0/24 across the tunnel. Phase 1 and phase 2 are up. Branch users can reach the HQ server at 10.10.1.10, but HQ users cannot reach the branch PC at 10.10.20.10; pings from HQ resolve to the local lab VLAN. Remote SSL VPN users receive 10.212.134.0/24 and need access to the branch PC. No BGP is used. The administrator wants to preserve the branch subnet on the branch and avoid readdressing.
1. Explain the routing and NAT problem. Why does HQ traffic never enter the tunnel?
Read the worked answer
HQ has a connected route for 10.10.20.0/24 because that subnet is a local lab VLAN. A connected route wins over a static route to the same prefix, and HQ also has no reason to prefer the tunnel for an address it believes is locally attached. When an HQ user pings 10.10.20.10, the packet is routed to the local lab VLAN, not to the IPsec tunnel, so the branch never sees it.
Branch-to-HQ works because the branch route to 10.10.0.0/16 points into the tunnel and HQ does not have an overlapping connected route for the branch's source address in that direction. The overlap is the core problem: the same 10.10.20.0/24 exists on both sides. NAT is needed to present the branch subnet as a unique range before it enters HQ routing.
2. Propose a NAT design that preserves branch addressing and supports HQ and SSL VPN access. Include the address ranges and policy direction.
Read the worked answer
Translate the branch LAN 10.10.20.0/24 to a unique range such as 10.250.20.0/24 before traffic reaches HQ. On the branch, apply source NAT on the IPsec policy from 10.10.20.0/24 to HQ and SSL VPN destinations, translating to 10.250.20.0/24. Add branch routes for HQ 10.10.0.0/16 and SSL VPN 10.212.134.0/24 through the tunnel.
On HQ, add a route for 10.250.20.0/24 through the tunnel. Apply destination NAT on the HQ-to-branch policies so traffic to 10.250.20.0/24 is translated to 10.10.20.0/24 before entering the tunnel. That includes HQ LAN and SSL VPN source policies. The branch return policy must allow the translated source to reach the branch LAN. Use central NAT or VIPs consistently and verify that no policy route sends 10.250.20.0/24 to the local lab.
3. What verification steps confirm both directions and SSL VPN access?
Read the worked answer
Check the HQ routing table for 10.250.20.0/24 via the tunnel and confirm no competing connected or static route. From HQ, ping 10.250.20.10 and run a debug flow to see destination NAT to 10.10.20.10 and egress through the tunnel. From an SSL VPN client, do the same and capture packets on both FortiGates to confirm the source is 10.212.134.x, the translated destination is 10.10.20.10, and return traffic is translated back.
Check session lists on HQ and branch for NAT flags, and verify IPsec phase 2 selectors still cover the translated ranges, ideally 0.0.0.0/0 on both ends. Inspect firewall policies for the SSL VPN and HQ LAN directions, and confirm the branch policy permits the translated source. If pings fail, test TCP as well, because ICMP may be blocked by a policy even when NAT is correct.