Professional Cloud Network Engineer
Private NAT is a feature of Cloud NAT that enables communication between networks that use the same or non-routable internal IP address ranges, which is common in hybrid or multicloud setups. It solves IP address conflicts by translating the source IP addresses of Virtual Private Cloud (VPC) instances to a different, designated range of private IPs before the traffic leaves Google Cloud. This translation allows an on-premises network and a VPC network that both use the same 10.0.0.0/8 block, for example, to communicate without renumbering either network.
A Private NAT gateway is a regional resource that performs this private-to-private translation. You configure it by creating a Cloud Router with a NAT configuration of type PRIVATE. You must also designate one or more dedicated subnet ranges, called NAT IP subnets, from which the gateway draws IP addresses for translation. The Cloud Router then advertises routes for these NAT IP subnet ranges to connected networks, such as those linked via Network Connectivity Center (NCC). This process hides the original, overlapping source IPs, allowing the on-premises routers to correctly route return traffic back to the translated addresses in Google Cloud.
Network Connectivity Center (NCC) acts as a centralized hub for managing connectivity between VPCs and hybrid resources like Cloud Interconnect or VPN tunnels. For Private NAT to work in a hybrid setup, the Cloud Router must advertise the NAT IP subnet ranges to the NCC hub, which then propagates them to the connected hybrid spokes. A key constraint is that if the NCC hub uses regional dynamic routing mode, it only advertises NAT subnets that are in the same region as the hybrid connection. This ensures traffic flows correctly: a VM's traffic is translated to a NAT IP, travels to on-premises via the hybrid spoke, and the on-premises response returns to that same NAT IP.
Configuring Private NAT requires careful planning of the NAT IP subnet size, as it uses port address translation (PAT) and the number of concurrent connections per VM impacts port usage. This subnet must not overlap with any IP range in the connected networks. A major tradeoff is that Private NAT is primarily for outbound-initiated connections from the VPC; inbound connections from on-premises cannot be initiated unless a mapping was first created by an outbound flow. For full bidirectional communication, alternatives like Private Service Connect or network re-architecting may be needed. While Private NAT adds a slight translation latency, it provides a managed solution to resolve IP overlap.
Private Service Connect (PSC) route propagation across Network Connectivity Center (NCC) allows services published via PSC in one VPC network to be reached by workloads in other connected VPCs and from on-premises environments, all through a central hub. This creates transitive reachability, enabling a consumer in any connected spoke VPC to access a producer service without needing direct peering to the producer's VPC.
NCC uses a hub-and-spoke model. When you enable PSC endpoint propagation on VPC spokes, route information for PSC-published services is automatically exchanged through the NCC hub. For example, if a producer service is published via PSC in Spoke A, the NCC hub learns the route and advertises it to Spoke B and Spoke C. This propagation is a key advantage over traditional VPC Network Peering, as it centralizes service discovery and access across many VPCs without configuring individual peerings.
Fine-grained control over which services are accessible is managed through export and import route policies on the NCC spokes. The producer's spoke must use an export filter to allow its PSC endpoint routes to be advertised to the hub. Consumer spokes must use import filters to allow those routes from the hub into their own routing tables. These policies let administrators create segmented, multi-tenant architectures where only specific spokes can access certain published services.
This architecture supports complex service consumption patterns. You can publish multiple PSC endpoints in a single VPC for different services and control access paths with Cloud Router and VPC firewall rules. For hybrid access, on-premises clients can reach Google APIs or published services directly by having Cloud Router advertise the PSC endpoint IP addresses back across Cloud Interconnect or VPN tunnels. Private Service Connect global access can also provide failover between different PSC endpoints. This allows connectivity to Google APIs, third-party services, and services in other VPCs privately, without internet traffic.
NCC VPC spokes offer specific benefits over VPC Network Peering, including support for up to 250 VPC spokes per hub, centralized export/import filters, and the PSC propagation capability. However, NCC has limitations: it does not propagate source tags or service accounts between VPCs, offers limited options for inserting Network Virtual Appliances (NVAs), and incurs inter-VPC transit costs. Choose NCC VPC spokes when you need PSC propagation and centralized route management. Choose VPC Network Peering if your application doesn't use PSC or if you need to insert NVAs between VPC networks.
Designing hybrid routing involves integrating Cloud Router, Network Connectivity Center (NCC), Private NAT, and Private Service Connect (PSC) to enable private, dynamic connectivity between Google Cloud VPCs and on-premises or other cloud networks. Diagnosing problems requires analyzing BGP advertisements, NAT port usage, and the order of firewall rule evaluation.
Cloud Router exchanges dynamic routes with external routers using BGP over Dedicated Interconnect, Partner Interconnect, or HA VPN tunnels. When configured for global dynamic routing, it learns routes from on-premises in one region and propagates them to all subnets in the global VPC. Cloud Router can also be configured to advertise custom IP prefixes, such as those for PSC endpoints or internal proxy ranges, to on-premises networks. Network Connectivity Center centralizes this by having hybrid spokes (like Interconnect attachments) and VPC spokes connect to a hub. When dynamic routing is enabled on VPC spokes, routes learned from hybrid spokes automatically propagate to all connected VPC spokes.
Hybrid NAT is a specific use of Private NAT designed to let VMs in a VPC communicate with on-premises networks that have overlapping IP addresses. To deploy it, you create a subnet with the purpose PRIVATE_NAT and assign it to a Cloud NAT gateway with a rule matching nexthop.is_hybrid. The associated Cloud Router must be in the same region and dedicated solely to this NAT. In this workflow, the on-premises router only advertises its non-overlapping subnets to Cloud Router. In return, Cloud Router advertises the PRIVATE_NAT subnet range to on-premises. When a VM in an overlapping subnet sends traffic, Hybrid NAT translates its source IP to one from the PRIVATE_NAT pool, allowing the on-premises system to route the return traffic correctly.
A critical constraint occurs when both Private NAT and PSC propagation are used in the same VPC spoke. If a subnet is configured to use Private NAT, traffic from that subnet destined for a PSC-propagated endpoint is automatically dropped. To maintain connectivity to both hybrid networks and PSC services, you must avoid applying NAT to all subnets. Instead, use the --nat-custom-subnet-ip-ranges flag to target only the specific, overlapping subnets that need translation, leaving other subnets free to communicate directly with PSC endpoints.
Connectivity Tests in Network Intelligence Center can diagnose paths across VPCs, VPNs, Interconnect, and NCC hubs, but it cannot analyze PSC propagation or on-premises routing outside Google Cloud. For NCC, verify that site-to-site data transfer is enabled, dynamic routing is set to global, and BGP policies aren't filtering necessary routes. Traffic drops can also stem from Cloud NAT port exhaustion, where VMs run out of allocated ports for new connections. Adjust the minimum ports per VM setting and enable Cloud NAT logging (ERRORS_ONLY or ALL) to monitor for dropped translations. Firewall evaluation order is also crucial: egress rules evaluate the packet's original, untranslated source IP, while ingress rules evaluate the packet after any destination NAT (DNAT) has occurred.
StudyCerts
StudyCertsPRIVATE_NAT purpose subnet and a Cloud Router in the same region that hosts no other NAT configurations.Private NAT performs private-to-private IP address translation, typically to resolve IP overlaps in hybrid networks, using IPs from a user-defined private subnet. A traditional public Cloud NAT gateway translates private VPC IPs to public, internet-routable IP addresses for outbound internet access.
Use NCC VPC spokes when you need centralized route management, want to propagate Private Service Connect endpoints across many VPCs, or are connecting VPCs across different organizations. Use VPC Network Peering when you need to insert Network Virtual Appliances between VPCs, your application doesn't use PSC, or you want to avoid inter-VPC transit costs.
Hybrid NAT assigns a unique, non-overlapping PRIVATE_NAT subnet range in Google Cloud. The on-premises router advertises only its non-overlapping subnets to Cloud Router, which advertises the PRIVATE_NAT range back on-premises. Traffic from an overlapping VMC subnet is translated to a PRIVATE_NAT IP, so the on-premises system sees a source IP from a range it can route to, resolving the conflict.
The Google Cloud network platform automatically drops traffic from a subnet configured for Private NAT if the destination is a PSC endpoint learned through propagation. This is a system constraint. To reach both hybrid networks and PSC services, you must configure NAT to apply only to specific, overlapping subnets using --nat-custom-subnet-ip-ranges, leaving other subnets untouched.
Prepare and test your skills
Prepare and test your skills