Tailscale cannot reach subnets on other devices

[jdub]

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

[ken830]

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.

[ss4pcRFradio]

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 10.0.1.1
PING 10.0.1.1 (10.0.1.1): 56 data bytes
64 bytes from 10.0.1.1: seq=0 ttl=64 time=98.524 ms
64 bytes from 10.0.1.1: 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?

[hansome]

Please refer to

GL-AXT1800 - Tailscale - Remote Subnet Routing Fails

We’ll fix this as soon as possible. For now, try adding the argument to line 73 of /usr/bin/gl_tailscale yourself, for example: [image]

[stickyIcky]

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 192.168.1.64
PING 192.168.1.64 (192.168.1.64): 56 data bytes
64 bytes from 192.168.1.64: seq=0 ttl=63 time=104.761 ms
64 bytes from 192.168.1.64: seq=1 ttl=63 time=85.401 ms
64 bytes from 192.168.1.64: seq=2 ttl=63 time=145.711 ms
64 bytes from 192.168.1.64: seq=19 ttl=63 time=**995.803 ms**
64 bytes from 192.168.1.64: seq=20 ttl=63 time=160.140 ms
64 bytes from 192.168.1.64: 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!

[hansome]

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.

[bswinnerton]

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?

[hansome]

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.

[pmocek]

@jsr

I’m not trying to use tailscale on my beryl as a “server” (an exit node) – simply as a “client” (a node that connects to an exit node) and routes ALL of my LAN traffic through that node.

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.

[elafargue]

@hansome

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

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)

[hansome]

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

[HarvsG]

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 Network → Firewall (not Status → Firewall)
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

[dmio]

v4.5

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.

[yuxin.zou]

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.

[jamesg227]

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

[yuxin.zou]

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.

[jamesg227]

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?

[yuxin.zou]

@jamesg227

Will this be fixed in the upcoming update?

In 4.5 firmware, opening the egress node will force the reporting of routes from the WAN & LAN’s subnet to tailscale.

@jamesg227

Why is access to WAN network required?

It actually report the WAN’s subnet to tailscale and open access on the firewall. If this is not done, Internet traffic returning to the exit node will not make it back to the router.

[madrian]

Guys, what I am doing wrong. I still can not access remote subnets (tailscale ping is working, it must be a firewall issue).

[madrian]

I got it working, but the problem was not with firewall rules.

There is a problem when (I think) the WAN connection is not reliable (for example in repeater mode you are connecting to a remote router) and tailscale is trying multiple time set up ip table rules - which then fails.

Mon Oct 16 22:38:28 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:28 dns: OScfg: {Nameservers:[100.100.100.100] }
Mon Oct 16 22:38:28 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:28 peerapi: serving on http://100:41552
Mon Oct 16 22:38:28 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:28 peerapi: failed to do peerAPI listen, harmless (netstack available) but error was: listen tcp6 [fd7a:115c:a1e0:ab12:4843:cd96:6251:9294]:0: bind: cannot assign requested address
Mon Oct 16 22:38:28 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:28 peerapi: serving on http://[fd7a:115c:a1e0:ab12:4843:cd96:6251:9294]:1
Mon Oct 16 22:38:28 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:28 Switching ipn state Starting -> Running (WantRunning=true, nm=true)
Mon Oct 16 22:38:29 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:29 monitor: RTM_DELROUTE: src=172.20.10.8/0, dst=, gw=172.20.10.1, outif=14, table=52
Mon Oct 16 22:38:29 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:29 monitor: RTM_DELROUTE: src=, dst=10.88.1.0/24, gw=, outif=19, table=52
Mon Oct 16 22:38:29 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:29 monitor: RTM_DELROUTE: src=, dst=172.20.10.0/28, gw=, outif=14, table=52
Mon Oct 16 22:38:29 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:29 monitor: RTM_DELROUTE: src=, dst=192.168.2.0/24, gw=, outif=19, table=52
Mon Oct 16 22:38:29 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:29 [RATELIMIT] format("monitor: %s: src=%v, dst=%v, gw=%v, outif=%v, table=%v")
Mon Oct 16 22:38:56 2023 daemon.err tailscaled[11496]: 2023/10/16 20:38:56 logtail: upload succeeded after 1 failures and 33s

If I do a simple tailscale down and tailscale up, I see that everything is working and ip table rules are created properly.