Windows Kills SMB Speeds When Using Tailscale
danthesalmon.com
Windows Kills SMB Speeds When Using Tailscale
1–10 of 43 posts
Re: Windows Kills SMB Speeds When Using Tailscale
#2It was nice to see PowerShell could change the interface metric when the adapter GUI refused due to the empty IP field. I bet that check has been there since the 90s.
It makes me a little happy when a new CLI is able to do something the old GUI cannot!
Re: Windows Kills SMB Speeds When Using Tailscale
#3So, a virtual adapter advertises 100Gbps link speed, but is not capable of delivering that and the takeaway is "Windows kills..." ?
How do other OSes handle the situation of having two interfaces with identical routes to a given destination ?
I don't see a better solution than using link speed, but I haven't thought about it too deeply.
Re: Windows Kills SMB Speeds When Using Tailscale
#4I don’t think this is exclusive to Windows. SMB is a crappy service for anything outside local LAN. I am not too familiar with Tailscale but from what I understand, it’s basically akin to a VPN.
Re: Windows Kills SMB Speeds When Using Tailscale
#5I don’t think this is exclusive to Windows. SMB is a crappy service for anything outside local LAN. I am not too familiar with Tailscale but from what I understand, it’s basically akin to a VPN.
Did you read the linked post? It actually has nothing to do with SMB
Re: Windows Kills SMB Speeds When Using Tailscale
#6This is framed as a problem with windows, when it’s clearly a problem with tailscale misreporting its capabilities to the OS. If I have a 100gbit and a 1gbit interface, it’s perfectly reasonable for the OS to auto assign route metrics to prefer the much faster interface.
This is the OS working as designed, switching to Linux won’t help. Tailscale needs to do a better job reporting link characteristics.
Re: Windows Kills SMB Speeds When Using Tailscale
#7This isn't a Windows problem. The OP would experience the same problem on Linux. I've run into this with SRs. I believe I may have even opened an issue with Tailscale to detect when a client is local to an exit and/or provide more fine grained route ingestion depending on where the client is with respect to the SR.
But... Again, not a Windows problem. It is easy to fix by just advertising a longer route. But that implies you won't clobber other things. By default a more specific route will be chosen so a longer route advertised on the TS interface won't be selected.
Re: Windows Kills SMB Speeds When Using Tailscale
#8This is framed as a problem with windows, when it’s clearly a problem with tailscale misreporting its capabilities to the OS. If I have a 100gbit and a 1gbit interface, it’s perfectly reasonable for the OS to auto assign route metrics to prefer the much faster interface. This is the OS working as designed, switching to Linux won’t help. Tailscale needs to do a better job reporting link characteristics.
This actually would have nothing to do with the problem (advertised link speed) if Tailscale had more fine grained control over how SR routes are distributed. Currently it's all or nothing and there's no way to ignore specific routes if you're local to that network. Route length trumps network metrics, so it would be better handled in that manner.
In almost every OS I've seen interface metrics will only be used for equal cost route lengths.
Re: Windows Kills SMB Speeds When Using Tailscale
#9If 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.