Tailscale Peer Relays
32 comments
·October 29, 2025homebrewer
progval
Heh. I have a 30-nodes Tinc network over the internet but some hosts are behind a NAT. It keeps randomly losing routes between these nodes. It even has the infuriating behavior that often it loses the route a few seconds after I successfully established a SSH connection.
Also, traffic seems to be decrypted and re-encrypted by relaying nodes, unless you use "ExperimentalProtocol = yes" added by Tinc 1.1, which was never formally released.
0x696C6961
Wireguard can do what you're describing.
int0x29
Wireguard can't punch through NATs or firewalls without third party software like Tailscale. Also I'm pretty sure each peer to peer connection needs to be individually set up in a config file ahead of time
HowardStark
Nebula[0] addresses this and is IMO an improvement over WireGuard. Came out of Slack originally, and it supports peer discovery, NAT hole punching, and some other cool features. Also still uses the Noise Protocol.
In practice, the extra networking features + better first class peer config management baked in is very nice (Nebula’s “lighthouses” are configured with a tool similar to DSNet for Wireguard[1])
[0] https://github.com/slackhq/nebula [1] https://github.com/naggie/dsnet
zerkten
What's the use case for this? It seems to be for situations where you might have a SaaS product, but there is some data required from a customer system. You'd expose the customer data using this relay and integrate into the SaaS. Is that the gist of it? Integration would still likely involve you giving the customer some software to expose a limited API and handle auth, logging, etc.
smashed
They are an alternative to the tailscale operated DERP servers, which are cloud relays.
Even with the much touted NAT punching capabilities of tailscale, there are numerous instances where tailscale cannot establish a true p2p connection. The last fallback is the quite slow DERP relay and from experience it gets used very often.
If you have a peer in your tailscale network that has a good connection and that maybe you can even expose to the internet with a port forward on your router, you now have this relay setting that you can enable to avoid using the congested/shared DERP servers. So there is not really a new use-case for this. It's the same, just faster.
danudey
The explanation that I think wasn't entirely clear in the post is how it actually works/why that's better.
From what I can tell, the situation is this:
1. You have a host behind NAT
2. That NAT will not allow you to open ports via e.g. uPnP (because it's a corporate firewall or something, for example) so other tailscale nodes cannot connect to it
3. You have another host which has the same configuration, so neither host can open ports for the other to connect in
The solution is to run a peer relay, which seems to be another (or an existing) tailscale node which both of these hosts can connect to via UDP, so in this circumstance it could be a third node you're already running or a new one you configure on a separate network.
When the two NAT'ed hosts can't connect to each other, they can both opt to connect instead to this peer node allowing them to communicate with each other via the peer node.
Previously this was done via Tailscale's hosted DERP nodes; these nodes would facilitate tailscale nodes to find each other but could also proxy traffic in this hard-NAT circumstance. Now you can use your own node to do so, which means you can position it somewhere that is more efficient for these two nodes to connect to and where you have control over the network, the bandwidth, the traffic, etc.
selasa67118
Jangan ragu main di jo777 karena paling terpercaya
Deathmax
I can finally tear down my custom DERP server that I was using to get higher throughput between two NAT'd clients.
xeonmc
I wonder if the next step could be to have all tailscale clients automatically able to accept forwarding requests between any two machines within the tailnet, so that the mesh seamlessly auto-routes around any breaks within the mesh?
huhtenberg
Yeah, such extension is natural and it comes up frequently in the context of overlay networks. The defining question here is if you are OK with relaying other people's CP traffic.
VikingCoder
"within the tailnet." So, the "other people" are people you've authorized to be on your tailnet, at least in this conversation.
fukka42
> All customers can use two peer relays, for free, forever. As your needs scale, so will the number of available peer relays. To add even more peer relays to your tailnet, come have a chat with us.
I have to pay to be able to donate my own infra to make tailscale's server better?
HexDecOctBin
Hard to parse the networking jargon, but does this enable offline connections?
If I have two devices on my local LAN (both connected to a Tailnet) and my home internet goes, currently the devices disconnect from each other. I have been looking for a way to prevent that, so that the all devices connected to the same WiFi network on a tailnet can find each other even if the internet connection to the wider world is broken.
nirav72
> my home internet goes, currently the devices disconnect from each other.
You might be able to solve this by hosting your own control plane such as Headscale. Instead of having Tailscale manage/coordinate all the nodes on tailnet.
sampullman
I ran headscale for a while and can confirm local devices could still chat when the internet went down.
the8472
That'd be easy if only wireguard supported multiple endpoints per peer, then one could add the ULA address of the local devices in addition to the external one.
bananapub
that already works
HexDecOctBin
Not for me. Maybe some misconfiguration on my part then.
justinsaccount
run `tailscale status` and ensure that your local machines are connected to each other `direct` and not using a relay.
cpressland
I was literally looking for a solution for this over the weekend and ended up with a very quirky setup for my Kubernetes Operator.
Now I can rip all that out and use this! Bravo!
ilmblover2
Man K8s is my nightmare haha. 100% agree
amluto
How does this interact with machines that are shared from one Tailnet to another? Is there specific syntax to grant the appropriate permission to a user or device that accesses the destination via sharing?
The docs also say:
> As a rule of thumb, the src devices in the grant policy should typically be devices in a stable physical location behind a strict NAT or firewall that prevents direct connections. This typically includes devices in corporate networks or cloud environments. It usually does not include mobile devices or laptops that frequently change locations and network conditions.
Is there some reason that one should not set up a peer relay to enable a laptop to access a machine that is behind a NAT? (Tailscale regularly fails to establish direct connectivity from a laptop behind a NAT to a machine that's behind a different NAT, at least in my experience.)
kabirx
One limitation of custom DERP is that across tailnets, they don't share the same DERP maps and don't have access to each others' DERPs.
With Tailscale Peer Relays, the available relay bindings can be seen by the devices on either side of a connection; as such it should work out of the box with a sharing relationship between tailnets.
karaziox
In your example the src would be the "machine that is behind a NAT". That's the one the peer relay enable access to. And then all your other devices (that laptop) can reach it through the peer relay.
I was also a bit confused on the meaning of src/dst in the grants. The naming didn't match my thinking.
amluto
Hmm. It would be very nice if this worked when the laptop is on a different tailnet.
conradludgate
My reading of the docs suggests that the relays and both peers must be in the same tailnet. Additionally, both peers must have the correct ACLs set up to access each other
liuliu
How to do site-to-site traffic over Tailscale / WG encryption? From preliminary testing, it seems have difficulty to saturate a 10Gbps connection while plain HTTP (nginx) traffic does that fine. Of course it should vary from CPU to CPU, but any tips how to improve that? Ideally I would love to go over with encrypted traffic, although everything is public, just one less thing need to be careful (in case future need to transport some non-public data over).
mh-
You'd need to analyze what's bottlenecking when you're doing that.
Even a cursory look at htop on both ends while you're trying to saturate that link would be informative.
rcarmo
OK, another use for port 1337. Anyone got a better, mnemonically memorable choice in the low range?
syahlanahda
jo777. gacor
This was better solved by tinc about 20 years ago. All tinc nodes can work as relays (but you can disallow that if you want), it does not rely on a centralized server, and works fine without access to the internet. It is a true mesh. The world would be better served by porting tinc to wireguard and some memory safe language instead of reimplementing parts of its functionality from scratch.