Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx, apache2 or another reverse proxy, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
Operating System (Family and Version): Pi bookworm
I'm expecting the DNS requests to be forwarded and then returned to the requesting device.
Actual Behaviour:
I received a new router from my ISP and my Pi Hole is no longer functioning. I contacted my ISP and they claim neither they nor their new router is blocking port 53 requests.
All endpoints on my network (including my Pi) can send DNS requests and receive responses via my router (192.168.1.1).
For those same devices, if I route DNS requests to the Pi (or 127.0.0.1 locally), I can see in all those requests in the live Pi Hole query log and it is being forwarded just fine. However, no responses are received.
I would like to confirm that it is not a configuration problem on the Pi Hole side.
I see that the debug tests are not able to get a good reply:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.sensecapturkiye.com is NOERROR on lo (127.0.0.1)
[✓] www.sensecapturkiye.com is NOERROR on eth0 (192.168.1.10)
[✓] No IPv4 address available on wlan0
[✗] Failed to resolve www.sensecapturkiye.com on wg0 (10.39.18.1)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.szlakluxentrix-pl.com is NOERROR on lo (::1)
[✓] No IPv6 address available on eth0
[✓] No IPv6 address available on wlan0
[✓] No IPv6 address available on wg0
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
And the examination of the log files confirm what you found, queries are being forwarded but no reply is being seen.
Can you run a quick dig from the Pi-hole server command line? Something like
dig +notcp google.com @8.8.8.8
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.8.8#53: timed out
; <<>> DiG 9.18.47-1~deb12u1-Debian <<>> +notcp goog@e.com @8.8.8.8
;; global options: +cmd
;; no servers could be reached
dig +trace google.com @8.8.8.8
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.8.8#53: timed out
; <<>> DiG 9.18.47-1~deb12u1-Debian <<>> +trace google.com @8.8.8.8
;; global options: +cmd
;; no servers could be reached
Hmm, I don't see anything wrong with the Pi-hole configuration and the fact that digs that don't use Pi-hole at all are failing sounds like a network issue.
What kind of modem or router are you using? Any firewall software?
How about the output from sudo iptables -S and sudo iptables -L -v -n
It is a Nokia WiFi Beacon 19. I've even tried to turn the security level of the built in firewall from High -> Low -> Off and Attack Protection to Off as well. Same results!
sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-logging-allow
-N ufw-logging-deny
-N ufw-not-local
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-skip-to-policy-forward
-N ufw-skip-to-policy-input
-N ufw-skip-to-policy-output
-N ufw-track-forward
-N ufw-track-input
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-output -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-N ufw-track-output
-N ufw-user-forward
-N ufw-user-input
-N ufw-user-limit
-N ufw-user-limit-accept
-N ufw-user-logging-forward
-N ufw-user-logging-input
-N ufw-user-logging-output
-N ufw-user-output
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-logging-forward -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT] "
-A ufw-before-logging-input -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT] "
-A ufw-before-logging-output -m conntrack --ctstate NEW -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT] "
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW AUDIT INVALID] "
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-forward -s 10.39.18.0/24 -i wg0 -o eth0 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 57359 -j ACCEPT
-A ufw-user-input -s 10.39.18.0/24 -i wg0 -p tcp -m tcp --dport 53 -j ACCEPT
-A ufw-user-input -s 10.39.18.0/24 -i wg0 -p udp -m udp --dport 53 -j ACCEPT
-A ufw-user-input -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -s 192.168.1.0/24 -p udp -m udp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j DROP
-A ufw-user-input -p udp -m udp --dport 22 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 80 -j ACCEPT
-A ufw-user-input -s 192.168.1.0/24 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 53 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 53 -j ACCEPT
-A ufw-user-input -j DROP
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
I've even tried to disable ufw completely and it still has the same problem.
sudo ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] Anywhere on eth0 ALLOW FWD 10.39.18.0/24 on wg0
[ 2] 57359/udp ALLOW IN Anywhere # allow-wireguard
[ 3] 53 on wg0 ALLOW IN 10.39.18.0/24
[ 4] 22 ALLOW IN 192.168.1.0/24
[ 5] 22 DENY IN Anywhere
[ 6] 80 ALLOW IN Anywhere
[ 7] Anywhere ALLOW IN 192.168.1.0/24
[ 8] 53/tcp ALLOW IN Anywhere
[ 9] 53/udp ALLOW IN Anywhere
[10] Anywhere DENY IN Anywhere
[11] 22 (v6) DENY IN Anywhere (v6)
[12] 80 (v6) ALLOW IN Anywhere (v6)
[13] 53/tcp (v6) ALLOW IN Anywhere (v6)
[14] 53/udp (v6) ALLOW IN Anywhere (v6)
[15] Anywhere (v6) DENY IN Anywhere (v6)
[16] 57359/udp (v6) ALLOW IN Anywhere (v6) # allow-wireguard
sudo ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.10 uid 0
sudo ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.10 metric 100
10.39.18.0/24 dev wg0 proto kernel scope link src 10.39.18.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 100
So the results are a bit weird. In the beginning, i was getting 99% packet loss after 192.168.1.1. But after a while, the numbers started to improve. Reset stats and did it a couple more times and no more loss??
That's typically an IP address for a router. I'm guessing that is the Nokia's web interface IP? (BTW, that's a damn sexy WiFi router!).
So the issue looks like it's between the LAN and the router. But what is odd is that you have two different classes for numbering. 192.168.1.x/24 on the LAN and then 10.0.0.0/8. But those two nets/subnets will not directly communicate without a router in between doing the directing of traffic.
Does the router have web-based management or is it locked down to phone app management only?
10/8 and 192/24 require some kind of routing fabric to allow traffic to pass between the two and I'm wondering now if there's something on the router that is allowing internal traffic to exit the lan and pass to the wan but is dropping or blocking the wan DNS replies at the network edge.
It has both web GUI and the phone app. I even tried to install a windows based Pi hole equivalent (Technitium) and that doesn't seem to work either. So I'm suspecting you are right!
If you want to, we can try installing a packet capture package and see if there's anything in the DNS queries that shows where the issue is. I don't know if that will show much if the problem is on the router but at least it's something and we might just get lucky.
I got the router swapped back to the old WiFi 6e router and everything just works now. It was definitely something to do with that Nokia router that was blocking DNS requests. Thank you DanSchaper for helping me troubleshoot.
