Tailscale peer relays show the limits of shared relay capacity

At a glance

What this is: This is an operational analysis of Tailscale peer relays, showing that shared DERP relays preserve connectivity but can severely constrain sustained throughput over long-distance links.

Why it matters: It matters because remote access, Kubernetes administration, and other identity-mediated workflows can become unreliable when the fallback path is governed only for availability, not performance.

By the numbers:

• The same test reached 27.5 Mbits/sec with peer relays.
• The connection improved by 12.5X after enabling peer relays.
• Relay latency dropped from 452ms over DERP to 298ms on peer relays.

Context

Tailscale peer relays address a simple but important governance gap: secure remote access can remain available while still performing poorly enough to disrupt administration and data transfer. The underlying issue is not authentication failure, but the fact that shared relay infrastructure is optimized for reachability and fairness, not dedicated throughput.

In practice, the article shows how network fallback becomes part of the access control experience for operators working across regions. That matters for NHI-heavy workflows such as Kubernetes management, subnet routing, and service administration, where the control plane may be reachable but the operational path is still constrained.

The article’s starting position is typical for distributed teams: many environments assume relay fallback is “good enough” until long-haul traffic exposes the ceiling.

Key questions

Q: When should teams move remote access off shared relay fallback?

A: Teams should move high-volume or latency-sensitive administration off shared relay fallback when the relay becomes the bottleneck rather than the access path itself. If direct connections routinely fail, a dedicated peer relay gives you authenticated connectivity without competing for shared capacity. The decision is operational, not just technical, because the session may be secure but still unusably slow.

Q: Why does authenticated remote access still fail operationally over relays?

A: Authenticated remote access can still fail operationally when NAT traversal forces traffic through a shared relay that was built for reachability, not dedicated throughput. The session remains encrypted and valid, but the available bandwidth and latency can make ordinary admin tasks painful or impossible. That is why transport quality has to be governed alongside identity and device trust.

Q: What breaks when direct peer-to-peer connections are not possible?

A: What breaks is not authentication, but the assumption that a secure session will also be a performant one. In environments with CGNAT or symmetric NAT, direct connections may never form, so traffic stays on a relay path that can sustain the control plane but not the workload. The failure is practical usability, especially for Kubernetes or file-transfer tasks.

Q: How should teams compare peer relays and shared DERP for remote access?

A: Compare them as two fallback classes, not as interchangeable features. Peer relays give you dedicated capacity on infrastructure you control, while shared DERP gives you broad availability when nothing else works. Teams should reserve shared DERP for universal reachability and use peer relays when they need predictable throughput for trusted internal workflows.

Technical breakdown

Why shared relay fallback becomes the bottleneck

When direct peer-to-peer connectivity fails, Tailscale falls back to DERP, a managed relay layer that preserves encrypted transport but inserts an extra hop into the path. That design prioritizes availability, not dedicated capacity, so multiple tenants share relay bandwidth and shaping policies. The result is acceptable connectivity for SSH or control traffic, but poor sustained throughput for file movement, Kubernetes administration, or other high-volume sessions. The article’s tests show that the relay path can remain stable while still being operationally inadequate for real work.

Practical implication: Treat relay fallback as a controlled failover path, not as a default performance baseline.

How peer relays change the traffic path

Peer relays move the relay function onto nodes you control. The relay still forwards encrypted WireGuard traffic, but capacity is no longer shared with the wider customer base. Tailscale’s path preference remains the same in principle: direct connection first, then peer relay, then shared DERP as the universal fallback. This is an important architectural distinction because it separates reachability from resource governance. The control plane can continue to authenticate peers while the data plane uses dedicated infrastructure for heavier sessions.

Practical implication: Use peer relays when the access pattern is legitimate but shared relay capacity is the limiting factor.

NAT traversal limits are a governance issue, not just a networking quirk

