I am testing Tailscale with a RUTX11, running RUTX_R_00.07.07.1. My Tailscale client (Windows PC) has the IP of 100.110.188.20.
The RUTX LAN has address 10.3.100.1/24, and the WAN is 10.3.255.2/24, with the gateway at 10.3.255.1. Tailscale is advertising route 10.3.0.0/16. It is not set as an exit node. I can access everything on the LAN of the RUTX from my client.
I would like to access the interface of the ISP broadband router at 10.3.255.1 - I could do this previously when I was using ZeroTier. I think the required SNAT and firewall rules are in place to allow this to happen, but I cannot get a ping response.
Running tcpdump on eth1 (WAN) and filtering for ICMP shows the below:
18:33:43.981526 IP 10.3.255.2 > 10.3.255.1: ICMP echo request, id 1, seq 1, length 40
18:33:43.982286 IP 10.3.255.1 > 10.3.255.2: ICMP echo reply, id 1, seq 1, length 40
18:33:43.982542 IP 10.3.255.1 > 100.110.188.20: ICMP echo reply, id 1, seq 1, length 40
My understanding of this is that the RUTX is correctly applying the SNAT (masquerade) rule to my ping, the broadband router at 10.3.255.1 is responding, but then when the RUTX is applying the NAT to get the response back to me at 100.110.188.20 it’s coming back out eth1 for some reason - is this using the wrong routing table?
Any hints that would help get this working would be appreciated, thanks.
Looking at this more in combination with [OpenWrt Wiki] Routing basics I think it’s possibly a route table issue. If I ask the router what the route to 10.1.104.50 (a destination in my Tailscale network) is from an address in the LAN subnet on the router then it knows, but if I ask it the same question using the WAN IP it comes back as unreachable (interestingly it’s not just failing over to using the default route).
root@Teltonika-RUTX11:~# ip route get 10.1.104.50 from 10.3.255.1
RTNETLINK answers: Network unreachable
root@Teltonika-RUTX11:~# ip route get 10.1.104.50 from 10.3.100.1
10.1.104.50 from 10.3.100.1 dev tailscale0 table 52 uid 0
cache
root@Teltonika-RUTX11:~# ip route get 8.8.8.8 from 10.3.100.1
8.8.8.8 from 10.3.100.1 via 10.3.255.1 dev eth1 uid 0
cache
Entering the below in the CLI
ip route add 10.1.0.0/16 dev tailscale0
Adds a route to table 1 and clients in the subnet can now access 10.3.255.1 as (at a guess) the NAT process now knows where to send the packets back to.
root@Teltonika-RUTX11:~# ip route get 10.1.104.50 from 10.3.100.1
10.1.104.50 from 10.3.100.1 dev tailscale0 table 52 uid 0
cache
Is this a bug with the way Tailscale routes are put into the system? I appreciate it’s an edge case and have a workaround for now.