VSX Partition with Duplicate Partner Subnets
A 26000 appliance runs VSX with VS0 management, VS1 internal (10.10.0.0/16), VS2 DMZ (172.20.0.0/16), and VS3 for a new logistics partner. The partner insists on using 10.10.0.0/16 and 192.168.50.0/24 on its side; HQ already uses 10.10.0.0/16 internally and 192.168.50.0/24 for a branch. VS3 has one 1GbE external link to the partner and must exchange traffic with VS1's ERP server at 10.10.5.20. The customer will not re-IP either side and will not allow dynamic routing between VS1 and VS3. There is a single default route in VS0 to the internet; VS1 and VS3 each have their own default routes to different ISPs. The partner requires IKEv2 and a single tunnel for both subnets. No traffic may leak between VS1 and VS3 except ERP.
1. Can VSX support overlapping subnets in VS1 and VS3? Explain the routing and ARP isolation implications.
Read the worked answer
Yes, VSX can support overlapping IP spaces because each Virtual System has its own routing table, ARP table, and NAT domain. VS1's 10.10.0.0/16 and VS3's partner-facing 10.10.0.0/16 do not automatically conflict at the VSX layer. The danger is assuming that isolation alone solves reachability.
VS3 will have a route for 10.10.0.0/16 pointing to the partner. It therefore cannot also resolve 10.10.5.20 as an internal ERP address through the same table. VS0 does not route between VSs by default, and the two VSs have different ISP defaults. You need an explicit internal path, such as a dedicated virtual router interface or a /32 route for 10.10.5.20 that points to VS1, plus NAT so the partner sees a unique ERP address. Without that, traffic from the partner to the ERP will be sent back toward the partner, and return traffic will be asymmetric.
2. Design the NAT and VPN domain for VS3 so the partner can reach the ERP without leaking the duplicate /16 into HQ.
Read the worked answer
Use NAT at the VS3 boundary and keep the partner's duplicate range out of VS1.
- In VS3, translate the partner source 10.10.0.0/16 to a unique range, for example 172.30.0.0/16.
- Publish the ERP to the partner as a unique static NAT address, for example 192.168.100.20 translated to 10.10.5.20. Add a /32 route on VS3 for 10.10.5.20 through the internal virtual-router path to VS1, not through the partner default.
- On VS1, add a return route for 172.30.0.0/16 through the same internal path. Do not redistribute the partner /16 into VS1 or the lab.
- Set the VS3 VPN encryption domain to the translated addresses: 172.30.0.0/16 and 192.168.100.20. Do not include 10.10.0.0/16 in the tunnel domain, or the ASA will negotiate a child SA for the duplicate range and Check Point may match it to the internal network.
- Use manual NAT with a VPN match so the translation occurs before encryption. Build one IKEv2 tunnel with both translated subnets, and add static routes only for those prefixes. This preserves the no-leak requirement and avoids dynamic routing between VS1 and VS3.
3. What would you verify before and after enabling the tunnel, and what is the main failure mode to watch?
Read the worked answer
Before enabling, verify VS3's routing table has no ambiguous 10.10.0.0/16 path, the /32 ERP route points to the internal virtual router, and NAT rules are hit only for VPN traffic. Confirm VS1 has a return route for 172.30.0.0/16 and no route for the partner's 192.168.50.0/24. Check that the encryption domain contains translated addresses only.
After enabling, use vpn tu and IKEv2 debug to confirm one child SA for both subnets, not a separate SA for 10.10.0.0/16. Test partner-to-ERP with a source in 10.10.1.0/24 and confirm the log shows source NAT to 172.30.x.x and destination NAT to 10.10.5.20. Test ERP-to-partner return traffic. Run fw monitor on VS3 to verify the packet does not exit toward the partner default after destination NAT.
The main failure mode is a more-specific route or NAT rule causing the duplicated /16 to prefer the partner path. A secondary risk is asymmetric return through VS1's ISP default. Monitor for that with TCP resets and route-lookup logs.