Improvement on Tailscale for SDK v4.8 and potential issue notifications

[bruce]

Dear users:

We've recently become aware that some users using firmware v4.8.0-v4.8.3 have reported needing to enable masquerading of the tailscale zone in the firewall in order for LAN clients able to reach other devices and subnets of their tailnet.

We apologize for any trouble this may have caused.

PHENOMENON:

Even if Tailscale has announced and accepted routes, and approved the subnet in Tailscale cloud console, if masquerading is disable in the tailscale zone of the router's firewall, communication of tailnet can only occur on the router itself, but the router's LAN clients will not be able to access other devices of tailnet (if other devices are also routers, they include the subnets of those routers).

REASON:

The firmware versions v4.8.0-v4.8.3, we modified the Tailscale firewall rules to improve the security of the router's Tailscale network and ensure more stable tailnet communication. The firewall zone for tailscale appears as follows:

config zone 'tailscale0'
        option name 'tailscale0'
        option input 'ACCEPT'
        option mtu_fix '1'
        list device 'tailscale0'

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

The key is to add mtu_fix to ensure large TCP packets are able to pass through correctly, and only LAN clients on the primary (main) network can access the tailnet; but guest clients cannot access to the tailnet or subnets.

Before upgrading to v4.8.0-v4.8.3 firmware, some users had manually added tailscale0 to the WAN zone.
After keep settings and upgrading to v4.8.0-v4.8.3 firmware, Tailscale now has its own dedicated zone, which conflicts with the rules manually added to the WAN zone. Some users have reported that LAN clients are blocked from accessing tailnet, but manually enable masquerade of the tailscale zone (added by firmware) for LAN clients to access normally.

TEMP WORKAROUND:

If you met this this issue in v4.8.0-v4.8.3 firmware,

1. SSH to the router and execute the following command to clear the tailscale0 interface in the wan zone:

idx="$(uci -q show firewall | sed -n "s/^firewall\.@zone\[\([0-9]\+\)\]\.name='\?wan'\?$/\1/p" | head -n1)"
[ -n "$idx" ] && uci -q del_list firewall.@zone[$idx].device='tailscale0'
uci commit firewall
/etc/init.d/firewall restart

2. If worried that the above is troublesome, you can reset firmware and reconfigure your router.

The expected behavior of the firmware v4.8.0-v4.8.3, does not need to add the tailscale0 interface to the wan zone, nor need to enable masquerading in the dedicated tailscale zone.
Once the Tailscale cloud console has the correct subnet approved, the tailnet communication in LAN clients will work.

SOLUTION:

A script will be added in the next firmware update. During the upgrade process, it will check if the user has manually added the tailscale0 interface to the wan zone.
If yes, it will be removed the tailscale0 of wan zone, and the tailscale0 will be assigned to the dedicated Tailscale zone.

This will prevent some conflicts and ensure that users upgrading to v4.8.5 (and later) can use Tailscale without issues, the LAN clients can access other subnets in the tailnet.

-end

We sincerely apologize for the inconvenience this issue may cause!

GL.iNet Technical Support Team

[sammutd88]

I still had to tick masquerade in that zone for lan devices to get access. It also resets itself every time Tailscale is disabled again. Currently not very user friendly. This is with an exit node specified on a Slate 7 in 4.8.1 and 4.8.3

[bruce]

1. Reset firmware
2. Execute the command in SSH. After execution, restart tailscale in GL GUI:

idx="$(uci -q show firewall | sed -n "s/^firewall\.@zone\[\([0-9]\+\)\]\.name='\?wan'\?$/\1/p" | head -n1)"
[ -n "$idx" ] && uci -q del_list firewall.@zone[$idx].device='tailscale0'
uci commit firewall
/etc/init.d/firewall restart

[sammutd88]

Did all that. Went through the hassle of resetting it all on 4.8.3 and as stated, no traffic flow unless ticking masquerade when using an exit node. Subnet routes are fine. Problem is, that firewall change isn’t persistent, when Tailscale is disabled then re-enabled you have to do it again which is annoying.

[bruce]

Refer to tailscale configuration guide from gl docs, do you have approved router's LAN and WAN subnets on tailsclae console?

[sammutd88]

Hi Bruce,

With all due respect, if I didn’t have the Tailscale config correct, it wouldn’t work at all. I’m saying that when using an exit node, I need to tick masquerade. The default rule only works without an exit node being used.

[bruce]

With our testings to know, if the LAN and WAN subnets are not approved in Tailscale, but masquerade is enabled on the router firewall for tailscale zone or tailscale0 interface (in wan zone), it can still work fine with the tailscale exit node. However, we do not recommend enable masquerade because it may bring some hidden dangers.

If possible, please share your router with us via GoodCloud, I would like to remote check your router about this issue.

Technical Support via GoodCloud - GL.iNet Router Docs 4

Please PM me your router MAC address and the Admin Panel password, please screenshot the Edit route settings of this router in tailscale console to confirm.

[sammutd88]

Sent via PM

[hansome]

Thanks to pcmike for the discussion on Tailscale firewall settings to make things more clear.

@pcmike

The lazy way (just enable masquerading on the stock tailscale0 zone)
→ One checkbox in LuCI → everything “works”
→ But it breaks the most useful feature of Tailscale on a travel router: being able to remotely access devices behind the router (printers, NAS, cameras, SSH, RDP, etc.) with real tailnet source IPs. All remote connections suddenly appear to come from the router itself. Logs become useless, ACLs break, authentication fails on many services.

To handle subnet conflicts in a Tailnet:

The quick workaround is to enable masquerading on the stock tailscale0 zone. It “fixes” connectivity, but at the cost of breaking an important Tailscale feature on a travel router: remote access to LAN devices with real Tailnet source IPs. Once MASQ is enabled, all incoming traffic looks like it comes from the router, logs become useless, ACLs break, and many services relying on client IP fail.

uci set firewall.tailscale0.masq=1
uci commit firewall
/etc/init.d/firewall reload

We intentionally choose Tailscale’s proper “allow subnet” behavior instead of sacrificing functionality for connectivity.
If connectivity fails, the root cause is usually a real subnet conflict—not something we want to hide with masquerading.