{"id":1804,"date":"2026-03-02T11:19:43","date_gmt":"2026-03-02T16:19:43","guid":{"rendered":"https:\/\/cloudlearning365.com\/?p=1804"},"modified":"2026-03-02T11:20:33","modified_gmt":"2026-03-02T16:20:33","slug":"gcp-vpc-peering-route-export-and-import-clarified","status":"publish","type":"post","link":"https:\/\/cloudlearning365.com\/?p=1804","title":{"rendered":"GCP VPC peering route export and import clarified"},"content":{"rendered":"\n

In Azure\/AWS when you are peering two vNets\/VPCs, each end will automatically learn the opposite side CIDR ranges assigned to vNets\/VPCs subnets. It will not bring over User Defined Route (UDR) in Azure , neither will it bring over the static\/propagated routes in AWS.<\/p>\n\n\n\n

In GCP VPC peering, it has this very interesting export\/import feature that enriches what routes can be exposed across VPC peering, and it can be confusing for people come from Azure\/AWS background, and hope this blog will help to clarify this export\/import feature, as well as potential gochas.<\/p>\n\n\n\n

Lab setup<\/h2>\n\n\n\n

In this example, I’m creating two VPCs<\/p>\n\n\n\n

producer-vpc<\/strong> (services will be running in this producer-vpc, such as Cloud SQL or Filestore)<\/p>\n\n\n\n

consumer-vpc1<\/strong> (this VPC hosts VM or GKE cluster that consumes services provided by producer-vpc)<\/p>\n\n\n\n

producer-vpc configuration<\/h3>\n\n\n\n

producer-vpc<\/strong> only have a single subnet with CIDR 10.240.1.0\/24 assigned<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

producer-vpc<\/strong> now only have two active routes:
0\/0 -> Internet Gateway, type static, untagged (Scope limits column empty), priority 1000 (For internet egress)
10.240.1.0\/24 -> Network producer-vpc, type subnet, untagged (Scope limits column empty), priority 0. (Local routes for it’s own subnets)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

consumer-vpc1 configuration<\/h3>\n\n\n\n

In consumer-vpc1<\/strong>, I have created two subnets, each subnet also assigned secondary IP range (for services that might use secondary IPs, such as GKE pods), also I’ve used IP address that either fall within RFC1918 (10.0.0.0\/8, 172.16.0.0\/12, 192.168.0.0\/16), or Non-RFC1918 address range 6.0.0.0\/8 <\/p>\n\n\n\n

pupi-subnet1 primary IP range: 6.41.33.0\/24, secondary IP range: 6.41.34.0\/24
rfc1918-subnet1 primary IP range: 10.80.1.0\/24, secondary IP range: 10.80.2.0\/24<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

You might have noticed this name: PUPI, it refer to: P<\/strong>rivately U<\/strong>sed P<\/strong>ublic I<\/strong>P. Meaning you are using a public IP range for private use. More to come on this.<\/p>\n\n\n\n

These are the route tables of consumer-vpc1:
The top 4 rows are static routes added by me. It has a mixture of Static tagged RFC1918 route, Static tagged PUPI route, Static untagged RFC1918 route, Static untagged PUPI route.
The 5th row is default route for egress
The 6th to 10th are subnet routes that are: PUPI subnet primary IP range, RFC1918 subnet primary IP range, PUPI subnet secondary IP range, RFC1918 subnet secondary IP range<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

VPC peering<\/h2>\n\n\n\n

We will need to create VPC peering from consumer-vpc1 -> producer-vpc
Then we will have to create the reverse VPC peering from producer-vpc -> consumer-vpc1<\/p>\n\n\n\n

For the VPC peering from consumer-vpc1 -> producer-vpc, I’ve unchecked Exchange IPv4 custom routes<\/strong>, also unchecked Exchange subnet routes with privately used Public IPv4 address<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Do the same to create the reverse VPC peering from producer-vpc -> consumer-vpc1<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Observe route tables after initial VPC peering<\/h2>\n\n\n\n

After the status of both VPC peerings turned to Active<\/p>\n\n\n\n

In consumer-vpc1, we can see type: Peering subnet, destination 10.240.1.0\/24, priority 0, untagged, next hop -> Network peering producer-vpc<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In producer-vpc, we can see only RFC1918 subnet routes shows up as Peering subnet. The PUPI subnets routes didn’t show up.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

As a reminder, this is the subnets CIDR assignment for consumer-vpc1, the 6.41.x.x routes didn’t get added<\/strong><\/span> to producer-vpc route table via VPC peering.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Export \/ Import “Subnet routes<\/span>” with PUPI<\/h2>\n\n\n\n

To allow “Subnet routes<\/span><\/strong>” that are using PUPI, eg, the pupi-subnet1<\/strong> that are using 6.41.33.0\/24 and 6.41.34.0\/24 addresses to be exported to producer-vpc:<\/p>\n\n\n\n

First, update VPC peering from consumer-vpc1 -> producer-vpc, check “Export subnet routes with public IP<\/strong>“, or I’m referring it to Export “Subnet routes” with PUPI<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

2nd, update VPC peering from producer-vpc -> consumer-vpc1, check “Import subnet routes with public IP<\/strong>“, or I’m referring it to Import “Subnet routes” with PUPI<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Check producer-vpc route table, now we can see PUPI subnets 6.41.x.x show up as peering subnet routes.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Why this is important?<\/h2>\n\n\n\n

Coming from Azure\/AWS, the assumption is that peering VPCs will automatically learn all subnet routes across the peering connection. In GCP, this isn’t the case. You will have to enable “Export\/Import subnet routes with public IP<\/strong>“, or I’m referring it to Export\/Import “Subnet routes” with PUPI<\/strong>, to have the same effect.<\/p>\n\n\n\n

When you are using PUPI in your consumer VPC as you ran out of RFC1918 ranges, when you are connecting to PaaS services such as Cloud SQL, Filestore, you need to make sure Export\/Import “Subnet routes” with PUPI<\/strong> is enabled on the VPC peering connection.<\/span><\/p>\n\n\n\n

What is “Custom routes”<\/h2>\n\n\n\n

1. Static Routes <\/h3>\n\n\n\n

These are manually created by you. You define a destination CIDR range and a “next hop” (where the traffic should go).<\/sup><\/p>\n\n\n\n