Use VPC Network Peering

Google Cloud VPC Network Peering enables internal IP address connectivity across two Virtual Private Cloud (VPC) networks, regardless of whether they belong to the same project or the same organization. Peering supports connectivity between networks having dual-stack subnets.

For more information, see VPC Network Peering.

Create a peering configuration

Before you begin, you must have the name of the VPC network to which you will peer with. If that network is located in another project, you must also have the project ID of that project.

A peering configuration establishes the intent to connect to another VPC network. Your network and the other network are not connected until each one has a peering configuration for the other. After the other network has a corresponding configuration to peer with your network, the peering state changes to ACTIVE in both networks, and they are connected. If there's no matching peering configuration in the other network, the peering state remains INACTIVE, indicating that your network is not connected to the other one.

Once connected, the two networks always exchange subnet routes. You can optionally import both static and dynamic IPv4 custom routes and dynamic IPv6 custom routes from a peered network if it has been configured to export them. For more information, see import and export custom routes.

Console

  1. In the Google Cloud console, go to the VPC Network Peering page .
    Go to VPC Network Peering
  2. Click Create connection.
  3. Click Continue.
  4. In the Name field, enter a name for your peering configuration.
  5. Under Your VPC network, select a network you want to peer.
  6. Select the network to peer with.

    • If the network that you want to peer with is in the same project, select In project [NAME-OF-YOUR-PROJECT] and then the network to peer with.
    • If the network that you want to peer with is in a different project, select In another project. Specify the project ID that includes the network you want to peer with and the name of the VPC network.
  7. Under IP stack type, specify which subnet routes should be exchanged between the peered networks:

    • IPv4 (single-stack): Exchange IPv4 routes only.
    • IPv4 and IPv6 (dual-stack): Exchange both IPv4 and IPv6 routes.
  8. To import or export IPv4 and IPv6 custom routes, choose one or both of the following options:

    • Import custom routes: Import custom routes from the peer network. The peer network must enable custom route export for routes to be imported.
    • Export custom routes: Export custom routes to the peer network. The peer network must enable custom route import for routes to be exported.
  9. If your network or the peer network uses privately used public IPv4 ranges in their subnets, these routes are exported by default, but not imported by default. To import privately used public IPv4 subnet routes, select:

    • Import subnet routes with public IP to import privately used public IP subnet routes exported by the other network
  10. Click Create.

gcloud

Create a VPC Network Peering connection.

gcloud compute networks peerings create PEERING_NAME \
    --network=NETWORK \
    --peer-project=PEER_PROJECT_ID \
    --peer-network=PEER_NETWORK_NAME \
    [--stack-type=STACK_TYPE] \
    [--import-custom-routes] \
    [--export-custom-routes] \
    [--import-subnet-routes-with-public-ip] \
    [--export-subnet-routes-with-public-ip]

Replace the following:

  • PEERING_NAME: The name of the peering configuration.
  • NETWORK: The name of the network in your project that you want to peer.
  • PEER_PROJECT_ID: The ID of the project containing the network that you want to peer with.
  • PEER_NETWORK_NAME: The name of the network that you want to peer with.
  • STACK_TYPE: The stack type for the peering connection. Specify IPV4_ONLY to exchange only IPv4 routes. Alternatively, specify IPV4_IPV6 to exchange both IPv4 and IPv6 routes. IPV4_ONLY is the default value.
  • --import-custom-routes tells the network to accept custom routes from the peered network. The peered network must export the routes first.
  • --export-custom-routes tells the network to export custom routes to the peered network. The peered network must be set to import the routes.
  • --import-subnet-routes-with-public-ip tells the network to accept subnet routes from the peered network if that network is using privately used public IPv4 addresses in its subnets. The peered network must export the routes first.
  • --export-subnet-routes-with-public-ip tells the network to export subnet routes that contain privately used public IP addresses. The peered network must be set to import the routes.

Terraform

You can use a Terraform module to create a peering configuration.

