DDNS throwing error when VPN Client is enabled

MowMdown · July 15, 2024, 5:42pm

Device Model:

GL-MT6000 Flint2

Firmware version:

4.6.2

Screenshots:

Network topology diagram:

ISP Modem <---> Flint2 <----> Eero 6+ in bridge mode <---> Wifi Devices

Problem Description:

I've spent a whole day searching forums and reddit posts but have been unable to determine if this is an issue or just an incompatibility.

When I enable a VPN Client using "Domain Based VPN Policies" Set to only use the VPN for the whitelisted domains (Ex: Only use VPN for google.com) running a DDNS test fails with the error.

"The DNS record for this DDNS domain could not be found by the DNS server. Please check the Internet connection of the device"

Upon immediately disabling the VPN client profile, running the DDNS test works without any errors.

Services from GL.iNet Use VPN is set to DISABLED.

The only other thing I've enabled is to use AdGuard for DNS filtering.

System Logs:

Summary

Mon Jul 15 15:56:29 2024 kern.info kernel: [ 814.808440] hook is going to be disabled !
Mon Jul 15 15:56:29 2024 daemon.err rmmod: unloading the module failed
Mon Jul 15 15:56:44 2024 daemon.info dnsmasq[5180]: exiting on receipt of SIGTERM
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: Connected to system UBus
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: started, version 2.85 cachesize 150
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: DNS service limited to local subnets
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC no-ID loop-detect inotify dumpfile
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: UBus support enabled: connected to system bus
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq-dhcp[14860]: DHCP, IP range 10.0.0.100 -- 10.0.0.249, lease time 12h
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain test
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain onion
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain localhost
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain local
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain invalid
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain bind
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using nameserver 127.0.0.1#1653 for domain google.com
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using nameserver 127.0.0.1#1653 for domain reddit.com
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using nameserver 127.0.0.1#3053
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: using only locally-known addresses for domain lan
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: read /etc/hosts - 4 addresses
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[14860]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq-dhcp[14860]: read /etc/ethers - 0 addresses
Mon Jul 15 15:56:45 2024 daemon.notice netifd: Interface 'wgclient' is setting up now
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 user.warn : skip line without '=' Default
Mon Jul 15 15:56:45 2024 user.warn : skip line without '='
Mon Jul 15 15:56:45 2024 daemon.notice netifd: Network device 'wgclient' link is up
Mon Jul 15 15:56:45 2024 daemon.notice netifd: Interface 'wgclient' is now up
Mon Jul 15 15:56:45 2024 user.notice wgclient-up: env value:T_J_V_ifname=string J_V_address_external=1 USER=root ifname=wgclient ACTION=KEYPAIR-CREATED N_J_V_address_external=address-external SHLVL=2 J_V_keep=1 HOME=/ HOTPLUG_TYPE=wireguard T_J_V_interface=string J_V_ifname=wgclient T_J_V_link_up=boolean LOGNAME=root DEVICENAME= T_J_V_action=int TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin CONFIG_LIST_STATE= J_V_interface=wgclient K_J_V= action ifname link_up address_external keep interface J_V_link_up=1 J_V_action=0 T_J_V_address_external=boolean N_J_V_link_up=link-up T_J_V_keep=boolean PWD=/ JSON_CUR=J_V CONFIG_SECTIONS=global AzireVPN Mullvad FromApp group_6167 group_5485 group_8452 group_737 peer_517 CONFIG_cfg030f15_ports=
Mon Jul 15 15:56:45 2024 user.notice firewall: Reloading firewall due to ifup of wgclient (wgclient)
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15590]: Connected to system UBus
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: started, version 2.85 cache disabled
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: DNS service limited to local subnets
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC no-ID loop-detect inotify dumpfile
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: UBus support enabled: connected to system bus
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq-dhcp[15592]: DHCP, IP range 192.168.8.100 -- 192.168.8.249, lease time 12h
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain test
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain onion
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain localhost
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain local
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain invalid
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain bind
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using only locally-known addresses for domain lan
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: using nameserver 127.0.0.1#3053
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: read /etc/hosts - 4 addresses
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq[15592]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Mon Jul 15 15:56:45 2024 daemon.info dnsmasq-dhcp[15592]: read /etc/ethers - 0 addresses
Mon Jul 15 15:56:45 2024 authpriv.notice sudo: root : PWD=/ ; USER=root ; GROUP=nonevpn ; COMMAND=/usr/lib/gl_ddns/dynamic_dns_updater.sh -- stop
Mon Jul 15 15:56:46 2024 user.notice ddns-scripts[7783]: glddns: PID '7783' terminated by 'SIGTERM' at 2024-07-15 15:56
Mon Jul 15 15:56:47 2024 authpriv.notice sudo: root : PWD=/ ; USER=root ; GROUP=nonevpn ; COMMAND=/usr/lib/gl_ddns/dynamic_dns_updater.sh -- start
Mon Jul 15 15:56:47 2024 user.notice ddns-scripts[15924]: ddns: PID '15924' started at 2024-07-15 15:56
Mon Jul 15 15:56:47 2024 user.warn ddns-scripts[15924]: ddns: Service section disabled! - TERMINATE
Mon Jul 15 15:56:47 2024 user.notice ddns-scripts[15927]: glddns: PID '15927' started at 2024-07-15 15:56
Mon Jul 15 15:56:47 2024 user.warn ddns-scripts[15924]: ddns: PID '15924' exit WITH ERROR '1' at 2024-07-15 15:56
Mon Jul 15 15:56:47 2024 user.warn ddns-scripts[15927]: glddns: NO valid IP found

