Private NAT

Private NAT enables private-to-private translations across Google Cloud networks. Inter-VPC NAT, a Private NAT offering, lets you create a Private NAT gateway that works in conjunction with Network Connectivity Center Virtual Private Cloud (VPC) spokes to perform network address translation (NAT) between VPC networks.

Basic Private NAT configuration and workflow

The following diagram shows a basic Inter-VPC NAT configuration:

Inter-VPC NAT translation example.
Inter-VPC NAT translation example (click to enlarge).

In this example, Inter-VPC NAT is set up as follows:

  • The pvt-nat-gw gateway is configured in vpc-a to apply to all the IP address ranges of subnet-a in the us-east1 region. Using the NAT IP ranges of pvt-nat-gw, a virtual machine (VM) instance in subnet-a of vpc-a can send traffic to a VM in subnet-b of vpc-b, even though subnet-a of vpc-a overlaps with subnet-c of vpc-b.
  • Both vpc-a and vpc-b are configured as spokes of a Network Connectivity Center hub.
  • The pvt-nat-gw gateway is configured to provide NAT between VPC networks that are configured as VPC spokes to the same Network Connectivity Center hub.

Example Private NAT workflow

In the preceding diagram, a VM, vm-a with the internal IP address 192.168.1.2 in subnet-a of vpc-a needs to download an update from vm-b with the internal IP address 192.168.2.2 in subnet-b of vpc-b. Both the VPC networks are connected to the same Network Connectivity Center hub as VPC spokes. Assume that vpc-b contains another subnet 192.168.1.0/24 that overlaps with the subnet in vpc-a. For subnet-a of vpc-a to communicate with subnet-b of vpc-b, you need to configure a Private NAT gateway, pvt-nat-gw, in vpc-a as follows:

  • Private NAT subnet: 10.1.2.0/29. Create this subnet, with the purpose PRIVATE_NAT before configuring the Private NAT gateway. Ensure that this subnet does not overlap with an existing subnet in any of the VPC spokes attached to the same Network Connectivity Center hub.
  • A NAT rule whose nexthop.hub matches the Network Connectivity Center hub URL.
  • NAT for all address ranges of subnet-a.

The following table summarizes the network configuration specified in the preceding example:

Network name Network component IP address/range Region
vpc-a

subnet-a 192.168.1.0/24 us-east1
vm-a 192.168.1.2
pvt-nat-gw 10.1.2.0/29
vpc-b

subnet-b 192.168.2.0/24 us-west1
vm-b 192.168.2.2
subnet-c 192.168.1.0/24
vm-c 192.168.1.3

Private NAT follows the port reservation procedure to reserve the following NAT source IP address and source port tuples for each of the VMs in the network. For example, the Private NAT gateway reserves 64 source ports for vm-a: 10.1.2.2:34000 through 10.1.2.2:34063.

When the VM uses the TCP protocol to send a packet to the update server 192.168.2.2 on destination port 80, the following occurs:

  • The VM sends a request packet with these attributes:

    • Source IP address: 192.168.1.2, the internal IP address of the VM
    • Source port: 24000, the ephemeral source port chosen by the VM's operating system
    • Destination address: 192.168.2.2, the update server's IP address
    • Destination port: 80, the destination port for HTTP traffic to the update server
    • Protocol: TCP
  • The pvt-nat-gw gateway performs source network address translation (SNAT or source NAT) on egress, rewriting the request packet's NAT source IP address and source port:

    • NAT source IP address: 10.1.2.2, from one of the VM's reserved NAT source IP address and source port tuples
    • Source port: 34022, an unused source port from one of the VM's reserved source port tuples
    • Destination address: 192.168.2.2, unchanged
    • Destination port: 80, unchanged
    • Protocol: TCP, unchanged
  • When the update server sends a response packet, that packet arrives on the pvt-nat-gw gateway with these attributes:

    • Source IP address: 192.168.2.2, the update server's internal IP address
    • Source port: 80, the HTTP response from the update server
    • Destination address: 10.1.2.2, matching the original NAT source IP address of the request packet
    • Destination port: 34022, matching the source port of the request packet
    • Protocol: TCP, unchanged
  • The pvt-nat-gw gateway performs destination network address translation (DNAT) on the response packet, rewriting the response packet's destination address and destination port so that the packet is delivered to the VM that requested the update with the following attributes:

    • Source IP address: 192.168.2.2, unchanged
    • Source port: 80, unchanged
    • Destination address: 192.168.1.2, the internal IP address of the VM
    • Destination port: 24000, matching the original ephemeral source port of the request packet
    • Protocol: TCP, unchanged

Specifications

