Running AstroWarp, Tailscale, ZeroTier, and WireGuard Together on a GL.iNet Flint 3

Affiliate disclosure: This post may contain affiliate links. If you purchase through those links, Tech Relay may earn a commission at no additional cost to you.

Overview

The GL.iNet Flint 3 is one of those routers that starts out looking like a normal Wi-Fi box and then slowly turns into a homelab appliance the deeper you go.

On my Flint 3, I already had:

• WireGuard Server
• Tailscale
• ZeroTier
• VLANs
• Mesh Alpha firmware
• Multiple LANs
• Remote subnet access

Then I started testing AstroWarp.

The GL.iNet UI makes it look like AstroWarp does not want to coexist with other overlay/VPN services. When AstroWarp comes up, Tailscale and ZeroTier may suddenly disappear. Tailscale reports that tailscaled is not running. ZeroTier reports that zerotier-one.port is missing.

At first glance, that looks like a hard compatibility problem.

After digging into it from SSH, that is not what was happening.

The Linux networking stack could run everything together just fine.

The actual problem was this:

The GL.iNet management layer was flipping the Tailscale and ZeroTier UCI settings to disabled.

Once those settings were restored and the services were restarted, AstroWarp, Tailscale, ZeroTier, and WireGuard all ran together.

This post documents the testing, the commands, the symptoms, and the recovery script I now keep on the router.

Test Environment

This was tested on:

1Router:   GL.iNet Flint 3 / GL-BE9300
2Firmware: Mesh Alpha firmware
3Base:     OpenWrt 23.05 snapshot-style firmware
4Shell:    root SSH access

The relevant services were:

The test networks used in this write-up were:

1Local LAN:                 192.168.80.0/24
2Remote Tailscale subnet:   192.168.42.0/24
3ZeroTier network:          10.121.15.0/24
4AstroWarp tunnel:          10.3.128.0/24 via mptun0

Your networks will almost certainly be different. Adjust the IPs accordingly.

The Breakage

After enabling AstroWarp, Tailscale stopped responding:

1tailscale status

Output:

1failed to connect to local tailscaled; it doesn't appear to be running

ZeroTier also stopped responding:

1zerotier-cli info

Output:

1zerotier-cli: missing port and zerotier-one.port not found in /var/lib/zerotier-one

That usually means the daemons are not running.

The next step was to check UCI.

Checking Tailscale UCI

1uci show tailscale

Broken state:

 1tailscale.settings=settings
 2tailscale.settings.log_stderr='1'
 3tailscale.settings.log_stdout='1'
 4tailscale.settings.port='41641'
 5tailscale.settings.state_file='/etc/tailscale/tailscaled.state'
 6tailscale.settings.enabled='0'
 7tailscale.settings.lan_enabled='0'
 8tailscale.settings.wan_enabled='0'
 9tailscale.settings.ssh_enabled='1'
10tailscale.settings.masq='0'
11tailscale.settings.run_exit_node='0'

The important lines:

1tailscale.settings.enabled='0'
2tailscale.settings.lan_enabled='0'
3tailscale.settings.wan_enabled='0'
4tailscale.settings.masq='0'

So Tailscale was not broken at the binary level. It had been disabled in GL.iNet's UCI config.

Checking ZeroTier UCI

1uci show zerotier

Broken state:

1zerotier.gl=zerotier
2zerotier.gl.enabled='0'
3zerotier.gl.nat='1'
4zerotier.gl.wan_nat='0'
5zerotier.gl.join='69f5545babee4bbf'

The important line:

1zerotier.gl.enabled='0'

Again, not a mysterious tunnel failure. ZeroTier was simply disabled.

Verifying AstroWarp

AstroWarp created an mptun0 interface:

1ip -br addr | grep mptun

Example output:

1mptun0           UNKNOWN        10.3.128.2/24

Interface stats:

1ip -s link show mptun0

Example output:

1126: mptun0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2    link/none
3    RX:  bytes packets errors dropped  missed   mcast
4          1196      13     72       0       0       0
5    TX:  bytes packets errors dropped carrier collsns
6         16286     204    690       0       0       0

AstroWarp's routing table:

1ip route show table mptcp_mptun0

Output:

1default dev mptun0 scope link

Policy rules:

1ip rule show

Relevant rule:

130:     from all fwmark 0x2/0x2 lookup mptcp_mptun0

That tells us AstroWarp is policy-routed. Traffic marked with 0x2 uses table mptcp_mptun0, which defaults through mptun0.

AstroWarp was not installing simple remote subnet routes like Tailscale or ZeroTier. It was using policy routing.

Verifying Tailscale Routing

Once Tailscale was re-enabled, the router itself could reach the remote Tailscale subnet:

1ping 192.168.42.1

Example output:

