Cloud NAT (network address translation) lets certain resources without external IP addresses create outbound connections to the internet.
Cloud NAT provides outgoing connectivity for the following resources:
- Compute Engine virtual machine (VM) instances without external IP addresses
- Private Google Kubernetes Engine (GKE) clusters
- Cloud Run instances through Serverless VPC Access
- Cloud Functions instances through Serverless VPC Access
- App Engine standard environment instances through Serverless VPC Access
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 (source NAT or SNAT) for VMs without external IP addresses. Cloud NAT also provides destination network address translation (destination NAT or DNAT) for established inbound response packets.
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.
Cloud NAT provides the following benefits:
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.
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.
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.
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.
Cloud NAT can be configured to provide NAT to the internet for packets sent from the following:
The Compute Engine 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.
For GKE clusters, Cloud NAT can provide service even if the cluster has external IP addresses in certain circumstances. For details, see GKE interaction.
Cloud NAT allows outbound connections and the inbound responses to those connections. Each Cloud NAT gateway performs source NAT on egress, and destination NAT 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 Compute Engine VM's network interface as long as that network interface doesn't have an external IP address assigned to it. For GKE clusters, Cloud NAT can provide service even if the cluster nodes have external IP addresses in certain circumstances. For details, see GKE interaction.
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.
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.
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, Endpoint-Independent Mapping is disabled when you create a NAT gateway.
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.
Cloud NAT is a Port Restricted Cone NAT as defined in RFC 3489.
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.
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
|1200 seconds (20 minutes)||Yes|
TCP Transitory Connection Idle Timeout
RFC 5382 REQ-5
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.
TCP TIME_WAIT Timeout
RFC 5382 REQ-5
Note: Regardless of the value that you set for this timeout, Cloud NAT might require additional time (generally less than 30 seconds) before a NAT source IP address and source port tuple can be used to process a new connection.
ICMP Mapping Idle Timeout
RFC 5508 REQ-2
|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)||
For more information, see Delay for TCP source port reuse.
The following sections describe 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. For important background information, see the
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 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 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/0and 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
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. 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.
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.
GKE VPC-native clusters always assign each
node an alias IP range that contains more than one IP address (netmask smaller
/32). Therefore, the Cloud NAT port reservation
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
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.
Cloud NAT rules
The NAT rules feature lets you create access rules that define how Cloud NAT is used to connect to the internet. NAT rules support source NAT based on destination address.
When you configure a NAT gateway without NAT rules, the VMs using that NAT gateway use the same set of NAT IP addresses to reach all internet addresses. If you need more control over packets that pass through Cloud NAT, you can add NAT rules. A NAT rule defines a match condition and a corresponding action. After you specify NAT rules, each packet is matched with each NAT rule. If a packet matches the condition set in a rule, then the action corresponding to that match occurs.
NAT rules specifications
Before working with NAT rules, note the following specifications:
- A rule number uniquely identifies a NAT rule. No two rules can have the same rule number.
- Default NAT rule
- Each NAT configuration has a default rule.
- The default rule is applied if no other NAT rule matches in the same NAT configuration.
- The rule number of the default rule is
- Cloud NAT rules are supported only when the value of the NAT IP allocate
- Destination IP CIDRs in the match condition must not overlap across NAT rules. There can be at most one rule that can match any given packet.
- NAT IP addresses across NAT rules must not overlap.
- A rule must either have a non-empty
sourceNatDrainIP address. If the rule has an empty
sourceNatActiveIP address, new connections that match the NAT rule are dropped.
- NAT rules cannot be added to a NAT gateway that has Endpoint-Independent Mapping enabled. You cannot enable Endpoint-Independent Mapping on a NAT gateway that has NAT rules in it.
In addition, all VMs get ports assigned to them from the value for minimum ports per VM for each Cloud NAT rule. If the ports allocated to a VM from a NAT rule are exhausted, new connections that match the NAT rule are dropped.
For example, if you configure 4,096 ports per VM and have 16 VMs and 2 NAT rules
rule1 with 1 IP address and
rule2 with 2 IP addresses), alongside the default rule
default) with 2 IP addresses, all 16 VMs would get 4,096 ports in each bundle
of NAT rules. In this example, there are no issues in
all their VMs, but
rule1 isn't able to allocate ports for all its VMs.
Therefore, traffic from VMs that needs to go through
rule1 might be dropped
and show signs of being out of resources because the traffic does not use the
For more information about NAT rule configurations, see the NAT rules example.
Rule expression language
NAT rules are written using Common Expression Language syntax.
An expression requires two components:
- Attributes that can be inspected in rule expressions.
- Operations that can be performed on the attributes as part of an expression.
For example, the following expression uses the attributes
188.8.131.52/24 in the operation
inIpRange(). In this case, the expression
returns true if
destination.ip is within the
198.51.100.0/24 IP address range.
NAT rules support only the following attributes and operations:
Attributes represent information from an outgoing packet, such as the destination IP address.
||Destination IP address of the packet|
The following reference describes the operators that you can use with attributes to define rule expressions.
||inIpRange(X, Y) returns true if IP CIDR range Y contains the IP address X.|
||Logical operator. x || y returns true if x or y is true.|
||Equals operator. x == y returns true if x is equal to y.|
Match traffic with destination IP address
"destination.ip == '198.51.100.20'"
Match traffic with destination IP address
"inIpRange(destination.ip, '198.51.100.10/30') || destination.ip == '198.51.100.20'."
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 by 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 by using either its primary internal IP address or an alias IP range from the primary IP address range of
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
Cloud NAT rule configuration example
The following example illustrates how you might want to use NAT rules
when your destination allows access from only a few IP addresses. You want to
make sure that the traffic to such destinations from your Google Cloud
VMs in private subnets are source NAT-translated with those permitted IP
addresses only. You do not want to use these IP addresses for other
destinations. Consider the following requirements for VMs in the subnet
10.10.10.0/24 in VPC network
- The VMs must use NAT IP address
203.0.113.20to send traffic to destination
- The VMs must use NAT IP address
203.0.113.30to send traffic to destination
- The VMs must use NAT IP address
203.0.113.40to send traffic to any other internet destination.
For all other subnets in VPC network
test, VMs must use NAT IP
203.0.113.10 to send traffic to any destination.
You can use NAT rules for this example, but you need two NAT gateways because
10.10.10.0/24 has NAT rules that are different from the other
subnets. To create this configuration, follow these steps:
- Create NAT gateway (NAT GW 1) for subnet S1 with NAT IP address
203.0.113.40and add the following rules:
- NAT rule 1 in NAT GW 1: When the destination is
198.51.100.20/30, use source NAT with
- NAT rule 2 in NAT GW 1: When the destination is
198.51.100.31, use source NAT with
- NAT rule 1 in NAT GW 1: When the destination is
- Create NAT gateway 2 (NAT GW 2) for all other subnets (list all the
subnets except S1) and assign NAT IP address as
203.0.113.10. No NAT rules are needed in this step.
- Learn about Cloud NAT addresses and ports.
- Create your own Cloud NAT gateway.
- Create your own Cloud NAT rules.
- Create an example Compute Engine setup.
- Create an example GKE setup.
- Troubleshoot common issues.