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.)
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).
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.
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.
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.
I remember using Tinc a lot and really liking it. But as 1gbit+ speeds became more common, tinc struggled to maintain that much throughput on lowend hardware.
I also didn't know that tinc was still around, I might give it a try again just to play around with it and see what's changed.
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?
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.
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.
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.)
> 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 service better?
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.
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.
Great! This feature made a lot of sense, and it took a long time.
It’s like falling back to hub and spoke, except that the traffic is end to end encrypted, and the middle node is used only when direct connection is not possible, and for some clients. 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.
The derp servers have low throughput. Another option could be a pay-as-you-go derp service.
They might also be on their way to remove the need for reverse proxies, with the recent announcement on Tailscale services.
BTW, why could it be paid for more than two relays? You are using just your own devices and bandwidth :)
It actually lower the bandwidth bill for Tailscale by reducing the usage of their own relays. Ideally, by default the software will find whatever nodes could help with direct connection. It’s just routing within your own network.
One thing I didn’t understand: it uses an UDP port of my choice. What IP is it using? Everything via the tailnet or do I need to open this port to the internet?
If only available via Tailscale/tailnet - how is connectivity better since if two devices can connect to each other via Tailscale we are already on the direct connection route instead of a relay / derp connection?!
Is there a way to force clients to use a relay?
It seems like this is only meant as a fallback, but what if a relayed connection is actually faster (like when direct peering between tailnet members is slow, not rare in consumer connections)
Main downside I see compared to DERP is there's no way for this to work in the browser since it's native UDP. I wonder if it'd be possible to make it work over WebTransport in the future.
You can use Tailscale to connect services together (not just someone's laptop to a service, replacing OpenVPN), but what if Tailscale has an outage? Will my services not be able to find each other anymore?
> We believe our new Tailscale Peer Relays connectivity option—unique to Tailscale—gives customers the best performance and flexibility.
Seems pretty similar to some of the stuff ZeroTier was doing years ago. Hard to claim it's unique to Tailscale. Charging for it above and beyond the per user costs seems overboard as well.
Wow! I just spent a good chunk of time last week setting up headscale and split horizon SSL behind my network, and I expected I was going to just expose a Wireguard UDP port, but discovered no, it’s DERP or nothing. DERP has been OK, but I think just exposing a UDP port on my local network is better.
If we’re really confident in the security of that UDP client, that is. I feel very comfortable exposing a Wireguard bastion, time will tell how secure whatever protocol tailscale is serving, here, will be.
39 comments
[ 2.9 ms ] story [ 53.4 ms ] threadThe 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.)
Now I can rip all that out and use this! Bravo!
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.
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.
I also didn't know that tinc was still around, I might give it a try again just to play around with it and see what's changed.
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.
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.)
I have to pay to be able to donate my own infra to make tailscale's service better?
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.
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
They instead make your own infrastructure better.
Running a peer relay donates nothing to anyone.
It’s like falling back to hub and spoke, except that the traffic is end to end encrypted, and the middle node is used only when direct connection is not possible, and for some clients. 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.
The derp servers have low throughput. Another option could be a pay-as-you-go derp service.
They might also be on their way to remove the need for reverse proxies, with the recent announcement on Tailscale services.
BTW, why could it be paid for more than two relays? You are using just your own devices and bandwidth :)
It actually lower the bandwidth bill for Tailscale by reducing the usage of their own relays. Ideally, by default the software will find whatever nodes could help with direct connection. It’s just routing within your own network.
I recall that tailscale DERP servers were always slow and made things feel delayed when they had to be used as a relay.
If only available via Tailscale/tailnet - how is connectivity better since if two devices can connect to each other via Tailscale we are already on the direct connection route instead of a relay / derp connection?!
Seems pretty similar to some of the stuff ZeroTier was doing years ago. Hard to claim it's unique to Tailscale. Charging for it above and beyond the per user costs seems overboard as well.
If we’re really confident in the security of that UDP client, that is. I feel very comfortable exposing a Wireguard bastion, time will tell how secure whatever protocol tailscale is serving, here, will be.