1PING 192.168.42.1 (192.168.42.1): 56 data bytes
264 bytes from 192.168.42.1: seq=0 ttl=64 time=19.552 ms
364 bytes from 192.168.42.1: seq=1 ttl=64 time=22.230 ms

Route lookup:

1ip route get 192.168.42.1

Output:

1192.168.42.1 dev tailscale0 table 52 src 100.97.167.103 uid 0
2    cache

Tailscale route table:

1ip route show table 52

Relevant output:

1192.168.42.0/24 dev tailscale0

That proved Tailscale routing itself was good.

The LAN Client Symptom

The router could ping the remote Tailscale subnet, but a Windows PC behind the Flint 3 could not.

From Windows:

1ping 192.168.42.1

Broken output:

1Pinging 192.168.42.1 with 32 bytes of data:
2Reply from 192.168.80.1: Destination port unreachable.
3Reply from 192.168.80.1: Destination port unreachable.
4Reply from 192.168.80.1: Destination port unreachable.

The reply came from:

1192.168.80.1

That is the Flint 3 LAN gateway.

So the PC was sending packets to the router, and the router was rejecting them.

The missing piece was:

1tailscale.settings.masq='0'

Once Tailscale masquerading was restored and the service restarted, LAN clients could reach the remote subnet.

Working output from Windows:

1Pinging 192.168.42.1 with 32 bytes of data:
2Reply from 192.168.42.1: bytes=32 time=19ms TTL=63
3Reply from 192.168.42.1: bytes=32 time=23ms TTL=63
4Reply from 192.168.42.1: bytes=32 time=20ms TTL=63

Verifying ZeroTier

After restoring ZeroTier:

1zerotier-cli info

Output:

1200 info 73da18a38c 1.14.1 ONLINE

Router test:

1ping 10.121.15.226

Example output:

164 bytes from 10.121.15.226: seq=0 ttl=64 time=134.733 ms
264 bytes from 10.121.15.226: seq=1 ttl=64 time=17.723 ms

LAN client test from Windows:

1ping 10.121.15.226

Working output:

1Pinging 10.121.15.226 with 32 bytes of data:
2Reply from 10.121.15.226: bytes=32 time=23ms TTL=64
3Reply from 10.121.15.226: bytes=32 time=28ms TTL=64
4Reply from 10.121.15.226: bytes=32 time=24ms TTL=64
5Reply from 10.121.15.226: bytes=32 time=21ms TTL=64

ZeroTier did not need much help. Once zerotier.gl.enabled was put back to 1, it came back normally.

The Minimal Fix

This is the final command set that restored both Tailscale and ZeroTier:

1uci set tailscale.settings.enabled='1'
2uci set tailscale.settings.lan_enabled='1'
3uci set tailscale.settings.wan_enabled='1'
4uci set tailscale.settings.masq='1'
5uci set zerotier.gl.enabled='1'
6uci commit tailscale
7uci commit zerotier
8/etc/init.d/tailscale restart
9/etc/init.d/zerotier restart

That alone was enough to restore:

• Tailscale daemon
• Tailscale LAN subnet access
• ZeroTier daemon
• ZeroTier LAN client access

Recovery Script

I keep this script on the Flint 3 as /root/fix-astrowarp-overlays.sh.

 1cat >/root/fix-astrowarp-overlays.sh <<'EOF'
 2#!/bin/sh
 3
 4echo "[+] Restoring Tailscale settings..."
 5uci set tailscale.settings.enabled='1'
 6uci set tailscale.settings.lan_enabled='1'
 7uci set tailscale.settings.wan_enabled='1'
 8uci set tailscale.settings.masq='1'
 9
10echo "[+] Restoring ZeroTier settings..."
11uci set zerotier.gl.enabled='1'
12
13echo "[+] Committing UCI changes..."
14uci commit tailscale
15uci commit zerotier
16
17echo "[+] Restarting Tailscale..."
18/etc/init.d/tailscale restart
19
20echo "[+] Restarting ZeroTier..."
21/etc/init.d/zerotier restart
22
23sleep 5
24
25echo
26echo "=== Tailscale ==="
27tailscale status 2>/dev/null || echo "Tailscale is not ready yet."
28
29echo
30echo "=== ZeroTier ==="
31zerotier-cli info 2>/dev/null || echo "ZeroTier is not ready yet."
32
33echo
34echo "=== Interfaces ==="
35ip -br addr | grep -E 'tailscale0|zt|mptun0|wgserver' || true
36
37echo
38echo "[+] Done."
39EOF
40
41chmod +x /root/fix-astrowarp-overlays.sh

Run it whenever AstroWarp disables the overlays:

1/root/fix-astrowarp-overlays.sh

Optional Watchdog

If AstroWarp repeatedly disables Tailscale and ZeroTier, you can run a simple watchdog.

