What Overlapping IP Ranges Break When You Connect a Private Cloud to AWS

Private IP ranges are reused everywhere by design. Every company, every VPC, and every home router draws from the same few blocks set aside for private networks. That’s fine as long as the networks never need to talk to each other. The moment you connect an AWS VPC to a private cloud, every overlap between them becomes a routing problem.

The fix is easiest before you connect anything. This article covers what breaks, why it’s so common, and how to plan addresses so it doesn’t happen.

Why Overlaps Are So Common

Most overlaps aren’t mistakes. They come from defaults that nobody revisited.

AWS Default VPCs Share One Range

Every AWS region gives each account a default VPC, and the AWS Control Tower documentation notes that the default CIDR range is 172.31.0.0/16. When Control Tower creates VPCs, it assigns the identical range to every VPC for every account in an organizational unit. AWS points out that because of that default overlap, those VPCs can’t initially be peered with each other.

If your AWS workloads started in a default VPC, they’re probably using 172.31.0.0/16, and so is everyone else’s.

Kubernetes Brings Its Own Ranges

Kubernetes clusters use internal ranges for pods and services, separate from the network the nodes sit on. On Amazon EKS, if you don’t choose a service range when you create a cluster, Kubernetes assigns service addresses from either 10.100.0.0/16 or 172.20.0.0/16. The EKS configuration reference recommends choosing a block that doesn’t overlap with networks connected to your VPC, and the setting can only be chosen when the cluster is created.

Pod networks add more ranges on top of that, depending on the network plugin you use.

Other Defaults Pile On

• Container tooling. The Amazon VPC documentation notes that some AWS services use the 172.17.0.0/16 range, which is also a common default for local container networking.
• Office and VPN networks. Many office networks and remote-access VPNs use ranges in 192.168.0.0/16 or 10.0.0.0/8.
• Quick-start subnets. Teams creating networks in a hurry often reach for round numbers like 10.0.0.0/16 or 10.0.0.0/24, on every side.

Put a few of these together and an overlap is close to guaranteed unless someone planned against it.

What Breaks When Ranges Overlap

Traffic Never Leaves the Local Network

When a host sends traffic to an address, its routing table decides where it goes. If the destination falls inside a range the host considers local, the traffic stays local. So if your private cloud subnet is 10.0.1.0/24 and the AWS database you want to reach is 10.0.1.25, the packet never heads for the VPN. It looks for 10.0.1.25 on the local network and either fails or reaches the wrong machine.

Connections Get Refused Outright

Some AWS connectivity options check for overlaps and won’t proceed. AWS won’t create a VPC peering connection between VPCs with matching or overlapping IPv4 CIDR blocks. VPCs associated with a Direct Connect gateway must not have overlapping CIDR blocks either. If your private cloud connects to more than one VPC through the same path, each of those VPCs needs a distinct range.

Some Hosts Work and Others Don’t

Partial overlaps are the hardest to diagnose. If only part of a remote range overlaps a local one, hosts in the non-overlapping part are reachable and the rest aren’t. Teams can spend days on firewall rules and VPN settings before someone compares the address ranges.

Service Discovery Points to the Wrong Place

DNS may return a correct private address for a remote service, but if that address overlaps a local range, the client routes to the local network instead. The name looks right and the connection still fails.

Kubernetes Traffic Collides

If a cluster’s pod or service range overlaps the network on the other side of a hybrid connection, pods may be unable to reach remote services, because their traffic matches an internal cluster route first.

Future Connections Get Harder

Every new environment you add, such as another AWS region, a second private cloud location, or an acquired company’s network, has to avoid every range already in use. An early overlap you worked around becomes a constraint on everything that follows.

How to Fix an Overlap You Already Have

Renumber One Side

Moving one environment to a new, non-overlapping range is the cleanest fix. It’s also the most work: new subnets, redeployed or re-addressed instances, updated firewall rules, DNS, and configuration. It’s often easiest on whichever side is newer or smaller. If your private cloud isn’t in production yet, renumber it now.

Translate Addresses at the Boundary

Network address translation at the connection point can present one side’s hosts to the other under different addresses. It works, but it adds complexity. Logs show translated addresses, troubleshooting gets harder, and applications that embed IP addresses in their payloads or configuration can break.

Expose Only Specific Services

If only a few services need to cross the boundary, a proxy or load balancer with a non-overlapping address can stand in for each one. That limits the overlap’s impact without renumbering everything, though it doesn’t fix the overlap itself.

Keep Kubernetes Ranges Out of the Way

