NAT traversal is becoming an access-control problem, not just networking

At a glance

What this is: This is Tailscale’s analysis of why direct peer-to-peer connections fail in some environments and how NAT traversal, DERP relays, and endpoint-independent mappings reduce those failures.

Why it matters: It matters because identity and access controls increasingly depend on reliable, low-friction network paths for workloads, devices, and NHI-backed sessions across mixed environments.

By the numbers:

• In practice, Tailscale succeeds in establishing direct connections nearly all of the time, with direct NAT traversal success rates well north of 90% in typical conditions.

👉 Read Tailscale's analysis of NAT traversal improvements and DERP fallback

Context

NAT traversal is the set of techniques that lets two devices establish a direct connection even when routers, firewalls, or carrier networks sit between them. This matters for modern identity security because workload access, remote administration, and NHI-backed service communication increasingly depend on paths that are predictable enough for policy to enforce and resilient enough for sessions to complete.

Tailscale’s article frames the problem as a connectivity issue, but the governance issue is broader: when direct paths fail, organisations inherit relay dependencies, added latency, and more complex trust boundaries. That makes the quality of network traversal part of the access-control conversation, especially in multi-cloud, mobile, and heavily filtered enterprise environments.

For identity and security teams, the most relevant lesson is that secure connectivity is not only about encryption or authentication. It is also about whether the infrastructure can consistently reach the authorised peer without requiring brittle exceptions, manual port opening, or unmanaged relay workarounds.

Key questions

Q: What breaks when NAT traversal is too restrictive for peer-to-peer access?

A: Direct sessions fail when NATs randomise mappings, firewalls block UDP, or multiple translation layers prevent both peers from learning a stable endpoint. The result is higher latency, more relay dependency, and less predictable access behaviour. For security teams, that means the network cannot reliably enforce the access model the identity layer already authorised.

Q: Why do hard NATs complicate secure workload connectivity?

A: Hard NATs change the external port for each destination, so peers cannot predict a reusable return path. That makes hole punching unreliable and pushes traffic into relay paths. In practice, the more the network behaves this way, the more access design depends on traversal exceptions instead of stable, least-privilege connectivity.

Q: How do teams know whether relay use is a symptom of a governance issue?

A: Look for repeated relay fallback on networks that should support direct traffic, especially where the same users or workloads always hit the same restrictive edge. If the pattern aligns with firewall policy, proxy-only routing, or carrier-grade NAT, the issue is structural. The signal is persistent, segment-specific failure rather than random connection noise.

Q: Who is accountable when security policy blocks direct peer connections?

A: Accountability usually sits with the team that owns the edge posture, because the problem is often caused by NAT mode, firewall defaults, or security appliance rules rather than the application itself. If those controls are intentionally restrictive, the organisation must accept relay latency as the trade-off. If they are accidental, the control baseline needs correction.

Technical breakdown

Why symmetric NAT breaks peer-to-peer connections

Symmetric NAT assigns different external source ports depending on the destination, which makes peer discovery unstable. A peer can learn one mapped endpoint, but that endpoint only works for the specific remote address that created it. Hole punching, STUN, and similar techniques rely on mappings that are predictable enough for both sides to race traffic toward the same reachable tuple. When the mapping changes per destination, the remote peer cannot reliably guess where to send return packets, so a relay becomes the safe fallback.

Practical implication: teams behind hard NATs should expect more relay traffic and should treat traversal failures as an environmental control issue, not an application bug.

How DERP functions as a relay and fallback path

DERP is a coordination and relay layer that starts the connection, exchanges reachability information, and carries traffic when direct UDP cannot be established. In the normal case it steps aside after peer-to-peer connectivity succeeds. In restricted environments, however, it remains the active path so the session stays alive over HTTPS transport. That design trades latency for reliability and makes the connection workable even when UDP, unsolicited inbound traffic, or direct hole punching is blocked by policy or topology.

Practical implication: administrators need to know where relay dependency is intentional and where it indicates an overly restrictive network posture.

Why endpoint-independent mapping improves traversal without opening everything up

Endpoint-independent mapping reuses the same translated port for outbound traffic from the same internal socket, regardless of destination. That gives remote peers a stable endpoint to target, which improves the odds of direct connection establishment. The security distinction is important: this is not the same as blindly opening a port to the internet. Filtering rules can still restrict which external hosts may send return traffic, preserving more control than consumer-style port forwarding or universal UPnP exposure.

Practical implication: network teams should evaluate NAT behavior as a policy choice and prefer mappings that support direct connectivity without creating broad inbound exposure.

NHI Mgmt Group analysis

Connectivity reliability is now part of access governance. When direct paths fail, organisations do not just lose performance, they also lose predictability in how authorised connections are established and maintained. That affects workload access, remote admin channels, and any environment that depends on device-to-device trust. The practical conclusion is that secure access design has to include path reliability, not just authentication strength.

