_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI An open source, self-hosted implementation of the Tailscale control server
1vuio0pswjnm7 wrote 3 hours 36 min ago:
"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".
aborsy wrote 4 hours 16 min ago:
How much is the risk of my devices being compromised if Tailscale
coordination server is compromised, and tailnet lock is enabled?
infogulch wrote 5 hours 13 min ago:
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 think it's a nice idea, but the maintainer kradalby said it's out of
scope when I brought it up in 2023:
URI [1]: https://github.com/juanfont/headscale/issues/1370
Happily2020 wrote 12 hours 24 min ago:
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.
URI [1]: https://netbird.io/knowledge-hub/tailscale-vs-netbird
unixfox wrote 31 min ago:
No IPv6 though. Which is real deal breaker:
URI [1]: https://github.com/netbirdio/netbird/issues/46
mynameisvlad wrote 1 hour 38 min ago:
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.
davidcollantes wrote 7 hours 0 min ago:
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.
yamrzou wrote 9 hours 30 min ago:
Does it do the fancy NAT-traversal Tailscale does?
mrbluecoat wrote 6 hours 21 min ago:
Yes:
URI [1]: https://www.netbird.io/knowledge-hub/netbird-network-route...
udev4096 wrote 15 hours 35 min ago:
How does headscale hold up when you're streaming video over
jellyfin/plex?
cassianoleal wrote 13 hours 12 min ago:
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.
watusername wrote 7 hours 13 min ago:
> 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.
cassianoleal wrote 6 hours 46 min ago:
You can self-host DERP if you're up for it.
LilBytes wrote 6 hours 40 min ago:
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.
scottyeager wrote 15 hours 10 min ago:
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.
voxadam wrote 15 hours 56 min ago:
Does it run on Plan 9?
bradfitz wrote 7 hours 18 min ago:
Ha! But seriously, it's written in Go, so probably.
SuperShibe wrote 17 hours 21 min ago:
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â¦
bananapub wrote 11 hours 54 min ago:
tailnet lock seems way way less important for headscale than
tailscale, given you personally control the headscale infra.
SuperShibe wrote 7 hours 22 min ago:
only until someone finds a zeroday in headscale (remember, it never
got audited) or until the server running headscale itself gets
compromised. Especially in countries where getting a dedicated
public IPv4+IPv6 from your ISP is hard-impossible and youâd have
to rely on a server hosted externally (unless youâre large enough
to make deals with the ISP) some company hosting your server still
retains at minimum physical control over your headscale infra. For
why this is a problem, see the recent Oracle cloud breach.
codethief wrote 7 hours 37 min ago:
Depends on your threat model. Mine definitely includes one of my
servers getting compromised. (Which, tbh, is probably more likely
than Tailscale getting hacked.)
botto wrote 9 hours 26 min ago:
This is my thought as well, if you are in control then you also
control which nodes go on your tailnet
nativeit wrote 16 hours 35 min ago:
> 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.
xrd wrote 8 hours 0 min ago:
Can you share why you use ZeroTier over Tailscale? I run several
headscale control planes and it really is nice to self-host. But,
I'm curious about other options.
password4321 wrote 5 hours 21 min ago:
Not OP but I'm on ZeroTier because it was one of the best free
tiers available before Tailscale could run as a Windows service.
Also I believe it implements a lower layer of the network stack
so more options are supported, though I haven't needed to
investigate in detail.
password4321 wrote 2 hours 47 min ago:
More ZeroTier 3 years ago:
URI [1]: https://news.ycombinator.com/item?id=30283987#30284754
bingo-bongo wrote 14 hours 15 min ago:
They have a really great in-depth blog post describing how they do
it:
URI [1]: https://tailscale.com/blog/how-nat-traversal-works
jacobtomlinson wrote 8 hours 5 min ago:
This is a fascinating read!
throawayonthe wrote 13 hours 42 min ago:
i think they mean headscale's implementation specifics
themgt wrote 16 hours 43 min ago:
c.f.
URI [1]: https://github.com/juanfont/headscale/issues/2416
gpi wrote 17 hours 5 min ago:
One of the maintainers work for tailscale now.
wutwutwat wrote 16 hours 56 min ago:
maintainer's employment != security audit
gpi wrote 16 hours 49 min ago:
My thinking is their time is divided now and could lead to less
efforts spent on headscale.
palotasb wrote 14 hours 19 min ago:
Not compared to the previous state where he worked for an
unrelated company and only had his free time to contribute to
Headscale.
pilif wrote 17 hours 44 min ago:
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
miki123211 wrote 1 hour 27 min ago:
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.
comex wrote 36 min ago:
> I think they have said somewhere that Headscale is actually
revenue positive for them.
I have the same memory. But they may not feel that way forever.
Many a company started by attracting developers with a generous
free tier or open-source offering, then started to clamp down once
the going got tough.
Heck, it happened to one of Tailscale's competitors, ZeroTier,
which used to release their client software under GPLv3 but
eventually switched to BSL.
sixothree wrote 7 hours 34 min ago:
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.
techsupporter wrote 6 hours 42 min ago:
> 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:
URI [1]: https://tailscale.com/kb/1118/custom-derp-servers
pilif wrote 6 hours 57 min ago:
> 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.
dcow wrote 6 hours 11 min ago:
On the battery topic Iâm curious if you have anything more than
anecdotal evidence. A basic full tunnel wg network extension
doesnât affect battery in a noticeable or unacceptable way, in
my experience. Is tailscaleâs implementation doing more in a
way you can isolate and attribute to poor battery?
sixothree wrote 5 hours 44 min ago:
I can see it (tailscale) in my battery usage on multiple
devices. 20 hours of background usage per day is a bit much if
you ask me.
CharlesW wrote 5 hours 8 min ago:
FWIW: On iOS 18.4 my Battery report for the last 10 days is
~128h of background activity, using ~2% of my battery life.
risho wrote 17 hours 17 min ago:
arent most of the the tailscale clients open source aside from the
gui portion of the non open source os's?
notpushkin wrote 8 hours 37 min ago:
I think the whole Windows client is closed. On macOS though you can
use it from the command line just fine (apart from a couple quirks
due to a completely different VPN implementation [1]).
[1]: they have three:
URI [1]: https://tailscale.com/kb/1065/macos-variants
squiggleblaz wrote 8 hours 10 min ago:
From [1] "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 Windows clients use the code in this
repository but additionally include small GUI wrappers. The GUI
wrappers on non-open source platforms are themselves not open
source."
Moreover, there's [1] -chocolatey to aid the build process. I
haven't built it or run it.
On the other hand, while I suppose the Windows app is probably
reasonably straightforward to replicate, I guess it would be much
harder to produce an iOS or Android app because of the vagaries
of mobile programming.
URI [1]: https://github.com/tailscale/tailscale
URI [2]: https://github.com/tailscale/tailscale-chocolatey
pilif wrote 7 hours 24 min ago:
> 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.
dcow wrote 6 hours 27 min ago:
This was true in 2015. It is not true anymore.
notpushkin wrote 8 hours 1 min ago:
Thanks, I stand corrected then!
Android client is open source (and you can get in from F-Droid,
even), so that only leaves iOS I guess.
freedomben wrote 4 hours 39 min ago:
Yep, Tailscale takes a pretty reasonable approach to that
IMHO. Open source on platforms that are open source. I
think that works out pretty well because it meets people
where they are. For example the people who care about open
source (and thus are running linux or android) get their open
source needs met, and people who don't care about open source
strongly or at all (as evidenced in part by them running
closed/proprietary OSes) such as mac or windows users are
also met where they are. Of course this also helps protect
their business model because then competitors can't just take
the open source versions and run off with them, and the
number of linux users is quite small compared to mac and
windows so it keeps the majority of the client closed while
still providing the openness to those who truly care about
it.
*In my perfect world everybody would care about open source,
but the evidence is pretty clear that only a tiny minority of
people actually do, even among engineers
pilif wrote 14 hours 16 min ago:
Yes they are, unless you're using a mainstream OS and/or want to
use a GUI, which is probably the most common use case.
__float wrote 11 hours 24 min ago:
While the GUI is somewhat helpful, at the end of the day it's not
the key piece, and it could easily be rebuilt.
snvzz wrote 17 hours 55 min ago:
Headscale has been serving me well for half a year now. It is great, to
the point I have no idea how I lived without a tailscale network
before.
It is packaged in openbsd, and that package is the server I am using.
pluto_modadic wrote 18 hours 35 min ago:
wonder if some of the bugs with self-managing it have been worked out
:)
3abiton wrote 18 hours 43 min ago:
This looks interesting! What's the added value over wireguard +
openwrt setup?
alabastervlog wrote 7 hours 10 min ago:
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)
sunshine-o wrote 14 hours 7 min ago:
Some do not want/have a fixed IP address or anything listening on
their home network.
Tailscale or having Headscale hosted somewhere else allows you to do
that.
usagisushi wrote 18 hours 16 min ago:
It's a mesh VPN, so peers communicate directly without additional
delay.
I opted for Netbird myself because Headscale's UI felt too basic for
me back then. Has that improved over the years probably?
udev4096 wrote 15 hours 29 min ago:
How is netbird? Is it more stable than tailscale/headscale? How is
your performance while streaming a video?
usagisushi wrote 9 hours 44 min ago:
They are both based on WireGuard (kernel-space and user-space
`wireguard-go`), so I guess there's no significant difference in
performance for typical usage.
In terms of stability, Netbird has been pretty good for me. I've
been using Netbird as the backhaul network for my laptop, phone
and inter-site k3s cluster for several years without major
issues.
One major downside of Netbird is that its Android client can be
quite a battery drainer [1]. (It keeps your fingers warm during
winter, though!)
As for Tailscale, it offers some neat features like Funnel, which
is missing in Netbird, but in my case, covered by DNS and k8s
Ingress.
[1]
URI [1]: https://github.com/netbirdio/netbird/pull/3379
watusername wrote 18 hours 23 min ago:
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.
compootr wrote 18 hours 18 min ago:
it's wireguard that doesn't make me hate myself :)
mountainriver wrote 19 hours 12 min ago:
Love headscale, we just took it to production and itâs been great
linsomniac wrote 7 hours 12 min ago:
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.
syntaxing wrote 18 hours 45 min ago:
As in you rolled out an internal service for the whole company?!
cassianoleal wrote 13 hours 14 min ago:
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.
mrklol wrote 7 hours 53 min ago:
Mind sharing which feature?
cassianoleal wrote 6 hours 44 min ago:
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.
sshine wrote 16 hours 19 min ago:
Iâd love to see a write-up on that.
Especially in the unlikely event that you used Nix for the
deployment.
benley wrote 15 hours 13 min ago:
I've done exactly that: headscale in production at work, a few
hundred client devices, infrastructure mostly powered by nix.
What would you want to hear about it?
sshine wrote 50 min ago:
> headscale in production at work
- How much effort do you put into key management compared to
plain WireGuard?
- How automated is the onboarding process; do you generate
and hand over keys?
- How do you cope without the commercial Tailscale dashboard?
- Do you run some kind of dashboard or metrics system?
- How long did it take to set up?
- Were there any gotchas?
squiggleblaz wrote 8 hours 21 min ago:
* Does it work well?
* Do you recommend it?
* Do your users care?
* Is it difficult? Do you have to maintain it or is it
basically set it and forget it?
* What was memorable about setting it up?
* Why did you go for Headscale vs Tailscale or Netbird or some
other solution?
telotortium wrote 19 hours 50 min ago:
Should add the project name, Headscale, to the title
Headscale has been on HN many times.
DIR <- back to front page