Google Cloud Platform – VPC network peering

How to install web server (IIS) on Windows Server 2019

The VPC network peering allows private (RFC 1918) connectivity across two VPC networks that can span over multiple projects and even multiple organizations. In an organization with multiple network administrative domains, VPC peering allows for services to be available across VPC networks in a private IP space. These organizational services can also be exposed to other organizations via this private space. VPC network peering has more advantages than using public IP addresses or VPNs to connect organizations or networks with latency, and exposure to public internet being one of the most important ones. Also, when networks are peered, there are no egress traffic costs, which saves on overall network costs.

VPC network peering works with compute engine and app engine flexible environments. Routes, firewalls, VPNs, and other traffic tools are applied independently to each VPC network. When peering is set up, each side will only work when the configuration matches from both sides. Either side can turn off peering association at any time. One VPC network can peer with multiple VPC networks. It must be noted that the CIDR on one VPC network cannot overlap with the CIDR on another VPC network.

In the following diagram, you will see two projects, P1 and P2, that have two virtual networks that are attempting to peer. This will be an invalid peering configuration because both the projects have overlapping subnets, which causes routing issues:

This scenario is also valid when there is more than one VPC network attempting to peer with an overlapping subnet in the peering chain. The following diagram illustrates this example, where project P3 has an overlapping subnet with project P1:

In an already peered network, GCP checks for any overlap when a new subnet is created. If there is an overlap, the new subnet creation will fail but the peering between the networks will not break. The following is an illustration of this subnet creation check. As you can see, virtual network N2 has a new subnet, Subnet_3, that overlaps Subnet_1 in virtual network, N1. GCP will check to ensure that there is no overlap during subnet creation and will take corrective action if there is overlap:

GCP also ensures this subnet overlap check happens when multiple networks are peered. In the following diagram, you will see subnet creation in virtual network N3 will fail because of an overlapping subnet in virtual network N1. It is important to note that subnet creation will fail but not the peering:

Some things to remember about VPC network peering:

  • One VPC network can peer with multiple VPC networks. However, there is a limit. A network can have up to 25 directly peered networks that include both active and inactive peers.
  • A VPC network can have up to 7,500 VM instances in itself and in all directly peered networks.
  • An important point to remember is that only VPC networks are supported for peering and not legacy networks.
  • Once you peer two networks, every internal private IP becomes accessible across the peered networks. This, in effect, becomes a huge private network with multiple subnets in place guided by firewall rules that can further restrict traffic, if need be. VPC peering does not provide specific routing controls so any filtering of traffic based on CIDRs is not possible. If any filtering is needed, firewall rules need to be in place to allow or deny traffic to specific IPs.
  • When multiple VPC networks are connected, dissociative peering is not supported. This means if two networks are peered with a common network and are not peered directly with each other, they still cannot talk to each other. As an example, if N1 is peered with N2 and N3 ,and N2 and N3 are not peered directly, then N2 cannot talk to any instances in N3.
  • An instance can have multiple network interfaces, each connected to a different VPC network.

Let’s set up VPC peering:

  1. I created two projects called us-project1 and asia-project1. The aim here is to create two VPC networks in each of these regions and establish peering between them:
  1. Let’s create a VPC network under the asia-project1 project. Let’s call it asia-vpc-network. Select any Asia region for this VPC. Create this network with a subnet:
  1. Now, let’s create another VPC network under the us-project1 project and call it us-vpc-network. Select any US region for this VPC. Create this network with a subnet:
Remember that VPC peering does not work with overlapping subnets.

Now that we have established two VPC networks in two completely different regions, let’s go ahead and peer them with each other.

Under the us-project1 project:

  1. Click on VPC peering on the left menu.
  2. Click on Create connection from the introduction screen.
  3. Make sure you note down the project ID for both the projects and also the VPC networks we wish to peer:
  1. Click Continue.
  2. Enter the following details:
Remember your Project ID will be different to what I have. Also make sure the VPC network name matches exactly what you have created.
  1. Click Create. The VPC on the US region is now created:

We now need to create the VPC from the Asia region to complete the connection:

  1. Switch the project to asia-project1 project and click on VPC peering.
  2. Click on Create connection and click Continue:
  1. Fill out the VPC peering info and make sure you use your Project ID that was assigned to your project:
  1. Click Create. You will immediately see a Connected status:
  1. Check the VPC peering status in your other project. It should also show Connected.

We have successfully established the peering between two sites across two different continents. All resources deployed in these two VPC networks will be able to communicate with each other over internal networks.

Comments are closed.