For a Kubernetes cluster, the pod and service ranges are usually set at creation. If they collide with your hybrid ranges, the practical fix is often to build a new cluster with non-overlapping ranges and move workloads to it.

How to Plan Addresses So It Doesn’t Happen

Write Down Every Range in Use

Start with an inventory: every VPC in every AWS account and region, every private cloud network, Kubernetes pod and service ranges, office networks, and remote-access VPN pools. Most overlaps are discovered at this step.

Give Each Environment Its Own Block

Carve the private address space into large, distinct blocks by environment and region, and allocate subnets from inside them. An example plan:

The exact numbers don’t matter. What matters is that no two environments that might ever connect share a range.

Avoid the Defaults

Skip 172.31.0.0/16, 10.0.0.0/16, and the common quick-start ranges for anything that might connect to another environment. Choose Kubernetes service and pod ranges deliberately when you create clusters.

Leave Room to Grow

Allocate more space than you need today for each environment. Expanding a block later is much easier when the neighboring space is still free.

Keep the Plan in One Place

An address plan only works if people use it. Keep it in a shared, version-controlled location and check it before anyone creates a new VPC, subnet, or cluster.

Planning Addresses on OpenMetal

On an OpenMetal private cloud, you choose the private addresses on both layers of the network, so you can match your plan from the start:

• Private IP blocks you create in OpenMetal Central for VLANs connecting your clusters, from /21 down to /32, using addresses from the standard private ranges
• OpenStack VPC networks inside your private cloud, with custom IP ranges and subnets you define

If you’re connecting bare metal and private cloud resources, our guide to running bare metal and a private cloud on one private network covers how those blocks get assigned. To manage them as code, see managing bare metal VLANs and IP blocks as code. For the connection to AWS itself, our documentation covers creating a site-to-site VPN in OpenStack.

How a Deployment Works

Address planning is part of how we bring a new environment online:

• We plan ahead. During scoping, we review the networks your new environment needs to connect to, so the ranges in your private cloud fit your existing plan.
• You decide. You choose the address blocks, how your VLANs and VPC networks are laid out, and how the environments connect.
• We hand over. You get a running environment with the networks you planned, admin access, and a private Slack channel with our engineers for questions as you connect it to AWS.

Before You Connect: A Checklist

• List every VPC, private cloud network, Kubernetes range, office network, and VPN pool
• Confirm no two environments that will connect share any part of a range
• Check Kubernetes pod and service ranges on both sides
• Avoid default ranges for anything that will connect
• Leave room in each block for growth
• Record the plan somewhere everyone can find it

Who This Is For

This is most useful if you:

• Are about to connect a private cloud or bare metal environment to AWS
• Run workloads in default VPCs or with default Kubernetes ranges
• Have a VPN up but intermittent or one-sided connectivity
• Expect to add more regions, locations, or acquired networks over time

It’s less relevant if you:

• Run a single environment that will never connect to another
• Already maintain a company-wide address plan that everyone follows

The Short Version

Overlapping private IP ranges don’t announce themselves. They show up as connections that are up but don’t work. Inventory your ranges, give every environment its own block, and settle the plan before you connect anything.

If you’re planning a private cloud that will connect to AWS, talk with our team about your network design, or apply for a proof of concept to test the connection on real hardware.

Frequently Asked Questions

Why can’t my private cloud reach AWS when the VPN is up?

A common cause is overlapping private IP ranges. If the address you’re trying to reach falls inside a range your host considers local, traffic never goes to the VPN.

What IP range does an AWS default VPC use?

AWS default VPCs use 172.31.0.0/16. Because every default VPC uses the same range, it overlaps with any other network using it.

Can AWS peer VPCs with overlapping ranges?

No. AWS won’t create a VPC peering connection between VPCs with matching or overlapping IPv4 CIDR blocks. VPCs associated with a Direct Connect gateway also can’t overlap.

Do Kubernetes clusters cause IP overlaps?

They can. Clusters use internal ranges for pods and services. On Amazon EKS, service addresses default to 10.100.0.0/16 or 172.20.0.0/16 if you don’t choose a range, and the range can only be set when the cluster is created.

What’s the best way to fix an IP overlap?

Renumbering one side is the cleanest fix. Address translation at the connection point works but adds complexity, and exposing only specific services through a proxy limits the impact without fixing the overlap.

Can I choose my own private IP ranges on OpenMetal?

Yes. You create private IP blocks for your VLANs in OpenMetal Central and define custom IP ranges for VPC networks inside your OpenStack private cloud.