Hacker News Reader

Comment by caconym_ | Hacker News Reader

If Tailscale is being used for remote access to the author's LAN, why is it running on a desktop that's always physically connected to the LAN? I have a similar setup for remote access but using Wireguard instead; my main router (pfSense VM running on Proxmox like the author's thing) handles the tunnels and routing for the remote subnet(s), and it all Just Works. Only the devices that actually get used remotely need to be set up as Wireguard peers, and they're configured to disconnect from the tunnel when they're on my home wifi. IIUC Wireguard automatically does the setup/teardown of routes on those peers when it's toggled on/off.

View on HN

>If Tailscale is being used for remote access to the author's LAN, why is it running on a desktop that's always physically connected to the LAN?

Because it's probably not only used for that. Personally, I want to access my local network segment from anywhere, and at the same time SSH into a cloud box without exposing port 22 to the internet.

Tailscale does the second one really well. I've also had problems with route loops which is why I've avoided the subnet router feature.

> Because it's probably not only used for that. Personally, I want to access my local network segment from anywhere, and at the same time SSH into a cloud box without exposing port 22 to the internet.

In my Wireguard-based setup there is no difference between the former and the latter. Remote peers connect to my router via a single open Wireguard port and then routing goes both ways—remote to LAN, LAN to remote, and also remote to remote via my router. Machines on the LAN have routes to any other LAN or remote machine without needing multiple interfaces or any local VPN configuration.

For some people Tailscale's features will be game changers (NAT hole punching, automatic DNS for all tailnet clients across multiple subnets, etc.) but I'm afraid OP may be using Tailscale as a crutch rather than getting his router sorted out properly, and the result is this weird redundancy of core network functions covering the same set of machines.

It's not even really a Tailscale problem per se, though I guess if you have machines naively connected to a Tailscale "subnet router" analogous to how my network is set up, you may not be able to take advantage of the full Tailscale feature set.

> If Tailscale is being used for remote access to the author's LAN, why is it running on a desktop that's always physically connected to the LAN?

Tailscale has a few nice additional features as well, like automatic DNS assignment for hosts on the virtual network, generation of HTTPS certificates for those hosts, and, if you enable the right middleware in your locally run services, transparent authentication to web servers for computers on the network. If you're going all-in on Tailscale, you can use it to automate a lot of network management. That would require you to run Tailscale on all of your devices, though.

Because, for whatever reason I’ve yet to grasp, homelab folks like to implement Tailscale as some sort of “secure virtual network” abstraction layer - think something similar to zScaler ZPA - on top of their local LAN. To be fair, I didn’t think Tailscale did a good job explaining why this isn’t a great idea last time I tinkered with it in 2022.

If you can juggle SSH keys and forward ports on your firewall, you can just run plain old Wireguard. Don’t use Tailscale as a network abstractor unless you know what and why you’re using it that way for.

I needed access to my home NAS and linux GPU box while visiting family last year over the holidays. I was in a rush. I spent 45 minutes trying to get Wireguard configured and working, then tried Tailscale and had the network I was looking for in 15 minutes. I'm not a homelabber. I hate network admin.

Is Just Works™ / being moron-resistant, with good first-party client apps, a bad reason to pick Tailscale?

Of course not - if it works, it works, and I won’t fault folks for using Tailscale (heck, I like Tailscale, but I just got Wireguard working suitably for my needs first). My gripe was more that folks use it for a virtual network on their home LAN without seemingly grasping the implications of such abstraction - kind of like how the trend during the pandemic was “everything in Kubernetes” even though VMs might have been a better fit for their given problem.

If you’re willing to put in the effort to make it work, then go for it, but I just caution folks to understand there might be better solutions to consider - and that especially when talking about abstraction layers, you absolutely need to understand the implications of said layers before deployment.

> Because, for whatever reason I’ve yet to grasp, homelab folks like to implement Tailscale as some sort of “secure virtual network” abstraction layer - think something similar to zScaler ZPA - on top of their local LAN.

This is Tailscale's intended behavior, not a matter of how homelab folks like to implement it: https://github.com/tailscale/tailscale/issues/659#issuecomme...

Maybe I'm not understanding properly, but why can't my device ARP ping and handshake with the subnet router to determine that I'm on the local subnet and to stop routing it through Tailscale?

It could, but the Tailscale devs don't consider "silently start leaking traffic to anyone on the local subnet" to be a desirable feature.

Tailscale intentionally overrides your device's routing table to force traffic between hosts in the same subnet to go over a Wireguard tunnel instead of bypassing it. They do this because they believe that the presumption that a local subnet is trustworthy is false.

This is why I (thought I) prefaced my gripe with the context of date and documentation. Looking at modern docs, yeah, it absolutely looks like it’s trying to be a Freemium alternative to something like zScaler but on top of Wireguard (virtual secure network), but the OP’s article still makes me bristle because it demonstrates the lack of knowledge of the implications of that deployment model.

Case in point is that their grievance is about SMB to their NAS being routed over Tailscale despite being on the same network as the SMB endpoints. Ideally this is something that should’ve come up during the architecture phase of deployment: how should traffic be handled when both machines share the same network? When should Tailscale’s routing table prefer the local adapter over the Tailscale adapter? If Tailscale cannot be configured to advertise a specific link speed that accurately reflects network conditions, how can we apply policies to the endpoints to route traffic correctly?

I admittedly used this article as a personal soapbox to yell at (software) folks to get out of my lane (IT), and that was a fault of mine; I should’ve taken more time to articulate the pitfalls of these sorts of rapid deployments homelabs can facilitate, and share my expertise from my field with others instead of grandstanding. That’s on me.

Reply on news.ycombinator.com