Cloud NAT overview

Cloud NAT (network address translation) lets Google Cloud virtual machine (VM) instances without external IP addresses and private Google Kubernetes Engine (GKE) clusters send outbound packets to the internet and receive any corresponding established inbound response packets.

Architecture

Cloud NAT is a distributed, software-defined managed service. It's not based on proxy VMs or appliances. Cloud NAT configures the Andromeda software that powers your Virtual Private Cloud (VPC) network so that it provides source network address translation (SNAT) for VMs without external IP addresses. Cloud NAT also provides destination network address translation (DNAT) for established inbound response packets.

Traditional NAT versus Cloud NAT (click to enlarge).
Traditional NAT versus Cloud NAT (click to enlarge)

Cloud NAT implements outbound NAT in conjunction with static routes in your VPC network whose next hops are the default internet gateway. In a basic configuration, a default route in your VPC network meets this requirement.

Cloud NAT does not implement unsolicited inbound connections from the internet. DNAT is only performed for packets that arrive as responses to outbound packets.

Benefits

Cloud NAT provides the following benefits:

  • Security

    You can reduce the need for individual VMs to each have external IP addresses. Subject to egress firewall rules, VMs without external IP addresses can access destinations on the internet. For example, you might have VMs that only need internet access to download updates or complete provisioning.

    If you use manual NAT IP address assignment to configure a Cloud NAT gateway, you can confidently share a set of common external source IP addresses with a destination party. For example, a destination service might only allow connections from known external IP addresses.

  • Availability

    Cloud NAT is a distributed, software-defined managed service. It doesn't depend on any VMs in your project or a single physical gateway device. You configure a NAT gateway on a Cloud Router, which provides the control plane for NAT, holding configuration parameters that you specify. Google Cloud runs and maintains processes on the physical machines that run your Google Cloud VMs.

  • Scalability

    Cloud NAT can be configured to automatically scale the number of NAT IP addresses that it uses, and it supports VMs that belong to managed instance groups, including those with autoscaling enabled.

  • Performance

    Cloud NAT does not reduce the network bandwidth per VM. Cloud NAT is implemented by Google's Andromeda software-defined networking. For more information, see Network bandwidth in the Compute Engine documentation.

Specifications

Cloud NAT can be configured to provide NAT to the internet for packets sent from the following:

  • The VM's network interface's primary internal IP address, provided that the network interface doesn't have an external IP address assigned to it. If the network interface has an external IP address assigned to it, Google Cloud automatically performs one-to-one NAT for packets whose sources match the interface's primary internal IP address because the network interface meets the Google Cloud internet access requirements. The existence of an external IP address on an interface always takes precedence and always performs one-to-one NAT, without using Cloud NAT.

  • An alias IP range assigned to the VM's network interface. Even if the network interface has an external IP address assigned to it, you can configure a Cloud NAT gateway to provide NAT for packets whose sources come from an alias IP range of the interface. An external IP address on an interface never performs one-to-one NAT for alias IP addresses.

Cloud NAT allows outbound and established inbound responses to those connections. Each Cloud NAT gateway performs source network address translation (SNAT) on egress, and destination network address translation (DNAT) for established response packets.

Cloud NAT does not permit unsolicited inbound requests from the internet, even if firewall rules would otherwise permit those requests. For more information, see Applicable RFCs.

Each Cloud NAT gateway is associated with a single VPC network, region, and Cloud Router. The Cloud NAT gateway and the Cloud Router provide a control plane—they are not involved in the data plane, so packets do not pass through the Cloud NAT gateway or Cloud Router.

Routes and firewall rules

Cloud NAT relies on custom static routes whose next hops are the default internet gateway. To fully utilize a Cloud NAT gateway, your VPC network needs a default route whose next hop is the default internet gateway. For more information, see routes interactions.

Cloud NAT does not have any Google Cloud firewall rule requirements. Firewall rules are applied directly to the network interfaces of Compute Engine VMs, not Cloud NAT gateways.

You don't have to create any special firewall rules that allow connections to or from NAT IP addresses. When a Cloud NAT gateway provides NAT for a VM's network interface, applicable egress firewall rules are evaluated as packets for that network interface before NAT. Ingress firewall rules are evaluated after packets have been processed by NAT.

