This sounds really cool. basically. anyone connecting to my router, can now access my tailnet nodes. I enabled remote access LAN setting and followed the instructions here: Tailscale - GL.iNet Router Docs 4 but I can’t access my devices (trying via the 100. IP or the .ts.net address) any ideas if im missing some other setting?
bonus question: my tailscale dashboard says my tailscale is out of date on my slate 7. can i update it? or does it require a router update to get to latest tailscale?
Are you able to possibly produce a simple diagram showing your network topology with your local and remote routers and how you are planning to access your clients?
At home I have my server (“blah” in the screenshot above) with tailscale installed
then i have my glinet router with tailscale installed when im travelling (“gl-be3600” in the screenshot above)
when im travelling, when i connect my phone or laptop to my router… i expect to be able to ping my “blah” machine (either with the 100.x IP or the blah.my-animal.ts.net)
tailscale pretty much has all default settings. its a new TS account so i haven’t done anything crazy with acl rules or dns overriding or anything. saw the article about TS having support on glinet travel routers so that all clients connected to the router dont need to have TS installed, so i bought the router.
Your screenshot shows that you are advertising your subnet LAN routes on your Slate 7 when you would actually need to do that on your home server (and not needed on your travel router). Sorry if I misunderstood your topology.
I believe that what you are describing falls under the site-to-site (as oppsed to client-to-server) feature of Tailscale but someone with more experties than I am will hopefully shed some more light on the matter.
The workaround shown in the video is based on firmware v4.6.9 and should not directly applicable to current firmware versions.
From firmware v4.8.x onward, Tailscale operates within its own firewall zone, and forwarding to LAN and WAN is handled automatically according to the router’s configuration. Therefore, manually assigning firewall zones is generally unnecessary.
One possible difference is that masquerading is enabled on the WAN firewall zone but not on the Tailscale zone.
This may help in some scenarios like remote Tailnet devices don't support routing, but please be aware that it will perform source NAT, meaning remote Tailnet devices will only see the Slate 7’s Tailscale IP instead of the original LAN client IP (192.168.8.x).
hm. so im not sure what to do now. following the instructions in the video fixed my issue, but you said that it shouldn’t be needed.
I can DM you my mac address and you can investigate? I can set you up on my secondary WAN connection that’s isolated from my actual home network so I don’t have an issue with sharing if that will help you investigate.
We perform a detailed packet capture to pinpoint the cause of the connection issue.
Our analysis shows the following:
Direct LAN Routing: When the router sends requests using the local LAN address as the source, the target server does not respond to the ICMP (ping) requests.
Masquerading (SNAT): When we enable Masquerading in the tailscale0 firewall zone—which translates the LAN source address to the router's Tailscale IP—the target server responds successfully.
Based on this behavior, we confirmed our previous hypotheses:
The Tailscale tunnel on your GL.iNet router is working normally.
The issue lies on the target server's side. It is likely blocking traffic from "unknown" subnets (your LAN) via a firewall, or it lacks a return route to send data back to your specific LAN IP range.
We recommend:
Enable Masquerading: You can enable Masquerading for the tailscale0 zone in the firewall settings. This is the simplest fix, though please note that the target server will see all traffic as coming from the router itself, rather than individual devices on your LAN.
Adjust Target Server Configuration: If you need to identify individual devices, you should instead update the target server’s firewall to allow your LAN subnet or ensure its routing table correctly points back to your router for that subnet.
Hm. I have to admit some of this is going over my head. but i ended up running tailscale status on my server and see an error of
root@my-vps:~# tailscale status
100.89.69.45 my-vps coltonidle@ linux -
100.86.214.73 gl-be3600 coltonidle@ linux -
# Health check:
# - Some peers are advertising routes but --accept-routes is false
so from the looks of it. in tailscales documentation. most tailscale clients by default have accept-routes = true. but linux machines running tailscale have it set to false. so after:
i enabled tailscale on glinet,
then turn on LAN subnet routing on glinet
accepting subnet routing on tailscale admin console
I need to go to my server and accept-routes there via tailscale set --accept-routes
then everything seems to work.
sorry for the confusion, but i think we should be good to go now. hopefully this also provides an answer to other folks. one thing i still want to do is try how this actually works between other nodes on my tailnet as this is a small example, but i will come back and ask if i have other specific issues.
thank you @will.qiu for the detailed support! i will continue to buy glinet products (im up to 6!!!)
