Notifications
Clear all
Topic starter
02/08/2026 12:22 pm
TL;DR: Cloud NAT gateways are usually symmetric and optimised for outbound scale, which makes peer-to-peer connectivity difficult across AWS, Azure, and GCP, according to Tailscale. Direct connectivity remains possible through public IPs, configurable NAT behaviour, or controlled relay patterns, but each choice changes the operational burden on security teams.
NHIMG editorial — based on content published by Tailscale: NAT traversal improvements, pt. 2. Challenges in cloud environments
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Tailscale's analysis of NAT traversal challenges in cloud environments →
Cloud NAT traversal: what it means for secure direct connections?
Explore further
02/08/2026 1:22 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Cloud NAT traversal limits are shaping direct connection design
