Tailscale peer relays show the limits of shared relay capacity

At a glance

What this is: Tailscale shows that moving from shared DERP relays to self-hosted peer relays can materially improve remote access throughput when NAT traversal fails.

Why it matters: This matters because remote access reliability increasingly depends on whether access paths, relay capacity, and ACLs are governed as part of the identity control plane rather than treated as incidental network plumbing.

By the numbers:

• The same Delhi-to-Minneapolis test improved from 2.2 Mbits/sec over DERP to 27.5 Mbits/sec on peer relays.
• 12.5x improvement after peer relays were enabled., r relays were enabled.
• Peer relay latency dropped from 452ms to 298ms once the relay path was established.

👉 Read Tailscale's analysis of peer relays and DERP throughput limits

Context

Remote access is only as good as the path it takes when direct connectivity fails. In this article, the primary issue is not authentication or policy design, but the performance and control trade-off that appears when tailnet traffic falls back from direct peer-to-peer links to shared relay infrastructure.

For IAM and NHI practitioners, the intersection is real: access policy determines who can connect, but relay selection and path governance determine how that access behaves under constrained networks. That matters for administrators, operators, and any workload or service account that depends on stable remote reachability.

Key questions

Q: How should teams handle access when direct connections keep failing across NATed networks?

A: Treat repeated relay fallback as an operational control problem, not a one-off connectivity annoyance. If direct paths fail because of CGNAT or symmetric NAT, define whether a shared relay is acceptable or whether dedicated relay capacity is needed for admin work, remote support, or workload access. Measure the effect on latency, throughput, and user behaviour before standardising the fallback path.

Q: Why do shared relays become a bottleneck for remote administration?

A: Shared relays preserve connectivity, but they also inherit contention, distance, and provider-level fairness limits. That means the path may remain secure while still becoming too slow or inconsistent for file transfer, cluster management, or interactive troubleshooting. When access reliability matters, the transport layer becomes part of the security and operations design, not merely a networking convenience.

Q: What breaks when relay usage is invisible to the operations team?

A: Teams lose the ability to explain why a session feels slow, why a connection never upgrades to direct, or why some regions consistently perform worse than others. Invisible relay use also hides whether the organisation is depending on shared infrastructure for sensitive administration. Without that visibility, capacity planning and access governance both become guesswork.

Q: What should organisations consider before deploying their own peer relays?

A: Account for port exposure, relay placement, ACL scope, and the operational ownership of capacity. A peer relay can improve throughput, but it also introduces a node that must be maintained, monitored, and governed as part of the access path. The right question is not whether to relay, but which sessions deserve dedicated control.

Technical breakdown

Why NAT traversal falls back to relays

Tailscale first attempts direct peer-to-peer connectivity using NAT traversal. When networks use CGNAT, symmetric NAT, or restrictive firewalls, UDP hole punching can fail because each destination sees a different external mapping. At that point, traffic falls back to DERP, a shared relay that preserves encryption but adds an extra hop and capacity contention. The result is predictable: reachability remains, but throughput and latency become dependent on relay load and geography rather than the local link alone.

Practical implication: teams should treat relay fallback as a designed operating mode and measure its performance under real network conditions.

How peer relays change the traffic path

Peer relays keep the WireGuard-encrypted session intact but move the forwarding function onto infrastructure the tailnet owner controls. Each client establishes its own UDP connection to the relay node, and the relay forwards packets between those sockets without decrypting traffic. That changes the bottleneck from shared provider capacity to the operator’s own bandwidth, routing, and port exposure. In governance terms, it also turns a hidden network dependency into a configurable access control and capacity decision inside the tailnet.

Practical implication: capacity, placement, and ACL scope for relays should be reviewed like any other privileged access dependency.

Why relay governance belongs in identity-adjacent control design

Although this is a networking story, the control surface sits close to identity because Tailscale authorises peers before traffic flows and uses ACLs to decide which devices may use which relays. That means the relay is not just a transport endpoint. It is part of the trust path for remote administration, service access, and workload connectivity. In environments where NHI or admin access depends on always-on remote reachability, relay design affects both availability and the practical enforceability of least privilege.

Practical implication: review relay access as part of privileged connectivity design, not as an afterthought to network troubleshooting.

NHI Mgmt Group analysis

Relay path selection is now a governance issue, not just a connectivity issue. When direct paths fail, organisations inherit a fallback architecture that can reshape performance, reliability, and operational trust. That matters because the control plane for access is only as strong as the least predictable transport path. Practitioners should treat fallback relays as part of the access architecture, not as invisible plumbing.

