Cloud NAT traversal limits are shaping direct connection design

At a glance

What this is: This is an analysis of why cloud NAT behaviour often blocks direct peer-to-peer connections and which deployment patterns restore them.

Why it matters: It matters because cloud connectivity choices now shape exposure, routing complexity, and the amount of control security teams keep over direct connections, relays, and inbound reachability.

Context

Cloud NAT is translation for outbound internet access, but its default behaviour often works against direct inbound reachability. In practice, the translation rules that make private subnets easy to operate also make peer-to-peer session establishment harder, especially when both endpoints sit behind managed cloud NAT.

For IAM and NHI teams, this is not just a networking detail. Any workload that depends on stable, authenticated machine-to-machine connectivity inherits the constraints of the underlying address and port mapping model, so the choice of public IP, managed NAT, or relay affects both reachability and governance.

The cloud-default posture is therefore convenient, but not neutral. It shifts the burden from network design into operational exceptions, which is typical for managed cloud environments rather than an edge case.

Key questions

Q: How should teams design direct connectivity when cloud NAT is symmetric?

A: Start by assuming symmetric cloud NAT will block many peer-to-peer flows and design for either public reachability or a managed relay path. The key decision is whether the workload needs direct incoming sessions or only outbound access. Once that is clear, choose the least complex architecture that still preserves authenticated and encrypted transport.

Q: When should organisations use public IPs instead of managed NAT for cloud workloads?

A: Use public IPs when stable peer connectivity, predictable coordination or low-latency direct links matter more than the convenience of outbound-only NAT. That choice works best for critical infrastructure nodes and service endpoints that can be tightly restricted at the firewall while still remaining directly reachable.

Q: What breaks when cloud NAT cannot preserve stable mappings?

A: Direct peer-to-peer session establishment becomes unreliable because endpoints cannot depend on the same translated port being reachable from multiple peers. That usually forces fallback relays, manual exceptions or provider-specific configuration, which increases operational complexity and makes the network design harder to reason about.

Q: What should security teams do when direct connection depends on relays or subnet routers?

A: Treat the relay as a controlled dependency, not a convenience feature. Define ownership, monitor throughput and failure modes, and document which services rely on it. If the relay becomes the only path for critical traffic, it should be governed like production infrastructure with clear resilience and recovery expectations.

Technical breakdown

Why symmetric cloud NAT breaks direct connectivity

Symmetric NAT creates a different source port for each destination, which means the mapping a peer sees is not stable enough for reliable hole punching. That is acceptable for outbound client traffic because the return path is known, but it is hostile to peer-to-peer systems that need both sides to predict or reuse a reachable mapping. Cloud NAT gateways in AWS and Azure lean heavily toward this model, while GCP only becomes friendlier when static port allocation and endpoint-independent mapping are enabled. The architectural trade-off is scale and simplicity versus direct reachability.

Practical implication: if direct connections matter, treat symmetric cloud NAT as a design constraint, not a minor tuning issue.

Public IPs versus managed NAT gateways

Putting a workload behind a public IP removes the managed NAT layer from the path and lets the endpoint present a stable, directly reachable address. That does not mean exposing the whole machine to the internet, because firewall rules can still restrict UDP ingress to known ranges and the tunnel itself remains authenticated and encrypted. The choice changes the trust boundary: you are trading a managed outbound-only posture for a host-level exposure model that is often easier for peer connectivity and simpler for direct coordination. For critical nodes, that can be the cleanest path.

Practical implication: use public IPs where direct reachability is operationally valuable and host firewalling can keep the exposure bounded.

Why custom NAT and relay patterns add governance overhead

Running your own NAT instance, load balancer, subnet router or exit node can improve connectivity when the cloud provider's NAT is too restrictive. These patterns let operators influence mapping behaviour, preserve ports, or centralise routing through a better-connected node. The cost is that the environment becomes more stateful and more operationally fragile, because you now own redundancy, throughput limits, patching, and the risk of a bottleneck or single point of failure. In governance terms, the control plane moves from provider-managed simplicity to customer-managed responsibility.

Practical implication: reserve custom NAT and relay designs for cases where direct connectivity is worth the extra lifecycle and resilience burden.

NHI Mgmt Group analysis

Cloud NAT design is now an access-control decision, not only a routing decision: the shape of NAT mappings determines whether workloads can establish direct authenticated sessions or must depend on relays and special-case paths. That matters for identity governance because machine-to-machine access depends on stable reachability as much as it depends on credentials. Teams that treat network translation as a background service often miss the fact that it changes the practical boundary of the service account or workload identity. The practitioner conclusion is to review NAT behaviour as part of access architecture, not just infrastructure architecture.

