Just a quick notice for anyone using this software in their homelab. Tailscale has released v1.104.4 to address a series of prominent vulnerabilities disclosed last week. These vulns affect the Tailscale Serve and Tailscale SSH functionalities of the software, and allow already-authorized attackers to gain further privileges erroneously. Kindly update to that version or higher, especially if you are using one of the SSH/Serve features.
For headscale selfhosters that also use Tailscale SSH, consider setting TS_SSH_DISABLE_FORWARDING=1 on all clients, as headscale does not have a way to force turning off SSH forwarding (one of the attack vectors). Headscale also has a relevant disclosed vulnerability affecting node registration, and an in-progress patch for that which is trackable here.
Finally, do give your SSH grants/access control list a review again. You may also disable these ssh/serve features if you don’t need them (and even compile the binary without them if you know how), and consider traditional alternatives such as OpenSSH + normal reverse proxy.
Further links:
- Tailscale’s blogpost on findings and fixes, with security recommendations
- Tailscale’s security bulletin for more info on the vulnerabilities (see TS-2026-014 to TS-2026-017)
- Their prior investigation notes here
This is pedantics, but technically what you are talking about can be achieved with wireguard too. You are talking about using STUN/TURN to do NAT holepunching to establish a connection between two wireguard clients.
Wireguard is just the vpn protocol. Tailscale even uses it. How the connection is established, is up to the user. So what you’re really talking about is Tailscale vs “how most people set up Wireguard”.
The reason why I make this distinction is because it would be nice if somebody made an easy self-hosted way to do the STUN/TURN stuff for plain wireguard.
There’s Headscale, but it can’t be fully selfhosted because you need an external host if both clients are behind NAT.
afaik Headscale is designed for Tailscale and not plain Wireguard. It’s overkill for plain wireguard.
I mean, “plain WG” doesn’t have the ability to connect multiple sites seamlessly, nevermind from behind NAT. That’s what Headscale/Tailscale do, they enable multiple WG backends to connect together on the fly into a common VLAN, with almost zero extra config.
It may seem overkill if you only want to connect two sites but once you solve this problem for 2 it’s basically also solved for N so why not take advantage of the capability.
Doesn’t Tailscale do a lot more, like ACLs and tailnet lock and a web ui and everything? I thought Headscale was trying to provide the same, though I admit I’ve never tried it myself
It does, there’s a lot of features and UI added on top of it because it’s primarily an enterprise-oriented service and large companies tend to have a lot more complex usage scenarios than self-hosters.
Headscale is a FOSS reimplementation from scratch of some of the Tailscale proprietary features. It’s inteded as a fallback option for Tailscale users in case the Tailscale service ever enshittifies, and also as a canary for ongoing verification of the Tailscale claim that the client plane functionality is entirely FOSS and above-board.
Speaking of which, Tailscale today is a great example of a company using FOSS well. They are able to provide commercial services and have proprietary code while at the same time opening the client-facing code so users can see for themselves their privacy is cryptographically proven. They also cooperate very well with Headscale and provide a generous gratis service tier.
My issue with Headscale is that it seems like they are providing a very complex product and haven’t had any security audits (at least last I checked)…
Wireguard is nice because it is very simple, and thus has a much smaller attack surface.