Flint 3 - 4.8.4 - Tailscale Breaks LAN Internet Access Due to GL VPN Kill Switch Blackhole Rules

bryan · April 22, 2026, 8:05pm

Device: GL-BE9300 (Flint 3) - tested
Firmware: GL.iNet 4.8.4

When Tailscale is enabled on the GL-BE9300, all LAN client devices (PCs, laptops, phones, etc.) lose internet access entirely, even though the router itself retains internet connectivity and the Tailscale panel shows a green "Connected" status. The issue persists regardless of whether AdGuard Home is enabled or disabled, and occurs with basic Tailscale enabled — no exit node or custom configuration required.

The issue is caused by GL's VPN routing policy engine (/usr/bin/rtp2.sh) unconditionally calling set_global_killswitch_rule() from /lib/functions/vpn_func/global_leak_drop.sh whenever route_policy.global.enabled='1', regardless of whether any VPN client tunnel is actually active or whether Kill Switch is enabled on any tunnel. On router reboot, the blackhole rule persists.

The function set_vpn_route_leak_block_rule() inside /lib/functions/vpn_func/global_leak_drop.sh loops over a hardcoded interface list (lan guest wgserver ovpnserver) and writes the following ip rule entries into the routing table:

$ ip rule list

9910: not from all fwmark 0/0xf000 blackhole
9920: from all iif br-lan blackhole
9920: from all iif br-guest blackhole
9920: from all iif wgserver blackhole

Tailscale is not accounted for in rtp2.sh — the script only checks for wgclient* and ovpnclient* interfaces as valid VPN interfaces.

Additionally, when a tunnel's Kill Switch is toggled off while the overall tunnel rule is already in the state Off, the cleanup function clean_global_killswitch_rule() is never called. The blackhole rules are written when Kill Switch is enabled (even with the tunnel rule state Off) but the rules are not removed when it is disabled in this state, leaving stale blackhole rules active in the routing table indefinitely.

bryan · April 22, 2026, 9:10pm

I know the moderator switched this to Flint 3, but it likely affects all Tailwind (Beta) – tested also on Flint 1.

will.qiu · April 23, 2026, 9:23am

Hi

We tested locally using BE9300 v4.8.4, and it appears that enabling Tailscale does not affect LAN devices’ access to the internet.

Regarding the IP rule you mentioned, there are already other rules that match earlier and allow traffic to exit normally via the main routing table.
(When VPN is not enabled, LAN traffic matches the 6000: from all fwmark 0x8000/0xf000 lookup main .)

root@GL-BE9300:~# ip rule show
0:      from all lookup local
0:      from all to 192.168.8.0/24 lookup main
0:      from all to 10.100.32.0/20 lookup main
1:      from all iif lo lookup 16800
50:     from all to 100.100.100.100 lookup 52
800:    from all lookup 9910 suppress_prefixlength 0
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
9910:   not from all fwmark 0/0xf000 blackhole
9920:   from all iif br-lan blackhole
32766:  from all lookup main
32767:  from all lookup default

bryan · April 23, 2026, 3:53pm

Limited to one upload per post restriction so have to reply again, but here’s my Tailscale and VPN Dashboard.

crik91 · April 23, 2026, 4:54pm

Same here:

root@GL-MT6000:~# ip rule show | grep 9920
9920:	from all iif br-lan blackhole
9920:	from all iif br-guest blackhole
9920:	from all iif wgserver blackhole
root@GL-MT6000:~#

bryan · April 23, 2026, 5:48pm

I have a hunch that perhaps Will toggled the “Allow Remote Access LAN” (based on his screenshot stating “The device allows Tailscale clients to access resources on the LAN or WAN”…) which is likely causing it to route to 6000 allowing internet access to LAN devices. But toggling “Allow Remote Access LAN” shouldn’t be a prerequisite to getting this working properly since keeping “Allow Remote Access LAN” off is a valid use case. We may not need to access home LAN devices from outside Tailscale and may just want Tailscale local devices to communicate with each other.

will.qiu · April 24, 2026, 3:44am

As mentioned earlier, there are other rules in the IP rules that match LAN-to-WAN traffic.
The blackhole rule is only used in rare cases to prevent IP/DNS leaks.

If you want LAN devices to remotely access resources in the Tailnet, you need to enable “Allow Remote Access LAN” and approve the routes in the Tailscale Admin Console.
Otherwise, remote Tailscale nodes won’t have a return route to send responses back.

Also, this option does not affect internet access for LAN devices.

If you want LAN devices to access Tailnet resources without enabling “Allow Remote Access LAN”, you can enable Masquerading for the tailscale0 zone in LuCI → Network → Firewall, and allow forwarding from the tailscale0 zone to the LAN zone.
(We’ve added a one-click option for this in v4.9.)

