An open source, self-hosted implementation of the Tailscale control server • Hacker News Board

Re: An open source, self-hosted implementation of the Tailscale control server

#51

Post by watusername » Thu, Apr 03, 2025, 1:46 PM UTC

cassianoleal wrote: post #32

udev4096 wrote: post #22

How does headscale hold up when you're streaming video over jellyfin/plex?

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.

> If it needs to go through a DERP server, then it may suffer but in my experience that’s pretty rare.

It's semi-frequent in my case, and it's painful every time it does that since Tailscale's official DERP servers are very slow (they seem to have some aggressive QoS). It would be nice if Tailscale supported using regular TURN servers so I could just use one of the hosted solutions.

Re: An open source, self-hosted implementation of the Tailscale control server

#52

Post by linsomniac » Thu, Apr 03, 2025, 1:47 PM UTC

mountainriver wrote: post #3

Love headscale, we just took it to production and it’s been great

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.

Re: An open source, self-hosted implementation of the Tailscale control server

#53

Post by alabastervlog » Thu, Apr 03, 2025, 1:49 PM UTC

3abiton wrote: post #5

This looks interesting! What's the added value over wireguard + openwrt setup?

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)

Re: An open source, self-hosted implementation of the Tailscale control server

#54

Post by davidcollantes » Thu, Apr 03, 2025, 1:59 PM UTC

Happily2020 wrote: post #33

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. https://netbird.io/knowledge-hub/tailscale-vs-netbird

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.

Re: An open source, self-hosted implementation of the Tailscale control server

#55

Post by pilif » Thu, Apr 03, 2025, 2:02 PM UTC

sixothree wrote: post #47

pilif wrote: post #12

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

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.

> Specifically mobile clients and battery usage.

yes. Battery usage is super bad, mainly because of their DNS features which forces every DNS resolution to go through their network extension. At least recent updates have stopped the background power usage when you disconnect from the network in the app.

>But tunneling traffic through them is extremely worrysome.

it only does that in case of super bad NATs that make the usual NAT traversal techniques impossible. And presumably, the traffic is end-to-end-encrypted, so it doesn't matter if they have to be in the loop.

If you don't trust them to properly end-to-end encrypt, then it really doesn't matter whether they are in the loop for forwarding a packet or not because if you don't trust them to encrypt properly, all bets are off to begin with.

If you trust them however, it doesn't matter where the traffic is flowing through because only the intended machine is able to decrypt it.

Re: An open source, self-hosted implementation of the Tailscale control server

#56

Post by cassianoleal » Thu, Apr 03, 2025, 2:13 PM UTC

watusername wrote: post #51

cassianoleal wrote: post #32

Earlier quoted context omitted.

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.

> If it needs to go through a DERP server, then it may suffer but in my experience that’s pretty rare. It's semi-frequent in my case, and it's painful every time it does that since Tailscale's official DERP servers are very slow (they seem to have some aggressive QoS). It would be nice if Tailscale supported using regular TURN servers so I could just use one of the hosted solutions.

You can self-host DERP if you're up for it.

Re: An open source, self-hosted implementation of the Tailscale control server

#57

Post by cassianoleal » Thu, Apr 03, 2025, 2:15 PM UTC

mrklol wrote: post #45

cassianoleal wrote: post #31

Earlier quoted context omitted.

As opposed to what? This seems pretty normal. We considered it as well but there was a feature missing that meant we couldn’t use it for one of our main requirements. Had that not been the case, we’d have rolled it out.

Mind sharing which feature?

Honestly I'm hazy on the details but we're running a fairly complex environment in GCP with PSC everywhere, connections to on-prem and other external environments, and something wouldn't quite work due to all that.

Sorry I can't provide any more details but I really don't remember the specifics. We were in touch with Tailscale engineers and they offered some workarounds that we had already worked out but that wouldn't help us achieve what we were after.

Re: An open source, self-hosted implementation of the Tailscale control server

#58

Post by techsupporter » Thu, Apr 03, 2025, 2:17 PM UTC

sixothree wrote: post #47

pilif wrote: post #12

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

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.

> The reason I can't use Tailscale at work is because it routes traffic through servers we can't control.

You can run your own DERP servers and exclude the Tailscale ones even if you don’t run your own Headscale server: https://tailscale.com/kb/1118/custom-derp-servers

Re: An open source, self-hosted implementation of the Tailscale control server

#59

Post by LilBytes » Thu, Apr 03, 2025, 2:19 PM UTC

cassianoleal wrote: post #56

watusername wrote: post #51

Earlier quoted context omitted.

> If it needs to go through a DERP server, then it may suffer but in my experience that’s pretty rare. It's semi-frequent in my case, and it's painful every time it does that since Tailscale's official DERP servers are very slow (they seem to have some aggressive QoS). It would be nice if Tailscale supported using regular TURN servers so I could just use one of the hosted solutions.

You can self-host DERP if you're up for it.

Yep and most of us are already using Subnet routers it's not technically much harder.

Finding a cloud or VPS provider with free or cheap bandwidth (egress and ingress) is likely the biggest issue.

Re: An open source, self-hosted implementation of the Tailscale control server

#60

Post by dcow » Thu, Apr 03, 2025, 2:32 PM UTC

pilif wrote: post #48

squiggleblaz wrote: post #41

Earlier quoted context omitted.

From https://github.com/tailscale/tailscale "This repository contains the majority of Tailscale's open source code. Notably, it includes the tailscaled daemon and the tailscale CLI tool. The tailscaled daemon runs on Linux, Windows, macOS, and to varying degrees on FreeBSD and OpenBSD. The Tailscale iOS and Android apps use this repo's code, but this repo doesn't contain the mobile GUI code." and "The macOS, iOS, and…

> I guess it would be much harder to produce an iOS or Android app because of the vagaries of mobile programming. on iOS you also need a special entitlement that's only available on specific request and only to known developers, so practically impossible for any open source project to acquire.

This was true in 2015. It is not true anymore.