Cloud NAT product interactions

This page describes the important interactions between Cloud NAT and other Google Cloud products.

Routes interactions

A Public NAT gateway can only use routes whose next hops are the default internet gateway. Each Virtual Private Cloud (VPC) network starts with a default route whose destination is 0.0.0.0/0 and whose next hop is the default internet gateway. For important background information, see the routes overview.

The following examples illustrate situations that could cause Public NAT gateways to become inoperable:

• If you create a custom static route with next hops set to any other type of custom static route next hop, then packets with destination IP addresses matching the destination of the route are sent to that next hop instead of to the default internet gateway. For example, if you use virtual machine (VM) instances running a NAT gateway, firewall, or proxy software, you create custom static routes to direct traffic to those VMs as the next hop. The next-hop VMs require external IP addresses. Thus, traffic from the VMs that rely upon the next-hop VMs or the next-hop VMs themselves cannot use Public NAT gateways.

• If you create a custom static route whose next hop is a Cloud VPN tunnel, Public NAT does not use that route. For example, a custom static route with destination 0.0.0.0/0 and a next hop Cloud VPN tunnel directs traffic to that tunnel, not to the default internet gateway. Therefore, Public NAT gateways cannot use that route. Similarly, Public NAT gateways cannot use custom static routes with more specific destinations, including 0.0.0.0/1 and 128.0.0.0/1.

• If an on-premises router advertises a custom dynamic route to a Cloud Router managing a Cloud VPN tunnel or VLAN attachment, Public NAT gateways cannot use that route. For example, if your on-premises router advertises a custom dynamic route with destination 0.0.0.0/0, 0.0.0.0/0 would be directed to the Cloud VPN tunnel or VLAN attachment. This behavior holds true even for more specific destinations, including 0.0.0.0/1 and 128.0.0.0/1.

Private NAT uses the following routes:

• For Inter-VPC NAT, Private NAT uses only subnet routes exchanged by two Network Connectivity Center VPC spokes that are attached to a Network Connectivity Center hub. For more information about Network Connectivity Center VPC spokes, see VPC spokes overview.
• For Hybrid NAT (Preview), Private NAT uses the dynamic routes learned by Cloud Router over Cloud VPN.

Private Google Access interaction

A Public NAT gateway never performs NAT for traffic sent to the select external IP addresses for Google APIs and services. Instead, Google Cloud automatically enables Private Google Access for a subnet IP address range when you configure a Public NAT gateway to apply to that subnet range, either primary or secondary. As long as the gateway provides NAT for a subnet's range, Private Google Access is in effect for that range and cannot be disabled manually.

A Public NAT gateway does not change the way that Private Google Access works. For more information, see Private Google Access.

Private NAT gateways do not apply to Private Google Access.

Shared VPC interaction

Shared VPC enables multiple service projects in a single organization to use a common, Shared VPC network in a host project. To provide NAT for VMs in service projects that use a Shared VPC network, you must create Cloud NAT gateways in the host project.

VPC Network Peering interaction

Cloud NAT gateways are associated with subnet IP address ranges in a single region and a single VPC network. A Cloud NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks that are connected by using VPC Network Peering or by using Network Connectivity Center VPC spokes, even if the VMs in peered networks are in the same region as the gateway.

GKE interaction

A Public NAT gateway can perform NAT for nodes and Pods in a private cluster, which is a type of VPC-native cluster. The Public NAT gateway must be configured to apply to at least the following subnet IP address ranges for the subnet that your cluster uses:

• Subnet primary IP address range (used by nodes)
• Subnet secondary IP address range used for Pods in the cluster
• Subnet secondary IP address range used for Services in the cluster

The simplest way to provide NAT for an entire private cluster is to configure a Public NAT gateway to apply to all the subnet IP address ranges of the cluster's subnet.

For background information about how VPC-native clusters utilize subnet IP address ranges, see IP ranges for VPC-native clusters.

When a Public NAT gateway is configured to provide NAT for a private cluster, it reserves NAT source IP addresses and source ports for each node VM. Those NAT source IP addresses and source ports are usable by Pods because Pod IP addresses are implemented as alias IP ranges assigned to each node VM.

Google Kubernetes Engine (GKE) VPC-native clusters always assign each node an alias IP range that contains more than one IP address (netmask smaller than /32).

• If static port allocation is configured, the Public NAT port reservation procedure reserves at least 1,024 source ports per node. If the specified value for minimum ports per VM is greater than 1,024, that value is used.

• If dynamic port allocation is configured, the specified value for minimum ports per VM is initially allocated per node. The number of allocated ports subsequently varies between the specified values for minimum and maximum ports per VM, based on demand.

For information about Pod IP address ranges and VPC-native clusters, see Subnet secondary IP address range for Pods.

