Tailscale implementation in the 4.2.0 snapshot build … needs improvement.
Using the device bind link is not a great method for authorization. Using preauth keys would be far better.
The WAN/LAN access slider isn’t great. I would separate those out at a minimum, pushing just the LAN route or an allow-exit-node route (which would necessarily include the WAN).
Ideally (for a travel router) there should be a query of which other nodes provide an exit node status, and the ability to select between them.
Relying on Tailscale’s login server is also not ideal. This implementation isn’t much use to me (and likely others) without also supporting self-hosted control planes.
All of this functionality is pretty easily accomplished in CLI, so I’m surprised it isn’t implemented. For @alzhao or anyone who can answer - is anything like this planned? Particularly for a travel router, 2 and 3 seem critical.
In messing around more, some of this stuff (exit-nodes) works in CLI, but only if you go into Luci and assign the tailscale interface to firewall rules which pass traffic. The performance on the AR750s was… well, not good, tbh. Against my better judgment I may sacrifice an A1300 for the cause…
Update 2: things work… less well on the A1300. I can get TS to connect to my custom server, and I can set an exit node, but the A1300 doesn’t send traffic out, and LAN clients don’t send it over the exit-node, even with firewall rules enabled.
Ultimately exit nodes are a thing that just have to work on any Tailscale implementation for it to actually be useful at all as a travel router. This could solve a lot of the random “Why can I not get X VPN to work?” questions we see on here, so it would be super nice if we could get a good implementation.
While I would never hold out pfSense as the pinnacle of UX excellence, their decisions here have been pretty good:
The main thing that would need to be added to that would be a dialog to select which particular exit node you wanted to use, if you wanted to use one.
I feel like implementing this would be a game changer for a lot of people who need a quick, easy travel solution that just works. I’m happy to chat through and test solutions if that would be helpful.
The target of developing this page in the version is to help rookie users get started quickly. Therefore, it will not contain particularly complex functional settings. Especially it can be done in the Tailscale console.
Using preauth keys is more difficult to use and relatively unstable for new users.
Yes, we have discussed it. They should be separated.
I don’t see exit nodes as a complex setting. I see it as the essential setting for this product.
I disagree, especially when the bind link is blocked by a default pop-up blocker. (Which it is).
Will it be possible to do things in console and not have the GL.iNet implementation overwrite the settings? When trying to do things in console on the A1300, if I enabled Tailscale in the GUI after setting a custom server in console, it essentially went into a “tailscale down” / “tailscale up” loop because the GUI process monitor didn’t know how to deal with a custom login server. It’s one thing to not implement advanced settings. It’s entirely another to have the GUI conflict with / overwrite advanced settings.
After doing a manual console “tailscale up” and generating the binding link that the console could not (and having it stay up and not constantly reset itself), I get this result:
PING A1300-TAILSCALEIP (A1300-TAILSCALEIP): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
edit: just kidding. I went over into the Luci to add firewall rules so I could ping the Tailscale IP for the router, which works… except now we’re back in a tailscale up/down loop.
So basically Tailscale functionality is completely broken/unusable, at least on an A1300.
Edit 2: I do notice that the A1300 is running on 21.02, whereas the AR750S (where Tailscale kind of works, sort of, but very slowly) is running on 22.03. It also looks like there are different firewall table configurations on both of them (which you would kind of expect), but that the one on fw3 just doesn’t work, whereas the one on fw4 kind of does, maybe.
Cannot ping router’s Tailscale IP from another Tailscale node
When trying to manually add firewall rules via a Tailscale interface, something causes a tailscale down/tailscale up loop
GL.iNet firewall rules appear to not allow exit node functionality, necessitating 2)
I’ll have to check by resetting, but I suspect the implementation also doesn’t work with accept-routes, which is important.
It appears as though different models (with fw3 vs fw4) behave differently (though in fairness it’s hard to tell because things are so slow on the AR750S).
As I’ve mentioned elsewhere as someone who actually uses Tailscale (and uses it on travel routers), I’m happy to test functionality. I haven’t gone through and tried to actually test whether you can ping routes inside the router yet (I’ll do that today or tomorrow, maybe), but in general it does not feel like this was tested by someone who actually uses the product.
If there is a different router I should be trying this on I can try that (though I’m probably not going to mess up my AXT1800 since I’ve finally gotten it stable on a clean build).
Full reset on the A1300, and more testing. Updates:
Bind link generation still not working for me.
After doing a manual “tailscale up” in CLI and linking the A1300 to my account, I am able to ping other tailscale nodes and ping the A1300 from other tailscale nodes (good).
Accept routes is not implemented (I am not able to ping other subnets behind other routers that are advertising them).
A1300 is not advertising routes properly, even when enabled in GUI.
After a manual “tailscale up” in CLI, I am again unable to ping any other nodes from the A1300, or ping the A1300 from other nodes. Other nodes can ping each other.
Reboot. Again able to ping other nodes and ping the A1300.
Advertised routes are added to table 52, but still cannot ping (ping does work on other Tailscale node):
Routes appear to be added to table 52 properly, so I’m guessing it’s something to do with how the other GL.iNet firewall rules are interacting with the main route table.
Reboot. DNS is restored. Exit node functionality still doesn’t work. Accept routes functionality still doesn’t work. Can ping nodes / receive pings.
At the core, it looks like the main issues here are firewall rules, as well as some general problems in the scripts that are calling Tailscale up/down.
Ultimately, everything needs to work, but the real priorities are:
Need to be able to consistently ping the Tailscale IP (and not have this die for any reason while Tailscale is up.
Advertise routes and accept routes both need to work.
Using an exit node and advertising as an exit node (critical for travel router).
It would be nice to be able to use the new features in 1.34 (login to different accounts), but that’s a much lower priority.
Thanks. To be clear I did not test whether a LAN client could ping another Tailscale client - just whether a LAN client would pass traffic over the Tailscale interface when an exit-node was configured in Tailscale (and hence whether the client’s IP would appear to be coming from the exit-node).
root@GL-ROUTER:/etc/config# ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2): 56 data bytes
64 bytes from 100.64.0.2: seq=0 ttl=64 time=63.648 ms
64 bytes from 100.64.0.2: seq=1 ttl=64 time=30.675 ms
64 bytes from 100.64.0.2: seq=2 ttl=64 time=48.349 ms
^C
--- 100.64.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
… but clients connected to router cannot:
jdub@compy ~ % ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C
--- 100.64.0.2 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
If you disable tailscale in the gui, edit the init file to not check the enable flag, restart the service manually, go into Luci, add a tailscale interface and enter the appropriate firewall rules, then you can get Tailscale access on the lan:
jdub@compy ~ % ping 100.64.0.2
PING 100.64.0.2 (100.64.0.2): 56 data bytes
64 bytes from 100.64.0.2: icmp_seq=0 ttl=63 time=56.746 ms
^C
--- 100.64.0.2 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
What you can’t do, still, is use an exit node. It fails in various ways - initially by not passing traffic at all, then by bypassing the tailscale tunnel and passing directly to the internet.
Excited to see TailScale coming but I hope more work is done. A lot of these options like choose exit node, set WAN/LAN preference/access, and a host of other choices should be in the gl.inet GUI - not required to go to LuCI or to command terminal to access or configure. It’s pretty rough, i’d call it Alpha right now.
EDIT: And I understand the preference towards newbies and getting it easy to setup BUT there should then be an “Advanced” pane with the other options. Something simple like that, best of both worlds. TailScale is incredible but it has a plethora of settings, options, and switches which need to be configurable and easily accessible to be of utility. In a travel router, even more so.
I’ve been playing with Tailscale on a GL-AR300M (NAND) and a GL-MT2500.
Standard OpenWRT/Luci with the packages pulled down from the public repos has been the best result for me. I don’t see the GL.iNet web UI as a useful thing. Luci and ssh/command line are better options. Configuring Tailscale on command line and firewall in luci.
have been running the tailscale 1.36.0 versions on
shadow: OpenWrt 22.03.3, r20028-43d71ad93e
brume2: OpenWrt 21.02-SNAPSHOT, r15812+873-46b6ee7ffc. (beta2)
