Also read Shared VPCs - for Production and Non Production

Existing CIDR Blocks

  • VPC a - 10.7.0.0/24
  • VPC b - 172.30.0.0/24
  • On Prem CIDR - 10.0.0.0/8

IMP: Since 172.30.0.0/24 may be in use on premises, try and use something close to VPC a - e.g. 10.8.0.0/24

Sharing VPN Tunnel between Projects (VPCs)?

First Option - Create a VPC Peering from Project A (and VPC-a) to Project B (and VPC-b) and  the other way as well (b to a)

One of the main reasons that Peering shows 'inactive' is if there are ANY subnets with overlapping CIDR blocks - even within the default VPC, peering will fail. So - eliminate the default VPC.

Firewall Rules - Default - all egress is allowed. For testing, create a FW rule to allow all INGRESS TCP traffic . Of course, SSH (22 ) should be allowed for SSH accesss - works automatically in Chrome Browser - without any need to download of keys.

Even though the PEERING shows as ACTIVE, it does not mean your on prem can route to the PEERED VPC.  Depending on the CIDR Blocks in use (for e.g. your on prem may be using 172.30.0.0/24...., which is the same CIDR block as the VPC b).

So - Peered VPCs break (may not work) at run time - which is not great. The best thing to do is to a SHARED VPC (using a host project).

Shared VPC and Shared HOST project

Step 1 - Create a Shared Host Project (it is just a regular project UNDER the top level ORG). This project will HOST the shared VPC and the shared Subnets inside the shared VPC.

To create a SHARED VPC, you need to have the following role:

  • Shared VPC Admin (compute.networkAdmin and resourcemanager.projectIamAdmin)

Shared VPCs are in a SINGLE account , PEERING can be across accounts (or within the same project)

Shared VPCs are a convenient way to share out networking elements (like subnets) from one project to another.

Shared VPCs are NOT for sharing network resources across Environments

One common design that may seem appealing is to simply use a single HOST VPC - and use it to attach service projects that are PRODUCTION and NON PRODUCTION.

This is not a recommended route - since it is extremely easy to inadvertently share out a subnet to a Service project that may not be the correct one.

To correctly use Shared VPCs for PRODUCTION and NON PRODUCTION environments, review this post.

Summary

Shared VPC is a convenient way to share subnetworks across projects.

Peering is a way to share networks within the same project or ACROSS different accounts (B2B vendors etc.)




Need an experienced AWS/GCP/Azure/DevSecOps Professional to help out with your Public Cloud Strategy? Set up a time with Anuj Varma.