By Yair Knijn · February 13, 2026

The site-to-site VPN to your biggest customer failed because you both use 192.168.0.0/16

The contract is signed, the integration window is booked, and the NetOps lead spins up a site-to-site IPSec tunnel to the customer's data center. Phase 1 negotiates. Phase 2 negotiates. The tunnel shows up. Then the first ping into their app server times out, and so does every one after it. The wrong assumption was made weeks earlier: that two private networks could be bridged without first asking whether they share address space. They both default to 192.168.0.0/16, and now a routine connection is a remediation project.

This is the most boring failure mode in inter-org networking and it blocks more deals than any cipher mismatch. The CIDR overlap check is the cheapest pre-flight step in partner onboarding, and it is the one most often skipped because the tunnel coming up feels like success.

Why the tunnel comes up but the traffic doesn't

The control plane and the data plane fail at different layers, which is what makes this confusing. IKE builds the tunnel using your public endpoints, so a green Phase 2 only proves the two firewalls agreed on encryption and a set of proxy IDs. It says nothing about whether a packet can find its destination once it's inside. When your host wants to reach 192.168.10.20 on their side, its own routing table already claims that prefix as local. The packet never leaves for the tunnel. It gets ARPed onto your LAN, where nothing answers.

So the symptom is a healthy tunnel with zero useful traffic. No alarm fires, because nothing is technically broken. The collision lives in the routing decision, and both sides made the same mistake independently.

Overlapping private space: the partner-VPN failure mode

RFC 1918 handed everyone the same three blocks, and most networks gravitate to 10.0.0.0/8 or 192.168.0.0/16 at the edges. The IETF documented the consequences directly in RFC 5684, which describes how NAT deployments with overlapping address space produce connectivity that looks plausible and then quietly fails. The same dynamic shows up every time two companies that built independently try to route to each other, and it is routine after an acquisition where both inherited identical default subnets.

The check that prevents all of it takes seconds: enumerate the prefixes each side advertises into the tunnel and confirm the sets are disjoint. If 192.168.10.0/24 appears on both inventories, you have your answer before a single Phase 1 packet is sent.

Dual NAT and the ongoing cost of papering over collisions

When you can't renumber either side under deadline, the field fix is NAT, often dual NAT, where each network presents the other a translated range it doesn't actually use locally. Their 192.168.10.0/24 becomes 100.64.10.0/24 to you, yours becomes something else to them, and the firewalls rewrite addresses in both directions. It works. It is also a permanent tax.

Every translated flow now carries costs you'll pay for the life of the integration:

• Applications that embed IP literals in their payload, like some SIP, FTP, and Kerberos flows, break unless a protocol-aware helper rewrites the body too.
• DNS has to answer with translated addresses for that peer, so you maintain split-horizon views per partner.
• Every incident traceroute now reads in two address spaces, and on-call has to hold both maps in their head at 3am.
• The translation tables become undocumented load-bearing config that no one dares touch.

Pre-flight CIDR overlap checks as a partner-onboarding gate

The fix is procedural, not technical. Make an overlap check a required gate before any partner or customer tunnel is provisioned, the same way you'd gate on a firewall change ticket. You need an authoritative list of which prefixes you actually use, the peer's advertised prefixes in writing, and a deterministic comparison. The expensive part is the first item: most teams can't produce a current, trustworthy list of their own allocations on demand, which is exactly why the collision surfaces during the integration instead of before it.

Spot IPAM keeps each customer Environment's allocations reconciled against what DHCP and DNS actually serve, so when a partner sends their ranges you can run the overlap check against ground truth instead of a stale spreadsheet. The integrations that survive onboarding are the ones where both sides knew their own address space cold before the tunnel ever came up. See how the overlap and reconciliation checks work in features.