Notifications
Clear all
Topic starter
02/08/2026 12:22 pm
TL;DR: More than 90% of its connections reach direct peer-to-peer paths, but hard NATs, double NAT, restrictive firewalls, and carrier-grade NAT still force relays and add latency, according to Tailscale. The broader lesson is that connectivity policy, not just packet delivery, now shapes how securely and reliably distributed systems operate.
NHIMG editorial — based on content published by Tailscale: NAT traversal, and how we're improving it (pt. 1)
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Tailscale's analysis of NAT traversal improvements and DERP fallback →
NAT traversal and direct connections: are your controls keeping up?
Explore further
02/08/2026 1:22 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: NAT traversal is becoming an access-control problem, not just networking
