Egressing from Google Bare Metal Solution

Introduction

Google Cloud Bare Metal Solution (BMS) does not come with access to Google Cloud services, networking services, or the internet by design, this ensures that critical workloads such as Oracle workloads are as secure as possible.

The downside to this is that there is often a need for a subset of applications to egress to the internet. Typically on GCP we would solve a problem like this with Cloud NAT, however BMS is not compatible with Cloud NAT as the traffic does not originate in the Virtual Private Cloud (VPC).

Some options for accessing the internet include:

• Routing outgoing traffic through a NAT gateway running on GCE
• Routing traffic through a Compute Engine VM that serves as a proxy server
• Routing traffic through Cloud VPN or Dedicated Interconnect to on-premises gateways to the internet

This document covers off the first option above of using a NAT Gateway to route traffic to the internet. Other options under consideration have been mapped out here. This document assumes a working knowledge of GCP and networking.

Solution 1: NAT Gateway on GCE

The use of Network Address Translation (NAT) to translate any internal IP’s to public IP’s can be done by NAT’ing the traffic using iptables.

Simple NAT on GCE

Now if we run critical workloads on BMS, having a single GCE instance would create a single point of failure, to be able to withstand a zonal failure running a Managed Instance Group (MIG) and fronting this MIG with an Internal Load Balancer (ILB) allows for a highly available solution that is resilient to zonal failure.

NAT Managed Instance Group on GCE

The next step is to configure routes for this traffic, in GCP this is simple we can create a tag, however as BMS traffic does not originate in the VPC we cannot. The work around we can apply here is to tag all other traffic in the VPC (shown below is “tagged”), and create a route for untagged traffic to egress via the Load Balancer and NAT VM solution.

Tagging for NAT MIG

The only downside to this solution now is that any untagged traffic will need to egress through this solution, which presents 3 issues:

1. It is time consuming to tag, and ensure all future resources are tagged at creation time
2. Any traffic that is untagged in the entire VPC will egress via this solution, this includes traffic from other regions incurring latency and cost
3. In the even BMS is failed over to a DR region, the route will need to be updated for untagged traffic to egress via a different ILB

Solution 2: Proxy on GCE

The use of a proxy running on GCE such as Squid Proxy could also work, this would require setting the http_proxy on any servers running in the BMS extension, but this option makes the tagging and routing simpler.

Squid Proxy on GCE

Again having a single point of failure is undesirable, but as above is solved with a MIG, and an ILB as shown:

Squid Proxy on GCE MIG with ILB

The downside to this approach is making sure that the proxy config is set on each VM in BMS, and that any applications support the use of a proxy.