Direct connectivity is usually a control trade-off, not a universal preference: public IPs can simplify direct paths, but they also shift responsibility toward host firewalls and endpoint-level exposure management. Managed NAT reduces inbound reachability, which helps some security postures, but it also forces relay-based patterns that can complicate latency, troubleshooting and east-west design. That means the right answer depends on whether the workload is a critical node, a transient instance, or a routing point for other systems. The practitioner conclusion is to classify workloads by connectivity role before deciding on NAT strategy.

Cloud providers are quietly shaping the future of machine identity reachability: features such as endpoint-independent mapping and static port allocation show that the market is slowly acknowledging peer-to-peer requirements. That is a meaningful signal for NHI governance because workload identities increasingly need predictable transport behaviour to support secure automation, remote administration and distributed control planes. Stable mapping gap: when NAT policies recycle ports aggressively, the identity may be valid but the endpoint is still functionally unreachable. The practitioner conclusion is to track mapping behaviour as part of service design standards.

Relay-first designs should be treated as resilience exceptions, not default architecture: subnet routers and exit nodes can restore service when direct connection is impractical, but they also concentrate traffic and create additional operational dependencies. That centralisation may be acceptable for a controlled fallback path, yet it should not become the hidden norm for workload communication. For identity and platform teams, the governance question is whether the relay is a deliberate exception with clear ownership or an unmanaged workaround that quietly becomes part of the production path. The practitioner conclusion is to document when relays are allowed and who owns them.

What this signals

Stable mapping is the real control variable: direct connectivity fails or succeeds based on whether the NAT preserves usable session mapping, not simply on whether a public cloud offers NAT at all. For practitioners, that means transport design should be reviewed alongside identity and access assumptions for any workload that must be reachable without a relay.

Cloud teams should expect more pressure to expose controllable mapping behaviour in platform services. GCP's endpoint-independent mode is an example of the direction the market is moving, and the practical implication is that workload connectivity standards will increasingly need to distinguish between outbound scale and peer-friendly routing.

For practitioners

• Assess cloud NAT symmetry before assuming peer reachability Map which workloads sit behind AWS, Azure or GCP NAT services and test whether their mappings are endpoint-independent or symmetric. Use that result to decide whether direct connectivity is realistic or whether a relay pattern is unavoidable.
• Assign public IPs to critical nodes where direct links matter For workloads that must establish stable direct sessions, consider giving the instance a public IP and tightening UDP access with host firewalls and security groups. Keep the exposure narrow rather than relying on broad inbound rules.
• Treat custom NAT appliances as managed infrastructure If you replace cloud NAT with your own NAT instance, virtual router or firewall VM, document redundancy, patching, throughput limits and failure handling as part of the operating model.
• Use relay nodes only with explicit ownership When a subnet router or exit node is the least-bad option, define who maintains it, what traffic it carries and which systems depend on it so the relay does not become an invisible bottleneck.

Key takeaways

• Cloud NAT behaviour can make direct peer-to-peer connectivity unreliable even when the underlying workload is authenticated and encrypted.
• The most practical alternatives are public IPs, configurable NAT behaviour, or controlled relay nodes, each with different governance and operational trade-offs.
• Teams should classify connectivity by workload role and then choose the least complex design that still meets reachability, resilience and control requirements.

Key terms

• Symmetric NAT: Symmetric NAT is a translation mode in which the external address and port mapping can vary by destination. That behaviour makes standard hole punching unreliable, which is why direct peer connections often fail in consumer and mobile networks using this pattern.
• Endpoint-independent mapping: A NAT behaviour where an internal host can keep a more stable external mapping across destinations, improving the odds of direct peer connectivity. It is often preferred for secure direct networking because it reduces reliance on relays while preserving address translation.
• Subnet Router: A subnet router is a device that advertises routes to another network segment, allowing tailnet members to reach systems that are not directly running Tailscale. It expands the security boundary beyond a single host, so compromise or misconfiguration of the router can affect a broader set of assets.
• Exit Node: An exit node is a device that routes a client’s traffic through its encrypted tunnel to the wider internet. In practice, it becomes a trust broker for outbound traffic, so the operator must consider monitoring, segmentation, and whether the node should carry that level of privilege.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps security and identity practitioners connect access design to the broader control model their programmes depend on.