# Wireguard connection watchdog script for LUCI/GL.iNet router? **URL:** \ **Category:** Router\ **Created:** [August 27, 2025, 10:16am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413 "2025-08-27T10:16:24Z")\ **Posts on this page:** 15\ **Page:** 3
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [October 29, 2025, 11:27am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/44 "2025-10-29T11:27:39Z")
Hello Bruce, thanks again for your detailed tests! I think there is still a fundamental misunderstanding: ✅ DNS itself already works correctly ❌ The issue is that **WireGuard policy routing modifies DNS traffic** , depending on include/exclude rules. In my deployments the DNS server is always the Domain Controller on the other side of the tunnel (distributed by DHCP). Therefore, **DNS traffic must always go through the VPN** , regardless of which destination domain or IP is queried. Right now the GL firmware treats DNS as **destination traffic** → but DNS is **service traffic** , independent of the final target. Because of this behavior: - Using _include_ breaks DNS (DNS packets stay local instead of reaching the DC) - Using _exclude_ forces me to maintain a huge exclusion list - Which does not scale across many customer installations We need DNS routing **separate** from include/exclude destination rules. 📌 **What is needed** A simple option like: > “Send DNS traffic to VPN” > (all DNS packets: UDP/TCP 53, optionally DoT/DoH to specified DNS IPs) This solves the problem cleanly and makes “include” usable again. I hope this makes the situation clearer. Thank you again for reviewing it! Best regards, Dustin ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [October 31, 2025, 6:45am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/45 "2025-10-31T06:45:27Z")
Hello, Whether it is "include" or "exclude", DNS will spilt traffic according to the configured policy rules. For example, if it is "include", and the destination address is in the "include" list, the DNS will use VPN DNS, the access request will go to VPN tunnel; vice versa, if destination is not in the "include", the DNS will use WAN DNS, and the access request will go to the WAN (or the next tunnel rule) So we are curious why in your configuration the DNS of the VPN client cannot reach the domain control server of the VPN server, but in my test DNS works properly. 1. Please SHH login the router, and execute: `ipset list` 2. Please export the issue syslog in GL GUI \> SYSTEM \> Log ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [October 31, 2025, 12:16pm UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/46 "2025-10-31T12:16:03Z")
Hello Bruce, thank you for the clarification. I think I understand how your current logic works — DNS traffic is split depending on the _destination policy_ (include/exclude). However, this logic doesn’t fit setups where the **DNS server itself is located behind the VPN** — for example, when the VPN server side has a **Windows Domain Controller (DC)** providing DNS via DHCP. In this situation: - The client must **always** send _all DNS queries_ through the VPN, because the only valid resolver is the remote DC. - The DC DNS decides where each domain should go — internal or external. - If GL.iNet splits DNS before it reaches the DC, the lookup fails or resolves with wrong results. That’s why in my setup, _include_ breaks the DNS logic: DNS packets never reach the remote DC, because they’re already handled locally. The only way to make it work is _exclude_, which forces everything through the tunnel first — but that requires a huge exclude list. So the problem is not that DNS cannot “reach” the DC — it’s that **GL.iNet’s current policy engine decides DNS direction before the DNS query can even reach the correct server**. For corporate or AD environments, DNS must be treated as **service routing** , not **destination-based routing**. I’ll still collect the `ipset list` and syslog for your reference. Best regards, Dustin \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ BusyBox v1.33.2 (2025-09-04 11:11:17 UTC) built-in shell (ash) * * * ## | |.-----.-----.-----.| | | |.----.| |\_ | - || \_ | -**| || | | || _|| | |_\_\_\_\_\_|| | **_||||_\_\_\_** ||**| |\_\_\_\_| || W I R E L E S S F R E E D O M ## OpenWrt 21.02-SNAPSHOT, root@GL-XE3000:~# ipset list Name: dst\_net10 Type: hash:net Revision: 6 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 2760 References: 1 Number of entries: 38 Members: 196.0.0.0/6 193.0.0.0/8 112.0.0.0/5 16.0.0.0/4 126.0.0.0/8 176.0.0.0/4 173.0.0.0/8 192.192.0.0/10 32.0.0.0/3 1.0.0.0/8 160.0.0.0/5 64.0.0.0/3 12.0.0.0/6 168.0.0.0/6 192.170.0.0/15 194.0.0.0/7 200.0.0.0/5 120.0.0.0/6 172.0.0.0/12 10.0.0.0/8 192.176.0.0/12 192.128.0.0/11 172.64.0.0/10 4.0.0.0/6 124.0.0.0/7 128.0.0.0/3 172.128.0.0/9 208.0.0.0/4 8.0.0.0/7 192.0.0.0/9 192.169.0.0/16 192.160.0.0/13 172.32.0.0/11 174.0.0.0/7 192.172.0.0/14 2.0.0.0/7 96.0.0.0/4 11.0.0.0/8 Name: dst\_net10\_6 Type: hash:net Revision: 6 Header: family inet6 hashsize 1024 maxelem 65536 Size in memory: 1240 References: 0 Number of entries: 0 Members: Name: dst\_net1832 Type: hash:net Revision: 6 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 2824 References: 1 Number of entries: 37 Members: 172.32.0.0/11 120.0.0.0/6 126.0.0.0/8 32.0.0.0/3 192.0.0.0/9 174.0.0.0/7 11.0.0.0/8 176.0.0.0/4 192.170.0.0/15 192.128.0.0/11 192.176.0.0/12 124.0.0.0/7 192.192.0.0/10 8.0.0.0/7 194.0.0.0/7 208.0.0.0/4 4.0.0.0/6 172.0.0.0/12 172.64.0.0/10 193.0.0.0/8 192.169.0.0/16 173.0.0.0/8 64.0.0.0/3 160.0.0.0/5 192.172.0.0/14 1.0.0.0/8 12.0.0.0/6 196.0.0.0/6 96.0.0.0/4 172.128.0.0/9 200.0.0.0/5 168.0.0.0/6 16.0.0.0/4 128.0.0.0/3 192.160.0.0/13 2.0.0.0/7 112.0.0.0/5 Name: dst\_net1832\_6 Type: hash:net Revision: 6 Header: family inet6 hashsize 1024 maxelem 65536 Size in memory: 1240 References: 0 Number of entries: 0 Members: Name: GL\_MAC\_BLOCK Type: hash:mac Revision: 0 Header: hashsize 1024 maxelem 65536 Size in memory: 200 References: 1 Number of entries: 0 Members: root@GL-XE3000:~# \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Fri Oct 31 11:53:47 2025 daemon.info dnsmasq[21110]: using nameserver x.x.x.x#53 Fri Oct 31 11:53:47 2025 daemon.info dnsmasq[21110]: using nameserver 8.8.8.8#53 Fri Oct 31 11:53:47 2025 daemon.info dnsmasq[21110]: using nameserver 8.8.4.4#53 Fri Oct 31 11:53:47 2025 daemon.info gl-repeater[3224]: (repeater.lua:1731) interface "wwan" up Fri Oct 31 11:53:47 2025 daemon.notice netifd: wwan (21667): PING x.x.x.x (x.x.x.x): 56 data bytes Fri Oct 31 11:53:47 2025 daemon.info glc: (common.c:1741) Parse +COPS response success Fri Oct 31 11:53:47 2025 daemon.notice netifd: wwan (21667): 64 bytes from x.x.x.x: seq=0 ttl=64 time=9.368 ms Fri Oct 31 11:53:47 2025 daemon.notice netifd: wwan (21667): Fri Oct 31 11:53:47 2025 daemon.notice netifd: wwan (21667): --- x.x.x.x ping statistics --- Fri Oct 31 11:53:47 2025 daemon.notice netifd: wwan (21667): 1 packets transmitted, 1 packets received, 0% packet loss Fri Oct 31 11:53:47 2025 daemon.notice netifd: wwan (21667): round-trip min/avg/max = 9.368/9.368/9.368 ms Fri Oct 31 11:53:47 2025 user.notice kmwan: config json str={ "op": 6, "data": { } } Fri Oct 31 11:53:48 2025 user.notice kmwan: config json str={ "op": 2, "data": { "cells": [{ "interface": "wwan", "netdev": "apclix0", "track\_mode": "force", "addr\_type": 4, "force\_ip": "x.x.x.x", "tracks": [ { "type": "ping", "ip": "1.1.1.1" }, { "type": "ping", "ip": "8.8.8.8" }, { "type": "ping", "ip": "208.67.222.222" }, { "type": "ping", "ip": "208.67.220.220" }] } ] } } Fri Oct 31 11:53:48 2025 kern.debug kernel: [67.893721] [add\_dev\_config 319]add node success. iface:wwan, dev:apclix0, ifindex:12 Fri Oct 31 11:53:48 2025 daemon.info gl-repeater[3224]: (repeater.lua:1738) interface wwan status offline Fri Oct 31 11:53:48 2025 daemon.info glc: (common.c:1741) Parse +COPS response success Fri Oct 31 11:53:48 2025 user.notice firewall: Reloading firewall due to ifup of wwan (apclix0) Fri Oct 31 11:53:48 2025 daemon.info avahi-daemon[7852]: Joining mDNS multicast group on interface apclix0.IPv6 with address fe80::ecee:71ff:fe39:7758. Fri Oct 31 11:53:48 2025 daemon.info avahi-daemon[7852]: New relevant interface apclix0.IPv6 for mDNS. Fri Oct 31 11:53:48 2025 daemon.info avahi-daemon[7852]: Registering new address record for fe80::ecee:71ff:fe39:7758 on apclix0.\*. Fri Oct 31 11:53:49 2025 kern.debug kernel: [69.236179] Set\_ByPassCac\_Proc(): set CAC value to 1 Fri Oct 31 11:53:49 2025 kern.debug kernel: [69.538442] BcnCheck start after 2500 ms (ra0) Fri Oct 31 11:53:49 2025 kern.debug kernel: [69.542886] BcnCheck start after 2500 ms (ra0) Fri Oct 31 11:53:49 2025 daemon.info gl-repeater[3224]: (repeater-portal.lua:395) portal detecting... Fri Oct 31 11:53:50 2025 daemon.info gl-repeater[3224]: (repeater.lua:1738) interface wwan status online Fri Oct 31 11:53:50 2025 daemon.info gl-repeater[3224]: (repeater-portal.lua:418) not found portal Fri Oct 31 11:53:52 2025 cron.err crond[7473]: time disparity of 3112 minutes detected Fri Oct 31 12:38:10 2025 kern.debug kernel: [2729.580780] entrytb\_aid\_aquire(): found non-occupied aid:5, allocated from:4 Fri Oct 31 12:38:10 2025 kern.warn kernel: [2729.587881] 7981@C13L2,MacTableInsertEntry() 1577: New Sta:xx:xx:xx:xx:xx:xx Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.598280] 7981@C08L3,ap\_cmm\_peer\_assoc\_req\_action() 1714: Recv Assoc from STA - xx:xx:xx:xx:xx:xx Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.607739] 7981@C08L3,ap\_cmm\_peer\_assoc\_req\_action() 2241: ASSOC Send ASSOC response (Status=0)... Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.616940] 7981@C01L3,wifi\_sys\_conn\_act() 1115: wdev idx = 2 Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.623118] 7981@C08L3,hw\_ctrl\_flow\_v2\_connt\_act() 215: wdev\_idx=2 Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.747008] 7981@C15L3,WPABuildPairMsg1() 5310: \<=== send Msg1 of 4-way Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.753688] 7981@C15L3,PeerPairMsg2Action() 6303: ===\>Receive msg 2 Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.760474] 7981@C15L3,WPABuildPairMsg3() 5595: \<=== send Msg3 of 4-way Fri Oct 31 12:38:10 2025 kern.notice kernel: [2729.767173] 7981@C15L3,PeerPairMsg4Action() 6734: ===\>Receive msg 4 Fri Oct 31 12:38:10 2025 kern.warn kernel: [2729.778721] 7981@C15L2,PeerPairMsg4Action() 7098: AP SETKEYS DONE(rax0) - AKMMap=WPA2PSK, PairwiseCipher=AES, GroupCipher=AES, wcid=2 from xx:xx:xx:xx:xx:xx Fri Oct 31 12:38:13 2025 daemon.info dnsmasq-dhcp[21110]: DHCPDISCOVER(br-lan) xx:xx:xx:xx:xx:xx Fri Oct 31 12:38:13 2025 daemon.info dnsmasq-dhcp[21110]: DHCPOFFER(br-lan) x.x.x.x xx:xx:xx:xx:xx:xx Fri Oct 31 12:38:13 2025 daemon.info dnsmasq-dhcp[21110]: DHCPREQUEST(br-lan) x.x.x.x xx:xx:xx:xx:xx:xx Fri Oct 31 12:38:13 2025 daemon.warn dnsmasq-dhcp[21110]: Ignoring domain dwnet.intern for DHCP host name x Fri Oct 31 12:38:13 2025 daemon.info dnsmasq-dhcp[21110]: DHCPACK(br-lan) x.x.x.x xx:xx:xx:xx:xx:xx x Fri Oct 31 12:39:21 2025 kern.notice kernel: [2800.221288] 7981@C15L3,PeerGroupMsg1Action() 7167: ===\>Receive group msg 1 Fri Oct 31 12:53:21 2025 daemon.notice netifd: modem\_0001\_4 (12236): udhcpc: sending renew to x.x.x.x Fri Oct 31 12:53:21 2025 daemon.notice netifd: modem\_0001\_4 (12236): udhcpc: lease of x.x.x.x obtained, lease time 7200 Fri Oct 31 12:53:21 2025 user.notice kmwan: config json str={ "op": 6, "data": { } } Fri Oct 31 13:07:53 2025 authpriv.info dropbear[13424]: Child connection from x.x.x.x:12246 Fri Oct 31 13:08:02 2025 authpriv.notice dropbear[13424]: Password auth succeeded for 'x' from x.x.x.x:12246 ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [November 3, 2025, 6:53am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/47 "2025-11-03T06:53:57Z")
Hello, I understood what you request, and I think the firmware v4.7 and previous may be more in line with your needs. Since the previous firmware was not developed and supported DNS split, all DNS traffic went to the VPN. For your scenario, all DNS uses to VPN DNS, which is in line with your purpose. But for most ordinary users, they may prefer that DNS can also be split (WAN and VPN) instead of all go to VPN DNS. If the DNS does not split, will cause the returned resolution IP to not necessarily be the IP with the best/fastest one - for example, if the user configure an exclude list, and VPN tunnel is a server in the United States, all DNS uses remote VPN DNS (v4.7 firmware), he just want to access a domain web page which is in exclude list in Hong Kong (htpp/s session should go to WAN), but the resolution IP returned by VPN DNS is from the United States, the web loading and response speed of web page elements will be greatly reduced, since it connects to the United States server. On the other hand, streaming media such as HBO have been added to exclude, and it should go to WAN, all use VPN DNS in the v4.7 firmware, it would be detected by the APP and misjudged as using VPN, and access was not allowed. I assume the reason is the IP returned by VPN DNS does not match or does not belong to the WAN connected ISP local area. That’s reason why we have to improve and develop DNS spilt to ensure that domain is resolved to the best IP, which is more in line with user expectations and ensures higher availability. For your scenario, I think we have two ways: 1. Downgrade the firmware to v4.7 or previous. 2. Customize all LAN client DNS servers to DC IP, or manually set the router DNS to DC IP. This should bring that all DNS requests go to DC. ![Bruce_2025-11-03_14-55-01](https://forum-static.gl-inet.com/original/3X/a/3/a32d81d6ca0c1009877daca24638744f9a594d72.png) ![Bruce_2025-11-03_14-54-29](https://forum-static.gl-inet.com/original/3X/9/5/9522508f50c10cf1c75ab805ab67c60d8f517951.png) Configure the exclude list according to your needs, it will not affect the DNS settings as in my previous test. ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [November 7, 2025, 7:29am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/48 "2025-11-07T07:29:09Z")
Hello Bruce, thank you for the detailed explanation – now everything makes sense regarding the difference between the older (v4.7) and newer firmware behavior. I fully understand why the DNS split feature was introduced – for most home or private users it’s beneficial that DNS can be split between WAN and VPN for performance and streaming services. However, our use case is fundamentally different: - We deploy GL.iNet routers in **managed business environments** with **Windows Domain Controllers**. - The **DC is always the DNS server** for all clients and is located **behind the VPN**. - DHCP on the GL router points to the DC as DNS – clients must not and cannot modify DNS settings locally. - Many users do not have administrative rights to change network settings, so manually configuring DNS on each PC is not an option. Because of the new split-DNS logic, the router now intercepts DNS traffic before it reaches the remote DC. This breaks the Active Directory environment (domain login, group policies, Kerberos, internal name resolution, etc.). Downgrading to v4.7 could work temporarily, but it is not a long-term solution. We operate and maintain **a large number of GL.iNet routers** , and managing firmware downgrades or custom images across all devices is not practical. What would really help is a **configurable option in the GUI** such as: > “Always send all DNS traffic through VPN tunnel (disable DNS split).” That way, the split behavior stays the default for private users, but professional or enterprise users like us can explicitly enable full VPN DNS routing when required. Thank you again for all the support and clear explanations — I really appreciate your time. I hope your R&D team can consider adding such an option in a future firmware release. Best regards, Dustin ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [November 13, 2025, 2:22am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/49 "2025-11-13T02:22:27Z")
We think may not return back to the previous situation for currently or future firmware, and will not add the button in order to avoid confusing users. Let's evaluate whether there is a workaround to shoot this problem in the router SSH. ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [November 14, 2025, 8:45am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/50 "2025-11-14T08:45:23Z")
Hello Bruce, I understand your concerns, but unfortunately using an SSH-based workaround is not practical for our deployments. We plan to roll out these routers to many employees working in home-office environments. For these installations we must ensure that: 1. The router is reachable through the tunnel (ping / management IP) 2. All DNS queries can pass through the tunnel to the remote Domain Controller 3. The device fully follows RFC and WireGuard standards, without interfering with DNS traffic These are basic requirements, not special features. Any solution that depends on manually configuring every router via SSH is not feasible — neither for us nor for our customers. If these three standard behaviors cannot be guaranteed, then all the effort invested so far was unfortunately for nothing, and we will be forced to evaluate another vendor again. A firmware that breaks standard DNS behavior, requires manual SSH workarounds, or prevents remote management via VPN cannot be used in enterprise deployments. I hope your team can reconsider this, because otherwise the devices cannot be used in our environment. Best regards, Dustin ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [November 19, 2025, 10:49am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/52 "2025-11-19T10:49:32Z")
Hello, We are evaluating solutions, to improve this issue "forwarding specific DNS traffic (request) to the VPN tunnel", maybe in the firmware, but it may take some times, please allow a while. ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [November 19, 2025, 3:34pm UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/53 "2025-11-19T15:34:07Z")
Hello Bruce, thank you for the update. I appreciate that your team is now evaluating a proper solution for forwarding DNS requests through the VPN tunnel. As mentioned earlier, using SSH scripts or a paid custom firmware is unfortunately not an option for us. I had already informed your technical support that if this becomes the only way to achieve basic RFC-compliant behavior, we would be forced to switch to another vendor. It’s good to hear that R&D is now reviewing this and considering implementing both necessary functions directly in the firmware: 1. **Router/config interface reachable over the VPN tunnel** 2. **Disable DNS split (DNS always through VPN when required)** These two points are essential for our deployments. Can you provide a rough time frame for when these features might be available? Even an approximate estimate would help us plan our rollout and decide whether we can remain with GL.iNet or need to take a different route. Thanks again for your continued support. Best regards, Dustin ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [November 20, 2025, 2:37am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/54 "2025-11-20T02:37:39Z")
Yes, we have finalized a rough solution. This part code has been updated, and the latest firmware of X3000 should have merged the codes and fix this. > [@Dustin282](#): > > Router/config interface reachable over the VPN tunnel It does not disable DNS split, but will first check the DNS destination address. Like if say the DNS server is manually set up on the client PC (DC, the PC in your video is set up with a DNS server), it will not be split first (a check is added before the split), and the custom DNS will be sent to the VPN server through the tunnel. > [@Dustin282](#): > > Disable DNS split (DNS always through VPN when required) BTW, how many X3000s do you have? ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [November 24, 2025, 11:31am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/55 "2025-11-24T11:31:29Z")
Hello Bruce, thank you very much for the update. It’s great to hear that a rough solution has already been finalized and that the latest X3000 firmware includes the fix for router/config reachability over the VPN tunnel. Also the additional DNS logic — checking the DNS destination _before_ applying DNS split — sounds like exactly what we need for environments where the DNS server is manually set (Domain Controller). This is an important step forward and I appreciate that R&D has implemented this. We currently have **10 devices** in test operation at different customer sites. A wider rollout can only begin once these two issues are fully resolved and tested: 1. **Router/config interface reachable over VPN** 2. **Correct handling of DNS when a custom DNS server (Domain Controller) is used** Once these two functions work reliably, we are ready to deploy the next batch of devices. Regarding your question: At the moment we have 10 units in testing, but we plan significantly more depending on the stability of these features. Thank you again for your support and the quick progress on the firmware side. Best regards, Dustin ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [December 11, 2025, 7:51am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/56 "2025-12-11T07:51:21Z")
Hello Bruce, after the latest update I can now reach the router configuration page through the VPN tunnel. I only updated the GL.iNet router — nothing was changed on the Mikrotik side. Now the only thing missing is to remove the DNS filtering/splitting behavior from the WireGuard tunnel for our scenario. Once that part is adjusted, we can restart the full test phase with our customer deployments. Best regards, Dustin ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [December 11, 2025, 8:16am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/57 "2025-12-11T08:16:06Z")
Hello, R&D team has updated the codes and is waiting for the firmware to be compiled and tested. Please wait. ---
**Author:** ![system](https://forum-static.gl-inet.com/original/3X/7/7/77e28f6cb342ac4bd641bd9a6254595d61b2812a.png) [@system](https://forum.gl-inet.com/u/system)\ **Post date:** [April 16, 2026, 10:14am UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/59 "2026-04-16T10:14:02Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed. ---
**Author:** ![bruce](https://forum-assets.gl-inet.com/user_avatar/forum.gl-inet.com/bruce/32/35649_2.png) [@bruce](https://forum.gl-inet.com/u/bruce)\ **Post date:** [September 2, 2026, 12:19pm UTC](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413/60 "2026-09-02T12:19:18Z")
This problem has been fixed or improved on v4.8.3 and newer firmware versions, please upgrade to the latest firmware. [Previous page](https://forum.gl-inet.com/t/wireguard-connection-watchdog-script-for-luci-gl-inet-router/63413.md?page=2)