5 ms·

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

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.

fragmede 3mo ago
Tailscale contracts with cybersecurity firm Latacora to conduct traditional assessments, advisory services, design reviews, auditing and testing. https://tailscale.com/security https://tailscale.com/security
- traceroute66 3mo ago
  > 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 3mo ago
    Agree, but I'd class Mullvad as the most serious VPN provider, personally.
    - traceroute66 3mo ago
      > 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/ https://www.tillitis.se/
evan_a_a 3mo ago
>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 3mo ago
  > 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.
ivlad 3mo ago
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 3mo ago
  > 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. ;)
Retr0id 3mo ago
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 3mo ago
  > 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 3mo ago
    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
Bnjoroge 3mo ago
Did you try Headscale? https://github.com/juanfont/headscale https://github.com/juanfont/headscale or netbird? The latter has been great for me.
- traceroute66 3mo ago
  > Did you try Headscale? https://github.com/juanfont/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 3mo ago
    (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 3mo ago
> 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.
zie 3mo ago
> 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 3mo ago
  I haven't had problems with NetBird on Android and Linux. I have also used tailscale and found it comparable.
  - zie 3mo ago
    Neat, I haven't heard of/tried NetBird yet. Always more stuff out there to tinker with!
    - eightys3v3n 3mo ago
      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 3mo ago
  Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.
  - zie 3mo ago
    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?
    - 3mo ago

fragmede 3mo ago

Tailscale contracts with cybersecurity firm Latacora to conduct traditional assessments, advisory services, design reviews, auditing and testing. https://tailscale.com/security https://tailscale.com/security

traceroute66 3mo ago
> 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 3mo ago
  Agree, but I'd class Mullvad as the most serious VPN provider, personally.
  - traceroute66 3mo ago
    > 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/ https://www.tillitis.se/

evan_a_a 3mo ago

>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 3mo ago
> 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.

ivlad 3mo ago

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 3mo ago
> 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. ;)

Retr0id 3mo ago

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 3mo ago
> 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 3mo ago
  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

Bnjoroge 3mo ago

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

traceroute66 3mo ago
> Did you try Headscale? https://github.com/juanfont/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 3mo ago
  (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 3mo ago

> 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.

zie 3mo ago

> 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 3mo ago
I haven't had problems with NetBird on Android and Linux. I have also used tailscale and found it comparable.
- zie 3mo ago
  Neat, I haven't heard of/tried NetBird yet. Always more stuff out there to tinker with!
  - eightys3v3n 3mo ago
    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 3mo ago
Tailscale on iOS has always been highly unreliable for me, while the regular Wireguard app just works.
- zie 3mo ago
  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?
  - 3mo ago