Create:

 1cat >/root/watch-astrowarp-overlays.sh <<'EOF'
 2#!/bin/sh
 3
 4while true; do
 5    fixed=0
 6
 7    if [ "$(uci -q get tailscale.settings.enabled)" != "1" ]; then
 8        logger -t astrowarp-overlay-watch "Tailscale disabled; restoring"
 9        uci set tailscale.settings.enabled='1'
10        uci set tailscale.settings.lan_enabled='1'
11        uci set tailscale.settings.wan_enabled='1'
12        uci set tailscale.settings.masq='1'
13        fixed=1
14    fi
15
16    if [ "$(uci -q get zerotier.gl.enabled)" != "1" ]; then
17        logger -t astrowarp-overlay-watch "ZeroTier disabled; restoring"
18        uci set zerotier.gl.enabled='1'
19        fixed=1
20    fi
21
22    if [ "$fixed" = "1" ]; then
23        uci commit tailscale
24        uci commit zerotier
25        /etc/init.d/tailscale restart
26        /etc/init.d/zerotier restart
27    fi
28
29    sleep 30
30done
31EOF
32
33chmod +x /root/watch-astrowarp-overlays.sh

Run manually:

1/root/watch-astrowarp-overlays.sh &

Or add it to /etc/rc.local before exit 0:

1/root/watch-astrowarp-overlays.sh &

I prefer the manual recovery script unless AstroWarp keeps flipping the settings repeatedly.

Diagnostic Command Reference

Check AstroWarp

1ip -br addr | grep mptun
2ip -s link show mptun0
3ip route show table mptcp_mptun0
4ip rule show

Check Tailscale

1uci show tailscale
2tailscale status
3ip route show table 52
4ip route get 192.168.42.1

Check ZeroTier

1uci show zerotier
2zerotier-cli info
3zerotier-cli listnetworks
4ip -br addr | grep zt

Check WireGuard Server

1ip -br addr | grep wg
2wg show

Check Everything at Once

1ip -br addr | grep -E 'mptun0|tailscale0|zt|wgserver'
2ps w | grep -E 'mptun|tailscaled|zerotier|wireguard'

What I Think Is Happening

Based on testing, AstroWarp itself does not appear to be technically incompatible with Tailscale or ZeroTier.

The mptun0 interface works.

Tailscale works once re-enabled.

ZeroTier works once re-enabled.

WireGuard keeps working.

The thing that breaks Tailscale and ZeroTier is that GL.iNet's management layer changes their UCI settings when AstroWarp is enabled or refreshed.

That means this is less of a kernel/networking problem and more of a UI/service-management problem.

Important Warning About Routes

Running multiple overlay networks is powerful, but you need to avoid overlapping routes.

Bad idea:

1192.168.1.0/24 via Tailscale
2192.168.1.0/24 via ZeroTier
3192.168.1.0/24 via WireGuard

That can cause real routing conflicts.

Better:

1192.168.42.0/24 via Tailscale
210.121.15.0/24 via ZeroTier
310.1.0.0/24 via WireGuard
4AstroWarp via mptun0 policy routing

Keep the routed subnets distinct and predictable.

Final Result

After restoring the UCI settings, the Flint 3 successfully ran:

From a LAN client, both Tailscale and ZeroTier targets were reachable:

1ping 192.168.42.1
2ping 10.121.15.226

That is exactly what I wanted: AstroWarp enabled without sacrificing the existing remote-access stack.

Final Thoughts

The Flint 3 is flexible enough to run AstroWarp, Tailscale, ZeroTier, and WireGuard at the same time.

The Mesh Alpha firmware may try to protect users from route conflicts by disabling Tailscale and ZeroTier when AstroWarp is enabled. But in this test, the underlying system handled all of them once the settings were restored.

For advanced users, the fix is simple:

1/root/fix-astrowarp-overlays.sh

Keep that script on the router, and you can quickly recover when the GL.iNet UI decides to "help."

FAQ

Can AstroWarp and Tailscale run together on the Flint 3?

Yes. They worked together after Tailscale was re-enabled in UCI and restarted.

Can AstroWarp and ZeroTier run together on the Flint 3?

Yes. ZeroTier worked after restoring zerotier.gl.enabled='1' and restarting the service.

Does AstroWarp break WireGuard?

In this test, WireGuard server continued working.

Why did Tailscale stop working?

The GL.iNet management layer changed tailscale.settings.enabled to 0, along with LAN/WAN/masquerade options.

Why did ZeroTier stop working?

The GL.iNet management layer changed zerotier.gl.enabled to 0.

What is the quickest fix?

Run the recovery command block or use /root/fix-astrowarp-overlays.sh.

Is this officially supported?

No. This is an advanced, unsupported configuration tested on Mesh Alpha firmware.

Should everyone do this?

No. If you are not comfortable with SSH, UCI, and routing, stick with the GL.iNet UI-supported combinations.