Address space overlaps with an existing virtual network

Last reviewed: May 2026

If Azure returned this error, the fix is mechanical once you can see which existing range you collided with. This page shows how to find it and how to choose a range that will be accepted.

The exact error

What actually causes it

Azure is refusing an address space that intersects one already in use — usually on the far side of a peering, or on a VNet already connected to the same hub. Peering requires non-overlapping address spaces because Azure cannot build an unambiguous route table when the same prefix exists on both sides.

Find the conflicting range

List what is already allocated before guessing at a new range:

az network vnet list \
  --query "[].{Name:name, RG:resourceGroup, Space:addressSpace.addressPrefixes}" \
  --output table

Fix it, step by step

1. List every VNet address space in the subscription with the command above. Repeat across every subscription that participates in the peering mesh — this error very often comes from a VNet in a different subscription.
2. Paste the results into the bulk subnet calculator to see exactly which pairs intersect.
3. Pick a genuinely free range. If your organisation has a top-level block reserved for Azure, run it through the free subnet finder with the in-use spaces to get valid candidates.
4. Re-range the new VNet before peering. An address space can only be changed while no subnets in it are in use, so fix this before deploying resources.

The most common root cause is a default: the Azure portal frequently suggests 10.0.0.0/16, so organisations end up with several VNets all claiming it. If you are hitting this repeatedly, the fix is not per-VNet — it is to allocate each VNet a distinct block from one planned supernet and document it.

Preventing it next time

This error is almost always a symptom of address space that was never planned centrally. Allocating each environment a documented block from one supernet, and checking new ranges against that record before deployment, removes the whole class of failure. The Cloud VPC & VNet CIDR Planning Guide sets out that approach.