Indeed, this is why I won't use it either. I settled on Slack's Nebula [0] instead of wireguard because it handles direct p2p communication between nodes automatically.
There also exists an open source implementation of the tailscale control server [1] that you could self host.
We briefly considered building something atop Wireguard in the early days of Nebula, but decided not to do so because of scaling. Wireguard's protocol necessitates that all nodes have existing keypairs for each other ahead of time. At Slack's scale, that means every time a fresh node is launched, you would have to tell 50,000 other nodes it exists.
Obviously you can smarten this up and tell only hosts it might talk to. But this adds complexity. Using PKI eliminates this key distribution problem and means that you don't have the same scaling limitations as something built on WG.
Wireguard is a very very good VPN, but I cannot imagine trying to run something on the scale of tens of thousands of nodes when you need such complex coordination systems to exchange keys/trust, especially in a dynamic environment where nodes are coming and going all the time.
I totally get that it solvable overall, but Slack has had 4 years of nearly perfect uptime on Nebula, whilst using it to pass >95% of all backend traffic. These considerations may seem simple to address, but there are fundamentals that mattered and led us to writing Nebula. We didn't want to create something new, but to do what Slack needed, we had to.
It's not clear to me how much day-to-day use of Wireguard being a Fly customer requires, but I can't help but wonder if you guys should collaborate with Tailscale to make all of the micro-VMs appear on a Tailscale network, and authorize access between humans and the VMs that way.
(I admit that I haven't looked much into mesh networking / edge servers, so I don't know what the problems are. I always preferred Internet -> Identity Aware Proxy type thing -> mTLS mesh that is useless to humans. And, I don't ssh to stuff much anymore... I have my software collect debugging information and send it to something I can access through a browser or API, and control that software through an API. So everything is editing config files, basically, not SSHing places ;)
I think that by the sheer nature of Wireguard, it doesn't matter much. We don't send any readable data to Tailscale, they, for the greater part, handle plumbing between nodes. What goes in the pipes remains unnoticed and unknown to them.
Their MagicDNS feature may raise different concerns though, but I'll let others comment on it.
Tailscale uses Wireguard, but offers so much more on top. I used to think the same, but I think I was mixing it up with Zerotier; had a play with it and now think it's pretty great.
For example, you can set ACL rules for which devices can access which others (or the internet, if you have explicit exit nodes) - it's using Wireguard for networking, but you can't do that with (just) Wireguard, it's not just 'make Wireguard easier to set up', as you said that doesn't really need doing.
Yeah, definitely worth mentioning that Wireguard is actually super easy to manually configure, especially if you don't have a bazillion hosts or need to integrate with auth domains. I think a lot of the stuff individuals end up setting up Tailscale/Zerotier for (they obviously have a lot of other stuff going on, but the relevance to individual/small group users may be limited) would be equally well-served by plain old Wireguard.
I have heard this before (that wireguard does p2p), but have yet to see any examples of how to run this. Is it theoretical or just not fully implemented...?
Indeed. The author could have spent 15 minutes setting up Tailscale [0] and not expose any listening administration ports to the Internet at all. If they wanted to avoid using a hosted service, Wireguard alone is incredibly defensive against attackers who do not have access to the secret material. Tailscale basically just adds some NAT traversal [1] and OIDC login wrappers.
I'm not, but you could use vanilla Wireguard either directly to the exit node, or to another device (a little Pi or something) running Tailscale as a ..relay node I think they call it.
I've read that some people have used port 853 to mimic encrypted DNS or other ports less than 1024 to circumvent some WireGuard limits. I've yet to run into that.
If you use Wireguard only to route to/from to a central hub that has a static IP address then what you have is perfectly fine.
Tailscale works well for situations where you have lots of roaming devices that perhaps want to talk to each other as well as to central hubs or you want to gate all of this behind some kind of SSO.
I use tinc myself and like it. I like that I only have to update a single node and all the other nodes will accept those peers from that node. I've been playing with wireguard, and having the other nodes discover and communicate with each other directly doesn't happen without you adding the other's public key to both peers.
I remember there was talk about switching the backend for Wireguard for security and speed, but it seems to be on the backburner: https://github.com/gsliepen/tinc/issues/179
Kind of, in that you can use it to replace Tailscale if you want. Using Yggdrasil as a DIY Tailscale replacement is probably less work than manually configuring WireGuard, because it handles the mesh features of Tailscale for you.
All nodes are publicly routable rather than private, though. If you want to lock everything down to emulate Tailscale, you can just configure your firewall to only allow traffic from a whitelist of your devices' Yggdrasil addresses[1].
They customized it some, but it's all more or less upstream condoned code that Jason built.
Also, if you want to access your tailscale network, but don't have permissions to create a tun or wg device, the fully userspace implementation can work in that situation, which seems like a nice property to have.
The main reason I use wireguard on my personal network is to keep 3rd party clouds out of it. My understanding is that a closed source node that phones home is part of their solution. For my personal case, this is a total no-go.
There also exists an open source implementation of the tailscale control server [1] that you could self host.
[0] https://github.com/slackhq/nebula
[1] https://github.com/juanfont/headscale
reply