[traceroute66]

At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups.

But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years.

We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery. Especially as, AFAIK, Tailscale have never had a formal security audit on their software.

So we install it on hardened bastion hosts in an old-school "jump host" model. So people can still get access to where they need to be, but we don't need to install Tailscale's unaudited shit on every single server / vm / etc.

And we only use Tailscale as a glorified VPN, we don't use their hundreds of extra random features like this SSH one.

In terms of SSH, we use old-school OpenSSH and SSH certificates. Its really not that difficult and its really not expensive, you can do offline signing with Yubikeys, no need for expensive HSMs.

[zie]

> And we only use Tailscale as a glorified VPN, we don't use their hundreds of extra random features like this SSH one.

Same, you are not alone. The Tailscale VPN stuff just works. None of their competitors can claim this that I'm aware of. We tried several other products and none of them were as reliable and 'just worked'. I imagine they spend a lot of time just keeping that stuff working.

[eightys3v3n]

I haven't had problems with NetBird on Android and Linux. I have also used tailscale and found it comparable.

[zie]

Neat, I haven't heard of/tried NetBird yet. Always more stuff out there to tinker with!

[eightys3v3n]

Word of warning. Netbird does use maginally more data than Tailscale when idle. While you might be tempted by the Jetbird thirdparty app, I found it used ALOT more data and didn't work consistontly even with lazy connections.

[formerly_proven]

Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.

[zie]

Interesting! I use it only occasionally, but I don't leave the connection on. I only turn the iOS Tailscale connection on when I need to access resources behind Tailscale.

Are you having issues with it when it's always connected?

[formerly_proven]

It randomly and frequently turns off, then the connected services of course no longer work, then you turn it on manually, they still don’t work, then you hard kill safari a few times and/or toggle it on and off and it eventually works. On Linux or Windows the client is rock-solid however.

Meanwhile with wireguard: It just works. Every time. Every where. Unless someone blocks UDP.

[rudasn]

I have a hub and spoke wireguard nerwork that has been working somewhat perfectly for years, but there always are a couple of servers that just dont want to play nice. They connect to the hub, all good, and after a few minutes/hrs connection drops and handshakes fail. Using wireguard-go on docker (older linux machines) for all of them. Its a pain.

[traceroute66]

> Tailscale on iOS has always been highly unreliable for me

Its better than it used to be.

But the fundamental problem is that the Wireguard app is a simple GUI around `wireguard-go` built as a static C library via cgo. But Tailscale uses a fork of `wireguard-go` and then adds control client, DERP, NAT traversal etc. on top of it.

So there's quite a lot of "bloat" on top of the Wireguard code in Tailscale iOS and therefore your problem might not be Wireguard vs Wireguard implementation question but something happening elsewhere in the Tailscale code.

[Larrikin]

In what way has it been unreliable? All of my self hosted services sit on my local network with access provided by Tailscale. I navigate to the address and they just work.

[evan_a_a]

>We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery

Spoiler alert: This applies to all software. This is why security preaches defense in depth.

[traceroute66]

> Spoiler alert: This applies to all software. This is why security preaches defense in depth.

Thank you Mr/Mrs Pedant.

However this is a VPN product I am talking about which has an integral part in the defence in depth of which you speak.

Therefore it is only right and proper that I, and others, should be able to trust them to a greater degree. Never 100% of course, as you say. But if you are selling me a security product then you should be able to demonstrate you have put some damn effort into securing it.

"insecure argument handling" in a security product is not a good look. It stinks of sloppy coding practices followed up by a lack of security auditing.

[Retr0id]

I've been planning a similarly "paranoid" (but apparently not that paranoid) Tailscale setup, for the same reasons.

Another concern I have is whether a compromise of Tailscale's own infra could let an attacker just add itself to my network. Apparently the "Tailnet Lock" feature mitigates this, but it is off by default. If I was an APT, compromising Tailscale would be priority number 1!

[traceroute66]

> Another concern I have is whether a compromise of Tailscale's own infra could let an attacker just add itself to my network. Apparently the "Tailnet Lock" feature mitigates this, but it is off by default.

Yeah, we use "tailnet lock" to sort of cover that. AFAIK its the only option available.

I say "sort of" because "tailnet lock" is a bit half-assed in its design and implementation.

For example, you cannot sign new nodes from mobile devices (e.g. iOS). And as we know, locking down iOS is easier than a full desktop machine. So that's a bit of a missed opportunity. And as usual, there's a Tailscale Github issue open for it for years ...

And in practice, the "tailnet lock" addition is done through the `tailscale` software on the desktop/laptop. Its click a button or run a CLI without further authentication/authorisation required. So basically anyone could do it. And the keys are, of course, open to exfiltration, you can't use a Yubikey or anything like that. And you can't require multi-signer. Complete joke really.

