Ah, non-transparent middlebox trouble.
Windows Kills SMB Speeds When Using Tailscale
31–40 of 43 posts
Re: Windows Kills SMB Speeds When Using Tailscale
#32I’ve been curious as to why SMB seems to get little attention, and NFS even less. I had to go through hoops to even get NFS working at all on Windows.
I treated myself to 10GbE a while ago, and it feels like the protocol side of this is something that just gets overlooked. Unclear why. Maybe people just assume once it works, it works?
Re: Windows Kills SMB Speeds When Using Tailscale
#33Earlier quoted context omitted.
Tailscale shouldn't advertise a route that is local to the machine. This is a routing loop. The way SR route distribution works in Tailscale is that you accept all routes or nothing. Routing platforms have the concept of route filters to prevent accepting an advertised route that would create a loop. There are hacky ways around this without having to deal with metrics (just advertise a /23 instead of a /24 and the /2…
I really thought Tailscale would automagically figure this out. If this were true in all cases, my internet would not work at all since it would try to reach my router through the Tailscale interface. It's odd.
You don’t have any specific routes to random internet addresses though. And Tailscale would not either. Unless your Windows server is running BGP, all your Internet traffic is hitting the default route.
Re: Windows Kills SMB Speeds When Using Tailscale
#34I feel like this whole thing buries the lede a bit. Yes, turns out running overlay/VPN type things disrupts traffic patterns. This is a non-story. But we're talking about using wireguard on a local network, so the actual interesting question is: why does it cause the performance to plummet? Is it an implementation issue or something more fundamental? I expect some performance impact. I don't expect a three orders of…
It’s TCP, so bandwidth-delay product, if the hairpin that gets the traffic back to the local lan does anything non-trivial.
Re: Windows Kills SMB Speeds When Using Tailscale
#35It 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!
It's not just the new CLI. I guess you could have done the same with netsh for ages as well.
Re: Windows Kills SMB Speeds When Using Tailscale
#36If 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…
>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…
> 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.
Re: Windows Kills SMB Speeds When Using Tailscale
#37Does this also happen in Zerotier?
Don't take me wrong, I think tailscale is absolutely great, I'm just interested in trying Zerotier for a while since it has integration with OPNSense (in the GUI, I know tailscale works fine if you install the package and configure it manually).
Re: Windows Kills SMB Speeds When Using Tailscale
#38Earlier quoted context omitted.
Tailscale shouldn't advertise a route that is local to the machine. This is a routing loop. The way SR route distribution works in Tailscale is that you accept all routes or nothing. Routing platforms have the concept of route filters to prevent accepting an advertised route that would create a loop. There are hacky ways around this without having to deal with metrics (just advertise a /23 instead of a /24 and the /2…
I really thought Tailscale would automagically figure this out. If this were true in all cases, my internet would not work at all since it would try to reach my router through the Tailscale interface. It's odd.
The SR can't route for your gateway or else Tailscale itself would break it's own connection. A gateway IP isn't treated the same as a subnet route.
Re: Windows Kills SMB Speeds When Using Tailscale
#39I feel like this whole thing buries the lede a bit. Yes, turns out running overlay/VPN type things disrupts traffic patterns. This is a non-story. But we're talking about using wireguard on a local network, so the actual interesting question is: why does it cause the performance to plummet? Is it an implementation issue or something more fundamental? I expect some performance impact. I don't expect a three orders of…
I check the "Allow local network access" in Exit Nodes, then it transfers at max speed over local Ethernet.
This doesn't actually affect anything if you're accepting Tailscale SRs. The conflict the article states is accepting a route advertised by Tailscale for their local network (the SR route) while on the local network (same network as the SR route). This forces all traffic through the wireguard interface, then it's routed to the SR and then back out because the interface metric is better than the hardware because of the link speed advertised. This is the root of the bandwidth issue.
The "Allow local network access" is an IP filter that's put into place or not.
Re: Windows Kills SMB Speeds When Using Tailscale
#40This 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.
Using actual throughput would be a nice improvement over using link speed. In this case, just detecting the current throughput is a tiny fraction of the link speed and falling back to another link would be a huge improvement.