Without enabling “Allow Remote Access LAN”, it only applies to scenarios where remote Tailscale nodes access the router itself.

bryan · April 24, 2026, 6:03am

If you want LAN devices to remotely access resources in the Tailnet, you need to enable “Allow Remote Access LAN” and approve the routes in the Tailscale Admin Console.
Otherwise, remote Tailscale nodes won’t have a return route to send responses back.

Also, this option does not affect internet access for LAN devices.

Noted, but for this issue, I’m not trying to access my LAN devices remotely nor trying to have my LAN devices access Tailnet resources. I suppose we can leave this part out from the conversation since I don’t think its relevant to the issue I’m running into.

I may have had my initial cause with the 9910/9920 blackhole rules incorrectly diagnosed. So I will start describing my issue from scratch to see if you can assist on what’s actually going on here as I am clearly confused now.

I’m running into a scenario whenever my Tailscale is turned ON, my local LAN devices (connected to the router) internet stop working. The moment I turn OFF Tailscale, my local LAN devices can connect to the internet again.

I’ve tried playing around with the sequence and listed my rule list.

# Initial State: Tailscale is turned Off.
# Internet on my local LAN devices works.

root@GL-BE9300:~# ip rule list
0:      from all lookup local
1:      from all iif lo lookup 16800
800:    from all lookup 9910 suppress_prefixlength 0
1099:   from all fwmark 0x80000/0xc0000 lookup main
1101:   not from all fwmark 0x8000/0xc000 lookup 8000
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
9910:   not from all fwmark 0/0xf000 blackhole
9920:   from all iif br-guest blackhole
9920:   from all iif br-lan blackhole
9920:   from all iif wgserver blackhole
32766:  from all lookup main
32767:  from all lookup default

# After deleting rule 9910/9920, Tailscale is still left OFF. 
# My local LAN devices are still able to connect to the internet.
# Then I turn Tailscale back ON.
# My local LAN devices are still able to connect to the internet.
# My ip rule list looks like below with 9910/9920 still removed.

root@GL-BE9300:~# ip rule list
0:      from all lookup local
0:      from all to 192.168.8.0/24 lookup main
0:      from all to 136.x.y.z/20 lookup main
1:      from all iif lo lookup 16800
50:     from all to 100.100.100.100 lookup 52
800:    from all lookup 9910 suppress_prefixlength 0
1099:   from all fwmark 0x80000/0xc0000 lookup main
1101:   not from all fwmark 0x8000/0xc000 lookup 8000
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
32766:  from all lookup main
32767:  from all lookup default

# I reboot the Router, and the 9910/9920 returns with Tailscale still ON.
# The 9910/9220 rules are restored after the reboot.
# My local LAN devices are unable to connect to the internet upon the reboot.

root@GL-BE9300:~# ip rule list
0:      from all lookup local
0:      from all to 192.168.8.0/24 lookup main
0:      from all to 136.x.y.z/20 lookup main
1:      from all iif lo lookup 16800
50:     from all to 100.100.100.100 lookup 52
800:    from all lookup 9910 suppress_prefixlength 0
1099:   from all fwmark 0x80000/0xc0000 lookup main
1101:   not from all fwmark 0x8000/0xc000 lookup 8000
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
9910:   not from all fwmark 0/0xf000 blackhole
9920:   from all iif br-guest blackhole
9920:   from all iif br-lan blackhole
9920:   from all iif wgserver blackhole
32766:  from all lookup main
32767:  from all lookup default

# I then turn Tailscale OFF.
# My local LAN devices are able to connect to the internet again.

root@GL-BE9300:~# ip rule list
0:      from all lookup local
1:      from all iif lo lookup 16800
800:    from all lookup 9910 suppress_prefixlength 0
1099:   from all fwmark 0x80000/0xc0000 lookup main
1101:   not from all fwmark 0x8000/0xc000 lookup 8000
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
9910:   not from all fwmark 0/0xf000 blackhole
9920:   from all iif br-guest blackhole
9920:   from all iif br-lan blackhole
9920:   from all iif wgserver blackhole
32766:  from all lookup main
32767:  from all lookup default

# I then turn Tailscale back ON.
# My local LAN devices cannot connect to the internet.

