Cloud NAT (network address translation) allows Google Cloud virtual machine (VM) instances without external IP addresses and private Google Kubernetes Engine (GKE) clusters to send outbound packets to the internet and receive any corresponding established inbound response packets.
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 VPC network so that it also 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.
Cloud NAT implements outbound NAT in conjunction with static routes in your VPC whose next hops are 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.
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 configure a Cloud NAT gateway using manual NAT IP address assignment, 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 provide the control plane for NAT, holding configuration parameters 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 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 works directly with Google's Andromeda software-defined networking.
Cloud NAT can be configured to provide NAT to the internet for packets sent from:
The VM's network interface's primary internal IP address, provided that 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. See Applicable RFCs for more details.
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 default internet gateway. To fully utilize a Cloud NAT gateway, your VPC needs a default route whose next hop is the default internet gateway. See routes interactions for more detail.
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 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:
Primary and secondary IP 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 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 in order to provide NAT for alias IP ranges from subnet secondary IP address ranges of eligible VMs.
Custom subnet IP 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 ranges should be served by each gateway.
Using a Cloud NAT gateway does not change the amount of outbound or inbound bandwidth that a VM can use. Refer to network bandwidth in the Compute Engine documentation for bandwidth specifications, which vary by machine type.
VMs with multiple NICs
If you configure a VM with multiple network interfaces, each interface must be in a separate VPC network. Consequently:
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 multi-NIC 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. See Ports and the Port reservation procedure for details.
When a Cloud NAT gateway performs SNAT on egress for a packet sent from a VM, it can re-use the same source address and source port tuple once per unique destination (destination IP address, destination port, and protocol). A Cloud NAT gateway only performs DNAT for established inbound response packets whose source IP address and source port match the destination IP address and destination port of a corresponding outbound request packet. See Ports and connections and the NAT flow example for details about the relationship between ports and connections.
Because Cloud NAT is endpoint independent, Cloud NAT is compatible with common NAT traversal protocols like 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 once 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.
Cloud NAT gateways use the following timeouts.
|Timeout||Cloud NAT default||Configurable|
|UDP Mapping Idle Timeout
RFC 4787 REQ-5
|TCP Established Connection Idle Timeout
RFC 5382 REQ-5
|1,200 seconds (20 minutes)||Yes|
|TCP Transitory Connection Idle Timeout
RFC 5382 REQ-5
|ICMP Mapping Idle Timeout
RFC 5508 REQ-2
|Delay before re-using a 5-tuple for a new TCP connection
(source address and source port tuple combined with destination address, destination port, and protocol)
|120 seconds (2 minutes)||No
See Source port reuse for TCP connections for details.
The following sections note important interactions between Cloud NAT and other Google Cloud products.
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. Review the routes overview for important
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 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 themselves. 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/0and 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
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/0would be directed to the Cloud VPN tunnel or Cloud Interconnect attachment (VLAN). This holds true even for more specific destinations, including
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. See Private Google Access for details.
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 using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.
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 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 source addresses and source ports for each node VM. Those
NAT source 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 range is 256 IP addresses — subnet mask of
/24 — the Cloud NAT port reservation
at least 1,024 source address and source ports per node. See Subnet secondary
IP address range for
for details about Pod IP ranges and VPC-native clusters.
Independent of Cloud NAT, GKE performs SNAT 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:
- For VPC-native clusters, the Cloud NAT gateway is configured to apply to the secondary IP address range for the cluster's Pods, and
- 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 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. See Cloud Load Balancing overview and Health checks overview for additional details.
The following examples illustrate Cloud NAT concepts.
Basic NAT configuration
In this example:
nat-gw-us-eastgateway is configured to apply to the primary IP address range of
us-east1region. A VM whose network interface does not have an external IP address can send traffic to the internet using either its primary internal IP address or an alias IP range from the primary IP address range of
A VM whose network interface does not have an external IP address and whose primary internal IP address is located in
subnet-2cannot access the internet because no Cloud NAT gateway applies to any IP address range of that subnet.
nat-gw-eugateway is configured to apply to the primary IP address range of
europe-west1region. A VM whose network interface does not have an external IP address can send traffic to the internet using either its primary internal IP address or an alias IP range from the primary IP address range of
In the example above, 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 ranges of Subnet 1 as the NAT candidates. It is not possible to NAT only container1 or container2.