![]() ![]() My main machine right now is 192.168.0.135 and it pings the rest of my local lan in normal sub ms fashion. Still not sure why I'm seeing the same thing on the single local network when accept routes are enabled. But I always expected there to be some kind of impact as that network is also CGNATed. Since these have always been remote from each other I've never noticed issue 2) in my OP as the time it takes to reach either network is already limited by the 4G mobile network carrier its running on. This machine (8.201) already accepts routes from my other hosts, so it knows how to reach 192.168.0.0 and uses the pfsense box on that network as an exit route. The device I needed to access was the remote router (192.168.8.1) so I started announcing 192.168.8.0 as a route from 192.168.8.201. There are only two tailscale hosts on this network out of a total five hosts. The other network is 192.168.8.0 a few hundred miles away. The pfsense box on 192.168.0.2 does, and announces both a subnet route to 192.168. ![]() The networks involved are 192.168.0.0 (local) with perhaps 110 devices, some have tailscale running and some do not. In the instance where this all became apparent I had a need to access a remote device which can't run tailscale natively. I don't think so, but I'll explain the layout anyway. I can SSH from nnn.4 to nnn.183 for example, but going from any other machine to nnn.4 just fails. Could be that I've misconfigured something somewhere, but what? I have a few different local linux machines running and enabling/disabling the accept-routes doesn't seem to cause issues on anything but the deb11 host.Īlso, the machine in 1) can access any of the LAN machines just fine no matter what the route option is set to. Pinging 192.168.0.2 from 192.168.0.178 for example suddenly has an average time of 45ms rather than <1ms.īoth issues are easily sorted by only enabling the subnet route option when I need to access a non tailscale client on the other LAN of course, but surely there must be a way to fix these?Īs for issue 1) from what I can tell it only happens on a single host. As soon as I run tailscale set -accept-routes=false it starts replying to both again.Ģ) most of my clients (possibly all?) seems to go through TS for all LAN connections if accept-routes (tailscale subnets) is enabled. If I start pinging it from a different tailscale client it will reply to the TS IP, but not LAN. Using pfsense as a firewall/router on this LAN, with tailscale installed for remote access from the other LANs, and it's all working apart from these two issues Ī Debian 11 machine stops accepting incoming LAN connections after I run tailscale set -accept-routes on it. I've got a few tailscale clients and a few advertised routes, all working mostly fine. Ok, here's a weird one that I haven't experienced before.
0 Comments
Leave a Reply. |