[solved] IP forwarding for Tailscale

Installing and Using OpenWrt
1

Hi,

I want to use my OpenWRT 24.10 box (a Meraki MR18) as a Tailscale subnet router.
But here (https://tailscale.com/kb/1019/subnets#enable-ip-forwarding) I read that “IP forwarding is required to use a Linux device as a subnet router.”

But since I’m not very confortable yet with OpenWRT and Linux, and since the instructions are not straightfoward (several of “if… then…”) I’d like to know the sure route instead of messing everything up.

So:

2

There is a tailscale package in the official OpenWrt package repository. Maybe you want to have a look at the wiki page https://openwrt.org/docs/guide-user/services/vpn/tailscale/start

That way you don't have to set everything up from scratch

1 Like
3

Forwarding is allowed already on the router no need to set that.

You can view with e.g. sysctl net.ipv4.ip_forward

I like Netbird better than Tailscale but that is just my personal preference my notes:
OpenWRT Netbird setup
But of course using your own WireGuard server/client is even better as you are not dependent on a commercial third party but that is not always possible/feasible.

1 Like
4

Thanks @georg . I sure did that, at the time.

Thanks @egc for the info regarding Tailscale alternatives. Will definitely investigate this in the middle term. Tailscale is so useful and makes this reachable for my limited skillset, but the more my infrastructure is free from 3rd parties, the better.

root@Meraki_MR18:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

So I guess that yes, IP forwarding is on.

Below is my original problem, if any other poor soul has the same problem.

TL;DR: couldn’t ping my LAN devices from a remote Tailscale member.
Seems like SNAT was off (while it should be on by default).

Entering

tailscale set --snat-subnet-routes=true

fixed the thing for me. :tada:

_________________________________

So here was my problem:

My subnet router (meraki-mr18, running OpenWRT), runs Tailscale and advertises the LAN 192.168.100.0/24.

My PC (portable17) runs Tailscale with subnet routing from another LAN. When it tries to connect, via Tailscale, to machines inside 192.168.100.0/24 (for example, 192.168.100.250, which is running piCorePlayer), Tailscale subnet routing works partially: ping and HTTP requests from portable17 to the Tailscale IPs are successful, but when trying to reach 192.168.100.0/24 IPs directly, only the meraki-mr18 responds. Other LAN devices do not respond.

Devices on 192.168.100.0/24 have their gateway set to the ISP box (192.168.100.254), not to the subnet router meraki-mr18. When my PC sends requests to PiCorePlayer (192.168.100.250) via Tailscale subnet routing, the initial packets arrive, but the replies from 192.168.100.250 use the default gateway (ISP box), and never reach the remote device:

tc@piCorePlayer:~$ traceroute 100.122.232.146
traceroute to 100.122.232.146 (100.122.232.146), 30 hops max, 46 byte packets
1 livebox.home (192.168.100.254) 2.756 ms 2.895 ms 2.994 ms

So I have 2 questions:

  1. Shouldn’t the Tailscale client running on PiCorePlayer (192.168.100.250) automatically route responses correctly to requests from other Tailnet devices, regardless of their LAN?

  2. How can a remote device on the same Tailnet connect to the ISP box (192.168.100.254), if it isn’t possible to add custom routes on that device? I thought subnet routing was the magical solution for this kind of need (machines on the LAN not able to run Tailscale).

5

You would need to install a route in the Meraki main router so that devices on the LAN are able to return packets to remote VPN IPs via the PC that is running tailscale. Right now the LAN devices send them to their default route (the Meraki) which then does not know what to do.

This is true for routing a whole LAN over any VPN not just Tailscale, in the case where the VPN tunnel terminates in a LAN device instead of the LAN's main router.

SNAT works around this problem by making the remote packets appear to come from the LAN PC rather than a foreign address. But this means that LAN devices have no way to originate a connection to a remote machine. In some situations such as road warriors that is not something that would be happening anyway.