Subnet IP address range applicability

A Cloud NAT gateway can provide NAT services for packets sent from a VM's network interface as long as that network interface doesn't have an external IP address assigned to it. The Cloud NAT gateway can be configured to provide NAT for the VM network interface's primary internal IP address, alias IP ranges, or both. You make this configuration by choosing the subnet IP address ranges to which the gateway should apply.

You can configure a Cloud NAT gateway to provide NAT for the following:

  • Primary and secondary IP address ranges of all subnets in the region. A single Cloud NAT gateway provides NAT for the primary internal IP addresses and all alias IP ranges of eligible VMs whose network interfaces use a subnet in the region. This option uses exactly one NAT gateway per region.

  • Primary IP address ranges of all subnets in the region. A single Cloud NAT gateway provides NAT for the primary internal IP addresses and alias IP ranges from subnet primary IP address ranges of eligible VMs whose network interfaces use a subnet in the region. You can create additional Cloud NAT gateways in the region to provide NAT for alias IP ranges from subnet secondary IP address ranges of eligible VMs.

  • Custom subnet IP address ranges. You can create as many Cloud NAT gateways as necessary, subject to Cloud NAT quotas and limits. You choose which subnet primary or secondary IP address ranges should be served by each gateway.

Bandwidth

Using a Cloud NAT gateway does not change the amount of outbound or inbound bandwidth that a VM can use. For bandwidth specifications, which vary by machine type, see Network bandwidth in the Compute Engine documentation.

VMs with multiple network interfaces

If you configure a VM with multiple network interfaces, each interface must be in a separate VPC network. Consequently, the following is true:

  • A Cloud NAT gateway can only apply to a single network interface of a VM. Separate Cloud NAT gateways can provide NAT to the same VM, where each gateway applies to a separate interface.

  • One interface of a multiple network interface VM can have an external IP address, and thus be ineligible for Cloud NAT, while another one of its interfaces can be eligible for NAT if that interface doesn't have an external IP address, and you've configured a Cloud NAT gateway to apply to the appropriate subnet IP address range.

NAT IP addresses and ports

When you create a Cloud NAT gateway, you can choose to have the gateway automatically allocate regional external IP addresses. Alternatively, you can manually assign a fixed number of regional external IP addresses to the gateway. For details about each method, see NAT IP addresses.

You can configure the number of source ports that each Cloud NAT gateway reserves to each VM for which it should provide NAT services. The VMs for which NAT should be provided are determined by the subnet IP address ranges that the gateway is configured to serve. For more information, see Ports and the Port reservation procedure.

Applicable RFCs

Cloud NAT supports Endpoint-Independent Mapping and Endpoint-Dependent Filtering as defined in RFC 5128. You can enable or disable Endpoint-Independent Mapping. By default, NAT gateway uses Endpoint-Independent Mapping.

Endpoint-Independent Mapping means that if a VM sends packets from a given internal IP address and port pair to multiple different destinations, then the gateway maps all of those packets to the same NAT IP address and port pair, regardless of the destination of the packets. For details and implications pertinent to Endpoint-Independent Mapping, see Simultaneous port reuse and Endpoint-Independent Mapping.

Endpoint-Dependent Filtering means that response packets from the internet are allowed to enter only if they are from an IP address and port that a VM had already sent packets to. The filtering is endpoint-dependent regardless of Endpoint Mapping type. This feature is always on and not user configurable.

For more information about the relationship between ports and connections, see Ports and connections and the NAT flow example.

Cloud NAT is a Port Restricted Cone NAT as defined in RFC 3489.

NAT traversal

If Endpoint-Independent Mapping is enabled, Cloud NAT is compatible with common NAT traversal protocols such as STUN and TURN, if you deploy your own STUN or TURN servers:

  • STUN (Session Traversal Utilities for NAT, RFC 5389) allows direct communication between VMs behind NAT when a communication channel is established.
  • TURN (Traversal Using Relays around NAT, RFC 5766) permits communication between VMs behind NAT by way of a third server where that server has an external IP address. Each VM connects to the server's external IP address, and that server relays communication between the two VMs. TURN is more robust, but consumes more bandwidth and resources.

NAT timeouts

Cloud NAT gateways use the following timeouts.