admon · July 15, 2024, 6:37pm

Do you have a real external IP or some weird CGNAT like 192.168.x.x?

MowMdown · July 15, 2024, 7:17pm

It's a standard real external IP, nothing weird going on.

admon · July 15, 2024, 7:33pm

Could be some issue within the firmware, what do you think, @bruce?

MowMdown · July 16, 2024, 12:27am

I just noticed when the VPN client is active and I run an 'nslookup device.glddns.com' from the router itself, it cannot resolve and times out, as soon as it's disabled, it works no problem and gives me my public IP.

Edit: If I run 'nslookup device.glddns.com 127.0.0.1' it also resolves no problems.

Something with losing DNS when VPN is active is what is seems to be causing this.

2nd Edit: It also seems that disabling AdGuard and re-enabling adguard also fixes this issue. However rebooting the router or turning off the VPN and turning the VPN back on reintroduces the issue.

j2zero · July 17, 2024, 4:48am

@teleney Sounds like it could be the same bug as I experienced?

bruce · July 17, 2024, 6:21am

Clip_2024-07-17_14-19-34

Although ddns process logs print 'NO valid IP found', but after a while, it also achieves to upload the WAN IP.

Anyway, the syslog returns the ddns service probably have issue, will submit to R&D to check.

BTW, may I know if the OpenVPN client with policy also like this? As I did not reproduce this situation, please test it and let me know, thanks in advance.

teleney · July 17, 2024, 6:59am

Try disabling adguard home.

MowMdown · July 17, 2024, 1:04pm

BBTW, may I know if the OpenVPN client with policy also like this? As I did not reproduce this situation, please test it and let me know, thanks in advance.

Both were like this, yes.

It seems almost like a race condition between adguard firewall rules and VPN firewall rules depending on which service is enabled first and which one is second?

Because turning one or the other off seems to cause it to work again but it doesn't matter which one is turned off.

teleney · July 18, 2024, 6:06am

Yes, it looks like the DNS packets are sent from the VPN interface via AdGuard.

bruce · August 23, 2024, 4:20am

@MowMdown

Hi, sorry if disturbing you.

May I know how about this issue now in your router?
Since R&D could not reproduce this issue for now, and me too, if you still trouble about this issue, please reply to us, we would like to remote to your router to check it.

MowMdown · August 23, 2024, 11:50am

It somewhat seems to have cleared itself up, but if I find a guaranteed way to reproduce it I’ll reach back out.

Thanks for the help

pannal · September 2, 2024, 1:47am

Similar issue here. Some details:

