Overlapping Address Ranges That Cannot Be Connected

Two networks both built on 10.0.0.0/16 cannot be peered later, because one address would mean two hosts.

Two networks whose address ranges overlap cannot be joined directly, because an address in the shared part would name a machine in both. The usual cause is the default range: every team that accepts 10.0.0.0/16 when creating a network builds one that can never be connected to the others without renumbering.

Picture two teams in one company that each built a cloud network a year ago, both on 10.0.0.0/16, the console's suggestion. Now a service in one must call a database in the other, and the platform team is asked to connect them.

The symptom. The cloud provider refuses the peering connection outright, saying the ranges overlap. On platforms that accept it, or over a VPN, traffic for 10.0.2.15 goes to the machine with that address on the local side, never to the one on the far side.

Two pairs of networks and whether each can be connected

Overlappingcannot be peered

Network A: 10.0.0.0/16. Network B: 10.0.0.0/16. Every address exists in both, so a router cannot know which network 10.0.2.15 means. Peering is refused.

Distinctpeered without changes

Network A: 10.0.0.0/16. Network B: 10.1.0.0/16. No address is in both, so each side adds one route for the other's range and traffic flows.

Why it happens. A route says "send packets for this range that way". When the same range exists on both sides, there are two routes for one destination, and a router sends every packet to the more specific or the local one. Half the machines become unreachable, and which half depends on where you stand.

What it costs. Fixing it means moving one network to a new range: new subnets, new addresses for every server, new firewall rules, new DNS records, and a migration window for the databases. Workarounds exist, such as NAT between the networks or exposing one service through a private endpoint, but each adds a moving part to every request.

What to do instead. Plan ranges before the first network is built, and keep a register of which range belongs to which network: 10.0.0.0/16 for one, 10.1.0.0/16 for the next, and so on. The same applies to VPNs, where a home network on 192.168.1.0/24 clashes with an office that chose the same range, which is why offices are better off avoiding the most common home defaults.

← → move through sections and cards