🚨 GCP Error Guide: 'An IP range in the peer network overlaps' — Fix VPC Peering Overlap

Overview

GCP rejects a VPC Network Peering connection when any subnet range on one side overlaps with a range on the other. Peering does not do NAT — it stitches two VPCs into one flat routing domain — so every IP range across both networks must be unique. The error appears when you create or activate the peering:

ERROR: (gcloud.compute.networks.peerings.create) Could not fetch resource:
 - An IP range in the peer network (10.10.0.0/16) overlaps with an IP range
   in the local network (10.10.0.0/20) allocated by the resource
   (projects/my-project/regions/us-central1/subnetworks/default).

A closely related variant appears when a Private Service Access (PSA) allocation — used by Cloud SQL, Memorystore, or other managed services — collides with a peer subnet:

ERROR: The allocated range 'google-managed-services-default' (10.10.0.0/16)
 overlaps with a subnetwork in the peered network.

Symptoms

• gcloud compute networks peerings create fails immediately with an overlap message naming two CIDRs.
• The peering shows state INACTIVE and a details field mentioning overlapping ranges, even though both sides “accepted” it.
• A newly created subnet in one VPC breaks an existing, previously healthy peering (the peering goes inactive after the fact).
• Cloud SQL or Memorystore instance creation with private IP fails because its PSA range overlaps a peer subnet.
• Traffic between the two VPCs never establishes; routes for the peer’s subnets are missing from the route table.

Common Root Causes

• Both VPCs use the default 10.128.0.0/9 auto-mode ranges — auto-mode networks pick from the same well-known block, so two of them almost always overlap. This is the single most common cause.
• Reused “convenient” CIDRs — teams independently pick 10.0.0.0/16 or 192.168.0.0/16 for different projects, then try to peer them.
• A PSA allocation collides — the google-managed-services-* range for Cloud SQL/Memorystore was auto-allocated into a block the peer already uses.
• A newly added subnet — an existing peering was fine until someone added a subnet in a range the peer already had; peering re-evaluates and goes inactive.
• Transitive expectation — peering is non-transitive, but teams add ranges assuming a hub VPC’s peers can reach each other, creating overlaps in the hub.
• Secondary (alias) ranges overlap — GKE VPC-native pod/service secondary ranges collide with a peer subnet even when the primary ranges don’t.

Diagnostic Workflow

First, list every subnet and its range in both VPCs so you can see the collision directly:

gcloud compute networks subnets list \
  --filter="network:my-vpc" \
  --format="table(name, region, ipCidrRange, secondaryIpRanges)"

gcloud compute networks subnets list \
  --filter="network:peer-vpc" \
  --format="table(name, region, ipCidrRange, secondaryIpRanges)"

Inspect the peering itself for its state and the exact detail message:

gcloud compute networks peerings list --network=my-vpc
gcloud compute networks peerings list-routes my-peering \
  --network=my-vpc --region=us-central1 --direction=INCOMING

Check for Private Service Access allocations, which don’t appear in the subnet list but still consume ranges:

gcloud compute addresses list \
  --global \
  --filter="purpose=VPC_PEERING" \
  --format="table(name, address, prefixLength, network)"

List the effective routes to confirm whether the peer’s subnet routes are being imported or are missing due to the conflict:

gcloud compute routes list \
  --filter="network:my-vpc AND nextHopPeering:*" \
  --format="table(destRange, nextHopPeering, priority)"

Example Root Cause Analysis

A team peered prod-vpc (custom-mode, 10.20.0.0/16 in us-central1) with a partner’s analytics-vpc and the peering came up. Weeks later, Cloud SQL provisioning in prod-vpc failed and the existing peering flipped to INACTIVE.

gcloud compute addresses list --global --filter="purpose=VPC_PEERING" showed a PSA allocation google-managed-services-prod at 10.20.128.0/20. The partner had recently added an analytics-vpc subnet at 10.20.128.0/22 — carved from the same 10.20.0.0/16 space the team assumed it owned exclusively. Because peering merges routing domains, the new peer subnet overlapped the PSA range, and GCP deactivated the peering rather than create ambiguous routes.

The fix was to allocate a fresh, non-overlapping PSA range (10.60.0.0/20) for Cloud SQL, delete the colliding old allocation, and re-establish the private service connection. Longer term, the two teams agreed on a documented IP address plan so no side would ever carve from the other’s block again. The lesson: in a peered topology, every range — including invisible PSA allocations and GKE secondary ranges — shares one flat space, so IP planning must be global, not per-VPC.

Prevention Best Practices

• Maintain a central IP address plan (IPAM). Allocate a distinct, documented CIDR block per VPC before creating any subnet, and never reuse ranges across networks you might peer.
• Use custom-mode VPCs, not auto-mode. Auto-mode’s shared default ranges guarantee overlaps between two default networks.
• Reserve PSA ranges explicitly. Allocate google-managed-services-* ranges from your IPAM plan instead of letting GCP auto-pick, so Cloud SQL/Memorystore can’t collide with a peer.
• Account for secondary ranges. Plan GKE pod and service ranges as first-class allocations; they participate in peering overlap checks.
• Review before adding subnets. Any new subnet in a peered VPC must be checked against every peer’s ranges, because peering re-evaluates and can deactivate.
• Consider Private Service Connect or a hub-and-spoke with distinct blocks when you need many networks to interconnect without a single flat address space.

Quick Command Reference

# See both sides' subnet ranges
gcloud compute networks subnets list --filter="network:my-vpc" \
  --format="table(name,region,ipCidrRange,secondaryIpRanges)"

# Peering state and detail message
gcloud compute networks peerings list --network=my-vpc

# Find invisible PSA / peering allocations
gcloud compute addresses list --global --filter="purpose=VPC_PEERING"

# Allocate a fresh non-overlapping PSA range
gcloud compute addresses create google-managed-services-new \
  --global --purpose=VPC_PEERING --prefix-length=20 \
  --network=my-vpc --addresses=10.60.0.0

# Effective peering routes
gcloud compute routes list --filter="network:my-vpc AND nextHopPeering:*"

Conclusion

The VPC peering overlap error is not a bug to work around — it’s GCP refusing to build an ambiguous routing table. Because peering merges two VPCs into one flat address space, the fix is always to make ranges unique: identify the colliding CIDR (including invisible PSA and GKE secondary ranges), re-plan one side onto a non-overlapping block, and re-establish the connection. The durable prevention is a central IP address plan that treats every range across every peerable network as part of one namespace, so no two subnets, PSA allocations, or pod ranges ever collide again.