Private NAT is a Google Cloud software-defined managed service that performs private-to-private network address translation to resolve IP address conflicts between connected networks. A Cloud NAT gateway for Private NAT operates without proxy virtual machines (VMs), relying on Cloud Router as its control plane and Google's Andromeda software for data-plane packet processing. Each gateway is attached to a single Virtual Private Cloud (VPC) network, region, and Cloud Router instance. When outbound traffic leaves a VM located in an overlapping subnet, the gateway applies source NAT to translate the VM's private IP address into an address chosen from a dedicated Private NAT subnet. On return traffic, the gateway performs destination NAT to route packets back to the originating VM, allowing systems in overlapping subnets to reach non-overlapping subnets in external environments.
Remediating overlapping subnets requires creating a dedicated subnet in the source VPC with its purpose set to PRIVATE_NAT. This dedicated range must use IP addresses that do not collide with any subnets in the local VPC or the connected destination networks. Administrators create the Private NAT gateway on Cloud Router and assign NAT rules that define which traffic to translate based on destination conditions. For hybrid connections through Cloud Interconnect or Cloud VPN, the rule uses a match expression such as nexthop.is_hybrid and references the Private NAT subnet as the translation pool. Alternatively, gateways can be configured for Network Connectivity Center (NCC) spokes to translate traffic moving between VPC spokes attached to a central hub.
StudyCerts
StudyCertsSource VM (Overlapping Subnet) ──► Private NAT Gateway (Translates to Private NAT Subnet) ──► Cloud Interconnect / VPN ──► On-Premises Destination
Private NAT depends on dynamic route exchange between Cloud Router and the remote network to direct packets correctly. Cloud Router learns dynamic routes for external non-overlapping subnets over BGP sessions established across Cloud Interconnect or Cloud VPN. The external network must advertise only its non-overlapping routes to Google Cloud, and Cloud Router must advertise the Private NAT subnet range back to the external network. Security evaluation follows a strict sequence on the VM's virtual network interface: firewall rules check outbound traffic before source NAT translation occurs, and they evaluate inbound return traffic after destination NAT translation completes. The Private NAT gateway itself requires no special firewall rules.
Choose Private NAT when IP address spaces overlap between a Google Cloud VPC and an on-premises or secondary cloud network, and renumbering either environment is not feasible. The architecture enables communication between environments while avoiding the extensive downtime and administrative effort of re-addressing entire networks. However, Private NAT supports only outbound-initiated sessions and their direct response packets, strictly preventing unsolicited inbound connections from external hosts. Additionally, the service supports only TCP and UDP traffic and does not process ICMP. Administrators must size the Private NAT subnet accurately during initial creation because the subnet cannot be resized later.
Custom IP address ranges allow network administrators to specify customer-owned or third-party cloud IP addresses on Cloud Interconnect and Cross-Cloud Interconnect VLAN attachments. When custom router IP addresses are assigned to a VLAN attachment, Google Cloud creates an internal range resource that reserves that exact IP address using a /32 mask for IPv4 or a /128 mask for IPv6 inside the VPC. Provisioning these ranges requires enabling the Network Connectivity API and assigning the Compute Network Admin role (roles/compute.networkAdmin) with the networkconnectivity.internalRanges.create permission.
Candidate Router Addresses (/29 or /30 IPv4; /125 or /126 IPv6) ──► VLAN Attachment ──► Internal Range Resource (Reserves /32 or /128)
Addressing rules enforce strict subnet sizing and hygiene for candidate router addresses:
--candidate-cloud-router-ip-address and --candidate-customer-router-ip-address) must use a /29 or /30 mask within the same subnet, and link-local IPv4 addresses must strictly use /29.--candidate-cloud-router-ipv6-address and --candidate-customer-router-ipv6-address) must use a /125 or /126 mask within the same subnet and cannot use link-local or unique local address (ULA) spaces.Private Service Connect (PSC) enables secure, private layer 4 connections from consumer VPC networks to Google-managed and third-party services using internal IP addresses. A consumer establishes connectivity by creating a forwarding rule that claims an internal IP address from a regular consumer subnet. In the producer network, incoming traffic targets a service attachment associated with an internal load balancer or Secure Web Proxy instance, using a dedicated PSC NAT subnet to translate incoming source addresses. The consumer endpoint and the target service attachment must reside within the same Google Cloud region.
Consumer Subnet (PSC Endpoint IP) ──► NAT Translation ──► Producer VPC (Service Attachment + PSC NAT Subnet) ──► Producer Service
Addressing configurations between endpoints and service attachments follow defined translation rules:
Private services access (PSA) uses VPC Network Peering to connect a customer VPC network directly to Google-managed service networks. The consumer administrator must reserve an internal IPv4 address range of /24 or larger before creating the peering connection. Google Cloud then allocates subnets from this reserved block to host managed resources, such as Vertex AI clusters and Google Cloud VMware Engine components, inside the producer VPC.
Managed services require specific subnet sizing based on their operational workload:
/29 subnet for managed notebook instances./21 subnet for orchestration pipelines and private prediction endpoints./19 subnet for distributed worker pools./16 subnet to support high-throughput vector indexing queries./26 subnet for public IP edge services and internet access routing.Because VPC Network Peering does not automatically forward routes to external networks, Cloud Router must advertise the reserved PSA range as a custom route over BGP so on-premises clients can reach producer services. The peering connection must also have custom route import and export flags enabled.
Regional Envoy-based Application Load Balancers and Secure Web Proxies require a dedicated proxy-only subnet to supply internal IP addresses to proxy instances. A VPC network supports only one active proxy-only subnet per region, which must use the role ACTIVE and the purpose REGIONAL_MANAGED_PROXY with a recommended /23 CIDR range. When backends reside in an on-premises data center or another cloud, Cloud Router must advertise the proxy-only subnet over the hybrid connection so backends can return traffic directly to the Envoy proxies.
Client Request ──► Load Balancer IP ──► Proxy-Only Subnet (Envoy) ──► Hybrid Route ──► On-Premises Backend
Google Kubernetes Engine (GKE) VPC-native clusters require structured IP allocations across primary and secondary subnet ranges:
ClusterIP addresses to Kubernetes Services, scaling from /28 (16 Services) up to /16 (65,536 Services), with /20 (4,096 Services) used as the default GKE-managed allocation./64 primary IPv6 subnet, allocating a /96 prefix to each node, a /112 range for Pods on that node, and a /112 secondary range for Services.Hybrid IP allocation requires planning non-overlapping address spaces across on-premises data centers, Google Cloud VPCs, and remote clouds to ensure unambiguous packet delivery. When the same IP ranges exist on both sides of a hybrid connection, routers cannot identify the correct destination, leading to dropped packets and service outages. In VMware Engine deployments, management ranges, NSX workload segments, and HCX components must all use IP ranges distinct from on-premises subnets. Network teams must discover and remove any overlapping address ranges before establishing Cloud Interconnect attachments or Cloud VPN tunnels.
Cloud Router enforces strict limits on the number of route entries it can learn and advertise, which shapes IP planning across hybrid topologies. In any single region, Cloud Router can advertise a maximum of 250 unique routes from VMware Engine to a VPC network over private services access. This limit encompasses private cloud management networks, NSX segments, and HCX subnets. Network architects must use route summarization to combine multiple smaller subnets into larger CIDR blocks, such as aggregating four contiguous /24 subnets (10.10.10.0/24 through 10.10.13.0/24) into a single /22 summary route (10.10.10.0/22) to avoid exceeding route propagation limits.
VPC-native GKE clusters require separate secondary IP address ranges to ensure node, Pod, and Service networks do not exhaust address space. The size of the secondary range for Services directly dictates the maximum number of Kubernetes Services supported in a cluster:
/28 supports 16 Services./27 supports 32 Services./26 supports 64 Services./25 supports 128 Services./24 supports 256 Services./23 supports 512 Services./22 supports 1,024 Services./21 supports 2,048 Services./20 (GKE default) supports 4,096 Services.Multiple GKE clusters in the same subnetwork can share a primary IP range for worker nodes, but one cluster may consume the shared address pool and prevent others from scaling. While secondary Pod ranges cannot be shared across clusters, multiple clusters can share the same user-managed secondary IPv4 range for Services by referencing that identical range during cluster creation.
Dual-stack networking in GKE enables clusters to assign both IPv4 and IPv6 addresses to nodes and Pods within custom-mode VPC subnets. Dual-stack operation requires VPC-native clusters running GKE Dataplane V2. The subnetwork allocates a /64 IPv6 block as its primary range, assigning a /96 prefix to each node, a /112 prefix to Pods running on that node, and a separate /112 range for dual-stack Services. For IPv6 addressing types, GKE assigns public, internet-routable addresses from the 2600:1900/28 range when set to EXTERNAL, or private internal addresses from the fd20::/20 Unique Local Address (ULA) range when configured for INTERNAL access.
Hybrid network topologies dictate how subnets, routes, and address ranges are distributed across Google Cloud and on-premises environments:
/24 or larger, from which Google Cloud carves subnets for managed services like Vertex AI and VMware Engine./32 IPv4 or /128 IPv6 mask./20 secondary range supporting 4,096 Services, and multiple clusters can share the same user-managed secondary range for Services.Deploy Private NAT when an enterprise VPC network contains subnet ranges that overlap with an on-premises or secondary cloud network, and renumbering either side is operationally impossible or too costly. Private NAT translates outbound-initiated traffic into a dedicated, non-overlapping subnet so systems can communicate across hybrid links without re-addressing entire networks.
Private NAT supports only outbound-initiated TCP and UDP connections along with their inbound return packets. It does not permit unsolicited inbound connections initiated from the external network, and it does not support ICMP traffic.
Private Service Connect natively supports IPv4-to-IPv4 and IPv6-to-IPv6 connections, and it automatically translates IPv6 consumer endpoint traffic to reach IPv4 producer service attachments. However, an IPv4 consumer endpoint cannot connect to an IPv6 producer service attachment.
VPC Network Peering and proxy infrastructure do not automatically advertise internal service ranges to external networks. Cloud Router must advertise proxy-only subnets and private services access allocations as custom BGP routes so on-premises clients and hybrid backends know the return path for reaching Envoy proxies and Google-managed services.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills