Tailscale cannot reach subnets on other devices

What CLI options did you make? We can check for conflict and solve it for you.
Setting it as an exit node out of the box is in the planning.

Take a look at the link I posted, that document shows how to get it to work and it’s clear that your GUI implementation does not configure things correctly.

To clarify, I’m not talking about using the MT-3000 as an exit node. I just want it connected to my Tailnet and use the exit node I’ve selected for any clients connected to it. That does not work in 4.2.0.

And when I follow the instructions to fix the firewall policy via the OpenWRT interface the connectivity is spotty and the Tailscale process keeps restarting. The package provided is already very outdated so you should also update that or provide users the correct package.

Ultimately the way you’ve integrated Tailscale is very broken. The system does not update the firewall policy correctly like when you use plain Wireguard. Pretty frustrating considering your documentation claims this all works out of the box.

Sorry to be sloppy, will try to fix the problem asap.

You can get it to work in CLI if you disable mwan3. Pm me and I can walk you through it.

What’s the status of this? I’m brand new to GL iNet devices and just bought a Beryl AX. Enabled Tailscale, but none of the Beryl’s clients can see other Tailscale devices. The Beryl router itself can see other Tailscale devices – If I SSH into the Beryl, it can ping other devices and even get rsync to work.

I update the status. In order to solve the problems to reach the devices in other networks, I made the next changes

In luci

Interfaces, add new unmanaged interface. Name `tailscale`
Firewall settings: create new zone `tailscale`, interface `tailscale0`
In firewall settings, add new zone forwarding for tailscale → lan, tailscale → wan, lan → tailscale
In firewall settings, go to NAT Rules, add new NAT rule: Protocol: `any`, Outbound zone: `any`, Source/Destination: `any`, Action: `masquerade`. Go to “Advanced Settings” and set “Outbound device” to `tailscale0` interface

The next step is to set some settings in tailscale

tailscale set --accept-routes=true

Next, tailscale up and then I can reach my devices under the pfsense router.

root@GL-AXT1800:~# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=98.524 ms
64 bytes from seq=1 ttl=64 time=100.307 ms

but these settings disappear after a reboot. After a reboot I need to write from CLI again tailscale set --accept-routes=true and tailscale up

because if I don’t make these changes the following message appears:

# Health check:
#     - Some peers are advertising routes but --accept-routes is false

any ideas on how to make these changes permanent?

1 Like

Please refer to

1 Like

I’m having the same issue. I’ve read through and tried all the solutions in this thread, but none seem to be working for me.

I’m on a laptop, which is a client behind my gl-a1300 router, and I cannot ping anything behind my pfSense router. I can however ping devices behind pfSense if I ssh onto the gl-a1300 directly, although it has a lot of latency (this is probably due to a misconfiguration with the Firewall settings that I changed via Luci):

root@GL-A1300:~# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=63 time=104.761 ms
64 bytes from seq=1 ttl=63 time=85.401 ms
64 bytes from seq=2 ttl=63 time=145.711 ms
64 bytes from seq=19 ttl=63 time=**995.803 ms**
64 bytes from seq=20 ttl=63 time=160.140 ms
64 bytes from seq=21 ttl=63 time=266.942 ms

Another test that I did was to enable the tailscale client directly on my laptop. When I do that, I am able to access all devices behind pfSense with under 100ms latency.

I would prefer not having to go into Luci to update all the Firewall, NAT, etc. settings. Can you tell us when we can expect to have the official update ready? If not, could you perhaps write up the step-by-step instructions on how to work around these issues with Luci?

Thank you!

Add --accept-routes is the solution while don’t turn on “Custom Exit Nodes” on gl-a1300.
You can use command to change code and toggle tailscale.

sed -i 's/tailscale up/tailscale up --accept-routes/g' /usr/bin/gl_tailscale

Luci modification is not needed.


For anyone who is trying to have their GL.iNet device route traffic to their tailnet, I was able to get this working by doing the following:

  1. Enable Tailscale in Applications on 2.4.1 or later
  2. Add --accept-routes to the /usr/bin/gl_tailscale script using the sed that @hansome listed above: Tailscale cannot reach subnets on other devices - #26 by hansome
  3. Open Luci and create a new Firewall zone named tailscale with input, output, and forward accept, masquerading checked, and covered networks lan. Under advanced settings, you also need to add tailscale0 under covered devices.

@hansome @luochongjun is this something that can be automated as part of the --accept-routes changes that are coming in a future release?


I’m not sure if the luci is needed, but the --accept-routes change will be merged into a future release. Previously we found accept routes option makes the router inaccessible. We also need to find a way to handle that.

1 Like

That statement seems likely to misinform or confuse others reading this. A Tailscale exit node is no more a server than any other Tailscale node is. A Tailscale node that elects to use the services offered by an exit node is no more a client than any other Tailscale node is.

Tailscale creates and maintains a mesh network; a software-defined overlay network. Unless and until the operator of a Tailscale network (a tailnet) sets up network access control rules (ACLs) that prhibit such, any node on this network can connect to any other node on the network.

Any node can offer to other nodes the service of routing their packets to one or more subnets, typically so that those nodes can reach machines 1) that are not themselves Tailscale nodes, 2) to which those nodes cannot reach via normal networking, and 3) that the node offering this service (the subnet router) can, itself, reach.

An exit node is a node that offers routing to anywhere on the public Internet.

Before a node that wishes to offer subnet routing can do so, an operator of the tailnet generally must approve that routing in the Tailscale admin interface. This requirement of manual intervention can be eliminated by way of specifying auto approvers in the tailnet’s network access control rules.

Neither an exit node nor a subnet router can route packets that are not sent to it. A machine that is not running Tailscale–that is not a tailscale node–will not know anything about Tailscale and will not send any packets to a tailscale node unless something has indicated to it that said machine is the place where it should send packets destined for wherever it wants them to go.

1 Like

Any idea whether gl-inet is planning to add this option as the standard Tailscale startup arguments in a future firmware update? As far as I can tell, there is no downside, and this is needed to be able to connect to advertised routes…

(and I can confirm there’s no need to touch any firewall config or luck, --accept-routes is all that’s needed)

1 Like

Yes, it’s already been added to the code and is available in the snapshot version. v4.5 will be released when stable.

1 Like

I had this issue - devices in my home GL-MT1300 network couldn’t ping the Tailnet or subnet routes exposed by the Tailnet. However if I SSHed into the GL-MT1300, it could.

To fix:

  1. Log in to the advanced Luci GUI panel, go to NetworkFirewall (not StatusFirewall)
  2. Edit the first row
  3. On the second tab add covered devices: tailscale0
  4. Save and Save & Apply

How I got Tailscale on my Beryl MT-1300


This was 27 days ago. The current release is 4.2.3 on July, 6th. This issue has been outstanding for months when you said:

Sorry to be sloppy, will try to fix the problem asap.

And what do you mean by 4.5?

There’s also no snapshot version, at least not for the GL-MT3000. Please clarify @hansome with an ETA in the form of a date.

Version 4.5 is currently in alpha testing and has not yet been published. A beta version is expected by the end of August at the latest. The stable version depends on how long the testing takes.

So to confirm, at the moment we can’t turn on custom exit nodes if the accept routes line has been added?

You can turn on Custom Exit Nodes when the accept routes line has been added. But you must turn Allow Remote Access LAN & WAN and turn your LAN & WAN route in Tailscale Admin if you turn on it. Otherwise, you will not be able to access the Internet or even the router admin panel.

Will this be fixed in the upcoming update? I am looking to have the full tunnel/custom exit node working with being able to access the glinet LAN from tailscale. Why is access to WAN network required?