I have Tailscale on a couple of laptops which are used both at home and on the road. I also have a relay node setup inside my LAN which advertises the various ranges I use at home. When I’m home the default route for my LAN ranges goes over the Tailscale interface (routes are accepted on the laptop). This creates problems because my traffic is taking unnecessary hops to access devices which are in the same broadcast domain as my laptop’s wireless interface.
Is there anything which can be done about this, short of stopping and starting Tailscale each time with the flag set/not set?
Currently, Tailscale starts reaching to destination using derp for few seconds unless it found a direct connection if any or connection with minimum latency. But it does netmap the connection as direct when they both sitting on the same LAN. Can you please print ‘tailscale status’ while you find both are sitting in the same LAN but creating a connection via DERP which adds the hops? send this to support@tailscale.com.
ok this makes some sense. I’ve included some additional info below:
- my local net is 10.101.0.0/22
- 10.101.0.50 is not a tailscale node
- the relay node is on a different subnet because it’s a VM
- phoenix is the hostname of one of the affected laptops where these commands were run
➜ sudo tailscale status
100.80.132.82 phoenix glitchcrab@ linux -
100.117.28.12 tailscale-relay glitchcrab@ linux active; direct 172.25.0.110:41641, tx 9540 rx 7452
➜ ip r s
default via 10.101.0.1 dev wlp59s0 proto dhcp metric 600
10.101.0.0/22 dev wlp59s0 proto kernel scope link src 10.101.0.211 metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.20.0.0/16 dev br-aa079915e170 proto kernel scope link src 172.20.0.1
172.21.0.0/16 dev br-63f54406356f proto kernel scope link src 172.21.0.1 linkdown
➜ ip r g 10.101.0.50
10.101.0.50 dev tailscale0 table 52 src 100.80.132.82 uid 2000
cache
Edit: this is also causing further weirdness to happen. I have monitoring software running inside my LAN which is using ICMP for liveness checks against my laptop. When Tailscale is running I see the following via tcpdump:
15:06:19.534902 wlp59s0 In IP 10.101.0.45 > 10.101.0.211: ICMP echo request, id 53065, seq 4, length 64
15:06:19.534977 tailscale0 Out IP 10.101.0.211 > 10.101.0.45: ICMP echo reply, id 53065, seq 4, length 64
100.80.132.82 phoenix glitchcrab@ linux -
this shows laptop is not connected to Tailscale currently. Can you please connect the laptop to Tailscale and then collect the information?
Also, please do not share personal IP information here on the forum, please email directly to support@tailscale.com
The laptop is definitely connected to Tailscale; the Tailscale interface is up, its IP matches the IP in the TS web interface, and I can access other hosts on the same tailnet via magic DNS.
This is what I do currently (actually since I travel infrequently right now I leave it set to not accept routes most of the time). I think there is a GitHub issue open about this as well, so you can add your name there as an interested party.
The tricky bit will be determining the trigger for not accepting the routes; it’s not just as simple as checking to see if those routes are already in the routing table, because if you have multiple subnets in your home network your laptop will have a 0.0.0.0/0 default route to reach all of them, but the advertised route(s) from Tailscale will be the individual subnets.
1 Like
Any suggestions here @darshinimashar?
A workaround for making sure the LAN traffic does not use a subnet router unnecessarily, one can make the advertised subnet be a less specific route. For example if your LAN is 10.0.0.0/24, advertise the subnet route as 10.0.0.0/23. When you are on the local LAN and it installs a route for 10.0.0.0/24, the direct LAN connection will win. When you leave the local LAN and the /24 entry goes away, the /23 entry for the advertised subnet will win.
1 Like
I came here for the same issue.
In my case:
$ ip r s
default via 10.10.16.1 dev enp0s25 proto dhcp metric 100
default via 10.10.16.1 dev wlp3s0 proto dhcp metric 600
10.10.16.0/23 dev enp0s25 proto kernel scope link src 10.10.16.13 metric 100
10.10.16.0/23 dev wlp3s0 proto kernel scope link src 10.10.17.225 metric 600
$ traceroute -n 10.10.16.9
traceroute to 10.10.16.9 (10.10.16.9), 30 hops max, 60 byte packets
1 100.64.204.44 1.123 ms 1.119 ms 1.117 ms
2 10.10.16.9 1.111 ms 1.106 ms 1.070 ms
10.10.16.0/23 is my LAN, and I have a node (100.64.204.44) that advertises 10.10.16.0/23. While on my LAN, all my LAN traffic gets routed there.
I tried @darshinimashar 's trick but it didn’t work for me. Changed the node to relay 10.10.16.0/22, and I’m still getting routed through the node.
$ sudo ip route flush cache
$ ip r g 10.10.16.9
10.10.16.9 dev tailscale0 table 52 src 100.100.144.21 uid 1000
cache
$ traceroute -n 10.10.16.9
traceroute to 10.10.16.9 (10.10.16.9), 30 hops max, 60 byte packets
1 100.64.204.44 0.879 ms 0.810 ms 0.774 ms
2 10.10.16.9 0.763 ms 0.753 ms 0.741 ms
Here’s a link to the github issue: https://github.com/tailscale/tailscale/issues/1227