root@GL-BE9300:~# ip rule list
0:      from all lookup local
0:      from all to 192.168.8.0/24 lookup main
0:      from all to 136.x.y.z/20 lookup main
1:      from all iif lo lookup 16800
50:     from all to 100.100.100.100 lookup 52
800:    from all lookup 9910 suppress_prefixlength 0
1099:   from all fwmark 0x80000/0xc0000 lookup main
1101:   not from all fwmark 0x8000/0xc000 lookup 8000
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
9910:   not from all fwmark 0/0xf000 blackhole
9920:   from all iif br-guest blackhole
9920:   from all iif br-lan blackhole
9920:   from all iif wgserver blackhole
32766:  from all lookup main
32767:  from all lookup default

# I then turn Tailscale back OFF.
# My local LAN devices are able to connect to the internet again.

root@GL-BE9300:~# ip rule list
0:      from all lookup local
1:      from all iif lo lookup 16800
800:    from all lookup 9910 suppress_prefixlength 0
1099:   from all fwmark 0x80000/0xc0000 lookup main
1101:   not from all fwmark 0x8000/0xc000 lookup 8000
6000:   from all fwmark 0x8000/0xf000 lookup main
9000:   not from all fwmark 0/0xf000 lookup main
9910:   not from all fwmark 0/0xf000 blackhole
9920:   from all iif br-guest blackhole
9920:   from all iif br-lan blackhole
9920:   from all iif wgserver blackhole
32766:  from all lookup main
32767:  from all lookup default

Any idea?

will.qiu · April 24, 2026, 7:09am

There may be other configurations affecting LAN devices’ access to the internet.

Could you please follow the guide and share your device with us via GoodCloud so we can check it remotely?

Kindly note to send us the MAC address and the router password via private message so we can access it

crik91 · April 25, 2026, 2:01pm

Update: re-flashed the 4.8.4-snapshot, the strange unstable download speed are disappeared, and also the blackhole(in the 4.8.4-stable is permanent):

root@GL-MT6000:~# ip rule show | grep 9920
root@GL-MT6000:~#

rthco · April 28, 2026, 1:33am

