Connecting GLi routers to a Headscale network

Routers
1

Hi folks :blush:

Just wanted to start a thread for people to gather observations about their attempts to use GL.iNet routers with Headscale, an open-source alternative Tailscale coordination server.

My current status: I set up a Headscale instance on a VPS I control, and added both vanilla OpenWRT and GL.iNet routers (GL-AXT1800, GL-MT2500, GL-MV1000) running latest stable or GLi preview program firmware to the network. The GL.iNet devices were able to connect fine, but they occasionally fall off the network, and also don't seem to automatically connect to it after a reboot.

To connect, on the GLi devices after binding the device, I run

# tailscale login --login-server https://headscale.mydomain.net

And for a while, things work great. Sometimes the GLi devices disconnect, whereas the OpenWRT devices and others do not. I literally did all this yesterday so I haven't been looking thru the logs yet to see what is happening.

Came to the forum looking for tips, and figured I would start a Headscale thread. Perhaps I/we can figure out a way to stay stably connected with existing firmware. There is another thread requesting that support for custom Tailscale login server be added to GLi firmware: Tailscale Custom Coordination Server

8 Likes
2

Came here looking for this, thank you!

Here's hoping the setting for custom tailscale server gets added to the UI.

2 Likes
3

I have a quick question in passing that I was never able to suss out when looking at Tailscale itself or glancing thru the Headscale docs. Are PSKs supported given this is all based (IIRC) on WireGuard?

4

New user here but i found this has a headache to setup as every reboot it seemed to revert my config to blank tailscale

I ended up SSH’ing in and creating my own service

cat <<'EOF' > /etc/init.d/headscale-tailscale
#!/bin/sh /etc/rc.common
USE_PROCD=1
START=80
start_service() {
mkdir -p /etc/tailscale
procd_open_instance
procd_set_param env TS_DEBUG_FIREWALL_MODE=auto
procd_set_param command /usr/sbin/tailscaled 
--state=/etc/tailscale/tailscaled.state 
--port=41641
procd_set_param stdout 1
procd_set_param stderr 1
procd_set_param respawn
procd_close_instance
}
EOF

then made it executable
chmod +x /etc/init.d/headscale-tailscale

then enabled it
/etc/init.d/headscale-tailscale enable

Finally either reboot or run
/etc/init.d/headscale-tailscale restart

after this you can run whatever you want around the tailscale up to get a headscale working and surviving reboots (not had an update to test if it survives updates

I hope someone finds this helpful

5

Hi all, I’m thinking to buy a GL-MT3000 device, to use it as a personal router and connect it to my headscale istance. I’ve searched the web , but it seems that servers different form tailscale are not much supported. After so much time, was it fixed now?

6

Hello,

What server do you need to connect to?
Is the self-hosted server?

Please edit the startup script gl_tailscale to achieve it.

1 Like
8

I’ve found several twiks, but I’ve seen also, that a lot of persons had problem, because it was reset every reboot. I was wondering in all this time this kind of “bug” was fixed or if the firmware was updated in order to connect to other servers different from the tailscale.com?

9

This is actually a request, not a "bug" to fix.

For the gl_tailscale script reset/modified after restarting, you can use startup script /etc/rc.local and command sed to set up in each system bootup.

1 Like
10

I mean that the reset is a bug, and I’m aware that the support of a different server could be a request :slight_smile:
the sed script in a rc.local is a somekind of tweak, non a solution, but if there is no other solution, hope that at least the script will not be deleted every reboot :wink:

11

In my impression, restarting the router will not reset the script /usr/bin/gl_tailscale, because some users also set the router to host an exit node by modifying the script.

If reboot cause to the script resets, these user who configured a hosted exit node in GL router will be difficult to maintain the custom configuration script.

12

I don't have a device, so I trust you :slightly_smiling_face:

Thank you for answering

13

Very convenient timing that you posted this Bruce, I’d forgotten about it, and just came looking for a solution to the fact that Tailscale loses connection to my self-hosted Headscale server within a few hours on both Slate AX and Beryl AX. This has been very consistent across the past several firmware releases.

I will try setting this up tonight on Beryl AX and see how it performs.

I’m also planning on experimenting with ZeroTier soon, and will eventually self-host a coordination server for that.

Support for connecting to alternate self-hosted servers with Tailscale and ZeroTier in GLi’s firmware would be a huge selling point for me, and for a small but I suspect very loyal segment of users of GLi’s products… SDWAN solutions like these are very useful, but some of us are only willing to use them if we can self-host the coordination servers, because we don’t trust our governments, and leaving the coordination servers hosted by a third-party company is a great way to potentially invite state agents directly into the front door.

14

There may still be a few people who customize connections to their own self-host servers. Sure, we have opened root permissions and users can modify the startup script according to their needs.

However, if there is a disconnection problem about with coordination servers, it may not have much to do with the firmware. You can capture the network packets to check which packets are not transmitted successfully or are lost.

We will reserve to monitor this request volume. Thanks!