Merging two Azure estates whose hub VNets both use 10.0.0.0/16
Tailspin Toys runs a hub-and-spoke Azure estate: hub VNet 10.0.0.0/16 holding an Azure VPN Gateway, Azure Firewall, and a FortiGate NVA used for east-west inspection, peered to 14 spoke VNets. Tailspin has just acquired Adventure Works, whose entire estate - its own hub at 10.0.0.0/16 plus 9 spokes numbered from 10.1.0.0/16 - uses the identical hub range and is connected to its own datacenter by ExpressRoute. Both companies must reach a shared SAP system in Tailspin's on-premises network, and Adventure Works workloads must reach Tailspin's shared services VNet. All inter-spoke traffic in both estates must be inspected by a FortiGate. Application teams refuse to re-IP any production workload, and there are 6 weeks before the shared SAP go-live.
1. Explain how you will resolve the address overlap so both companies can reach the shared SAP system without re-IPing workloads, including why the obvious peering-based design fails.
Read the worked answer
The obvious design - peer the two hubs and route everything through a FortiGate - fails for a hard platform reason: Azure VNet peering cannot be created when the address spaces overlap, and even if it could, two 10.0.0.0/16 prefixes in the same routing domain would be indistinguishable. The same collision happens on ExpressRoute: Tailspin's on-prem sees 10.0.0.0/16 for its own hub and for Adventure Works' hub, so the SAP return path is ambiguous.
So the design must introduce address translation at a controlled boundary:
- Keep the two hubs completely separate (no direct peering between them). Each hub peers only to its own spokes and to a small transit VNet with a non-overlapping range (for example 172.20.0.0/24) that hosts the inspection FortiGates.
- Run the FortiGate pair with one VDOM per company, each VDOM's interface addressed inside that company's own space, and a third VDOM or interface on the transit range. Cross-company traffic is SNATed at the FortiGate so Adventure Works sources appear as a unique 172.20.x range toward Tailspin and toward SAP, with DNAT on the return.
- For SAP, source-NAT at the FortiGate facing the ExpressRoute gateway so on-prem sees a single unambiguous prefix; distribute only the translated range into the on-prem routing domain.
- Document the translation table as a first-class artifact - it becomes the thing every future troubleshooting call depends on.
The residual risk to flag to the steering committee: NAT breaks end-to-end source-IP logging and some Kerberos/application assumptions, so the long-term fix is a re-IP programme on the hub and datacenter only, not on workloads.
2. Define the route tables, UDRs, and peering options needed so spoke-to-spoke and spoke-to-on-prem traffic is inspected, while spoke traffic to a private endpoint stays local and no routing loop occurs.
Read the worked answer
Build it in three layers and test each independently.
1. Spoke subnets. Add a UDR on the workload subnets with:
- other spokes' prefixes → next hop Virtual appliance = FortiGate internal IP in the hub;
- on-prem prefixes → next hop Virtual network gateway (spoke peering must have
useRemoteGateways=true, hub peeringallowGatewayTransit=true); - the private-endpoint subnet's range → next hop Virtual network so PaaS traffic from the spoke addresses the endpoint directly instead of hair-pinning through the NVA.
2. NVA subnet. IP forwarding must be enabled on the FortiGate NICs. The FortiGate subnet's own route table must not contain the 0.0.0.0/0-to-NVA route or a route matching the hub range pointing at itself - that is the classic loop. The GatewaySubnet route table must also never point at the NVA for on-prem prefixes, or ExpressRoute traffic will bounce.
3. Asymmetry check. Peering gives a direct return path, so if the spoke sends traffic to the NVA but the far side replies directly, FortiGate drops the half-open flow as an asymmetric session. Fix by putting the mirror UDR on the destination spoke's subnet for the source spoke's range, so both directions traverse the same NVA instance. Validate with a packet capture on both FortiGate interfaces and with Network Watcher next hop from each subnet.