Wireguard connection watchdog script for LUCI/GL.iNet router?

[Dustin282]

Hello everyone,

I’m currently using a MUDI router, and in general I’m quite happy with it.
However, I noticed that it sometimes loses the Wireguard connection configured in LUCI.

My setup:

• GL.iNet with LUCI
• LUCI firewall rules
• LUCI Wireguard to Mikrotik Router 1
• LUCI Wireguard to Mikrotik Router 2

When the tunnel drops, I usually have to either restart the router or restart Wireguard manually in LUCI.

Now, I’d like to install the X3000 in my motorhome. Most of the time it just sits parked but should still remain online. Currently, a Mikrotik router is doing this job without issues.

My question:
Does anyone have a script that checks if the Wireguard tunnels are online (e.g. via ping to the remote endpoint), and if not:

• after 20 seconds offline → restart the tunnel
• after 10 minutes offline → reboot the whole router

Also, in which folder should such a script be placed so it survives firmware updates?

Without something like this, I can’t really replace the Mikrotik, since Wireguard there runs 100% stable.

Thanks in advance!

[9b9e69c2-4b75-4420]

Why would you want to reboot the whole device if a WG endpoint goes down? Technically you can but... why? That seems to be treating the symptom but not applying the cure.

@Dustin282

Does anyone have a script that checks if the Wireguard tunnels are online (e.g. via ping to the remote endpoint), and if not:

PersistantKeepAlive = 25 should be doing that already. Check your confs. A watchdog script should be apart of the stock OWRT @ /usr/bin/wireguard_watchdog:

This watchdog script tries to re-resolve hostnames for inactive WireGuard peers.
Use it for peers with a frequently changing dynamic IP.
persistent_keepalive must be set, recommended value is 25 seconds.

if [ ! "$(grep -m 1 '0 * * * * /usr/bin/wireguard_watchdog' /etc/crontabs/root)" = '0 * * * * /usr/bin/wireguard_watchdog     # hourly' ]; then
	printf '%s\n' '0 * * * * /usr/bin/wireguard_watchdog     # hourly' >> /etc/crontabs/root
fi

If you really want to reboot the interface/device you'll want luci-app-watchcat.

[OpenWrt Wiki] Watchcat - network watchdog utility

[bruce]

Why not try to establish VPN tunnels in GL GUI?

The firmware v4.8 of X3000 has supported multiple VPN tunnel and tunnels Failover.

[Dustin282]

Hi @Bruce,
thanks for your reply. I just checked my Mudi device and noticed that the ITEM mode is also new – that's great!

So, it looks like I can now set up multiple WireGuard tunnels and assign them to different networks on the router? I’ll definitely give that a try.

That means LuCI is now only really needed for configuring firewall rules.
If the GUI would allow setting things like “this WireGuard network has no access to local LAN,” that would be really cool.

[bruce]

Hi,

Yes, please try that in X3000 with v4.8.firmware.

@Dustin282

So, it looks like I can now set up multiple WireGuard tunnels and assign them to different networks on the router? I’ll definitely give that a try.

If Allow Remote Access the LAN Subnet is not enabled, the LAN subnet of this router cannot be accessed.

@Dustin282

If the GUI would allow setting things like “this WireGuard network has no access to local LAN,” that would be really cool.

[Dustin282]

Hi Bruce,
I’ve managed to get the VPN up and running so far. The first tunnel is established, and I can successfully ping the remote side. I disabled Global Mode so that only specific traffic goes through the tunnel as intended.

When the tunnel is off, I can access the internet without any issues.
However, when the tunnel is active, I can only reach the remote endpoint, but I lose internet access.

I’ve disabled all options that should prevent this from happening – Global Mode is off.

What am I doing wrong?

Thanks!

One more Test:
I added 0.0.0.0/0 to my WireGuard VPN connection. The internet worked, but the routes to the remote site stopped working because all traffic was forced through the tunnel. As a result, disabling the Kill Switch does not work properly.

[Interface]
Address = 10.xx.xx.200/24
ListenPort = 13231
PrivateKey = deleted
MTU = 1420

