Now I can rip all that out and use this! Bravo!
Even a cursory look at htop on both ends while you're trying to saturate that link would be informative.
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.
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.
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
So yes it is a differentiated thing between wireguard and tinc, as you phrased it in your other comment.
tinc: One public node, thousands of private nodes, with NAT punching. That's fine and typical in my experience.
But all that I've seen are still centralized/federated
It's not as simple to make it reliable as it is with Tailscale, but it works
It doesn't universally work without a helper script and a STUN server, though - you need a suitably "friendly" NAT that has reasonably predictable behaviour with respect to port mapping and/or just one side of each pair behind a NAT.
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.
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.
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.
I have a pretty basic setup with tailscale setup on an Apple TV behind a bunch of UniFi devices and occasionally tunnelled traffic is incredibly slow.
Wondering if it’s worth setting this up on my Plex server which is behind fewer devices and has a lot of unused network and cpu.
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've also used ZeroTier with good success.
They're a competitor that offers VPN with similar idealized P2P topology. Unlike Tailscale, ZT is not based on wireguard (ZT predates wireguard), but they do offer the option to use their own local auth without reliance/potential issues with yet-another party.
ZT also allows a person to create and use their own relay (called a "moon"), if that's something useful: https://rayriffy.com/garden/zerotier-moon
(For my own little purposes I don't really have a preference between either Zerotier or Tailscale.)
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 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.
It’s not a standard Wireguard port. With Wireguard included in Linux, I would not be worried.
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?!
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.
So instead of whitelisting all ports from IP range 100.64.0.0/10 I would just whitelist e.g. UDP port 12345 coming from IP range 100.64.0.0/10 to my public IP? Or just open up UDP 12345 completely?
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.
If it all comes together this may well become more magic :D
I hadn't heard about iroh using QAD. Thanks for that.
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.
amluto•10h ago
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.)
conradludgate•9h ago
karaziox•9h ago
I was also a bit confused on the meaning of src/dst in the grants. The naming didn't match my thinking.
amluto•9h ago
kabirx•9h ago
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.