Access-path fragility: is the named failure mode this article exposes. The article shows how CGNAT and symmetric NAT can force traffic onto shared relays, creating a hidden dependency that operators do not fully control. The lesson is that remote access programmes need visibility into when sessions are direct, relayed, or capacity-limited. Teams should measure fallback frequency and decide where dedicated relay capacity is justified.

Performance and policy converge when remote administration depends on encrypted relays. The issue is not whether traffic remains secure in transit, but whether the path is predictable enough to support administrative work, service access, and time-sensitive operations. In identity terms, this is adjacent to privileged access because the operator’s ability to reach a system is part of the effective control boundary. Practitioners should align relay design with operational risk, not just network convenience.

Shared relays are a sensible baseline, but dedicated relays change the operating model. Shared infrastructure maximises availability, while self-hosted relays optimise for capacity and local control. That trade-off becomes important when remote work, homelab operations, or distributed administration depend on sustained throughput. Practitioners should decide which access paths deserve dedicated capacity before users start working around the limitations.

This is a useful example of how identity-adjacent infrastructure can hide control assumptions. The access policy may be correct while the transport path silently degrades the user experience or operational reliability. In mature programmes, that gap is closed by monitoring the full connection path, not just the authentication event. Teams should fold relay behaviour into service availability and admin-access reviews.

What this signals

Access-path fragility is becoming visible wherever remote teams rely on fallback connectivity to reach critical systems. For identity-adjacent programmes, that means the practical boundary of access is no longer just authentication and authorisation, but also the reliability of the encrypted path that carries the session.

Organisations that support distributed administration should expect more pressure to classify relay paths by sensitivity and performance needs. When remote operations depend on stable connectivity, relay choice starts to resemble privileged infrastructure design rather than routine networking, and that is where governance, monitoring, and capacity planning must converge.

For practitioners

• Measure relay fallback under real network conditions Run repeated connection tests from the locations your admins and operators actually use, then record when sessions stay direct, switch to DERP, or upgrade to a peer relay. Use that data to identify where transport fallback creates operational risk for remote administration and service access.
• Define which devices may use dedicated relays Apply ACLs so only the systems that genuinely need relay-based reachability can use those nodes. Keep the scope narrow, because a relay is part of the access path and should be governed like other privileged connectivity components.
• Place relays where bandwidth is predictable Choose relay nodes with stable uplink capacity, low contention, and sensible geography relative to your user base. A relay in the wrong place may solve reachability while still leaving you with avoidable latency and jitter.
• Monitor direct-versus-relayed session behaviour Track how often the tailnet uses direct paths, peer relays, or shared DERP fallback. Persistent reliance on shared relays is a signal that NAT conditions or topology choices are shaping user experience more than policy intent.

Key takeaways

• Shared relay infrastructure can preserve reachability while still becoming the limiting factor for productive remote access.
• When NAT traversal fails, relay behaviour becomes part of the access control surface and should be measured, scoped, and governed accordingly.
• Dedicated relay capacity can improve operational reliability, but it also introduces a node that must be treated as privileged infrastructure.

Key terms

• Peer Relay: A peer relay is an organisation-controlled node that forwards encrypted traffic between devices when direct connectivity fails. It preserves end-to-end confidentiality while shifting the relay function from shared provider infrastructure to a system the operator can place, size, and govern.
• CGNAT: Carrier-grade NAT is a network translation layer used by ISPs to conserve IPv4 addresses by placing many customers behind shared public IPs. It often interferes with peer-to-peer connectivity because inbound reachability and stable port mapping become difficult to predict.
• 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.
• DERP: DERP is Tailscale's shared relay infrastructure for encrypted packet forwarding and connection establishment when direct paths are unavailable. It maximises availability, but because it is shared, performance is influenced by distance, contention, and provider-side capacity management.

What's in the full article

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

• iperf3 test output and the before-and-after throughput measurements from Delhi to Robbinsdale
• Step-by-step peer relay setup, including relay port configuration, router port forwarding, and ACL grants
• tailscale ping output showing the transition from DERP to peer-relay paths in practice
• Static endpoint override guidance for more complex relay discovery environments

👉 The full Tailscale post includes test results, relay setup steps, and verification examples.

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, the industry's only accredited NHI security programme. It is suitable for practitioners who need to connect identity governance to operational access decisions across modern security programmes.