Hybrid NAT

Hybrid NAT, a Private NAT offering, lets you perform network address translations (NAT) of IP addresses between a Virtual Private Cloud (VPC) network and an on-premises network or any other cloud provider network. These networks must be connected to your VPC network by using Google Cloud's enterprise hybrid connectivity products such as Cloud VPN.

Specifications

In addition to the generic Private NAT specifications, consider the following specifications for Hybrid NAT:

  • Hybrid NAT lets a VPC network communicate with an on-premises network or any other cloud provider network even if the subnet IP address ranges of the communicating networks overlap. By using a NAT configuration of type=PRIVATE, resources—both in the overlapping and non-overlapping subnets—of the VPC network can connect to the resources in only the non-overlapping subnets of the on-premises network or any other cloud provider network.
  • To enable Hybrid NAT, the on-premises network or the other cloud provider network must advertise its dynamic routes so that your VPC network can learn and use them. Your Cloud Router learns these dynamic routes from Google Cloud's hybrid connectivity solutions such as HA VPN or Classic VPN with dynamic routing configured. The destinations of these dynamic routes are IP address ranges outside your VPC network.

    Similarly, for return traffic, your VPC network must advertise the Private NAT subnet route by using a Cloud Router.

  • Hybrid NAT performs NAT on traffic originating from a VPC network to an on-premises network or any other cloud provider network. The networks must be connected by Cloud VPN over dynamic routes.

  • Hybrid NAT supports existing Classic VPN tunnels only if dynamic routing is enabled.

  • You need to create a custom NAT rule with a match expression nexthop.is_hybrid. The NAT rule specifies a NAT IP address range from a subnet of purpose PRIVATE_NAT that the resources in your VPC network can use to communicate with other networks.

  • Hybrid NAT is supported in all Google Cloud regions except us-central1 and us-east4.

  • The Cloud Router on which you configure Hybrid NAT must be in the same region as the VPC network.

  • The Cloud Router on which you configure Hybrid NAT can't contain any other NAT configuration.

  • You must not configure Hybrid NAT in a VPC network where Cloud Interconnect attachments are present.

Basic Hybrid NAT configuration and workflow

The following diagram shows a basic Hybrid NAT configuration:

Hybrid NAT translation example.
Hybrid NAT translation example (click to enlarge).

In this example, Hybrid 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.
  • By using the NAT IP address 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 an on-premises network or any other cloud provider network, even though subnet-a of vpc-a overlaps with another subnet in the on-premises network or other cloud provider network.

Example Hybrid NAT workflow

In the preceding diagram, 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 an on-premises network or any other cloud provider network. Cloud VPN connects your VPC network to an on-premises network or any other cloud provider network. Assume that the on-premises network or the other cloud provider network 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 the on-premises or the other cloud provider network, you need to configure a Private NAT gateway, pvt-nat-gw, in vpc-a as follows:

  • Private NAT subnet: Create this subnet, with a subnet IP address range of 10.1.2.0/29 and purpose PRIVATE_NAT before configuring the Private NAT gateway. Ensure that this subnet does not overlap with an existing subnet in any of the connected networks.
  • A NAT rule with match='nexthop.is_hybrid'.
  • NAT for all address ranges of subnet-a.

Hybrid 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:

  1. 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
  2. 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
  3. The update server sends a response packet that 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, which matches the original NAT source IP address of the request packet
    • Destination port: 34022, which matches the source port of the request packet
    • Protocol: TCP, unchanged
  4. The pvt-nat-gw gateway performs destination network address translation (DNAT) on the response packet, and rewrites 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

What's next