[Peer]
AllowedIPs = 10.aa.dd.1/32, 10.12.yr.0/24, 10.xx.xy.0/24
Endpoint = 80.tt.uu.7:13231
PersistentKeepalive = 25
PublicKey = deleted

[Dustin282]

hi,

i install LUCI, just for wireguard.

4 hours testing with the normal interface… no way → VPN or Internet.
20 minutes LUCI → everything is running..

[Dustin282]

Hi,
back to the topic LUCI and WireGuard:

WireGuard works great with LuCI, routing is fine. The only thing that bothers me a bit is the rather rudimentary firewall setup.

I tested a peer with DynDNS. After a reboot, however, WireGuard didn’t want to reconnect automatically. A DNS check via ping showed the correct IP in GL.iNet/LuCI. WireGuard’s keepalive is set to 25 seconds – as recommended.

Still, the tunnel didn’t come back on its own. Only after I manually restarted the interface, the connection was immediately re-established. Before that, I had already waited more than 10 minutes, without success.

Does anyone have an idea why this happens? Is there maybe a setting or trick to make WireGuard automatically reconnect after a DNS/IP change?

[9b9e69c2-4b75-4420]

If it's happening at bootup it could be a race condition. WG needs the time set to handshake. Unless your device has a real time clock (RTC) time is handled by the network time protocol (NTP) daemon which, of course, requires a WAN connection. It also requires DNS to be online. The problem is all network interfaces — including WG — come up at the same time. While the DNS, then time, is being looked up the WG tunnel could be trying to establish but failing to authenticate.

This also applies when using DOH or DOT as the TLS also needs the correct time.

Here is how to set the NTP server DNS & their corresponding IPs as found @ Luci -> System -> Time Synchronization. This removes the DNS dependency for NTPd:

uci set system.@timeserver[0].server='0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org 2.openwrt.pool.ntp.org 3.openwrt.pool.ntp.org 104.167.241.197 73.239.145.47 142.147.88.111 171.66.97.126'
uci commit system
service system restart

If just changing the connectivity state (eg: ifdown/ifup wan) the WG interface should automatically be apart of that process (logread -e netifd). Other than that the wireguard_watchdog script should be set in cron to periodically poll the DDNS used for the Endpoint. service cron restart after configuring.

pool.ntp.org: the internet cluster of ntp servers

[bruce]

Hi,

Try changing your profile AllowIPs to "0.0.0.0/0", fill in "10.aa.dd.1/32, 10.12.yr.0/24, 10.xx.xy.0/24" into To's Specified Domain/IP List:

@Dustin282

AllowedIPs = 10.aa.dd.1/32, 10.12.yr.0/24, 10.xx.xy.0/24

In this way, the traffic accessing these IPs or subnets will go to the VPN tunnel, and other Internet traffic will go to the WAN.
Configuration according to your needs, for reference only.

[Dustin282]

Hello,
I don’t think this issue is related to time.

All I did was replace the router in my camper. The remote endpoint is still the same MikroTik device, unchanged. Previously I also had a MikroTik in the camper, but now I’m using the GL.iNet X3000 Spitz.

Today I ran some more tests with LuCI. When the router boots, it establishes an LTE connection and the WireGuard tunnels come up fine.

However, if the router then switches connections — for example, when I raise the priority of the Wi-Fi Client/Repeater — it immediately goes online over the other Wi-Fi, but the WireGuard tunnels in LuCI do not reconnect. Even restarting the interface doesn’t help. The tunnels only start working again after I reboot the router.

To me this looks more like a reconnect problem.

I just don’t understand it, because with my old router switching between WAN mediums was never an issue. But since the GL.iNet is so convenient, I went with it.
Unfortunately, without WireGuard nothing works in my camper.

[Dustin282]

@bruce

Try changing your profile AllowIPs to "0.0.0.0/0", fill in "10.aa.dd.1/32, 10.12.yr.0/24, 10.xx.xy.0/24" into To's Specified Domain/IP List:

Hello @bruce,

I have been testing the GL.iNet interface for hours now, and I keep running into issues.

Problems:

• At home (192.168.1.0/24): I cannot access 172.10.10.200 (GL.iNet in the camper).

• GL.iNet to work: The VPN tunnel does not work. Only one tunnel ever works at a time.

