How to setup network connectivity between VPCs in Google Cloud

In this blog, I will explain in high-level three networking capabilities to help you in your architecture design decisions in cases where you need to connect VPCs in Google Cloud.

What is a VPC?

A Virtual Private Cloud (VPC) in Google Cloud is a virtual representation of a physical network. It is a global resource which spans all regions in Google Cloud offering capabilities to build up your network in the cloud at scale. With a VPC, you are able to configure your subnets, firewalls, routing, IP allocation and other networking concepts also found in physical networks.

Why would we need to connect between VPCs?

In some scenario’s, there could arise the need to allow communication between VPCs. whether it is within the same Google Cloud project or not. For example, when an organization is acquired, and you need to allow connectivity between your organizations’ VPC, and the acquired organizations’ VPC. Or when you have certain security requirements where you explicitly need to isolate your VPCs from each other. There are plenty of other scenarios where you could consider connecting VPCs.

VPC connectivity options

Google Cloud offers multiple networking capabilities to connect Google Cloud VPCs to each other. Each with their own characteristics. I will highlight in high-level three commonly used architectures.

VPC peering

VPC peering is a network connectivity service which allows you to connect VPCs. Once enabled, VPCs advertise the subnet routes with each other over a so-called peering connection. This allows both VPCs to be able to communicate with each other in both directions.

When using VPC peering, you have to take into consideration that you are not configuring peering with IP overlap. You first need to resolve any IP overlap between VPC networks before configuring a VPC peering connection.

Also take into consideration that VPC peering in Google Cloud is non-transitive. Which means a peered VPC cannot be used as a transit VPC to other peering connections.

In the architecture below, an example is illustrated how a peering connection between two VPCs looks like.

Source: Google Cloud

Private Service Connect

You might be looking for a more granular approach to connect with other VPCs, by example to connect with a single HTTPS application from another VPC. Or, if you just want to create a one-way connection to another VPC. Private Service Connect might be a better approach due to being able to securely expose services from VPCs instead of the whole network.

Private Service Connect is a cloud-native networking capability which leverages Network Address Translation (NAT) over Google Cloud’s private network between VPCs. It is build on a consumer-producer pattern where the producer is the exposing service and the consumer the client or vice versa, depending on your configuration. It is shipped with an authorization model in which you can control which projects are allowed to connect with each other and how many connections per project are allowed.

When using Private Service Connect, take into consideration that by default the client IP address is translated. The client IP address will not be in the request made to the service you’ve exposed. If you want to send the original client IP address to the exposed service, you could consider enabling the PROXY protocol option to keep the client IP address in the request. This does require that the exposed service is configured to accept PROXY protocol requests.

Below an example architecture connecting VPCs using Private Service Connect Endpoints

Source: Google Cloud

Virtual Machine Proxy

A third option could be Virtual Machine (VM) Proxies with multiple network interfaces. Using VM Proxies allows you to fully tailor your connectivity options to your needs. You configure Compute Engine VM’s with proxy software. For example, Squid or NGINX. The VMs have multiple network interfaces each in the desired VPC to connect with and have the routing tables and proxy configured within the VMs.

Take note that with this approach, the Virtual Machine is acting as the NAT gateway and the client IP address may be translated to the Network Interface of the VM. If you require the client IP address to be included in the request, you have to configure the proxy software to support PROXY protocol in-case of a layer 4 proxy or when creating a layer 7 proxy, add the original IP as a header.

Below a high-level architecture using a VM with two network interfaces (nic0 and nic1) to connect VPCs.

VM Proxy – IP Forwarding

Alternatively, you could enable IP forwarding. With IP forwarding, the Virtual Machine can be configured as a next-hop in the Cloud Router to forward packets to other destinations.

Note: When enabling IP forwarding, firewall rules at VM level are evaluated differently and strict source/destination checks are disabled. Therefore, IP forwarding may also be seen as a security risk.

Which capability should I choose?

The short answer is; this depends on your use-case. To make it a bit easier for you, below a list of pros and cons to help you in your design decisions:

VPC peering

Pros

1. Easy to set up

2. Bidirectional communication due automatic route advertisement.

Cons

1. IP space is shared and could cause IP overlap

2. Non-transitive to other peering connections

Private Service Connect

Pros

1. Granular configuration for connecting specific applications and endpoints between VPCs

2. Leverages NAT to deal with IP overlap

3. Shipped with an authorization model to enforce access-control on top of firewall rules.

4. Can be configured for transitive connections

Cons

1. Exposes services within a network, not the network itself. Making it not suitable for connecting full networks or a multitude of services to each other in some scenario’s.

VM Proxies

Pros

1. Tailor to your own needs. Configure specific endpoints, protocols, access-control and/or network connectivity between VPCs.

2. No IP overlap as the VM is acting as the NAT gateway

3. Bidirectional communication

4. Can be configured for transitive connections

Cons

1. You are responsible for securing, configuring and operating the proxy software.

2. In case of IP forwarding – Firewall rules are evaluated differently and strict host/destination checks are disabled.

Conclusion

You got a glimpse of three commonly used Google Cloud networking architectures to connect VPCs. Each with their own pros and cons. Consider carefully in each scenario what type of connectivity you would like implement in your cloud architecture. All of them might work, but some will work better than others:

• VPC Network peering enables connecting VPCs with little configuration, but has no granular controls to expose specific services. Also, IP spaces cannot overlap.

• Private Service Connect allows you to configure specific services to be securely connected between VPCs without the burden of IP space overlap. But this requires more configuration in comparison to VPC peering and might not be suitable if you need to connect many services between the VPCs in multiple directions.

• VM Proxies allows you to customize your connectivity between VPCs to your own needs by implementing the proxy software of choice or by configuring IP forwarding. However, you have to configure, secure and maintain the proxy yourself.

In my next blog, I will dive deeper into Private Service Connect how it works under the hood and how you can apply it in your projects.

Photo by Alina Grubnyak on Unsplash