Windows routes all SMB traffic through Tailscale even when LAN IP is specified (is much slower)

Windows
1

I have 3 windows devices on the same 1Gbps physical network that are connected to the same Tailscale “Tailnet”. Even when I use the local IP address (like \\192.168.1.100\C) to mount drives over SMB shares in Windows, System still makes that connection through tailscale regardless.

I can see that System is uploading/downloading through 100.x.x.x IPs from resource monitor. As a result, the speeds are at most 25 MB/s when they can easily be 100 MB/s+ through the local IP.

Besides trying to block off all Port 139/445 traffic from all tailscale IPs using firewall rules, I can’t find a way to fix this, and I don’t want to block SMB traffic because I need SMB over Tailscale when I’m outside with my laptop.

Even if I disconnect Tailscale for a while, as soon as I connect to it again, System starts routing all traffic through tailscale IP again and reduces speed too much.

Why does Windows do this? Connects through a different IP even when I specified which IP to use while mounting the shares or accessing them?

One guess I have is - in network adapter properties, Tailscale states it’s bandwidth as 100 Gbps, which could be the reason why Windows routes through that IP instead, but it should still not ignore a directly mentioned IP.

Is there any way to fix this and route through local IPs instead of Tailscale when possible?

2

I have not encountered that in my setups. Could you make a connection over SMB, then run tailscale bugreport and send that code to support@tailscale.com ?

3

Sure, will do. Thanks.

4

I’m having the same issues. I tried disabling NETBIOS entirely (in network settings) and still the network file share traffic routes through TailScale. And what’s even more fun is that my network shares are pointing directly to local DNS hostnames (like server.local resolves to 172.16.1.10) - and not a NETBIOS/etc name like “server”.

5

Did you ever get this resolved?

6

Keep in mind that I’m just another user and an enthusiast… I could possibly be wrong about some things in the explanation. (but the solution I list works for me :slight_smile: )

Explanation (what I think is the case) -
This seems to be a problem with Windows, not Tailscale.

I don’t think anything “routes through” tailscale IP to local IP (100.x.x.x ↔ 192.168.x.x) because that makes no sense - there is no route from the virtual subnet to the physical one, but instead, I think Windows matches NETBIOS or some sort of domain names on both IPs and decides “the same system is behind both these IPs, better use the one with a higher bandwidth adapter” since Tailscale adapter states it’s bandwidth as 100 Gbps.

Another reason why I’m quite sure of this being the case - is because Resource Monitor (network tab) lists tailscale IP or local IP for a very short time (few seconds), but lists hostname afterwards instead when I check TCP connections on SMB ports, regardless of local or tailscale IP being used. The hostname of the computer is listed (the one you can change from advanced system properties). Either that, or some other name system causes this.

I tried the same approach as you @backpackhasjetz - tried everything I could to disable name systems, I prefer static IP anyway, but didn’t help, even blocking netbios ports on system process through a firewall didn’t work when I tried it, there could be some sort of caching or a way to remember which IP had which system last.

My personal solution - I ended up using a 3rd party firewall, and manually set a filter which blocks all network traffic where these 3 conditions match:
• Application is: System (ntoskrnl.exe)
• Specific IP (100.x.x.x)
• Port 139 or Port 445

I could also specify IP range here to block SMB on all tailscale IPs through the system (IP range 100.0.0.0-100.255.255.255).

Windows still tried to connect through tailscale first, but failed very quickly (you won’t even notice any slowdowns or extra time to connect) and falls back to the next best route after no connections can be made (which is most probably your actual router’s local IP), resulting in normal speeds over SMB again.

This way I can individually block port 139/445 traffic to/from any specific tailscale connected system on my virtual subnet (or even all of them if I specify IP range as 100.0.0.0 - 100.255.255.255), and I can simply enable/disable that rule with one click. Since I know that 2 of my desktops will always be on the same physical network, I left this rule enabled permanently on those, meanwhile I manually toggle that rule if I take my laptop somewhere else and need SMB to work over tailscale.

I used a paid firewall software for this but you could also use something free or maybe even Windows firewall too, haven’t tried that yet but it should work. This firewall blocking rule being enabled or not could be automated with a simple script if windows firewall is used, so you could have an automatic block if SMB connection can be made through local network.

Hope this simple solution works for you too :slight_smile:

7

Yes. I used a 3rd party firewall to create a rule (or filter?) that blocks system (ntoskrnl.exe), port 139 or port 445 on specific IPs. The IPs could be say your SMB server, or entire tailscale IP range if you never want SMB to work over tailscale. Remember to do this for both IPv4 and IPv6. It should be possible to do with windows firewall too.

