Cloud NAT traversal limits are shaping direct connection design

At a glance

What this is: This is a Tailscale analysis of why cloud NAT traversal is difficult and which deployment patterns improve direct connectivity.

Why it matters: It matters because cloud connectivity choices affect exposure, routing, and control boundaries for identity-aware access patterns, especially where workloads, services, and operators need authenticated direct links.

👉 Read Tailscale's analysis of NAT traversal challenges in cloud environments

Context

Cloud NAT is built for outbound reliability, not for symmetric peer discovery or stable inbound reachability. That design choice becomes a governance issue when security teams try to build direct, authenticated connections across cloud instances without introducing unnecessary relays or public exposure. In identity-heavy environments, the connectivity model also affects how workloads, service endpoints, and access paths are controlled.

The article frames a practical trade-off for cloud operators: either make instances directly reachable, tune NAT behaviour, or centralise traffic through a controlled node. None of those options is free, and each changes the risk surface, the operational overhead, and the degree of path control available to the team.

Key questions

Q: How should security teams design cloud connectivity when NAT blocks direct peer-to-peer traffic?

A: Start by classifying which services truly need direct peer reachability and which can remain behind managed NAT. For the direct-path group, use public IPs or NAT settings that preserve stable mappings, then enforce access with endpoint firewalls and authenticated transport. That keeps the security boundary explicit instead of relying on translation behaviour.

Q: Why do managed cloud NAT gateways make direct connections harder?

A: Managed cloud NAT gateways are usually symmetric, so the external port mapping changes in ways that prevent reliable hole punching. That is excellent for outbound scaling but poor for peer discovery. The result is a higher failure rate for direct links, especially when both endpoints sit behind the same kind of managed NAT.

Q: What do teams get wrong about using NAT as a security control?

A: Teams often treat NAT as a protective boundary when it is really an address translation mechanism. If the workload needs inbound reachability, the real control is the firewall, the transport authentication, and the identity policy attached to the endpoint. NAT may reduce exposure, but it does not replace governance.

Q: When should organisations use relay nodes instead of direct connectivity?

A: Use relay nodes only when direct reachability or configurable NAT behaviour is not practical at acceptable cost. They are useful for simplifying traffic flow, but they create concentration risk and a dependency on a shared chokepoint. If you choose them, assign ownership, monitor performance, and plan failover explicitly.

Technical breakdown

Why symmetric cloud NAT breaks peer-to-peer connectivity

Cloud NAT gateways typically use symmetric mapping, which means the source port can change per destination and the external mapping is not stable enough for hole punching. That is efficient for outbound scale, but it works against peer discovery because two endpoints cannot reliably predict each other's return path. AWS and Azure behave this way by default, while GCP can be made more compatible through endpoint-independent mapping. The net effect is that direct connectivity fails more often in managed cloud NAT than in host-level NAT or carefully tuned virtual routers.

Practical implication: security teams should treat managed cloud NAT as an architectural constraint when planning direct connectivity for critical workloads.

Public IPs, UDP reachability, and the security boundary

Assigning a public IP to a cloud instance removes the managed NAT from the path and usually improves the odds of direct connectivity. The security model then shifts to the host firewall and the authenticated transport itself, rather than depending on NAT as an implicit barrier. For WireGuard-based connectivity, the point is not to expose everything, but to permit the specific UDP path the client needs. This is a familiar pattern in modern network design: reduce hidden intermediaries and enforce policy at the endpoint boundary instead of relying on translation behaviour.

Practical implication: if direct connectivity is required, validate whether firewall policy can replace NAT as the real control boundary.

Custom NAT instances and relay nodes trade simplicity for control

A custom NAT instance or firewall VM can preserve source-port behaviour more predictably than a managed cloud NAT gateway, especially when configured for endpoint-independent mapping. That gives operators more control over peer reachability, but it also creates a component they must harden, patch, scale, and make highly available. Relay patterns such as subnet routers or exit nodes reduce the need for every instance to be directly reachable, but they concentrate traffic and create bottlenecks. In practice, these options are about choosing where complexity lives, not eliminating it.

Practical implication: use controlled relay patterns only when direct reachability or configurable NAT is operationally impractical.

NHI Mgmt Group analysis

