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

At a glance

What this is: This article explains how direct peer-to-peer networking succeeds most of the time, but hard NATs, multi-layer NAT, firewalls and CGNAT still push some traffic onto relay paths.

Why it matters: It matters because teams designing secure connectivity now need to treat path selection, firewall policy and relay fallback as part of the access-control model, not just the networking stack.

Context

NAT traversal sits at the boundary between connectivity and control. When devices cannot establish a stable direct path, the environment is no longer just shaping performance, it is shaping which peers can talk, how reliably they can do so, and whether the session uses a direct encrypted path or a relay.

This article focuses on the operational problem that arises when NAT, firewalls, proxies and carrier networks interfere with peer-to-peer traffic. The identity angle is indirect but real: the communication path becomes part of how access is established and sustained, especially where service-to-service or device-to-device trust depends on the network path remaining usable.

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 and double NAT make peer-to-peer access unreliable?

A: Hard NATs change the external mapping by destination, which removes the stability hole punching depends on. Double NAT adds more translation points and more timing failure modes, so even when both peers are willing to connect, the path may never converge on a usable return route.

Q: How do you know when relay fallback is becoming an access problem?

A: When direct sessions fail repeatedly in the same environments, relay use becomes a signal that policy or network design is shaping access. That is especially true if the affected sites share hard NATs, CGNAT, blocked UDP or proxy-only egress.

Q: Should security teams prefer relay-based connectivity or direct peer-to-peer paths?

A: Prefer direct peer-to-peer paths where the network can support them, because they reduce latency and avoid unnecessary intermediary dependence. Keep relay fallback as a resilience layer for hostile or constrained networks, but do not treat it as the normal security posture for every environment.

Technical breakdown

How UDP hole punching and relay fallback work

Tailscale’s model starts with a relay-assisted exchange and then upgrades to direct UDP if both peers can discover a usable path. The relay, DERP, is not the primary data plane in normal conditions. It is the coordination and fallback layer that lets each side learn observed addresses, exchange keys, and test whether intervening NATs will permit return traffic. This pattern matters because the protocol is not just moving packets, it is negotiating a path through stateful middleboxes. Where the negotiation succeeds, direct encrypted traffic replaces relay use. Where it fails, the relay preserves connectivity at the cost of latency. Practical implication: treat relay fallback as a control-path signal, not only a transport failure.

Practical implication: monitor how often sessions stay on relay paths, because persistent fallback usually indicates a network policy or NAT design problem.

Why symmetric NAT and double NAT break direct connectivity

Symmetric, or hard, NATs create different external port mappings for each destination, which destroys the predictability that peer-to-peer traversal depends on. Double NAT compounds the problem by adding more translation points and more chances for the session to miss its timing window. Hole punching succeeds when both sides can coordinate outbound traffic and the mapping remains stable enough for the return flow to arrive. Once the mapping becomes destination-specific or too layered, the peer cannot reliably infer which endpoint to target. That is not merely a networking inconvenience. It is a control condition that determines whether a direct session can exist at all. Practical implication: the more translation layers in the path, the more likely the organisation is to depend on relay infrastructure.

Practical implication: simplify translation layers where possible, especially on networks that need low-latency peer connectivity.

Why firewall policy now affects access as much as NAT does

A firewall that blocks unsolicited UDP can stop hole punching even when NAT behavior is otherwise workable. In those environments, the issue is not address translation alone but whether the security policy allows the initial exchange that makes direct connectivity possible. That turns traversal into an access-control question: the path cannot exist unless the policy permits the probe and return traffic needed to establish it. Relay over HTTPS can preserve reachability, but it also changes the trust and latency profile of the connection. The important distinction is that connectivity now depends on both packet handling and policy intent. Practical implication: teams should review firewall rules as part of identity and access design for device-to-device traffic.

Practical implication: validate whether UDP and peer-to-peer traffic are intentionally allowed, rather than assuming relay fallback will cover every environment.

NHI Mgmt Group analysis

Access control is now embedded in the network path: direct connectivity is no longer just a routing outcome, because NAT behavior and firewall policy determine whether a trusted peer can complete the session. That means connectivity engineering and access governance have merged at the transport edge. Practitioners should treat path selection as part of their control model, not as a background implementation detail.

Hard NATs create a governance problem by making trust non-deterministic: symmetric mappings, double NAT and CGNAT reduce the predictability needed for stable peer-to-peer communication. In practice, this means the same identity and policy decision can produce different access outcomes depending on the network path. Teams should design for path variance instead of assuming uniform reachability across environments.

Relay fallback is a resilience control, but it also hides policy friction: a relay keeps sessions alive when direct traversal fails, which is useful operationally, but it can also mask the underlying access-control conditions that made direct traffic impossible. The named concept here is path-conditioned access: the effective permissions of a device-to-device connection depend on the network conditions that let the session form. Practitioners should measure where that condition appears and whether it is intended.

Endpoint-independent behavior is a security and usability trade-off, not a binary choice: the article shows why the industry is moving away from the strictest NAT behavior without abandoning filtering discipline. That is the right frame for modern connectivity governance, because the goal is not to remove control, but to make control compatible with direct encrypted communication. Practitioners should evaluate whether their network design is preserving security by policy or merely by blocking useful paths.

What this signals

Path-conditioned access: the effective permissions of a peer-to-peer session are shaped by whether NAT and firewall conditions allow the path to form. That means connectivity policy and access policy are now operationally entangled, and teams need to measure both together.

Relay fallback should be treated as a resilience feature, not a substitute for network design. If direct sessions routinely fail in the same zones, the issue is likely environmental policy, translation complexity or transport filtering that deserves remediation.

For practitioners

• Measure relay dependence across your estate Track how often device-to-device sessions stay on relay paths versus upgrading to direct connectivity. Persistent relay use usually signals a network condition that deserves investigation, not just a performance annoyance.
• Review firewall policy for peer-to-peer traffic Check whether UDP, unsolicited return traffic and hole-punching probes are intentionally allowed in the environments that need direct communication. If the policy blocks them, direct connectivity will fail even when NAT traversal is otherwise possible.
• Reduce unnecessary translation layers Minimise double NAT, stacked NAT gateways and overly restrictive middleboxes in networks that depend on low-latency peer connections. Each extra translation point lowers the odds of a stable direct path forming.
• Use relay fallback as a signal, not a default Treat DERP or equivalent relay dependence as a diagnostic indicator of path-conditioned access. Investigate whether the cause is symmetric NAT, port mapping volatility, firewall filtering or endpoint configuration.

Key takeaways

• Direct connectivity is still the desired path for distributed systems, but it depends on NAT and firewall behavior that many teams do not control directly.
• Hard NATs, double NAT and transport filtering reduce the reliability of hole punching and increase the likelihood of relay dependence.
• The practical response is to treat relay usage, firewall policy and translation layers as governance signals, not just network details.

Key terms

• NAT Traversal: A set of techniques that lets devices communicate across network address translation boundaries when direct routing is blocked. It combines discovery, hole punching, relaying, and protocol adaptation so encrypted traffic can still reach its destination under restrictive network conditions.
• 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.
• Hole Punching: Hole punching is a networking technique used to help two endpoints establish a direct connection through intervening NAT devices or firewalls. It is common in remote access systems that need peers to discover and reach each other without exposing broad inbound access. When it works well, it reduces dependence on permanent open ports and central relays.
• Carrier-Grade NAT: Carrier-Grade NAT is a provider-side address translation layer that lets many subscribers share one public IP address. For remote access, it makes inbound connections unreliable or impossible because the fleet operator does not control the translation boundary.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.