Configuration:

• Policy Mode enabled

• 2 WireGuard groups with one connection each

• Kill Switch on or off inside the tunnel makes no difference

• "Allow Remote Access to the LAN Subnet" is enabled on both tunnels

The second tunnel I start always stays orange. It never comes up.
I have been testing for hours without success.

PS.
Another add-on that worked with LuCI and my old Mikrotik router:
I had a DNS forwarding rule in the router pointing to a server in my home network. This does not work at all with GL.iNet.
As a workaround, I configured DHCP so that the DNS on the other side of the VPN tunnel should be used, but unfortunately I do not get any response – as if DNS requests are being filtered or “fished out” inside the tunnel.

PPS.

---

I tested again: when I make DNS queries via TCP, I can reach the servers at the end of the tunnel. I assume that UDP is not possible over GLI WireGuard, while it does work with LuCI.
Could that be the case?

pls help

log Tunnel what’s not working:
Log

Tue Sep 2 18:20:34 2025 daemon.info dnsmasq[871]: read /tmp/hosts/dhcp.wgclient1 - 4 addresses
Tue Sep 2 18:20:45 2025 daemon.info dnsmasq[3441]: read /tmp/hosts/dhcp.wgclient1 - 4 addresses
Tue Sep 2 18:20:45 2025 daemon.info dnsmasq[3439]: read /tmp/hosts/dhcp.wgclient1 - 4 addresses
Tue Sep 2 18:20:45 2025 daemon.info dnsmasq[3440]: reading /tmp/resolv.conf.d/resolv.conf.wgclient1
Tue Sep 2 18:20:45 2025 daemon.info dnsmasq[3440]: read /tmp/hosts/dhcp.wgclient1 - 4 addresses
Tue Sep 2 18:20:56 2025 daemon.info dnsmasq[4342]: read /tmp/hosts/dhcp.wgclient1 - 4 addresses
Tue Sep 2 18:20:56 2025 daemon.info dnsmasq[4343]: reading /tmp/resolv.conf.d/resolv.conf.wgclient1

[Dustin282]

Hi Bruce,
I'm honestly close to giving up. I've invested a lot of time into the GL.iNet interface, but I'm getting really frustrated. I'm still having problems in the camper setup.

• No ping from home to the camper router

• Only one VPN tunnel is active, even though two are configured

• DNS issues within the tunnel: I want clients to use the DNS servers from home and work. Even better would be proper forwarding like in LuCI

• Network acceleration must be turned off; otherwise, MODBUS queries from home to the Victron system don't work

• OpenWRT is outdated: WireGuard handoff issues I had in LuCI (e.g. switching Wi-Fi) are already fixed in current OpenWRT versions

And my Mudi is driving me crazy as well. It shows as online, but keeps dropping the connection constantly. But that's something I’ll look into later.

[bruce]

Hi,

Sorry for the late reply.

Since I can't reproduce your issue locally, I would like to deep know about your issue and situation.

The PC connected to MT6000's LAN, is not only able to access the remote X3000 (vpn client) GL GUI, and the X3000 LAN clients.

1. Please provide your network topology, as detailed as possible, including the VPN server router, VPN client router (X3000), their IP subnet, etc.

@Dustin282

No ping from home to the camper router

2. Please confirm that the second profile can be connected normally on the mobile phone/pc.

@Dustin282

Only one VPN tunnel is active, even though two are configured

3. As long as the X3000 VPN client is connected to the home VPN server, the X3000 DNS server can use the home DNS server. Just change the DNS address to the home DNS server LAN IP in the X3000 VPN profile.

4. The issue might stem from an incompatibility between hardware acceleration and MODBUS messages, please disable the hardware acceleration.

@Dustin282

Network acceleration must be turned off; otherwise, MODBUS queries from home to the Victron system don't work

5. This is the op version brought by the closed source SDK. Please configure WireGuard, WiFi and other functions in the GL GUI, and do not configure it in Luci.

What is LuCI - GL.iNet Router Docs 4

@Dustin282

OpenWRT is outdated: WireGuard handoff issues I had in LuCI (e.g. switching Wi-Fi) are already fixed in current OpenWRT versions

