I85PREP
⌘ K
Fortinet NSE 7 study materials
Fortinet NSE 7 study resources

Overlapping server subnets across an acquisition IPsec tunnel

Fortinet NSE 7 · Put your knowledge to work in context.

All case studies

Overlapping server subnets across an acquisition IPsec tunnel

Both Meridian HQ and the acquired site use 10.10.20.0/24 for their server VLANs: HQ has the domain controller 10.10.20.10, and the site has the ERP server 10.10.20.50. A route-based IPsec tunnel between the two FortiGates is up with 0.0.0.0/0 phase2 selectors, and HQ users need the site ERP while site users need the HQ domain controller. Today, an HQ user opening 10.10.20.50 reaches the local domain controller instead, and the site's users cannot reach 10.10.20.10 at all. A junior engineer proposed adding a static route for 10.10.20.0/24 on HQ pointing at the tunnel. The two sites have no other overlapping subnets.

1. Explain why the proposed static route will not work, and what it would do to HQ's own server VLAN if forced.

Read the worked answer

The destination prefix is identical on both sides, so there is no routing decision that can distinguish them.

Why the static route fails

  • The connected route for 10.10.20.0/24 on HQ has administrative distance 0. A static route for the same prefix has a higher distance and is never installed while the connected route exists.
  • Even if the static route were forced in with a lower distance or by removing the connected route, HQ would then send all 10.10.20.0/24 traffic into the tunnel, including traffic for its own domain controller and any local server, breaking HQ's own server VLAN.
  • Both sites believe 10.10.20.x is local. ARP for 10.10.20.50 on HQ resolves to a local MAC, so packets never even reach the routing table in a way that could be redirected.

The deeper point This is an addressing collision, not a routing problem. Routing can only choose between distinct destinations; it cannot give one address two meanings. The fix must change the addresses that one side uses on the wire, which means NAT on the tunnel.

2. Design the NAT and routing scheme so both directions work, including what each side's policy and phase2 must contain.

Read the worked answer

Use shadow ranges so each side sees the other's servers under addresses that do not overlap.

Shadow ranges

  • 10.99.20.0/24 represents 'the remote site's servers' on both sides.
  • 10.99.10.0/24 represents 'the remote side's clients' on both sides.

HQ to site ERP (10.10.20.50)

  1. HQ: destination NAT at HQ will not work, because after translation the destination 10.10.20.50 is local to HQ. Instead HQ routes 10.99.20.0/24 into the tunnel and sends traffic to 10.99.20.50.
  2. HQ policy LAN to tunnel: source NAT 10.10.0.0/16 to 10.99.10.0/24, so the site's replies do not collide with its own 10.10.x addresses.
  3. Site: VIP 10.99.20.50 maps to 10.10.20.50; policy tunnel to LAN matches the VIP, destination-NATs, and allows the flow.
  4. Site: static route 10.99.10.0/24 via the tunnel, so return traffic to HQ's translated clients goes back through IPsec.

Site to HQ domain controller (10.10.20.10) Mirror the design: the site sends to 10.99.20.10 with source NAT to 10.99.10.0/24; HQ destination-NATs 10.99.20.10 to 10.10.20.10 and routes 10.99.10.0/24 back into the tunnel.

Phase2 0.0.0.0/0 selectors already cover 10.99.0.0/16. If selectors are narrowed later, they must include both the real and shadow ranges, or the tunnel will drop the translated traffic even though routing is correct. Verify with diagnose vpn tunnel list that both selectors are installed.

3. What kinds of traffic will still misbehave under this design, and how would you handle them?

Read the worked answer

Anything that embeds IP addresses inside the payload breaks, because NAT rewrites headers only.

Likely failures

  • SIP/SDP: the SDP body advertises the real 10.10.20.x address; the media path then points at an address that means something different on the far side. SIP ALG can help only if it is enabled on both policies and understands the flow.
  • FTP active mode and some legacy file transfer tools: the PORT command carries an IP address.
  • DNS and LDAP: records and referrals return real internal names and addresses, so clients resolve to 10.10.20.x and bypass the shadow range.
  • HTTPS redirects and application links that contain internal hostnames.

Handling

  1. Prefer to re-IP the smaller site. Overlapping-subnet NAT is a workable bridge but accumulates exceptions; schedule a renumbering project with the shadow design as the interim.
  2. For DNS, use conditional forwarding or split DNS so each side resolves the other's names to the shadow addresses.
  3. Enumerate SIP and other embedded-IP applications before cutover and test each one; do not assume the ALG fixes every vendor's implementation.
  4. Document the shadow ranges in the address objects and keep destination NAT on the receiving side, not the sending side, so the translated destination is always local to the FortiGate doing the translation.