module "peering1" {
  source        = "terraform-google-modules/network/google//modules/network-peering"
  version       = "~> 9.0"
  local_network = var.local_network # Replace with self link to VPC network "foobar" in quotes
  peer_network  = var.peer_network  # Replace with self link to VPC network "other" in quotes
}

For the two peered VPC networks, each self link includes a project ID and the name of the VPC network. To get the self link for a VPC network, you can use the gcloud compute networks describe command or the networks.get method in each VPC network's project.

When you create a peering from the local_network to the peer_network, the peering relationship is bidirectional. The peering from the peer_network to the local_network gets created automatically.

To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.

Update a peering connection

When you update an existing VPC Network Peering connection, you can do the following:

  • Change whether your VPC network exports or imports custom routes or privately used public IPv4 subnet routes to or from the peer VPC network.
  • Update an existing peering connection to enable or disable the exchange of IPv6 routes between the peering networks.

Your network imports routes only if the peer network is also exporting the routes, and the peer network receives routes only if it imports them.

Console

  1. In the Google Cloud console, go to the VPC Network Peering page.
    Go to VPC Network Peering
  2. Select the peering connection to update.
  3. Click Edit.
  4. Update the IP stack type selection to specify which subnet routes should be exchanged between the peered networks:
    • IPv4 (single-stack): Stop the existing exchange of IPv6 routes over the peering and continue exchanging only IPv4 routes.
    • IPv4 and IPv6 (dual-stack): Start exchanging both IPv4 and IPv6 routes, provided that the matching peering connection also has IP stack type set to IPv4 and IPv6 (dual-stack).
  5. To import or export IPv4 and IPv6 custom routes, choose one or both of the following options:
    • Import custom routes to import custom routes exported by the other network
    • Export custom routes to export custom routes to the other network. The other network must import the routes to see them.
  6. If your network or the peer network uses privately used public IPv4 ranges in their subnets, these routes are exported by default, but not imported by default. To import privately used public IPv4 subnet routes, select:
    • Import subnet routes with public IP to import privately used public IP subnet routes exported by the other network
    • Click Save.

gcloud

gcloud compute networks peerings update PEERING_NAME \
    --network=NETWORK \
    [--stack-type=STACK_TYPE] \
    [--import-custom-routes] \
    [--export-custom-routes] \
    [--export-subnet-routes-with-public-ip] \
    [--import-subnet-routes-with-public-ip]

Update the following:

  • PEERING_NAME: The name of the existing peering connection.
  • NETWORK: The name of the network in your project that is peered.
  • STACK_TYPE: The stack type for the peering connection.
    • Specify IPV4_ONLY to stop the existing exchange of IPv6 routes over the peering and continue exchanging only IPv4 routes.
    • Specify IPV4_IPV6 to start exchanging both IPv4 and IPv6 routes, provided the matching peering connection also has stack_type set to IPV4_IPV6.
  • --import-custom-routes tells the network to accept custom routes from the peered network. The peered network must export the routes first.
  • --export-custom-routes tells the network to export custom routes to the peered network. The peered network must be set to import the routes.
  • --import-subnet-routes-with-public-ip tells the network to accept subnet routes from the peered network if that network is using privately used public IPv4 addresses in its subnets. The peered network must export the routes first.
  • --export-subnet-routes-with-public-ip tells the network to export subnet routes that contain privately used public IP addresses. The peered network must be set to import the routes.

List peering connections

List existing peering connections to view their status and whether they're importing or exporting custom routes.

Console

  1. In the Google Cloud console, go to the VPC Network Peering page.
    Go to VPC Network Peering
  2. Select the peering connection to view its details.

gcloud

gcloud compute networks peerings list

List routes from peering connections

You can list the dynamic routes that your VPC network is importing from or exporting to a peered VPC network. For exported routes, you can check whether a peer network is accepting or rejecting your custom routes. For imported routes, you can check whether your network is accepting or rejecting custom routes from a peer network.

You might not see the same number of routes for each region. For more information, see Troubleshooting.

