Tailscale Peer Relays can improve connectivity when direct peer-to-peer paths are difficult, but they do not change the core rule: access policy still decides who can reach what. A relay path is a transport reliability tool, not permission by itself.
The useful mental model is “better pathing for encrypted Tailscale traffic,” not “a new public service to trust blindly.”
What are Tailscale Peer Relays?
Tailscale describes Peer Relays as a feature for configuring devices to relay traffic for peers when direct connections are not possible. The feature is meant to improve connectivity and performance in constrained environments where normal NAT traversal or direct paths do not work well.
In plain language: one tailnet device can help traffic cross a difficult network path without turning every destination into a public service.
Does a relay decrypt traffic?
The relay should be understood as forwarding encrypted traffic between peers, not becoming the application security boundary. Tailscale’s broader model is built around WireGuard-encrypted peer traffic and policy-controlled access.
That means the relay path can matter for availability, routing, and operational trust, but it should not be treated as a place where application authorization disappears.
What does change operationally?
Peer relays add a new infrastructure role. That role needs ownership, placement, monitoring, and policy.
Ask four questions before using one:
- Which devices may act as relays?
- Which peers may use them?
- Who owns relay uptime and updates?
- What happens if the relay is unavailable?
If nobody owns the answers, the relay is premature.
What does not change?
Peer relays do not justify broad subnet routes, public admin dashboards, or vague tailnet ACLs. If a resource should only be reachable by two admins, keep that policy narrow whether the packet path is direct, DERP, or peer-relayed.
For route design, compare Tailscale exit node vs subnet router and the subnet router security checklist.
When should a small team care?
Care when remote sites sit behind restrictive NAT, CGNAT, firewalls, or networks where direct peer paths are unreliable. Peer relays can be a practical reliability layer for field offices, lab networks, and customer environments.
If your direct connections already work and latency is acceptable, the simplest design may still be the best design.
Practical policy
Use this policy:
Peer relays are approved infrastructure nodes. They must be tagged, owned, updated, monitored, and scoped in policy like any other access component.
That keeps the feature from becoming invisible network magic.
FAQ
Do Peer Relays replace DERP?
They address related connectivity problems, but design details depend on Tailscale’s current implementation and policy. Use Tailscale docs for exact behavior.
Can a peer relay see my application data?
Treat it as a relay for encrypted Tailscale traffic, not as an application endpoint. Application data should still be protected by the end-to-end encrypted path and the app’s own controls.
Should every tailnet enable peer relays?
No. Use them where they solve a real connectivity or performance problem.
Sources
- Tailscale Peer Relays docs: https://tailscale.com/docs/features/peer-relay
- Tailscale Peer Relays GA announcement: https://tailscale.com/blog/peer-relays-ga
- Tailscale NAT traversal and security model documentation: https://tailscale.com/kb/