> It’s also similar to running your own derp server (which works also in TCP), but without the hassle of doing so, and perhaps without having to open ports to the internet (needed in derp) so long as the relay is reachable by peers.

I think most folks will need to open a port to the internet, because otherwise you wouldn't need the tailscale to begin with. e.g. connecting your cloud network to your on premise network etc.

Of course exceptions apply, like both clients can reach the peer relay, but not each other directly.

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. For end-to-end encryption, you need "ExperimentalProtocol = yes" added by Tinc 1.1, which was never formally released.

I'd like to rewrite something like it in a language I'm familiar with (perhaps based on cjdns' protocol which is better documented than Tinc's) but it's not easy.

Wireguard can do what you're describing.

I've used ZeroTier in the past and I don't recall a feature similar to this being part of their offering. What I do remember is home brewed crypto, incredibly poor single threaded performance, and a glacial development pace. Any thread about Tailscale inevitably brings up alternatives, but having tried many of them in the past, I've yet to find one that actually competes across all the features and performance. The comparisons to other solutions tend to give me "why do you need Dropbox when FTP exists?" vibes.

mind developping on the "it's DERP or nothing"? Have you been trying to expose a direct wireguard port of your own, or the Tailscale?

(Tailscalar) I'm very bullish on WebTransport in the future, but, it doesn't solve for NAT traversal. I'm watching keenly as well how Iroh gets on with QAD, relatedly.

If it all comes together this may well become more magic :D

Since the latency would be higher due to the additional hops or distance, I wonder if it's not better to make the request crash so that the issue is clearly detected rather than to continue in a degraded but "invisible" state.

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.

The tailscale login servers had an issue last week. My local network had an issue at the same time and all connections dropped. Then none of my stuff could reconnect because I couldnt connect to tailscale :(

Looking into setting up my own headscale instance now. This is the first issue I’ve had with tailscale but seems dumb that my local lan devices couldn’t even talk to each other.

Man K8s is my nightmare haha. 100% agree

> It allows customers to make just one firewall exception for connections only coming from their tailnet.

You'll need to open a single UDP port on your firewall, so it's your public facing IP address. You don't need an entire VM somewhere, just a single port.

Regarding the speed question. You'd use the derp when it's not possible to make a peer to peer connection, which limits your speed to derp server's speed and load. Which the peer relay, you can practically use the entire bandwidth you have between your devices.

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.

Tailscale is a few things. It might be fair to say that it is mostly a software platform with a web frontend that allows orgs (and individual users alike) to easily create secure VPNs, so their various systems can have a secure, unfiltered virtual private network on which to communicate with eachother even if they're individually scattered across the four corners of the Internet.

The usual (traditional) way to do VPN stuff is/was hub-and-spoke: Each system connected to a central hub, and through that hub each system had access to the other systems.

But the way that Tailscale operates is different than that: Ideally, each connected system forms a direct UDP/IP connection with every other system on the VPN. There is no hub. In this way: If node A has data to send to node F, then it can send it directly there without traversing through a central hub.

And that's pretty cool -- this peer-to-peer arrangement is gloriously efficient compared to hub-and-spoke. (It's efficient enough that a person can get quite a lot done with Tailscale for free, with no payment expected ever.)

But we don't live in an ideal world. We instead often live in a world of NAT and firewalls -- sometimes even implemented by the ISPs themselves -- that can make it impossible for two nodes to directly send UDP packets to eachother. This results in unreachable nodes, which is not useful.

So Tailscale's workaround to that Internet problem is to provide Designated Encrypted Relays for Packets (DERP). DERP usually works, and end-to-end encryption is maintained.

DERP is also not at all new. It brings back some aspects of hub-and-spoke, but only for nodes that can't communicate directly; DERP behaves in a way akin to a hub, to help these crippled nodes by relaying traffic between them and the rest of the VPN's nodes.

But DERP is a Tailscale-hosted operation. And it can be pretty slow for some applications. And there was no way, previously, for an individual user to improve the performance of DERP: It simply was whatever it was -- with a collection of DERP servers chewing through bandwidth to provide connectivity for a world of badly-connected VPN nodes.

But today's announcement brings forth Tailscale Peer Relay.

> What's the use case for this?

The primary use case for this is simple: It is an alternative to DERP. A user can now provide their own relay service for their network's badly-connected peers to use. So now, rather than being limited to whatever bandwidth DERP has available, relaying can offer as much bandwidth as a user can afford to pay for and host themselves.

And if a user plans it right, then they can put their Peer Relay somewhere on the network where it can help minimize inter-node latency compared to DERP.

(It's not for everyone. Tailscale isn't for everyone, either -- not everyone needs a VPN at all. I'd never expect a random public customer to use it knowingly and directly.)

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

https://github.com/juanfont/headscale

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.

that already works

I'm paraphrasing what one of the engineers said when I asked this question to the team (I'm a TS insider):

There's an application size limit associated with NetworkExtension.

https://developer.apple.com/documentation/networkextension

So they would need to get the binary size smaller in order to implement this on iOS or Apple TV.

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.

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.

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

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.

What is the equivalent feature of netbird? Can you link the documentation please?

Just set the relay up as an exit node too

You mean the library that almost got me banned from my VPS provider because it dialed about half the RFC1918 space?

I'm using 3377 (D-E-R-P) since it's effectively replacing the DERP servers on the specified source devices.

Tailscale employee here.

I kinda doubt we'll end up charging for it (as it costs us ~nothing except support costs, which are real), but it's easier to make it free later when it's GA rather than rug pull on people and start charging for it in the future if we start it out free+unlimited.

Your peer relays don't make Tailscale's infrastructure better.

They instead make your own infrastructure better.

Running a peer relay donates nothing to anyone.

> to make tailscale's server better?

While I don't think that's accurate, I, too, am surprised that this feature isn't¹ completely free. After all, it will make it easier (or possible at all) for many people to use Tailscale.

¹) s/isn't/might not end up being. See https://news.ycombinator.com/item?id=45751253