Cloud NAT symmetry is a reliability problem, not just a networking inconvenience. When translation is optimised for outbound scale, the security team loses predictable peer reachability and has to reintroduce control elsewhere. That shifts the burden onto endpoint policy, route design, and authentication. For practitioners, the real question is whether the environment can support secure direct connectivity without depending on opaque network behaviour.

Direct connectivity changes the control plane for identity-aware access. Once a workload has a public IP and authenticated transport, the access decision moves closer to the endpoint and farther from the NAT layer. That is often a better governance model than assuming network translation provides protection. The intersection with IAM is clear: workload access depends on authenticated identity, not just on network placement, so route design and identity policy must be aligned.

Endpoint-independent mapping is the right named concept for this problem space. The article shows that peer-friendly NAT is less about NAT in general and more about whether mappings remain stable enough for hole punching. That distinction matters for cloud architects deciding between managed NAT, custom NAT, and direct exposure. For practitioners, the lesson is to design for mapping behaviour, not just for connectivity success.

Relay nodes reduce friction but create concentration risk. Subnet routers and exit nodes can simplify reachability when direct P2P is impossible, but they also centralise traffic and make the relay a dependency. That is an availability and governance trade-off, not a free optimisation. Teams should treat these nodes as controlled chokepoints and monitor them accordingly.

Cloud providers are being pushed toward more identity-friendly connectivity models. GCP's endpoint-independent option and similar design discussions show that customers want predictable peer connectivity without giving up security controls. The market direction is toward configurable path behaviour, not blind trust in translation defaults. Practitioners should expect network design choices to become more explicit in security reviews.

What this signals

Cloud teams should expect more pressure to make routing behaviour explicit rather than implicit. The security review question is shifting from whether a network is private to whether the path between endpoints is predictable, authenticated, and governable.

Path-control debt: when teams depend on managed NAT defaults, they accumulate hidden dependencies that are hard to test, hard to tune, and easy to overlook during incident response. The better operating model is to decide deliberately where connectivity should be direct, where it should be relayed, and which control owns each decision.

For practitioners

• Map workloads that require direct reachability Identify cloud instances, containers, and service nodes that depend on peer-to-peer connectivity, then separate them from workloads that can safely stay behind managed NAT. Document which applications need stable UDP behaviour and which can tolerate relay paths.
• Prefer public IPs with tight firewall scope for critical nodes Where direct connectivity is operationally necessary, use a public IP or equivalent instance-level address and restrict UDP access to known ranges and ports. Do not rely on NAT as the only security control for those paths.
• Tune NAT behaviour before adding more relay layers If you must keep private addressing, test whether your cloud offers endpoint-independent mapping, static port allocation, or a custom NAT instance that preserves source ports. Validate the mapping behaviour under load before putting production traffic through it.
• Treat subnet routers and exit nodes as controlled chokepoints If you use a relay pattern, harden the node, assign ownership, monitor throughput, and document failover. These nodes concentrate traffic and should be governed like shared infrastructure, not treated as an incidental workaround.

Key takeaways

• Cloud NAT symmetry is a design choice that favours outbound scale over predictable peer connectivity.
• Direct connectivity becomes easier when teams move the control boundary to the endpoint, firewall, and authenticated transport.
• Relay patterns and custom NAT can solve reachability, but they also concentrate operational risk and management overhead.

Key terms

• Symmetric NAT: A NAT mode that assigns different external mappings for different destinations, which makes return paths unpredictable for peer-to-peer connections. In cloud environments, symmetric NAT improves outbound scaling but weakens direct connectivity because hole punching depends on stable mappings.
• 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.

What's in the full article

Tailscale's full blog post covers the operational detail this post intentionally leaves for the source:

• Cloud-by-cloud behavioural differences between AWS NAT Gateway, Azure NAT Gateway, and GCP Cloud NAT
• Configuration trade-offs for public IPs, UDP reachability, and endpoint-independent mapping
• Relay patterns such as subnet routers, exit nodes, and custom NAT instances
• Practical constraints around throughput, high availability, and port allocation

👉 The full Tailscale post covers cloud-by-cloud behaviour, configuration trade-offs, and relay options in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader access and infrastructure decisions.