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.
Editorial analysis by NHI Mgmt Group, based on content published by Tailscale: “How Tailscale is improving NAT traversal (part 1)”.
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.
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.
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.
Practitioner guidance
- Measure relay dependence across your estate Track how often device-to-device sessions stay on relay paths versus upgrading to direct connectivity.
- 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.
- Reduce unnecessary translation layers Minimise double NAT, stacked NAT gateways and overly restrictive middleboxes in networks that depend on low-latency peer connections.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:22 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: NAT traversal is becoming an access-control problem, not just networking