The article shows why CGNAT and symmetric NAT break UDP hole punching in some residential networks, especially where endpoint-dependent mapping prevents stable direct paths. That creates a structural dependency on relays even when identity and device trust are intact. For teams managing remote operators or non-office environments, the practical issue is not whether access works once, but whether the path supports the workload behind it. In identity terms, the authenticated session is only part of the control story; transport quality can still determine whether the session is usable.

Practical implication: Plan for environments where direct connectivity will not succeed and document approved relay options in policy.

NHI Mgmt Group analysis

Shared relay fallback is an availability control, not a performance control. The article makes clear that DERP keeps sessions alive when direct connections fail, but it does not guarantee the throughput needed for real administration work. That distinction matters for identity and access programmes because the access path is part of the operating model, not an implementation detail. Practitioners should treat fallback paths as governed infrastructure with explicit service expectations.

Capacity ownership changes the governance profile of remote access. Peer relays move relay performance from a shared service to infrastructure under local control, which changes who can size, monitor, and constrain the path. For identity teams, this is a useful example of how authenticated connectivity still depends on the quality of the transport layer. The lesson is that access design now includes bandwidth assurance for remote operators.

Fallback-path performance is becoming part of NHI and admin workflow reliability. When service accounts, Kubernetes administration, or subnet routing depend on a relay path, the practical question is no longer only whether access is authorized. It is whether the approved route can support the operational task without dropping into an unusable bottleneck. That makes relay governance relevant to broader identity operations, especially in distributed and cross-border environments.

Peer-relay policy should be explicit, not incidental. The article shows that the relay choice can materially affect usability even when the security posture is unchanged. That means organisations should document when shared relays are acceptable, when dedicated relays are required, and which remote workflows cannot tolerate fallback performance. The practitioner conclusion is straightforward: path selection deserves the same operational discipline as access approval.

Remote access architecture is now part of identity experience design. In practice, users judge access systems by whether they can complete a task, not just by whether authentication succeeds. A relay path that preserves confidentiality but throttles work still produces governance failure at the service level. Teams running NHI-heavy operations should align access policy, network fallback, and workload expectations so the experience matches the control intent.

What this signals

Dedicated relay capacity is now part of access governance. If remote administration depends on long-haul connectivity, teams should classify the relay path as a controllable service tier rather than a background network detail. That means defining when shared fallback is acceptable, when owned capacity is required, and how remote workflows are prioritised when bandwidth becomes constrained.

Remote operator experience is a security concern when it affects execution. A secure session that cannot move data or support routine administration can still create pressure for unsafe workarounds, including bypassing approved workflows. NHI-heavy operations, especially Kubernetes administration and service management, should therefore include path validation in their access design and change control.

Peer-relay architecture is a practical example of transport assurance for identity-mediated work. The authenticated connection is only one layer of the control stack. Where access depends on non-office networks or cross-region links, practitioners should expect relay selection, NAT behaviour, and bandwidth limits to shape whether identity controls are usable in practice.

For practitioners

• Define relay fallback tiers Set policy for when shared DERP is acceptable and when a dedicated peer relay is required for administrative or data-heavy sessions.
• Provision an owned relay node Assign a well-connected node as a peer relay and size it for the throughput profile of your remote operations.
• Validate direct and relayed paths separately Use tailscale ping and throughput testing to confirm whether sessions are direct, peer-relayed, or falling back to shared DERP.
• Document NAT constraints for remote users Record which networks are likely to fail hole punching so teams know when to expect relay dependence rather than direct connectivity.

Key takeaways

• Shared relay fallback preserves availability, but it can cap throughput enough to disrupt ordinary remote administration.
• The article shows that transport path selection affects the usability of authenticated sessions even when identity and encryption are intact.
• Teams that rely on remote access for Kubernetes or service administration should govern fallback capacity, not assume all relays are equivalent.

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.
• 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.
• 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.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to operational reality. It is suitable for teams that must manage machine access, remote administration paths, and the governance of non-human credentials.