Strict NAT and firewall behaviour create a hidden security tax. Relay fallback is often treated as a networking inconvenience, but it is also a signal that the environment is forcing exceptions into normal access flow. Those exceptions complicate monitoring, increase latency, and can push teams toward brittle workarounds. In identity programmes, that is the same pattern seen when access policy must compensate for infrastructure that cannot support the intended control model.

Endpoint-independent mapping is a useful middle ground between openness and usability. The article shows that networks can support direct peer connectivity without adopting the broad exposure of consumer port-opening features. That matters for NHI and workload communication because the control objective is not maximum openness, but stable reachability with bounded return traffic. The practitioner takeaway is to prefer traversal patterns that preserve least exposure while enabling the session to complete.

Named concept: traversal trust gap. This article illustrates the gap between what a policy authorises and what the network can reliably deliver. A connection may be approved in principle, yet still fail in practice because NAT behaviour, UDP filtering, or multi-layer routing prevents the peer from ever reaching the authorised endpoint. The governance conclusion is that identity controls must be matched with network conditions that can actually honour them.

What this signals

Traversal trust gap: security teams should treat NAT behaviour as part of the access-control surface, because a granted connection that cannot be established predictably is only partially governed. The practical question is no longer whether a session is authorised, but whether the environment can preserve that authorisation across the real network path.

Where workloads, devices, and NHI-backed services depend on direct connectivity, relay-heavy environments also create operational blind spots. Teams should watch for persistent fallback patterns in multi-cloud, mobile, and proxy-restricted networks, then decide whether the right fix is edge policy tuning, architectural change, or accepting relay use as the secure default.

For practitioners

• Measure relay dependency by network segment Track where sessions fall back to DERP, then correlate those sites with hard NAT, double NAT, proxy-only endpoints, and UDP filtering. Use that evidence to separate unavoidable relay use from avoidable infrastructure constraints. Suggested anchor: DERP.
• Review firewall rules that suppress UDP hole punching Check whether intrusion prevention, corporate firewall policy, or security gateway defaults are blocking unsolicited UDP or classifying peer-to-peer traffic as suspicious. If they are, decide whether the control is intentional or merely overbroad. Suggested anchor: UDP hole punching.
• Prefer endpoint-independent NAT where feasible Where you control the edge, test whether router and firewall configurations can preserve a stable external mapping for outbound UDP from the same internal socket while still filtering return traffic. That reduces relay dependence without the exposure created by generic port forwarding. Suggested anchor: stable external mapping.
• Use traversal diagnostics before changing access architecture Run connection diagnostics to identify NAT type, mapping stability, hairpin behaviour, and IPv6 availability before redesigning access paths or opening ports. This gives you a factual basis for whether the issue is transport, policy, or environment. Suggested anchor: connection diagnostics.

Key takeaways

• NAT traversal is not just a networking optimisation, because it directly affects whether authorised connections can be established without brittle exceptions.
• Hard NATs, multi-layer translation, and UDP filtering explain why some environments consistently fall back to relays instead of direct peer-to-peer paths.
• The strongest practical response is to measure relay dependency, tune edge policy, and prefer stable mappings that preserve least exposure without breaking connectivity.

Key terms

• Symmetric NAT: A NAT mode that assigns different external source ports depending on the destination being contacted. It makes peer-to-peer discovery much harder because the reachable endpoint is not stable across conversations, so hole punching and similar techniques often fail without a relay.
• UDP Hole Punching: A traversal technique where both peers send outbound UDP traffic at roughly the same time so their NATs record the mapping and allow return traffic. It works best when the translation layer preserves a predictable endpoint and when firewalls do not block unsolicited UDP outright.
• Endpoint-independent Mapping: A NAT behaviour that reuses the same translated port for outbound traffic from the same internal socket regardless of destination. It improves peer reachability by creating a stable external endpoint, while still allowing filtering rules to limit which return packets are accepted.
• DERP Relay: A coordination and relay path used when direct peer-to-peer connectivity cannot be established. It keeps the session alive over a more reliable but higher-latency path, which is useful when NAT, firewall, or network policy prevents direct UDP traversal.

What's in the full article

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

• Walkthroughs of how DERP, STUN, and UDP hole punching interact during connection setup
• Examples of hard NAT, double NAT, and firewall behaviour that interfere with direct paths
• Details of the FreeBSD PF endpoint-independent mapping patch and why it improves traversal
• Implementation notes on NAT-PMP, PCP, IPv6 preference, and connection diagnostics

👉 Tailscale's full post covers the traversal edge cases, FreeBSD patch details, and diagnostic changes

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of practical access control. It helps practitioners connect identity policy to the infrastructure conditions that determine whether access actually works.