Since setting up DietPi with AGH and Unbound, some wifi clients have no internet access (but connected to the AP (Connected, device cannot provide Internet). It only happens on the two VLAN SSIDs that I have pointed to the DietPi for DNS. Wired clients on these VLANs have full internet access working through the AGH/Unbound, and a 3rd VLAN SSID that is not pointed at the DietPi works just fine also. Rebooting the AP will solve the issue temporarily, but it will come back every few days or every day. I thought this issue was on the wireless AP but I found another post that links it to the AGH - the solution there was to change the DNS server in AGH. But mine should be pointed to Unbound so not sure how to proceed.
Does AGH produce any logs about the possibly failing queries?
The first thing I’d check is if the two VLAN SSIDs are capable of reaching the AGH on the DietPi machine. When you launch a DNS request (dig for example), does it show the IP address of the AGH? Can you ping that machine from the VLAN?
I went through some other posts and tried to find commands/logs or what not to help troubleshoot this, but not sure how to get to the AdGuard Home logs or how to see verbose logs. These are from the DietPi machine using PuTTY:
] DietPi-Services | cron active (running) since Tue 2022-06-07 23:15:11 BST; 14h ago
[ OK ] DietPi-Services | dropbear active (running) since Tue 2022-06-07 23:15:08 BST; 14h ago
[ OK ] DietPi-Services | unbound active (running) since Tue 2022-06-07 23:15:10 BST; 14h ago
[ OK ] DietPi-Services | adguardhome active (running) since Tue 2022-06-07 23:15:09 BST; 14h ago
[ INFO ] DietPi-Services | dietpi-vpn inactive (dead)
[ INFO ] DietPi-Services | dietpi-cloudshell inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Tue 2022-06-07 23:15:08 BST; 14h ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Tue 2022-06-07 23:15:08 BST; 14h ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Tue 2022-06-07 23:15:09 BST; 14h ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
dietpi@DietPi:~$ ss -tulpn | grep LISTEN
tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 256 127.0.0.1:5335 0.0.0.0:*
tcp LISTEN 0 256 127.0.0.1:8953 0.0.0.0:*
tcp LISTEN 0 4096 *:8083 *:*
tcp LISTEN 0 4096 *:53 *:*
tcp LISTEN 0 1000 [::]:22 [::]:*
dietpi@DietPi:~$ dig 192.168.42.42 -p 53 google.com
; <<>> DiG 9.16.27-Debian <<>> 192.168.42.42 -p 53 google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42251
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;192.168.42.42. IN A
;; AUTHORITY SECTION:
. 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022060800 1800 900 604800 86400
;; Query time: 100 msec
;; SERVER: 192.168.42.1#53(192.168.42.1)
;; WHEN: Wed Jun 08 13:37:03 BST 2022
;; MSG SIZE rcvd: 117
dietpi@DietPi:~$ sudo journalctl -u unbound.service
-- Journal begins at Tue 2022-06-07 23:15:05 BST, ends at Wed 2022-06-08 13:39:2 2 BST. --
Jun 07 23:15:09 DietPi systemd[1]: Starting Unbound DNS server...
Jun 07 23:15:10 DietPi systemd[1]: Started Unbound DNS server.
Jun 07 23:15:10 DietPi unbound[378]: [378:0] info: start of service (unbound 1.1 3.1).
The problem happened last night between 6-8 PM so if you could tell me how to pull logs from that time frame, I am not sure how to do that.
I was able to get a windows 10 PC wireless connected to one of the affected VLAN SSIDs and run this
C:\Users\css_s>nslookup google.com
Server: dietpi.lan
Address: 192.168.42.42
Non-authoritative answer:
Name: google.com
Addresses: 2607:f8b0:4006:81e::200e
142.251.35.174
For me it doesn’t looks like issues on the DietPi device. All services are up and running. And just restarting the AP, to fix the issue, will not have any effect to AGH + Unbound. Both will continue working as they are. As well you stated that all is running fine for other network devices while it is failing for some special VLAN’s only. Again an indication for some more general network challenges and not for AGH + unbound as they continue working whole time (for other device).
Best would be to perform testing from an effected network client (like this Windows box) as soon as DNS resolution is failing. Once this happen, try to ping the DietPi device and probably other devices as well. Next to this, you could run nslookup on that Windows box to verify DNS resolution.
In parallel you could verify AGH + unbound on DietPi as follow
AGH: dig @127.0.0.1 google.com
Unbound: dig @127.0.0.1 -p 5335 google.com
Important is to use the @ip.of.dns.server. Otherwise DNS query will be done towards DNS server defined on the system network settings. In your case it seems to be 192.168.42.1 according to your dig output.
;; SERVER: 192.168.42.1#53(192.168.42.1)
Just for completeness:
journalctl -u adguardhome
I am still looking into other things on my network to see when this happens again if I can narrow it down. The thing that brought me here, is this reddit thread
The issue only happens on the 2 VLAN SSIDs that are pointed to the DietPi machine, and its not constant maybe once every couple days? Not sure yet on the frequency. Yesterday, updating and restarting the AGH software and restarting the DietPi resolved the issue, but previously restarting the wireless AP had solved the issue. A 3rd VLAN SSID works without issue when this issue is going on, but that isn’t pointed towards DietPi for its Primary DNS Server. Hard-wired clients work fine (and seem to resolve through the DietPi by checking DNSleaktest.com), which is what is throwing me off.
Here is the AGH journal/log:
dietpi@DietPi:~$ sudo journalctl -u adguardhome
-- Journal begins at Tue 2022-06-07 23:15:05 BST, ends at Wed 2022-06-08 17:59:26 BST. --
Jun 07 23:15:09 DietPi systemd[1]: Started AdGuard Home (DietPi).
Jun 07 23:15:10 DietPi AdGuardHome[364]: 2022/06/07 23:15:10.680663 [info] AdGuard Home, version v0.107.7
Jun 07 23:15:10 DietPi AdGuardHome[364]: 2022/06/07 23:15:10.913836 [info] Initializing auth module: /mnt/dietpi_userdata/adguardhome/data/sessions.db
Jun 07 23:15:10 DietPi AdGuardHome[364]: 2022/06/07 23:15:10.920467 [info] auth:initialized. users:1 sessions:2
Jun 07 23:15:10 DietPi AdGuardHome[364]: 2022/06/07 23:15:10.920743 [info] Initialize web module
Jun 07 23:15:12 DietPi AdGuardHome[364]: 2022/06/07 23:15:12.049925 [info] AdGuad Home is available at the following addresses:
Jun 07 23:15:12 DietPi AdGuardHome[364]: 2022/06/07 23:15:12.051648 [info] Go to http://127.0.0.1:8083
Jun 07 23:15:12 DietPi AdGuardHome[364]: 2022/06/07 23:15:12.051767 [info] Go to http://[::1]:8083
Jun 07 23:15:12 DietPi AdGuardHome[364]: 2022/06/07 23:15:12.051817 [info] Go to http://192.168.42.42:8083
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.265532 [info] Starting the DNS proxy server
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.265673 [info] Ratelimit is enabled and set to 20 rps
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.265717 [info] The server is configured to refuse ANY requests
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.265765 [info] DNS cache is enabled
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.265833 [info] MaxGoroutines is set to 300
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.265968 [info] Creating the UDP server socket
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.266795 [info] Listening to udp://[::]:53
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.267040 [info] Creating a TCP server socket
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.267415 [info] Listening to tcp://[::]:53
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.267985 [info] Entering the UDP listener loop on [::]:53
Jun 07 23:15:19 DietPi AdGuardHome[364]: 2022/06/07 23:15:19.268645 [info] Entering the tcp listener loop on [::]:53
This is the startup log from yesterday only. As your restarted your system, previous logs are gone. You need to have a look once the issue occur.