Console

  1. In the Google Cloud console, go to the VPC Network Peering page.
    Go to VPC Network Peering
  2. Select the peering connection to view its details.
  3. View customs routes that your network is importing or exporting. Use the region selector to view dynamic routes in a particular region. Subnet and static routes are global and are shown for all regions.

    • To view the imported custom routes, select the Imported routes tab.
    • To view the exported custom routes, select the Exported routes tab.

gcloud

gcloud compute networks peerings list-routes PEERING_NAME \
    --network=NETWORK \
    --region=REGION \
    --direction=DIRECTION

Update the following:

  • PEERING_NAME: The name of an existing peering connection.
  • NETWORK: The name of the network in your project that is peered.
  • REGION: The region where you want to list all dynamic routes. Subnet and static routes are global and are shown for all regions.
  • DIRECTION: Specifies whether to list imported (incoming) or exported (outgoing) routes.

Delete a VPC Network Peering connection

You or a network administrator for the peer VPC network can delete a peering configuration. When a peering configuration has been deleted, the peering connection switches to INACTIVE in the other network, and all routes shared among the networks are removed.

Console

  1. Go to the VPC Network Peering page in the Google Cloud console.
    Go to VPC Network Peering
  2. Select the checkbox next to the peering you want to remove.
  3. Click Delete.

gcloud

gcloud compute networks peerings delete PEERING_NAME \
    --network=NETWORK

Update the following:

  • PEERING_NAME: The name of the peering connection to delete.
  • NETWORK: The name of the network in your project that is peered.

Example VPC Network Peering setup

Consider an organization 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.

Peering from network-a to network-b
Peering from network-a to network-b (click to enlarge)

Before you begin, you need the project IDs and network names of the networks you want to peer.

Console

  1. Go to the VPC Network Peering page in the Google Cloud console.
    Go to VPC Network Peering
  2. Click Create connection.
  3. Click Continue.
  4. Enter a Name of peer-ab for this side of the connection.
  5. Under Your VPC network, select the network you want to peer.
  6. Set the Peering VPC network radio buttons to In another project, unless you want to peer within the same project.
  7. Specify the Project ID of the other project.
  8. Specify VPC network name of the other network.
  9. Select Import custom routes and Export custom routes.
  10. Click Create.

gcloud

gcloud compute networks peerings create peer-ab \
    --network=network-a \
    --peer-project=project-b \
    --peer-network=network-b \
    --import-custom-routes \
    --export-custom-routes

At this point, the peering state remains INACTIVE because of the absence of a matching configuration in network-b in project-b.

When the peering state becomes ACTIVE, VPC Network Peering automatically exchanges subnet routes. Google Cloud also exchanges custom routes (static routes and dynamic routes) by importing or exporting them over the peering connection. Both networks must be configured to exchange custom routes before they are shared. For more information, see Importing and exporting custom routes.

To see the current peering state, view the peering connection:

Console

  1. Go to the VPC Network Peering page in the Google Cloud console.
    Go to VPC Network Peering
  2. Status says "Waiting for peer network to connect."

gcloud

gcloud compute networks peerings list --network network-a

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.

Peering from network-b to network-a (click to enlarge)
Peering from network-a to network-b (click to enlarge)

Console

  1. Go to the VPC Network Peering page in the Google Cloud console.
    Go to VPC Network Peering
  2. Click Create connection.
  3. Click Continue.
  4. Enter a Name of peer-ba for this side of the connection.
  5. Under Your VPC network, select the network you want to peer.
  6. Set the Peering VPC network radio buttons to In another project, unless you want to peer within the same project.
  7. Specify the Project ID of the other project.
  8. Specify VPC network name of the other network.
  9. Select Import custom routes and Export custom routes.
  10. Click Create.

gcloud

gcloud compute networks peerings create peer-ba \
     --network=network-b \
     --peer-project=project-a \
     --peer-network=network-a \
     --import-custom-routes \
     --export-custom-routes

Step 3: VPC Network Peering becomes ACTIVE