For the convenience of remote support, please share the X3000 router with us through GoodCloud. We will check the WG client configuration of your router after obtaining the above information.

Technical Support via GoodCloud - GL.iNet Router Docs 4

[Dustin282]

Natürlich, hier ist deine Nachricht ins Englische übersetzt:

---

Hi Bruce,

1. Important background info:
   The configuration was sent via PM.
   The home server is a MikroTik router. In the camper, I'm using the GL.iNet Spitz.
   When I power off the GL.iNet in the camper and switch back to the previous MikroTik router, everything works flawlessly.
   Both tunnels come up immediately and function as expected — DNS, remote access to the home router, etc. — everything works.

2. If I disable the first tunnel and activate the second, it works.
   Also, both tunnels work simultaneously when using the MikroTik router. I haven’t changed the configuration on the home side.

3. The home DNS server is configured as the DNS server on both ends.
   But regardless of whether the DNS entry is present or not, I can’t get any UDP DNS packets through the tunnel.

4. Correct — hardware acceleration is now disabled.

As mentioned, I’ve done everything using the GL.iNet web interface.
In LuCI, I only created a backup — I haven’t clicked or changed anything there.

[Dustin282]

Hi Bruce,

I’ve found the cause of the DNS issue — it’s well-intended in the configuration logic, but honestly quite frustrating when setting things up.

First, I did a full factory reset on the router and rebuilt the entire configuration from scratch.

My goal was to use a DNS server on the other side of the VPN tunnel.

