Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: Reliable NAT traversal still depends on fallback relays when direct peer connections fail, and Tailscale says its current TCP-based DERP path can add latency, retransmissions, and throughput limits while it explores UDP-based relay options and broader connectivity changes. The governance lesson is that resilience engineering now sits alongside access design, because direct paths are not guaranteed in hostile networks.
NHIMG editorial — based on content published by Tailscale: NAT traversal improvements, pt. 3: looking ahead
Questions worth separating out
Q: How should security teams govern peer-to-peer connectivity when direct paths are not guaranteed?
A: Treat peer-to-peer as an approved connectivity mode that still needs explicit policy, device eligibility rules, and logging.
Q: Why do relays become a security and resilience issue in NAT-heavy environments?
A: Because the relay is the path that actually carries traffic when direct connectivity fails, it becomes part of the control surface for availability, throughput, and policy enforcement.
Q: What breaks when organisations assume direct peer connectivity will always work?
A: Operational reliability breaks first, because locked-down networks, carrier NAT, and enterprise firewalls can force a fallback route.
Practitioner guidance
- Define fallback-path policy for peer connectivity Document which business applications may use relay-based fallback, which device classes are eligible, and what network conditions justify it.
- Measure relay performance under adverse conditions Test latency, packet loss, and throughput when direct connectivity fails, then compare the relay path against your service targets.
- Separate approved P2P from unmanaged sharing Create controls that distinguish sanctioned peer connectivity from unsanctioned file sharing or ad hoc remote access.
What's in the full article
Tailscale's full blog post covers the implementation detail this post intentionally leaves for the source:
- How DERP works as a TCP-based fallback relay when peers cannot connect directly.
- The specific trade-offs the vendor sees in moving toward UDP-based relaying for worst-case connectivity.
- Why enterprise policy is shifting from blanket P2P blocking toward approved business use cases.
- How IPv6 adoption changes the long-term shape of NAT traversal and direct connectivity.
👉 Read Tailscale's analysis of NAT traversal and faster fallback connectivity →
NAT traversal improvements: what a faster relay model means?
Explore further
02/08/2026 1:21 pm
Faster fallback connectivity is becoming part of security architecture, not just network plumbing. When direct peer connections fail, the relay path becomes the actual enforcement surface for availability and control. That shifts attention from ideal routing to operational assurance, because the organisation only benefits from encrypted connectivity if the fallback path is dependable. Practitioners should treat relay design as a resilience control, not an implementation footnote.
A question worth separating out:
Q: What is the difference between direct peer connectivity and relay-based fallback?
A: Direct peer connectivity sends traffic between endpoints without an intermediary, while relay-based fallback forwards traffic through a shared intermediate service when direct paths fail. The difference matters because the relay introduces latency, potential throttling, and an additional governance point that must be trusted and monitored.
👉 Read our full editorial: NAT traversal is shifting toward faster fallback connectivity
