How to Connect VPCs with Overlapping CIDRs

June 16, 2025

Overlapping CIDRs and the Future of VPC Connectivity

TLDR:

  • CIDR Basics: CIDR (Classless Inter-Domain Routing) defines IP address ranges crucial for networking like VPCs and subnets.
  • Challenges of Overlapping CIDRs: Common IP ranges like 10.0.0.0/16 cause connectivity issues when VPCs share them.
  • Current Workarounds: Solutions include NAT gateways, re-IPing VPCs, proxying traffic, or avoiding connections altogether.
  • Future with noBGP: noBGP offers encrypted tunnels, policy-controlled routing, and service-level identity, enabling VPC connections despite CIDR conflicts.
  • Advantages: Eliminates subnet planning and migration projects, adapting to modern, distributed network needs without compromising security or scalability.

If you’ve worked in DevOps, IT, or cloud infrastructure, you’ve probably dealt with the headache of overlapping IP ranges. It’s one of the most common blockers when trying to connect VPCs—especially across teams, regions, or organizations.

What should be a simple problem to solve—connecting two networks—becomes an architectural roadblock because of something as mundane as subnet math.

Let’s unpack why this happens, how teams deal with it today, and how modern networking is finally offering a better way forward.

What Is a CIDR?

CIDR stands for Classless Inter-Domain Routing. It’s a way to allocate and define IP address ranges in a network. A CIDR block like 10.0.0.0/16 defines an IP space from 10.0.0.0 to 10.0.255.255. VPCs, subnets, and firewall rules all rely on these blocks to route traffic.

The problem? These blocks don’t just label addresses—they define where data can and can’t go.

So when two VPCs use the same CIDR range (say, both using 10.0.0.0/16), they can’t distinguish each other’s traffic. The network doesn’t know which “10.0.0.5” you mean—and your routing table breaks.

Why Do CIDRs Overlap?

Simple: there are only so many private IP ranges to go around, and nobody owns them.

The most commonly used CIDR blocks—10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12—are reused by nearly every company. Teams spin up VPCs with defaults. Development environments clone production CIDRs. Partners build isolated networks with no coordination. And then comes the day you try to connect two of these worlds—and everything falls apart.

How Teams Manage CIDRs Today

Let’s be honest: the workarounds aren’t pretty.

  1. NAT gateways and translation – You assign fake IPs and NAT them to the real ones. It adds complexity, latency, and pain to debugging.
  2. Re-IP one of the VPCs – Involves downtime, reconfiguration, and risk. Not always possible for legacy systems or third-party apps.
  3. Proxy traffic through a third system – Adds another hop, more surface area, and doesn’t scale well.
  4. Just avoid it – This is more common than you’d think. Teams decide not to connect environments because the overhead is too high.

None of these are scalable. They’re duct tape—sometimes necessary, but never ideal.

The Future: Networks Without Subnet Collisions

Imagine if you could connect VPCs—even with overlapping IPs—without caring about their CIDR blocks.

That’s what noBGP makes possible.

Instead of relying on IPs and routing tables, noBGP identifies services and workloads by service-level identity. Traffic isn’t routed based on “10.0.1.1 talks to 10.0.2.2”—it’s routed from Service A to Service B, even if both are in VPCs using the exact same IP ranges.

Here’s how:

  • 🔒 Encrypted tunnels between endpoints (bridges), even across clouds and regions
  • 🚫 No exposure of public IPs, no BGP announcements, and no shared address resolution
  • 🧠 Policy-controlled routers that enforce rules like region locking, latency-based routing, and access control
  • Works regardless of CIDR conflicts, NATs, or cloud vendor limitations

This means no subnet planning meetings. No re-IP migration projects. No compromise.

Why It Matters

Every year, companies become more distributed—multi-cloud, multi-region, multi-team. The idea that we can carefully plan and coordinate every IP block across all of those environments is fantasy.

You need a network model that embraces collisions, not one that collapses under them.

Let Go of the Past

We accepted the IP model because it’s what the internet gave us. But we’re not bound to it forever.

Service identity. Private networks. Deterministic paths. These are the building blocks of a modern, programmable network—one that works how your team actually builds and scales today.

Because just because we did something a certain way in the past, doesn’t mean we have to live with that forever.

FAQ:

Q: What causes CIDR overlap issues in VPCs?

A: CIDR overlap occurs when multiple VPCs or networks use the same IP address range, such as 10.0.0.0/16. This can happen due to default settings in cloud environments or when different teams set up networks without coordination.

Q: How can CIDR overlap impact network connectivity?

A: CIDR overlap prevents proper routing between networks because the routing tables can’t distinguish between overlapping IP addresses. This leads to traffic being misrouted or blocked altogether, disrupting communication between services.

Q: What are common solutions to CIDR overlap problems?

A: Common solutions include NAT gateways for address translation, re-IPing one of the VPCs to a non-overlapping CIDR, proxying traffic through an intermediary system, or avoiding connectivity altogether between conflicting networks.

Q: How does noBGP address CIDR overlap challenges?

A: noBGP uses service-level identities instead of IP addresses for routing, enabling seamless connectivity between VPCs with overlapping CIDRs. It eliminates the need for subnet reconfiguration or NAT by focusing on logical service routing.

Reinventing networking to be simple, secure, and private.
Register your free account now