(What would be really great is if I could keep the DNS on the X3000 and just use domain-based forwarding — like it's possible in LuCI.)

Initially, I hadn’t entered any domains in the “Domain List” field, so the router silently dropped all UDP DNS packets — only TCP DNS requests were allowed.
When I did enter specific domains, the client was only able to query the DNS server for those exact domains. That would mean I’d need to list every domain in the world — obviously not practical.

The alternative is to use the Exclude Mode under VPN Policy Routing, and invert the logic.

So instead of defining which traffic should go through the tunnel, I excluded all global IP ranges except my internal networks (the ones I want to route through the VPN).
This way, the DNS server — and any other internal services — are reachable via tunnel, and all other traffic goes out via regular WAN.

I think this behavior should really be made more clear in the UI or documentation — maybe a warning or help icon could explain it better.

---

Now I still have two remaining issues:

1. No ping from home to the camper router — everything else is reachable (servers behind it, DNS, etc.), but not the router itself.

2. Only one tunnel can be active at a time — even though both are defined.

Other than that, I'm happy with the performance so far.
WireGuard handover works well when switching between mobile and repeater mode — no need to restart the tunnel.

Thanks again for your help!

This is at Home:
200 is my X3000 Spitz
178 is my Victron Cerbo
Radio, Eufy is also online!

Tunnel Chance, the other one is online:

[bruce]

Hi,

Are these two tunnels not connected to the same VPN server, right?

@Dustin282

If I disable the first tunnel and activate the second, it works.
Also, both tunnels work simultaneously when using the MikroTik router. I haven’t changed the configuration on the home side.

I will check DNS in the remote.

@Dustin282

But regardless of whether the DNS entry is present or not, I can’t get any UDP DNS packets through the tunnel.

In addition to DNS server, I will also check:

1. Tunnel 2 connection status
   2. Please tell me what rules do you need to do? To ensure that the tunnel connection is normal, we first set Profile AllowedIPs to 0.0.0.0/0, and then fill in the IP you need to go to VPN access in To - Specified Domain / IP List.

2. Ping from home router to X3000 - Please enable Allow Remote Access the LAN Subnet on X3000, and access the GL GUI via the X3000 VPN tunnel IP, like 10.1.0.2
   

   

3. Do not configure anything in Luci. If you have configured it in Luci, please restore the device to the factory first, then import the VPN Profile, and then share it with us with GoodCloud.

[Dustin282]

Hello Bruce,
correct, the tunnels have different routers as their remote peers.
From both remote peers I was able to access the router configuration from the respective network when I still had a Mikrotik router. I haven’t made any changes on the VPN remote peers since I switched to GLI.

It’s clear that “Remote Access the LAN subnet” has to be enabled, we already discussed that. If it were off, I wouldn’t be able to reach anything. But I am polling the Cerbo from Victron every second via Modbus.
IP masquerading must of course be disabled, but in your screenshot it is enabled.

As I already mentioned, I completely reset the router yesterday and configured everything, including enabling LuCI. And the router behaved exactly the same as before I reset it. I only enabled LuCI afterwards so I could make a backup, nothing more.

PS.
This “hack” I built with the exclude for VPN is hopefully not supposed to be a permanent solution.

[bruce]

You should create a static route in your VPN server.

Test with my MT6000 VPN server as follows, when I created a static route in MT6000, the ping of MT6000 is able to receive the reply from your X3000 LAN clients.

The test process:

1. Switch to my test profile on your X3000. (The test profile from my MT6000 VPN server. Deleted after the test, and restored to your own two profiles)
   

   

2. Keep your original tunnel options:
   

   

3. My MT6000 VPN server, created a static route:
   

   

On MT6000 SSH, ping your X3000 and X3000 LAN clients:

root@GL-MT6000:~# ping 10.1.0.2
PING 10.1.0.2 (10.1.0.2): 56 data bytes
64 bytes from 10.1.0.2: seq=0 ttl=64 time=263.570 ms
64 bytes from 10.1.0.2: seq=1 ttl=64 time=488.002 ms
64 bytes from 10.1.0.2: seq=2 ttl=64 time=272.853 ms
^C
--- 10.1.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 263.570/341.475/488.002 ms
root@GL-MT6000:~# ping 172.22.20.200
PING 172.22.20.200 (172.22.20.200): 56 data bytes
64 bytes from 172.22.20.200: seq=0 ttl=64 time=261.828 ms
64 bytes from 172.22.20.200: seq=1 ttl=64 time=262.779 ms
^C
--- 172.22.20.200 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 261.828/262.303/262.779 ms
root@GL-MT6000:~# ping 172.22.20.173
PING 172.22.20.173 (172.22.20.173): 56 data bytes
64 bytes from 172.22.20.173: seq=0 ttl=254 time=262.679 ms
64 bytes from 172.22.20.173: seq=1 ttl=254 time=263.337 ms
64 bytes from 172.22.20.173: seq=2 ttl=254 time=479.720 ms
^C
--- 172.22.20.173 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 262.679/335.245/479.720 ms
root@GL-MT6000:~#
root@GL-MT6000:~#
root@GL-MT6000:~# ping 172.22.20.182
PING 172.22.20.182 (172.22.20.182): 56 data bytes
64 bytes from 172.22.20.182: seq=0 ttl=63 time=459.721 ms
64 bytes from 172.22.20.182: seq=1 ttl=63 time=270.873 ms
64 bytes from 172.22.20.182: seq=2 ttl=63 time=269.256 ms
^C
--- 172.22.20.182 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 269.256/333.283/459.721 ms
root@GL-MT6000:~# ping 172.22.20.49
PING 172.22.20.49 (172.22.20.49): 56 data bytes
64 bytes from 172.22.20.49: seq=0 ttl=63 time=266.122 ms
64 bytes from 172.22.20.49: seq=1 ttl=63 time=510.248 ms
64 bytes from 172.22.20.49: seq=2 ttl=63 time=263.342 ms
^C
--- 172.22.20.49 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 263.342/346.570/510.248 ms

The ping without issue, indicating that there is no problem with the X3000 VPN features.

[Dustin282]

---

Hello Bruce,

thanks again for testing. When I power down my X3000 and bring up the old Mikrotik, I can reach the Mikrotik without any issues – and I don’t need to change anything on the remote peers.

From your test, I suspect that the X3000 is still routing some network that I’m not aware of. When I try to reach the router, it might be using an additional network or IP address on the WireGuard interface to send the return packets. In that case, I wouldn’t get any reply, because my home peer doesn’t know that network. However, in the GL.iNet UI I don’t see any extra networks configured.

The WireGuard server is not enabled on my GL.iNet device.

Also, when I check via SSH, I don’t find any unknown IP addresses.

Could this be the issue?