Every few months I come back to this repo to check if they finally got Tailnet lock running or if someone security audited them in the meanwhile. Unfortunately neither of these things seem to make any progress and thus, I’ve grown uncertain in how much I can trust this as a core part of my infrastructure.
The entire premise of Tailscale SaaS builds on creating tunnels around your firewalls, then enabling the user to police what is allowed to be routed through these tunnels in a intuitive and unified way.
Headscale seems to have nailed down the part of bypassing the firewall and doing fancy NAT-traversal, but can they also fulfill the second part by providing enough of their own security to make up for anything they just bypassed, or will they descend to just being a tool for exposing anything to the internet to fuck around with your local network admin?
To me, not giving your Tailscale implementation any way for the user to understand or veto what the control server is instructing the clients to do while also not auditing your servers code at all sure seems daring…
> Headscale seems to have nailed down the part of bypassing the firewall and doing fancy NAT-traversal
Did they really roll-their-own for those functions? I thought this was just a control layer on top of Tailscale’s stock services on the backend, are they facilitating connections with novel methods? Apologies if I’m asking obvious questions, I use ZeroTier pretty regularly, but I am not too familiar with Tailscale.
If you're interested in self-hosting your orchestration server, you can look into Netbird. It's a very similar tool, but has the server open sourced as well. So you have a self-hosted control server with a nice GUI and all the features the paid version does.
Compared to Headscale, Netbird has so many moving pieces! It looks robust, and powerful, and featureful... yet, self-hosting Headscale is super simple, and less demanding.
I've been slowly moving everything over from Tailscale to Netbird and aside from some shenanigans with Tailscale taking over the entire CGNAT route, it works wonderfully!
Tailscale is still running for now, but I'm getting closer and closer to decommissioning it and switching entirely to Netbird.
I think it would be neat if headscale allowed peering / federating between instances. (Maybe after the ACL rework.) One of the main problems is address collisions.
So here's my proposal: commit to ipv6-only overlay network in the unique local address (ULA) range, then split up the remaining 121 bits into 20 low bits for device addresses (~1M) and 101 high bits that are the hash of the server's public key. Federate by adding the public key of the other instance and use policy and ACLs to manage comms between nodes.
I've been running headscale for 2.5 years and it's been pretty good. We use our gmail domain for logging in, which gives a big benefit that users can self-serve their devices. Unlike with OpenVPN in the past where ops had to hand off the certs and configs. Really the only downside has been when they accidentally connect to the tailscale login server instead of our own and then can't figure out why they can't reach any services. We use user groups to set up what services users can access.
We are still running the old headscale, because we have some integrations that will need to be ported to the new control plane. According to "headscale node list | wc" we have ~250 nodes, most of them are servers.
One thing I really don't love about tailscale some of the magic it does with the routing tables and adding firewall rules, but it has mostly not been an issue. Tailscale has worked really quite well.
Keep in mind that for many use cases (mobile access, GUI on macOS), this relies on the official Tailscale clients keeping the ability to set the control server.
The moment the inevitable enshitification will start at Tailscale, this feature will go away.
I’m saying this as a currently super happy Tailscale customer who was burned multiple times in the past by other companies being sold or running out of VC money
I may be misremembering, but I think they have said somewhere that Headscale is actually revenue positive for them.
That feels right to me. Headscale is mostly used by home labbers and small hobby users, it competes with self-hosted OpenVPN and WireGuard, not Pulsesecure, Cisco Anyconnect or GlobalProtect. It's a way to introduce Tailscale to people who love to try new shiny tech in their spare time, but don't want to give up control over their infrastructure.
Those people will then bring their Tailscale expertise and enthusiasm to work. Work really doesn't like managing IT infrastructure unless it's one of their core competencies.
Sure, some companies will actually choose Headscale over Tailscale proper, but I suspect that's a small minority (especially if you take company size and the money involved into account). That's just cost of revenue, not unlike Facebook advertising or billboards on the side of a road in Silicon Valley.
Tailscale clients are the thing I am least happy about with Tailscale. Specifically mobile clients and battery usage.
The reason I can't use Tailscale at work is because it routes traffic through servers we can't control.
I would _love_ to use tailscale at work. It would solve so many problems. I am okay with being forced to open ports. But tunneling traffic through them is extremely worrysome.
Your devices will connect to each other peer-to-peer (even behind complex NATs) with no manual configuration, subject to ACLs you centrally manage. It just works.
People sometimes dismiss Tailscale as "just" a WireGuard orchestrator, but it's actually much more than that - From a product perspective, WireGuard is just an implementation detail.
Tailscale's value prop is "Wireguard that the merely somewhat-technically-inclined can set up and manage unassisted". Across tons and tons of clients (my AppleTVs connect to my Tailscale network, this took maybe a minute to configure—and they can act as gateways)
"To me, not giving your Tailscale implementation any way for the user to understand or veto what the control server is instructing the clients to do while also not auditing your servers code at all sure seems daring..."
This statement sugggests that publishing the Headscale control server source code is not enough to allow the user to "understand or veto what the control server is instructing the clients to do".
If using the Headscale control server, the user can "understand or veto" anything "the control server is instructing the clients to do". This may be accomplished by reading, editing and compiling the source code.
If using the Tailscale control server, the user can only "understand or veto what the control server is instruction the clients to do" to the extent that the Tailscale company permits. The user is prohibited from editing or compiling the source code.
Not all users want the option to read, edit and compile third party software that they use. Some users may be comfortable relying on the ongoing assurances of companies funded by Silicon Valley VC. For those users that want the option of 100% open source projects, not dependent on venture capital, Headscale can be useful.
The author of Headscale calls the Tailscale coordination server "essentially a shared dropbox for public keys".
Do you mean when using it as a relay because p2p connectivity isn't possible? The preferred operating mode of Tailscale networks is for the bulk of traffic to go p2p, using various tricks for NAT and firewall traversal.
I’ve used it extensively to stream video across continents. No issues as long as you can get a P2P connection going. If it needs to go through a DERP server, then it may suffer but in my experience that’s pretty rare.
SuperShibe|11 months ago
The entire premise of Tailscale SaaS builds on creating tunnels around your firewalls, then enabling the user to police what is allowed to be routed through these tunnels in a intuitive and unified way.
Headscale seems to have nailed down the part of bypassing the firewall and doing fancy NAT-traversal, but can they also fulfill the second part by providing enough of their own security to make up for anything they just bypassed, or will they descend to just being a tool for exposing anything to the internet to fuck around with your local network admin? To me, not giving your Tailscale implementation any way for the user to understand or veto what the control server is instructing the clients to do while also not auditing your servers code at all sure seems daring…
bananapub|11 months ago
nativeit|11 months ago
Did they really roll-their-own for those functions? I thought this was just a control layer on top of Tailscale’s stock services on the backend, are they facilitating connections with novel methods? Apologies if I’m asking obvious questions, I use ZeroTier pretty regularly, but I am not too familiar with Tailscale.
gpi|11 months ago
themgt|11 months ago
Happily2020|11 months ago
https://netbird.io/knowledge-hub/tailscale-vs-netbird
davidcollantes|11 months ago
mynameisvlad|11 months ago
Tailscale is still running for now, but I'm getting closer and closer to decommissioning it and switching entirely to Netbird.
nchmy|11 months ago
Here's a gh issue for it.
https://github.com/netbirdio/netbird/issues/1103
unixfox|11 months ago
yamrzou|11 months ago
telotortium|11 months ago
Headscale has been on HN many times.
infogulch|11 months ago
So here's my proposal: commit to ipv6-only overlay network in the unique local address (ULA) range, then split up the remaining 121 bits into 20 low bits for device addresses (~1M) and 101 high bits that are the hash of the server's public key. Federate by adding the public key of the other instance and use policy and ACLs to manage comms between nodes.
I think it's a nice idea, but the maintainer kradalby said it's out of scope when I brought it up in 2023: https://github.com/juanfont/headscale/issues/1370
snvzz|11 months ago
It is packaged in openbsd, and that package is the server I am using.
mountainriver|11 months ago
linsomniac|11 months ago
We are still running the old headscale, because we have some integrations that will need to be ported to the new control plane. According to "headscale node list | wc" we have ~250 nodes, most of them are servers.
One thing I really don't love about tailscale some of the magic it does with the routing tables and adding firewall rules, but it has mostly not been an issue. Tailscale has worked really quite well.
syntaxing|11 months ago
voxadam|11 months ago
bradfitz|11 months ago
pilif|11 months ago
The moment the inevitable enshitification will start at Tailscale, this feature will go away.
I’m saying this as a currently super happy Tailscale customer who was burned multiple times in the past by other companies being sold or running out of VC money
risho|11 months ago
miki123211|11 months ago
That feels right to me. Headscale is mostly used by home labbers and small hobby users, it competes with self-hosted OpenVPN and WireGuard, not Pulsesecure, Cisco Anyconnect or GlobalProtect. It's a way to introduce Tailscale to people who love to try new shiny tech in their spare time, but don't want to give up control over their infrastructure.
Those people will then bring their Tailscale expertise and enthusiasm to work. Work really doesn't like managing IT infrastructure unless it's one of their core competencies.
Sure, some companies will actually choose Headscale over Tailscale proper, but I suspect that's a small minority (especially if you take company size and the money involved into account). That's just cost of revenue, not unlike Facebook advertising or billboards on the side of a road in Silicon Valley.
sixothree|11 months ago
The reason I can't use Tailscale at work is because it routes traffic through servers we can't control.
I would _love_ to use tailscale at work. It would solve so many problems. I am okay with being forced to open ports. But tunneling traffic through them is extremely worrysome.
3abiton|11 months ago
watusername|11 months ago
People sometimes dismiss Tailscale as "just" a WireGuard orchestrator, but it's actually much more than that - From a product perspective, WireGuard is just an implementation detail.
usagisushi|11 months ago
I opted for Netbird myself because Headscale's UI felt too basic for me back then. Has that improved over the years probably?
alabastervlog|11 months ago
sunshine-o|11 months ago
Tailscale or having Headscale hosted somewhere else allows you to do that.
unknown|11 months ago
[deleted]
aborsy|11 months ago
1vuio0pswjnm7|11 months ago
This statement sugggests that publishing the Headscale control server source code is not enough to allow the user to "understand or veto what the control server is instructing the clients to do".
If using the Headscale control server, the user can "understand or veto" anything "the control server is instructing the clients to do". This may be accomplished by reading, editing and compiling the source code.
If using the Tailscale control server, the user can only "understand or veto what the control server is instruction the clients to do" to the extent that the Tailscale company permits. The user is prohibited from editing or compiling the source code.
Not all users want the option to read, edit and compile third party software that they use. Some users may be comfortable relying on the ongoing assurances of companies funded by Silicon Valley VC. For those users that want the option of 100% open source projects, not dependent on venture capital, Headscale can be useful.
The author of Headscale calls the Tailscale coordination server "essentially a shared dropbox for public keys".
udev4096|11 months ago
scottyeager|11 months ago
cassianoleal|11 months ago
pluto_modadic|11 months ago