As soon as the peering moves to an ACTIVE state, subnet routes and custom routes are exchanged. The following traffic flows are set up:

  • Between VM instances in the peered networks: Full mesh connectivity.
  • From VM instances in one network to internal passthrough Network Load Balancer endpoints in the peered network
Peering ACTIVE (click to enlarge)
Peering ACTIVE (click to enlarge)

Console

  1. Go to the VPC Network Peering page in the Google Cloud console.
    Go to VPC Network Peering
  2. Status says "Connected."
  3. 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

The routes to peered network CIDR prefixes are now visible across the VPC network peers. These routes are implicit routes that generated for active peering connections. They don't have corresponding route resources. The following procedure shows routes for all VPC networks for project-a.

Console

  1. Go to the Routes page in the Google Cloud console.
    Go to Routes

gcloud

gcloud compute routes list --project project-a

Create multiple peering connections

Consider the scenario in which VM instances in network-a need to access services from two different external organizations: SaaS1 and SaaS2. To access both using only internal IP addresses, two peering connections are required:

  • network-a peers with network-b, which is in SaaS1
  • network-a peers with network-c, which is in SaaS2

With VPC Network Peering, it doesn't matter that that network-b and network-c are in different projects and different organizations.

Cross-organization peering (click to enlarge)
Cross-organization peering (click to enlarge)

To create this setup, 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. At the time of peering, Google Cloud checks if subnets with overlapping IP ranges exist; if yes, then the peering fails. In the case of a peered network, if you try to create a VPC subnet or expand a subnet IP range, Google Cloud performs check to ensure new subnet ranges don't overlap with the existing ones.

For more information on overlap checks, see the following:

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.

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.

Tags and service accounts are not usable across peered networks

You cannot reference a tag or service account pertaining to a VM from one peered network in a firewall rule in the other peered network. For example, if an ingress rule in one peered network filters its source based on a tag, it will only allow apply to VM traffic originating from within that network, not its peers, even if a VM in a peered network has that tag. This situation holds similarly for service accounts.

GKE with VPC Network Peering

VPC Network Peering with GKE is supported when used with IP Aliases or custom routes. Kubernetes Services, if exposed by using an internal passthrough Network Load Balancer, and Pod IPs are reachable across VPC networks.

Cloud Load Balancing with VPC Network Peering

Cloud Load Balancing does not support having load balancer's frontends and backends in different VPC networks, even if they are peered with VPC Network Peering.

Internal passthrough Network Load Balancers and internal Application Load Balancers support VPC Network Peering only for client access from the peered VPC network.

Limits

See VPC Network Peering limits.

Troubleshooting

Q: My peering connection is set up, but I am unable 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 networks. This time depends on the size of the networks that are peering. If you have recently set up the peering connection, 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, Google Cloud 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 might 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.

Before you can delete a VPC network, you must first delete all peering configurations in the network. See deleting a VPC network peering connection.

Q: Can you peer VPC networks that have subnets with overlapping primary or secondary IP ranges?

No. You can only peer VPC networks whose subnets have unique primary and secondary subnet IP ranges.

Q: How do I make sure new subnets I create in my VPC network will not have subnet IP ranges that conflict with subnets or routes in peer networks?

Before creating new subnets, you can list the routes from peering connections. Make sure you do not use any of their destinations as either primary or secondary IP ranges when you create new subnets in your VPC network.

Q: I have a VPC network that is peered with another VPC network. I want to create a subnet in my network. How do I create this subnet so that it does not overlap with my peer's peer subnets?

At this time, a command that helps you to find this doesn't exist. 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 Network 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: How do I verify that traffic is passing between peered VPC networks?

You can use VPC Flow Logs to view network flows sent from and received by VM instances. You can also use Firewall Rules Logging to verify that traffic is passing between the networks. Create VPC firewall rules that allow (or deny) traffic between the peered networks, and turn on Firewall Rules Logging for those rules. You can then view which firewall rules were hit using Cloud Logging.

Q: How do I determine if there are any requests from other VPC networks to connect to my VPC network using VPC Network Peering?