General specifications

  • Inter-VPC NAT enables VPC network resources in overlapping subnets to communicate with the resources in non-overlapping subnets by using a NAT configuration of type=PRIVATE.
  • To enable Inter-VPC NAT between two VPC networks, configure each VPC network as a VPC spoke of a Network Connectivity Center hub. ​When you create the spoke, you must prevent the overlapping IP address ranges from being shared with other VPC spokes. For more information, see Create a VPC spoke.
  • You need to create a custom NAT rule by referencing a Network Connectivity Center hub. The NAT rule specifies a NAT IP address range from a subnet of purpose PRIVATE_NAT that the VMs can use to communicate with another VPC network.
  • Inter-VPC NAT supports address translation for VPC subnets within a region as well as across regions.
  • Private NAT allows outbound connections and the inbound responses to those connections. Each Private NAT gateway performs source NAT on egress, and destination NAT for established response packets.

  • Private NAT does not permit unsolicited inbound requests from peer VPC spokes, even if firewall rules would otherwise permit those requests. For more information, see Applicable RFCs.

  • Each Private NAT gateway is associated with a single VPC network, region, and Cloud Router. The Private 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 Private NAT gateway or Cloud Router.

Routes and firewall rules

Private NAT relies on 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.

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

You don't have to create any special firewall rules that allow connections to or from NAT IP addresses. When a Private 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

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

  • Primary and secondary IP address ranges of all subnets in the region. A single Private 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.
  • Custom subnet list. A single Private NAT gateway provides NAT for the primary internal IP addresses and all alias IP ranges of eligible VMs whose network interfaces use a subnet from a list of specified subnets.

Bandwidth

Using a Private 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 to have multiple network interfaces, each interface must be in a separate VPC network. Consequently, a Private NAT gateway can only apply to a single network interface of a VM. Separate Private NAT gateways can provide NAT to the same VM, where each gateway applies to a separate interface.

NAT IP addresses and ports

When you create a Private NAT gateway, you must specify a subnet of purpose PRIVATE_NAT from which NAT IP addresses are assigned for the VMs. For more information about Private NAT IP address assignment, see Private NAT IP addresses.

You can configure the number of source ports that each Private NAT gateway reserves on each VM for which it is to provide NAT services. You can configure static port allocation, where the same number of ports is reserved for each VM, or dynamic port allocation, where the number of reserved ports can vary between the minimum and maximum limits that you specify.

The VMs for which NAT is to be provided are determined by the subnet IP address ranges that the gateway is configured to serve.

For more information about ports, see Ports.

Applicable RFCs

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

NAT timeouts

Private NAT gateways use the following timeouts. You can modify the default timeout values to decrease or increase the rate at which ports are reused. Each timeout value is a balance between efficient use of Private NAT resources and possible disruption to active connections, flows, or sessions.

Timeout Description Private NAT default Configurable

UDP Mapping Idle Timeout

RFC 4787 REQ-5

Specifies the time in seconds after which UDP flows must stop sending traffic to endpoints so that the Private NAT mappings are removed.

UDP Mapping Idle Timeout affects two endpoints that stop sending traffic to each other. It also affects endpoints that take longer to respond, or if there is increased network latency.

You can increase the specified timeout value to decrease the rate at which ports can be reused. The larger timeout value means that the ports are held for longer connections and also protects against pauses in traffic over a specific UDP socket.

30 seconds Yes

TCP Established Connection Idle Timeout

RFC 5382 REQ-5

Specifies the time in seconds that a connection is idle before the Private NAT mappings are removed.

TCP Established Connection Idle Timeout affects endpoints that take longer to respond, or if there is increased network latency.

You can increase the timeout value when you want to open TCP connections and keep the connections open for a long time without a keepalive mechanism in place.

1200 seconds (20 minutes) Yes

TCP Transitory Connection Idle Timeout

RFC 5382 REQ-5

Specifies the time in seconds that TCP connections can remain in the half-open state before the Private NAT mappings can be deleted.

TCP Transitory Connection Idle Timeout affects an endpoint when an external endpoint takes a longer period than the specified time, or when there is increased network latency. Unlike the TCP Established Connection Idle Timeout, the TCP Transitory Connection Idle Timeout affects only half-open connections.

30 seconds

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

Yes

TCP TIME_WAIT Timeout

RFC 5382 REQ-5

Specifies the time in seconds that a fully closed TCP connection is retained in the Private NAT mappings after the connection expires.

TCP TIME_WAIT Timeout protects your internal endpoints from receiving invalid packets that belong to a closed TCP connection that are retransmitted.

You can decrease the timeout value to improve the reuse of Private NAT ports at the cost of possibly receiving retransmitted packets from an unrelated, previously closed connection.

120 seconds

Note: Regardless of the value that you set for this timeout, Private NAT might require up to an additional 30 seconds before a Private 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

Specifies the time in seconds after which Internet Control Message Protocol (ICMP) Private NAT mappings that don't have any traffic flows are closed.

ICMP Mapping Idle Timeout affects an endpoint when the endpoint takes a longer to respond than the specified time, or when there is increased network latency.

30 seconds Yes

What's next