Timeout Cloud NAT default Configurable

UDP Mapping Idle Timeout

RFC 4787 REQ-5

30 seconds Yes

TCP Established Connection Idle Timeout

RFC 5382 REQ-5

1,200 seconds (20 minutes) Yes

TCP Transitory Connection Idle Timeout

RFC 5382 REQ-5

30 seconds

Note: Regardless of the value that you set for this timeout, Cloud NAT might require up to an additional 30 seconds before a NAT source IP address and source port tuple can be used to process a new connection.

Yes

ICMP Mapping Idle Timeout

RFC 5508 REQ-2

30 seconds Yes
Delay before reusing a 5-tuple for a new TCP connection (NAT source IP address and source port tuple combined with destination address, destination port, and protocol) 120 seconds (2 minutes)

No

For more information, see Delay for TCP source port reuse.

Product interactions

The following sections describe important interactions between Cloud NAT and other Google Cloud products.

Routes interactions

A Cloud NAT gateway can only use routes whose next hops are the default internet gateway. Each 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 Cloud 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, packets with destination IPs matching the destination of the route are sent to that next hop instead of to the default internet gateway. For example, if you use VM instances running NAT, firewall, or proxy software, you would necessarily create custom static routes to direct traffic to those VMs as the next hop. The next-hop VMs require external IP addresses. Thus, neither traffic from the VMs that rely upon the next-hop VMs nor the next-hop VMs themselves could use Cloud NAT.

  • If you create a custom static route whose next hop is a Cloud VPN tunnel, Cloud 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. Consequently, Cloud NAT gateways would not be able to use that route. This holds true even for 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 Cloud Interconnect attachment (VLAN), Cloud 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 Cloud Interconnect attachment (VLAN). This holds true even for more specific destinations, including 0.0.0.0/1 and 128.0.0.0/1.

Private Google Access interaction

Cloud NAT 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 Cloud 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 Cloud NAT gateway does not change the way that Private Google Access works. For more information, see 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 connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.

GKE interaction

A Cloud NAT gateway can perform NAT for nodes and Pods in a private cluster, which is a type of VPC-native cluster. The Cloud 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 Cloud NAT gateway to apply to all of the cluster's subnet's IP address ranges.

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

When a Cloud 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. Because the smallest possible Pod IP address range is 256 IP addresses—subnet mask of /24—the Cloud NAT port reservation procedure reserves at least 1,024 NAT source IP addresses and source ports per node. For information about Pod IP address ranges and VPC-native clusters, see Subnet secondary IP address range for Pods.

Independent of Cloud NAT, GKE performs 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, Cloud NAT can be useful to non-private clusters as well, including both VPC-native and routes-based clusters. 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, packets sent from Pods in a non-private cluster can be processed by a Cloud NAT gateway if both of the following are true:

  • For VPC-native clusters, the Cloud NAT gateway is configured to apply to the secondary IP address range for the cluster's Pods.

  • The cluster's IP masquerade configuration is not configured to perform SNAT within the cluster for packets sent from Pods to the internet.

Cloud Load Balancing interactions

Google Cloud external load balancers and health check systems communicate with VMs by using special routes. Backend VMs do not 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.

Examples

The following examples illustrate Cloud NAT concepts.

Basic NAT configuration

Cloud NAT (click to enlarge).
Cloud NAT (click to enlarge)

In this example:

  • The nat-gw-us-east gateway is configured to apply to the primary IP address range of subnet-1 in the us-east1 region. A VM whose network interface does not have an external IP address can send traffic to the internet by using either its primary internal IP address or an alias IP range from the primary IP address range of subnet-1, 10.240.0.0/16.

  • A VM whose network interface does not have an external IP address and whose primary internal IP address is located in subnet-2 cannot access the internet because no Cloud NAT gateway applies to any IP address range of that subnet.

  • The nat-gw-eu gateway is configured to apply to the primary IP address range of subnet-3 in the europe-west1 region. A VM whose network interface does not have an external IP address can send traffic to the internet by using either its primary internal IP address or an alias IP range from the primary IP address range of subnet-3, 192.168.1.0/24.

GKE example

Cloud NAT with GKE (click to enlarge).
Cloud 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 candidates. It is not possible to enable NAT for only container1 or container2.

What's next