Just FYI to anyone reading for clarity.. someone opened a github issue for the gl-tailscale-fix plugin with a link to this forum thread ( BE9300 breaks internet for LAN devices · Issue #10 · RemoteToHome-io/gl-tailscale-fix · GitHub )

The issue being discussed above is not related to the gl-tailscale-fix plugin. The 9920 blackhole firewall rules being referenced in this thread are from GL's latest addition in some new firmware versions to implement their own native TS killswitch functionality. (Our plugin does not use 9920 table rules.)

Our plugin makes the killswitch function a manual user-enabled on/off GUI toggle. The recent GL KS function is currently not user controlled (potentially related to the cause of the above issue).

will.qiu · May 6, 2026, 2:35am

Hi,

Thanks to @bryan for providing remote access.

We’ve identified the root cause of the issue—an update to Tailscale introduced a problem with firewall marks.

github.com/tailscale/tailscale

`nftables` firewall backend using fwmark `0x00000400/0x0000ff00` instead of `0x00040000/0x00ff0000`

opened 08:03AM - 19 Apr 24 UTC

Seas0

connectivity OS-linux P1 Nuisance bug pod/network-features

### What is the issue? `nftables` firewall backend on Linux seems not using f…wmark `0x00040000/0x00ff0000` like its correspondent in `iptables`, instead it uses fwmark `0x00000400/0x0000ff00` for firewall rules. ### Steps to reproduce On systems that using `nftables` backend ```bash sudo nft -s list ruleset ip ``` ```nft table ip filter { chain FORWARD { type filter hook forward priority filter; policy accept; counter jump ts-forward } chain INPUT { type filter hook input priority filter; policy accept; counter jump ts-input } chain ts-forward { iifname "tailscale0*" counter meta mark set meta mark & 0xffff04ff | 0x00000400 meta mark & 0x0000ff00 == 0x00000400 counter accept oifname "tailscale0*" ip saddr 100.64.0.0/10 counter drop oifname "tailscale0*" counter accept } chain ts-input { iifname "lo*" ip saddr <local_ts_ip> counter accept iifname != "tailscale0*" ip saddr 100.115.92.0/23 counter return iifname != "tailscale0*" ip saddr 100.64.0.0/10 counter drop iifname "tailscale0*" counter accept udp dport <ts_lis_port> counter accept } } table ip nat { chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; counter jump ts-postrouting } chain ts-postrouting { meta mark & 0x0000ff00 == 0x00000400 counter masquerade } } ``` On systems with `iptables` ```bash sudo iptables -nvL -t filter ``` ``` Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ts-input all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ts-forward all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain ts-forward (1 references) pkts bytes target prot opt in out source destination 0 0 MARK all -- tailscale0 * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x40000/0xff0000 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x40000/0xff0000 0 0 DROP all -- * tailscale0 100.64.0.0/10 0.0.0.0/0 0 0 ACCEPT all -- * tailscale0 0.0.0.0/0 0.0.0.0/0 Chain ts-input (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * <ts_local_ip> 0.0.0.0/0 0 0 RETURN all -- !tailscale0 * 100.115.92.0/23 0.0.0.0/0 0 0 DROP all -- !tailscale0 * 100.64.0.0/10 0.0.0.0/0 0 0 ACCEPT all -- tailscale0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:<ts_lis_port> ``` ### Are there any recent changes that introduced the issue? Seems a3c7b21 forgot to take endianness into consideration, as shown [here](https://github.com/tailscale/tailscale/commit/a3c7b21cd18866cd8ceeee9b102c9e4171fcd719#diff-24d56f3ddeab24b98059a573652492d4aea06a7a23299f6a622bb4b4be3368ddR69) ### OS Linux ### OS version Arch Linux ### Tailscale version 1.64.0 ### Other software firewalld ### Bug report _No response_

If users manually updated to affected version, the firewall marks may not be applied correctly, causing the traffic to match the IP rules blackhole rule.

For affected users, we recommend rolling back the update for now.
(If you updated via @admon’s script, you can run sh update-tailscale.sh --restore.)

For more details, please refer to the fix submitted by our R&D team to @admon’s repository:

github.com/admonstrator/glinet-tailscale-updater

fix: patch Tailscale for #11803 nft fwmark native-endian (until #19601)

main ← handongming:fix/nft-fwmark-endian-11803

opened 02:17AM - 06 May 26 UTC

handongming

+113 -0

## Problem On **little-endian** hosts (arm64, amd64), Tailscale’s **nftables*…* netfilter backend built fwmark **mask/value** bytes for `meta mark` / `Bitwise` expressions using the **wrong byte order**. Rules that should match **`0x40000 / 0xff0000`** (third byte) instead behaved like **`0x00000400 / 0x0000ff00`** — i.e. the mask effectively hits the **wrong 8-bit lane**. That collides with **policy-routing marks in the `0x8000 / 0xf000` nibble** (e.g. OpenWrt **fw4 / `vpn_table`** style marks on GL.iNet firmware). **Tailscale’s `0x80000/0xff0000` and GL’s `0x8000/0xf000` are meant to be non-overlapping in `ip rule`**, but the nft bug shifts the bitfield so they **fight the same mark bits**. Typical symptom: **first packet of a flow passes, later packets break** (e.g. LAN ping gets one reply then silence) once **connmark save/restore** paths run on **ESTABLISHED** traffic — consistent with [tailscale#11803](https://github.com/tailscale/tailscale/issues/11803). Workaround users may try: `tailscale set --netfilter-mode=off` (trade off Tailscale’s netfilter integration). Proper fix: **`encoding/binary.NativeEndian`** in `util/linuxfw` — same direction as [tailscale#19601](https://github.com/tailscale/tailscale/pull/19601). ## This PR - Adds `patches/0001-fix-nftables-fwmark-endianness.patch` (from the #11803 / #19601 fix). - In `build-tailscale.yaml`, after checking out `tailscale/tailscale`, checks out this repo under `repo/` and runs `patch -p1 < repo/patches/0001-...` **before** `go mod download` / cross-compile. **No change** to feature tags, UPX publishing, or release flow — only the Tailscale sources are patched before build. ## When to drop this Remove the patch + checkout/apply steps after **#19601** is merged **and** the Tailscale release you build already contains the fix.

bryan · May 6, 2026, 3:51am

Cheers GL.iNet team, your full support and quick turnaround is commendable in itself.

admon · May 6, 2026, 4:31am

Admon's version of Tailscale is fixed now; no need to --restore. Just run the script once more to get the fixed version

bryan · May 6, 2026, 4:32pm

cc @will.qiu

I’m not sure if there’s another issue lingering but with admon’s latest push, it worked for a while but after my scheduled reboot, it stopped working. The interesting thing now that I noticed is that if I have Tailscale active (with Network Acceleration enabled), my LAN devices’ internet works. But with Network Acceleration disabled and Tailscale active, my LAN devices internet stops working again.

With Tailscale disabled, my LAN devices’ internet works as normal.

Thoughts here?

will.qiu · May 9, 2026, 11:06am

Thank you for the feedback.

It does indeed seem that there are still some issues. We have asked the development team to review and fix them again.

will.qiu · May 11, 2026, 1:42am

The development team has submitted another PR to Admon’s repository to fully fix this issue, and we have verified that it is now working properly.

Please try updating to the latest version of Tailscale again using Admon’s script and see whether the issue is resolved.

bryan · May 11, 2026, 3:57am

Looks like this update worked on both reboot with and without Network Acceleration. Thanks again!