After the block, windows makes a quick attempt, fails and falls back to the next best IP which should be the actual local network. You won’t notice any delay at all, it’s very fast.

Now, my two desktops that are always on the same local network, always have smb over tailscale to each other blocked with the firewall rules, meanwhile I toggle the rule on or off with my laptop depending on if im at home or outside.

Hope this simple solution works for you as well… (just block it in firewall)

Some more explanation -

Overall I think this is a windows issue, has nothing to do with Tailscale. Tailscale is just another network adapter that is acts as a path between the same computer(s). My first thought was also to disable netbios but system kept making connections regardless of settings, services disabled, etc. Windows sees the same computer behind both IPs and selects the one with higher bandwidth (Tailscale states it’s link speed as 100 Gbps) even after mentioning the IP when mounting SMB shares.

If you open up resource monitor and go to network tab, very quickly, you’ll notice TCP connections will list IPs for a few seconds and change that to computer names instead for SMB connections, which made me see that at least by default, no “route through” tailscale exists that can connect from tailscale (100 subnet) to local (192 or 172 subnets).

8

Thanks for the responses, folks. The guidance on blocking via firewall makes sense; maybe in the future we’ll figure out a better way to handle the problem, though. Either on the MS side or Tailscale side.

9

Take note that this is Windows and it’s stupid behavior, not a problem with Tailscale. Tailscale is just a tunnel that any software can use on end systems.

From the last 10 years of experience I’ve had with Microsoft, their support and the way Windows is changing - I can confidently say that they will not listen to your problem or provide any functional solution for it whatsoever. At best you’ll get pointless generic copy paste solutions for this.

I use a lot of encrypted tunnels for different purposes and at the moment, I have 5 of them including Tailscale.

Windows shows this behavior through all of them, even Wireguard and OpenVPN which are just regular VPN tunnels.

If Windows knows that the same system is at the other end of two tunnels (probably through NETBIOS), it uses some logic to route traffic through what it thinks is a more efficient route.

Blocking it in firewall is the ONLY way to ensure that things will keep working properly.

I have a VPS which also is a wireguard and openvpn server, and all my end devices (including a 20TB Windows home storage server build) are always-on connected to that server through both.

Few days ago, I started noticing extremely laggy behavior while doing anything with Explorer on my main desktop. Turned out Windows was routing all traffic through the wireguard VPN tunnel which was limited to 100 Mbps and had a very high ping.

I had to specifically block SMB ports 139 and 445 again on the wireguard tunnel’s IP addresses as well. After failing a few times, Windows went back to the actual physical local network and started working at full speed and 1ms latency again.

After a restart, same thing repeated with OpenVPN tunnel. Same process to restrict system in firewall. Same behavior, different tunnels.

End conclusions -

• This is not a Tailscale-specific issue
• Firewall blocking seems to be a very easy, one-time and simple solution
• Windows doesn’t respect specified IPs when connecting to SMB (just like it doesn’t respect most other settings, specially any settings regarding updates)

10

Captain, totally get what you’re saying - I wasn’t saying this is a Tailscale-specific issue - it is Microsoft’s fault - but would be great if someday someone came up with a workaround; would be beneficial to not just Tailscale but any other VPNs that face a similar issue (as you posted). Microsoft also has to support an insane number of systems, and be backwards compatible for a lot of bloated legacy things - so I try and cut them a little slack. I would rather not add a firewall to my system (I don’t use them) - so I hold out hope for another solution in the future. Maybe someday someone will stumble on this thread and provide one, and then Tailscale could implement it.

11

You can explicitly set the metric of your LAN adapter to 1 and of the tailscale adapter to 500, making the LAN adapter the preferred path.

12

I had already tried that as well but Windows keept doing things with a mind of it’s own anyway, atleast on the 3 systems I have.

I already have firewall rules set to absolutely make windows work the way I want, so if anyone can test and confirm that this works, it’d be nice.

Also, to set metric using GUI, tailscale tunnel adapter is set to manual without any configuration, and to save changes, it requires IPv4 configuration.

It is possible to use Get-NetIPInterface and Set-NetIPInterface powershell commands to change metric without having to have a valid IP configuration.

Example -
Set-NetIPInterface -InterfaceIndex 25 -AddressFamily IPv4 -InterfaceMetric 500

The index can be seen from Get- command first.

13

Any fixes here, I am having the exact same issue. No matter what I do all Samba / CIFS traffic goes over tailscale and the CPU goes through the room.

Lan: 192.168.8.0/22
Source IP: 192.168.8.44
Server IP: 192.168.8.249

Should be no reason it would go over tailscale, it’s a local subnet.