You can't list any peering requests for your VPC network. You can only see the peering configurations that you have created.

VPC Network Peering requires that both your network and another network create a peering configuration to one another before a connection can be established. Even if a network administrator for another VPC network creates a peering configuration to your network, no peering connection is created unless you create a peering configuration to that network.

Q: How do I make routes in a peer network available to an on-premises network connected to my VPC network using Cloud VPN or Cloud Interconnect?

VPC Network Peering does not support transitive routing; that is, imported routes from other networks are not automatically advertised by Cloud Routers in your VPC network. However, you can use custom IP range advertisements from Cloud Routers in your VPC network to share routes to destinations in the peer network.

For Classic VPN tunnels using static routing, you must configure static routes to the peer network's destination ranges in your on-premises network. Note that certain use cases of Classic VPN tunnels are deprecated.

Q: Why are custom routes not exchanged between peered networks?

First, list the routes from your peering connections. If you don't see routes to destinations that you expect, check the following:

  • List peering connections. Find the network with the desired destination ranges, and ensure that its peering state is ACTIVE. If the peering connection is INACTIVE, a peering configuration for your network does not exist in the other network. If you don't manage the other network, you'll need to coordinate with a network administrator who does.

  • Update the peering configuration in your network so that it is configured to import custom routes from the other network. Ensure that the other network has been configured to export its custom routes.

Q: Why is traffic destined for a peer network being dropped?

First, list peering connections to make sure your network is still connected to the other one. If the peering state is INACTIVE, a peering configuration for your network does not exist in the other network. If you don't manage the other network, you'll need to contact a network administrator who does.

Next, list routes from peer connections. You can only import as many routes as are allowed by the VPC Network Peering limits.

Q: Why is traffic being sent to an unexpected next hop?

Review the routing order to see if another route was chosen instead.

Q: Why can't my VPC network peer with a particular VPC network?

If you cannot create a peering configuration with certain VPC networks, an organization policy might be constraining the VPC networks that your network can peer with. In the organization policy, add the network to the list of allowed peers or contact your organization administrator. For more information, refer to the constraints/compute.restrictVpcPeering constraint.

Q: I have a VPC network that is peered with another VPC network. I've changed the value of stack_type for my peering to IPV4_IPV6. However, I don't see the exchange of IPv6 subnet routes over the peering.

Ensure that the value of stack_type for the matching peering connection is also set to IPV4_IPV6. Both sides of a peering connection must have stack_type set to IPV4_IPV6 before IPv6 routes and traffic can be exchanged.

Q: I have a VPC network that is peered with another VPC network. I've changed the value of stack_type for my peering to IPV4_IPV6. However, dynamic IPv6 routes aren't being exported.

To export dynamic and static IPv6 routes, you must enable the –export-custom-route and the –import-custom-route flags on the matching peering connections.

Q: I've enabled the import and export of custom routes. However, IPv6 static and dynamic routes aren't being exchanged.

Ensure that both the peerings have stack_type set to IPV4_IPV6.

Q: My peering update operation to switch stack_type to IPV4_IPV6 is failing due to quota limits.

If IPv6 is enabled on the peering, the number of routes that is imported by one of the networks can lead to the exceeding of the per-peering-group quota for that network. File a request to increase the per-peering-group quota, or remove some routes from one of the networks to stay within the quota. For more information about limits, see VPC Network Peering limits.

Q: Some dynamic routes are imported, but I don't see all of them.

Consider the following:

  • You might not see the same number of routes for each region. If multiple routes with the same IP address ranges are exchanged across regions, only the routes with the highest priority are imported. If these routes are exchanged across the same region, all routes are imported.

  • When a network reaches the per-peering-group limit of dynamic routes, no more routes are imported. However, it's not possible to determine which routes are omitted.

Q: Do the –import-subnet-routes-with-public-ip and –export-subnet-routes-with-public-ip flags affect the exchange of IPv6 subnet routes?

No. These flags only affect the exchange of IPv4 subnet routes.

What's next