Also if you use "tailnet lock" with the Tailscale Mullvad integration, its a one-way street. You can sign Mullvad nodes so they can be used as exit nodes, but it is impossible to revoke signatures from obsolete/replaced Mullvad nodes (with tailscale clients, you simply delete them from the org which means they have to re-auth and re-join under a new ID ... but you can't do that with the Mullvad integration, so the 'ghost' exit node could easily return). Your only option is to remove the signing node that signed the Mullvad nodes and start again from scratch. Another joke.

So, yeah, "better than nothing" is the way I would summarise "tailscale lock".

[rao-v]

Comically you can sign Tailnet lock from iOS, but it’s an insane workflow.

You need to generate a QR code then scan it from the signing mobile device, which opens a secret menu option to sign (fine just brings up a confirmation dialog).

Incredibly annoying but perhaps more secure vs the threat of randomly tapping at prompts

[traceroute66]

> Comically you can sign Tailnet lock from iOS, but it’s an insane workflow.

Interesting, thanks for pointing out the insane workflow.

Although looking around, footguns still remain in terms of relying too much on iOS and Tailnet Lock, e.g. https://github.com/tailscale/tailscale/issues/20475

[pedrocr]

> If I was an APT, compromising Tailscale would be priority number 1!

Crowdstrike would be at a much higher priority. They already have a cloud connected root console to all the machines in entire corporations. Compromising your network is small potatoes compared to that.

[ivlad]

Genuine question, if you use bastion hosts, why do you need Tailscale? Why not to expose tcp/22 to the internet and allow public key authentication only (or, certificate based one, if you prefer fancy)? OpenSSH security track record seems to be better than that of Tailscale.

[traceroute66]

> Genuine question, if you use bastion hosts, why do you need Tailscale? Why not to expose tcp/22

Fair question. The short answer is my wording was a little off.

We do have pure SSH bastion hosts. Those are OpenBSD-based with a few tweaks, but basically they are locked-down and heavily monitored to within an inch of their life.

The reason Tailscale is there is mostly so the non-techies can access intranet portals and such-like.

But Tailscale does have a useful party-trick for the techies too, in that you can do DNS-suffix based routing (without needing to use Tailscale's DNS).

So they can automagically hop via a Tailscale bastion host to "*.$region.rds.amazonaws.com" or whatever. You just specify the DNS suffix and anything on that wildcard will work. It therefore enables us to further harden access to that stuff to a source IP of the Tailscale bastion hosts (in addition to the usual security stuff, of course).

Tailscale takes care of the automagic load-balancing/re-routing to the Tailscale bastion hosts, so we just have a bunch installed in random geographically-dispersed places and as long as >0 are up and running the Techies will always have a route to where they need to be.

Obviously the above is over-simplified summary before the pedants start picking it apart. ;)

[fragmede]

Tailscale contracts with cybersecurity firm Latacora to conduct traditional assessments, advisory services, design reviews, auditing and testing.

https://tailscale.com/security

[traceroute66]

> Tailscale contracts with cybersecurity firm Latacora to conduct

And these published audits of the `tailscale` software are where ?

Even half-serious VPN providers like Mullvad publish in public their regular security audits of their app and infrastructure.

There is zero reason Tailscale cannot do the same.

And frankly, given the nature of this vulnerability, "insecure argument handling" I'm not entirely sure it has been audited ? Or if it has, they should be looking for a new auditor ASAP !

[_joel]

Agree, but I'd class Mullvad as the most serious VPN provider, personally.

[traceroute66]

> I'd class Mullvad as the most serious VPN provider

I agree. Its annoying that lots of places have recently been blanket-banning Mullvad IP ranges.

Their sister-company Tilitis[1] is also doing interesting things with the Tkey product.

The present version has limitations due to the original security model but the up-and-coming version has a revised security model to make things a bit more "real-world" useful whilst not making any security trade-offs.

[1] https://www.tillitis.se/

[Bnjoroge]

Did you try Headscale? https://github.com/juanfont/headscale or netbird? The latter has been great for me.

[traceroute66]

> Did you try Headscale? https://github.com/juanfont/headscale or netbird?

Am aware of them but IIRC they are both unaudited which kind of brings us back to square one ? We would still end up running them at arms-length as we do with Tailscale at the moment.

Isn't Headscale server-side only ?

Also a bit strange that "Tailscale vs Netbird" doesn't feature more prominently on their "Compare Netbird" page. It is hidden behind "Load More". ;D

[greengreengrass]

(not top poster)

> Isn't Headscale server-side only ?

Yes. You're still running the native Tailscale client code on the hosts, which this evidence reveals can't be as trusted as Tailscale would like us to believe.

I also wouldn't trust Headscale fully. It had a critical defect at some point that, IIRC, would allow an attacker to rotate the key of a registered node without auth to a value chosen by the attacker. And its primary maintainer is a member of the Tailscale team, apparently maintained with full approval of their employer and with reasonable transparency between the projects, but nonetheless the overlap is a little close for comfort.

Frankly, as you've said, I don't trust any of these solutions to be anything more than a convenient way to jump onto a bastion or another host of minimal consequence to get into the network and jump onwards.

[xyzzy_plugh]

> we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years.

This is a poor measure of quality. I've spent considerable time knee-deep in these issues in particular and the vast, vast majority of them are feature requests, bug reports awaiting more information from the submitter, or bug reports that cannot easily be reproduced (likely conflicts with other software). On the whole, Tailscale does an excellent job of "just working" in practically every possible environment. They do an incredible job thriving in the diverse ecosystem of software networking and their work will naturally never be remotely done. There will always be gaps, it's the nature of the beast. I'm not aware of any other product that does a better job here.

If you've spent any time dealing with enterprise software you'd know that there is an infinite firehose of these sort of issues. We're lucky that Tailscale keeps these public. Many other vendors track these sort of issues privately.

If there are particular issues which jeopardize the security posture of Tailscale deployments that have been open for a significant amount of time, my clients and I would love to know. Please share!

> We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery. Especially as, AFAIK, Tailscale have never had a formal security audit on their software.

I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?

I absolutely guarantee they undergo regular formal security audits. There's no question.

> So we install it on hardened bastion hosts in an old-school "jump host" model. So people can still get access to where they need to be, but we don't need to install Tailscale's unaudited shit on every single server / vm / etc.

Bastion hosts are a terrible model in 2026. I can't take this approach seriously.

> we don't need to install Tailscale's unaudited shit on every single server / vm / etc.

You never need to do this. Simply create an exit node into your subnet, and everything you want becomes routable.

It sounds to me like your architecture struggles with a zero-trust network approach if you view this as a blocker. I've got some slots available if you need a consultation!

> In terms of SSH, we use old-school OpenSSH and SSH certificates. Its really not that difficult and its really not expensive, you can do offline signing with Yubikeys, no need for expensive HSMs.

It's expensive in terms of engineer-hours, especially compared to Tailscale. It's also easy to get wrong, and end up with the same vulnerability as TFA, or worse.

But my main issue is that if you see this as equivalent it's telling me that you're not really the target audience. Your set-up is far more vulnerable than the out-of-the-box experience you get with Tailscale. If you don't mind, then I'm happy for you.

Lastly, I don't work for Tailscale and I'm not affiliated with them in any way beyond being a happy user that has solved a lot of problems very easily with their product. I highly recommend it to practically everyone. It's great.

I'm having a hard time taking your comment seriously. It just seems like non-constructive FUD.

[traceroute66]

> I absolutely guarantee they undergo regular formal security audits. There's no question.

Well, they clearly don't if they have an "insecure argument handling" vulnerability.

As others here have said already here, its an "venerable and ancient class of bugs".

Its the sort of thing that should be picked up by modern defensive programming that includes fuzz testing.

And it is CERTAINLY the sort of thing that should be flagged by any competent security audit. "insecure argument handling" is bread-and-butter for security auditors.

> I can't take this seriously. If you were a customer you could, you know, ask them? Or inspect their SOC2 documents?

SOC2, ISO27001 and all that shit is not the same thing.

As I said, anyone serious who is proud of having had their software audited as clean would publish their reports in public. Nothing to hide. And it strengthens your case with customers.

It can always be a suitably redacted management summary written by the auditor. That's what everyone else does.

[greengreengrass]

>> Or inspect their SOC2 documents?

> SOC2, ISO27001 and all that shit is not the same thing.

Hard agree. SOC2/ISO27001 are a thing that might be useful, but are mostly a framework dreamt up by auditors and other people who like wearing suits (and making lots of money).

They have some normative controls. But a SOC2 audit is not going to survive contact with an engineer who can push code and whose job depends on the company they work for making money. Where they have to ship product features, and don't have weeks to justify every line of code they write.

A SOC2 audit is not going to survive contact with a script kiddie in their bedroom (or, a nation-state APT) who has plenty of time and an LLM to help them find vulnerabilities or weird edge cases they can compose to attack a system.

These frameworks might serve a purpose, but corporate 'compliance' departments have been lulled into a false sense of security that a satisfactory SOC2 audit means the product is secure and obviates them from asking more technical details or for a fuller audit. It's not. That doesn't matter in a lot of cases, but probably does for a network security solution - I would absolutely be asking deeper questions if I was deploying any of these products en masse.

But then again, the insurers probably asked for a SOC2 certificate, so I guess like most things in life, it's not about whether the systems are secure - it's about whose insurance is ultimately covering the loss.

[xyzzy_plugh]

Have you tried asking them for a copy of such a report? Or is your plan to just continue complaining until they make one public?

The finding in TFA was the result of a security audit.

[cyphar]

As an open source maintainer of a fairly large project, we get reports from Ada Logics and similar firms every once in a while and those are absolutely not the same as a proper security audit (which we've also had commissioned in the past). Reports are just a description of a particular issue, not the deeper analysis of the general structure of the codebase that you get from a good audit.

[traceroute66]

> The finding in TFA was the result of a security audit.

Don't you fucking dare.

Might I point you to the words "We would like to thank Anthropic and Ada Logics for reporting this issue.".

It was not commissioned by Tailscale. It was DONE BY OTHERS AND REPORTED TO TAILSCALE. Just like the fucking disclosure tells you.

Tailscale should not be relying on the random goodwill of others to do random audits of unknown coverage at random intervals.

That is not a serious approach to security.

They should be commissioning their own, paid out of their own pocket, at regular intervals, and publishing the results.