Independent of Public NAT, Google Kubernetes Engine performs source network address translation (source NAT or SNAT) by using software running on each node when Pods send packets to the internet, unless you've changed the cluster's IP masquerade configuration. If you need granular control over egress traffic from Pods, you can use a network policy.

Under certain circumstances, Public NAT can be useful to non-private VPC-native clusters as well. Because the nodes in a non-private cluster have external IP addresses, packets sent from the node's primary internal IP address are never processed by Cloud NAT. However, if you want your public cluster to use static external IP addresses that are provided by a Public NAT gateway, do the following:

• Configure the Public NAT gateway to apply only to the secondary IP address range of the cluster's pod objects.
• Configure your cluster to disable the default SNAT, so that GKE preserves the IP addresses for the source pod objects of the packets that are sent to the internet.
• Configure your IP masquerade agent by specifying appropriate CIDRs as the non-masquerade destinations, so that the agent preserves the IP addresses for the source pod objects of the packets that are sent to the non-masquerade destinations.

The following example shows a typical interaction of Public NAT with GKE:

Public NAT with GKE (click to enlarge).

In this example, you want your containers to be NAT translated. To enable NAT for all the containers and the GKE node, you must choose all the IP address ranges of Subnet 1 as the NAT candidate:

• Subnet primary IP address range: 10.240.0.0/24
• Subnet secondary IP address range used for Pods: 10.0.0.0/16

It is not possible to enable NAT for only Pod1 or Pod2.

A Private NAT gateway can perform NAT for nodes and Pods in a private cluster and in a non-private cluster. The Private NAT gateway automatically applies to all the subnet IP address ranges for the private subnet that your cluster uses.

Direct VPC egress interactions

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Public NAT gateways can perform NAT for Cloud Run services or jobs that are configured with Direct VPC egress. To enable your Direct VPC egress instances to use a Public NAT gateway, configure your Public NAT gateway with the following settings:

• Specify the --nat-all-subnet-ip-ranges flag to let all IP address ranges of all subnets in the region to use the Public NAT gateway.
• Set the value of the--endpoint-types flag to ENDPOINT_TYPE_VM. This value ensures that only VMs (including Direct VPC egress VMs) can use the Public NAT gateway.
• In case of static port allocation, set the value of the --min-ports-per-vm flag to four times the number of ports required by a single Cloud Run instance.
• In case of manual NAT IP address allocation, assign an appropriate number of IP addresses to your Public NAT gateway to account for the summation of the number of Google Cloud instances and the number of Direct VPC egress instances that you have deployed in your VPC network.

In addition to the gateway configuration, to send egress traffic from a Cloud Run service or job, you must set the --vpc-egress flag to all-traffic when you create the service or job.

If you have configured a Cloud Run service or job that has the --vpc-egress flag set to private-ranges-only, then the service or job sends traffic only to internal IP addresses. You don't need a Public NAT gateway for routing traffic to internal destinations.

To prevent Cloud Run services or jobs that have the --vpc-egress flag set to private-ranges-only from using a Public NAT gateway, do the following:

• Configure the Public NAT gateway with the --nat-custom-subnet-ip-ranges flag.
• Set the value of the --nat-custom-subnet-ip-ranges flag to the subnet names where you have deployed Cloud Run services or jobs with the --vpc-egress flag set to all-traffic.

The following limitations apply to Cloud Run services and jobs that use Public NAT gateways:

• Cloud NAT metrics for Direct VPC egress endpoints aren't exported to Cloud Monitoring.
• Cloud NAT logs for Direct VPC egress don't display the name of a Cloud Run service, revision, or job.

You can't use Private NAT gateways with Direct VPC egress instances.

Connectivity Tests interactions

You can use Connectivity Tests to check connectivity between network endpoints that use Cloud NAT configurations. You can run Connectivity Tests on networks that use either Public NAT gateways or Private NAT gateways, or both.

You can view the NAT configuration details in the Configuration analysis trace pane on the Connectivity test details page.

Cloud Load Balancing interactions

Google Cloud regional internal Application Load Balancers and regional external Application Load Balancers communicate with multiple regional internet network endpoint group (NEG) backends. By configuring Cloud NAT gateways for the regional internet NEGs, you can allocate your own set of external IP address ranges from where the Google Cloud traffic should originate. The health checks and data plane traffic are sourced from the NAT IP addresses that you allocate.

Other Google Cloud external load balancers and health check systems communicate with VMs by using special routes. Backend VMs don't require external IP addresses nor does a Cloud NAT gateway manage communication for load balancers and health checks. For more information, see Cloud Load Balancing overview and Health checks overview.

What's next

• Learn about Cloud NAT addresses and ports.
• Set up a Public NAT gateway.
• Configure Cloud NAT rules.
• Set up a Private NAT gateway.