upvote
I see it now, it's a bundle of both the practical and security aspects. I think the security aspects serve mostly as a marketing tool, potentially serving users who truly need a VPN.

But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.

Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.

Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.

reply
> But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle.

If you are listening on a public IP, you can trivially be attacked by anyone on the Internet.

If you listen on a private IP that only Tailscale can reach directly, you can only be attacked by Tailscale itself, or by anyone who successfully infiltrated Tailscale's network.

Should you run plaintext protocols over Tailscale? Absolutely not. But you're going to receive orders of magnitude less malicious traffic on a server accessible only over Tailscale compared to a server listening on the public Internet.

reply
Yeah, but to the extent that the server is useful, it needs to be exposed to the internet.

If you make your tailscale available to the internet through tailscale, you are still weak to external attackers, putting a VPN in the middle doesn't fundamentally change that dynamic, maybe it shifts it around and it confuses you enough to feel less shifty about it.

But it doesn't decrease your risk, if your HTTP server is weak to a tailscalething.tld/../../etc/ attack, it doesn't really matter that requests to other ports are blocked, (which probably don't even have processes listening anyways)

reply
> Yeah, but to the extent that the server is useful, it needs to be exposed to the internet.

Not if it's a private server, like the poster above was describing. For example, if I want to maintain a NAS to store my photos and view them anytime, I am better off running it on a Tailscale network that only I (and some friends/family) can acces, no reason to expose it publicly and then try to secure it.

reply
This use case you have in mind where someone has a fixed server and uses tailscale to patch over the lack of IP, I think is a very rare use case.
reply