Google Cloud Platform (GCP) Virtual Private Cloud (VPC) Network Peering allows private RFC 1918 connectivity across two VPC networks regardless of whether or not they belong to the same project or the same organization.
For details on VPC Network Peering, see the VPC Network Peering Overview.
VPC Network Peering setup
Within the same organization node, a network could be hosting services that need to be accessible from other VPC networks in a same or different projects.
Alternatively, one organization may want to access services offered by other organizations. This is the case in third-party services offering.
Project names are unique across all of GCP, so you do not need to specify the organization when setting up peering. GCP knows the organization based on the project name.
Setting up a VPC Network Peering session
Consider an organization-A which needs VPC Network Peering to be established between network-A in project-A and network-B in project-B. In order for VPC Network Peering to be established successfully, administrators of network-A and network-B must separately configure the peering association.
Step 1: Peer network-A with network-B
A user with appropriate IAM permissions in project-A configures network-A to peer with network-B. For example, users with the roles/editor or roles/compute.networkAdmin role can configure peering.
Before you begin, you will need the project IDs and network names of the networks you want to peer.
Console
- Go to the VPC Network Peering page in the Google Cloud Platform Console.
Go to the VPC Network Peering page - Click Create connection.
- Click Continue.
- Enter a Name of
peer-abfor this side of the connection. - Under Your VPC network, select the network you want to peer.
- Set the Peering VPC network radio buttons to
In another project, unless you wish to peer within the same project. - Specify the Project ID of the other project.
- Specify VPC network name of the other network.
- Click Create.
gcloud
gcloud compute networks peerings create peer-ab \
--network network-A \
--peer-project project-B \
--peer-network network-B \
--auto-create-routes
At this point, the peering state remains INACTIVE because there is no matching
configuration in network-B in project-B.
Console
- Go to the VPC Network Peering page in the Google Cloud Platform Console.
Go to the VPC Network Peering page - Status says "Waiting for peer network to connect."
gcloud
gcloud compute networks peerings list --network network-A
NAME NETWORK PEER_PROJECT PEER_NETWORK AUTO_CREATE_ROUTES STATE STATE_DETAILS peer-ab network-A project-B network-B True INACTIVE The peering network has not been configured.
Step 2: Peer network-B with network-A
A NetworkAdmin,
or a user with appropriate IAM permissions, in project-B must configure the
matching configuration from network-B to network-A in order for the peering
to become ACTIVE on both ends.
Console
- Go to the VPC Network Peering page in the Google Cloud Platform Console.
Go to the VPC Network Peering page - Click Create connection.
- Click Continue.
- Enter a Name of
peer-bafor this side of the connection. - Under Your VPC network, select the network you want to peer.
- Set the Peering VPC network radio buttons to
In another project, unless you wish to peer within the same project. - Specify the Project ID of the other project.
- Specify VPC network name of the other network.
- Click Create.
gcloud
gcloud compute networks peerings create peer-ba \
--network network-B \
--peer-project project-A \
--peer-network network-A \
--auto-create-routes
Step 3: VPC Network Peering becomes ACTIVE and routes are exchanged
As soon as the peering moves to an ACTIVE state, traffic flows are set up:
- Between VM instances in the peered networks: Full mesh connectivity.
- From VM instances in one network to Internal Load Balancing endpoints in the peered network
Console
- Go to the VPC Network Peering page in the Google Cloud Platform Console.
Go to the VPC Network Peering page - Status says "Connected."
- Go to the VPC Network Peering page in the other project to see that it also says "Connected."
gcloud
gcloud compute networks peerings list --network network-A
NAME NETWORK PEER_PROJECT PEER_NETWORK AUTO_CREATE_ROUTES STATE STATE_DETAILS peer-ab network-A project-B network-B True ACTIVE The peering became ACTIVE at 2016-06-08T15:10:14.111-07:00.
gcloud compute networks peerings list --network network-B
NAME NETWORK PEER_PROJECT PEER_NETWORK AUTO_CREATE_ROUTES STATE STATE_DETAILS peer-ba network-B project-A network-A True ACTIVE The peering became ACTIVE at 2016-06-08T15:10:14.111-07:00.
The routes to peered network CIDR prefixes are now visible across the VPC network peers. These routes are implicit routes generated for active peerings. They don't have corresponding route resources. The following command lists routes for all VPC networks for project-A.
Console
- Go to the Routes page in the Google Cloud Platform Console.
Go to the Routes page
gcloud
gcloud compute routes list --project project-A
NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-2a865a00fa31d5df network-A 0.0.0.0/0 default-internet-gateway 1000 default-route-8af4732e693eae27 network-A 10.0.0.0/16 1000 peering-route-4732ee69e3ecab41 network-A 10.8.0.0/16 peer-ab 1000
Deleting a VPC Network Peering session
Either side can remove the peering configuration. This makes
the peering INACTIVE again, and all the routes to the peer network will be
removed. In this example, peering configuration is removed from network-A.
Console
- Go to the VPC Network Peering page in the Google Cloud Platform Console.
Go to the VPC Network Peering page - Select the checkbox next to the peering you want to remove.
- Click Delete.
gcloud
gcloud compute networks peerings delete peer-ab --network network-A
When one end of a network peering session is deleted, peering at the other
end becomes INACTIVE.
Peering VPC networks across organizations
Consider the scenario in which VM instances in project-A/network-A need to access services from two different external organizations: SaaS1 and SaaS2. In order to access those via RFC 1918 space, network-A must peer with SaaS1 project-B/network-B and SaaS2 project-C/network-C where the services are hosted.
To create this setup, simply create two different peering sessions.
Restrictions
No subnet IP range overlap across peered VPC networks
No subnet IP range can overlap with another subnet IP range in a peered VPC network.
Checks performed at VPC Network Peering setup
At the time of peering, GCP checks to see if there are any subnets with overlapping IP ranges between the two VPC networks or any of their peered networks. If there is an overlap, peering is not established. Since a full mesh connectivity is created between VM instances, subnets in the peered VPC networks can’t have overlapping IP ranges as this would cause routing issues.
If there were any subnets with overlapping IP ranges between peers of a given VPC network, it would cause a routing conflict. For example, suppose VPC network N1 has already peered with VPC network N2, then VPC network N3 tries to peer with N2. This is an invalid peering because N3 has a subnet Subnet_5 whose IP range overlaps with Subnet_1 in network N1.
Checks performed at subnet creation in VPC Network Peering scenarios
When a VPC subnet is created or a subnet IP range is expanded, GCP performs a check to make sure the new subnet range does not overlap with IP ranges of subnets in the same VPC network or in directly peered VPC networks. If it does, the creation or expansion action fails. For example, when a new subnet subnet_3 is created in network N2 in the following figure, the IP ranges must not overlap with the IP ranges defined in the directly peered network N1.
GCP also ensures that no overlapping subnet IP ranges are allowed across VPC networks that have a peered network in common. If it does, the creation or expansion action fails. For example, when a new subnet subnet_5 is created in network N3 in the following figure, the IP ranges must not overlap with the IP ranges defined in directly peered network N2, or with network N1, because N1 is already peered with N2.
Legacy networks are not supported in VPC Network Peering
Legacy Networks are networks that do not have subnets. Legacy networks cannot peer with any other networks and are not supported in VPC Network Peering.
VPNs not reachable across peered networks
VPN in a network can't be reached from a peered network.
No Compute Engine DNS across projects
Compute Engine internal DNS names created in a network are not accessible to peered networks. The IP address of the VM should be used to reach the VM instances in peered network.
User-configured routes are not propagated across peered networks
User-configured routes are not propagated across peered networks. If you configure a route in a network to a destination in a VPC network, such a destination will not be reachable from a peered network.
Tags and service accounts are not usable across peered networks
You cannot use a tag or service account from one peered network in the other peered network.
Kubernetes Engine with VPC Network Peering
VPC Network Peering with Kubernetes Engine is supported when used with IP Aliases. Kubernetes Services, if exposed via Internal Load Balancing, and Pod IPs are reachable across VPC networks.
Limits
Number of peerings limit
A network can have up to 25 directly peered networks in total. This total includes both active and inactive peerings.
VPC Network Peering VM instances limit
A VPC network can have up to 7500 instances in itself and all directly peered VPC networks.
Each network has a "peering instance limit." This is a limit to the number of instances that can be in the network and in all directly peered networks combined.
VPC Network Peering Internal Load Balancing forwarding rules limit
The per-network limit is 50. In other words, the number of forwarding rules in a network and all its directly peered networks cannot exceed this limit.
Each network has a "peering Internal Load Balancing forwarding rule limit." This is a limit to the number of Internal Load Balancing forwarding rules that can be in the network and in all directly peered networks combined.
Troubleshooting
Q: My peering connection is set up, but I am not able to reach peer VMs or internal load balancers.
After the peering connection is ACTIVE, it may take up to a minute for all the traffic flows to be set up between the peered VPC networks. This time depends on the size of the VPC networks that are peering. If you have just set up the peering connection, please wait up to a minute and try again. Also, ensure that there are no firewall rules blocking access to/from peer VPC network subnet CIDRs.
Q: When I try to set up the peering connection, I get an error that another peering operation is in progress.
In order to avoid contention with routing updates and the like, GCP allows only one peering-related activity at a time across peered networks. For example, if you set up peering with one network and immediately try to set up another, all the tasks from the first peering may not have completed. It may take up to a minute for all tasks to complete. Alternatively, your existing network peer may be adding an internal load balancer or VM, both of which affect what is reachable between networks. In most cases, you should wait a minute or two and retry the peering operation.
Q: When I try to delete a VPC network with ACTIVE peerings, I get an
error.
Delete your side of the peering connection and retry.
Q: The VPC networks that I am trying to peer have overlapping subnet CIDRs. Is there anything I can do to make this work?
No. You will have to change your VPC networks such that the subnet CIDRs are non-overlapping
Q: I have a VPC network that is peered with another network. I want to create a subnet in my VPC network. How do I create this subnet so that it does not overlap with my peer VPC network?
Please look at the peering routes that point to your peer VPC network as the next hop. These routes represent the list of subnet CIDRs in your peer VPC network. Please choose a CIDR that does not overlap with your existing subnet CIDRs and your peer VPC network's subnet CIDRs
Q: I have a VPC network that is peered with another VPC network. I want to create a subnet in my VPC network. How do I create this subnet so that it does not overlap with my peer's peer VPC networks?
At this time, there is no command that helps you to find this. Please ask the admin of the peered network to find out what subnet routes are already in that network.
Q: Are there any security or privacy concerns with VPC peering?
After peering is set up, each VPC network knows the subnet ranges of the other network. In addition, each peer VPC network is able to send and receive traffic from the all VMs in the other network unless firewall rules are in place to prevent it. Other than that, peered networks do not have visibility into each other.
Q: Can I see if there are VPC peering requests by other VPC networks for my network?
No. VPC peering works on a bi-directional basis. You set up peering from your side and your peer sets it up from their side. You only have visibility into the VPC peering requests that you have set up.
What's next
- See the Routes overview for more information on VPC routing.