Router: Beryl AX
Adguard enabled (upstream is unbound at 1053; changing that doesn't change the behavior)
VPN via Wireguard-client, with DNS entries and MTU set (1384) in Config (possible culprits?)
"AdGuard Home Handle Client Requests" enabled
"Allow Custom DNS to Override VPN DNS" enabled (toggling doesn't change behavior)
WAN use peer dns (default; but changed before, maybe important?)
WAN via physical RJ45
Latest stable
No DDNS (so not the same as the thread starter, but the same as the consecutive post's issues)

nslookup and opkg update via SSH on the router doesn't work (resolv.conf contains the upstream DNS from the LAN I'm at), nslookup of the same domains with 127.0.0.1 as the resolver works.

Disabling peer DNS and adding 8.8.8.8 on the WAN device as custom DNS for example works, but probably has bad implications for captive portals.

Additionally:

Disabling AGH and it works again, with the below resolv.conf
Re-enabling AGH and it still works, but resolv.conf still looks like this:

search lan
nameserver 127.0.0.1
nameserver ::1

Before it looked like this:

# Interface wan
nameserver 194.168.4.100
nameserver 194.168.8.100

Which are the peer DNSs, which I'd expect to be what should be in here for the router itself.

Restarting the device uses the peer DNS again in resolv.conf (can't resolve any DNS again).

Seems like we're looking at a timing/order-of-execution issue here, as suspected by the previous user. Not sure which resolv.conf is the correct one, but something is wrong here. Peer DNS should be the default for the router, exempted from all LAN firewall/forwarding handling, shouldn't it? And it should work with my settings. Peer DNS should always work for the router itself and its zone. I guess some firewall rule/setting is preventing it from working.

Edit: edited with more info after being approved

Edit 2: tl;dr: with this configuration the router can't resolve hosts and thus opkg doesn't work

pannal · September 2, 2024, 2:53pm

FYI: @bruce I'll be using this exact setup for another week, so if you need further details/logs, or me to test things, please let me know.

Pro4TLZZ · September 2, 2024, 10:03pm

If you do sudo -g nonevpn nslookup domain.com does that work?

I run my ddns config in a different way to avoid the exact nslookup failure when VPN is active.

Without an additional restart of the ddns service I get fails on the nslookup.

 225427 ERROR : BusyBox nslookup error: '1'
 225427       : ;; connection timed out; no servers could be reached

After the service restart the ddns works fine.

Here is the config.

root@GL-MT6000:~# cat /etc/init.d/ddns
#!/bin/sh /etc/rc.common
START=95
STOP=10

PROG=/usr/lib/ddns/dynamic_dns_updater.sh
bypassvpn=`uci -q get vpnpolicy.global.service_policy`

if [ $bypassvpn = 1 ];then
        PROG="sudo -g nonevpn /usr/lib/ddns/dynamic_dns_updater.sh"
else
        PROG=/usr/lib/ddns/dynamic_dns_updater.sh
fi

boot() {
        return 0
}

reload() {
        $PROG -- reload
        return 0
}

restart() {
        $PROG -- reload
        sleep 10 # give time to shutdown
        $PROG -- start
}

start() {
        $PROG -- start
}

stop() {
        $PROG -- stop
        return 0
}

root@GL-MT6000:~# cat /etc/config/ddns

config ddns 'global'
        option ddns_dateformat '%F %R'
        option ddns_loglines '250'
        option ddns_rundir '/var/run/ddns'
        option ddns_logdir '/var/log/ddns'
        option cacert '/etc/ssl/certs'

and then finally here in startup the sleep is a crucial step, I'm not sure why it's needed. nslookup should work fine after internet and vpn connect but I don't know.

sleep 30 && /etc/init.d/ddns restart

pannal · September 3, 2024, 12:41am

Thanks for the suggestions, I'll try that. Keep in mind, my issue isn't the same as the OPs, but somewhat related. Not using DDNS. If nonevpn fixes this, there's still the question of the wonky issue that the router's DNS resolver changes depending on whether it's a fresh boot or if you've restarted adguard.

teleney · September 4, 2024, 2:21am

Hi, you got the point. I think this is indeed an issue.
I also realized this problem a few weeks ago. It will cause the router's own dns to always be forwarded from dnsmasq. From my investigation, it is because when we set the dns-related configuration, the order of restarting the service does not meet the expectations of dnsmasq.
Now I have made some changes. After the modification, when custom DNS is used instead of peer DNS, the content of the /tmp/resolv.conf will be restored to peer DNS.
What do you think about this?

teleney · September 4, 2024, 2:31am

I think this may be caused by the peer DNS being unable to resolve these domain names.

teleney · September 4, 2024, 2:57am

Do you want the router's own DNS to always use dnsmasq?
Try adding content like the following image to /etc/config/dhcp, then restart dnsmasq. The content of /tmp/resolv.conf will always be 127.0.0.1.

pannal · September 4, 2024, 11:56am

Honestly I have no idea. I'm expecting the router to do the right thing. I don't know what the implications would be if the router itself didn't use the advertised DNS, with regards to captive portals.

I tried resolving google.com, pretty sure the DNS resolves that (the environment I'm currently in doesn't have a captive portal or any restrictions, as it isn't a hotel but an apartment).

I have just updated to the latest RC (4.6.4-release2), which was released yesterday, and I've seen changes regarding this topic. I'll investigate.