Hi,
I've been running PiHole with unbound for a few years now on a Pi Zero W.
I wanted to use my PiHole on my iPhone so I installed and set up wireguard using this guide from the Pi-Hole docs. I also set up ufw following this post on the forum, as well as this blog post.
After the setup everything is working fine except unbound. I removed and reinstalled unbound following this guide in the Pi-Hole docs.
PiHole works fine if I set my Upstream resolver to Quad9.
I do not think ufw is the problem. If I run sudo ufw disable and reboot the pi the problem remains.
Relevant info:
The output of dig fail01.dnssec.works @127.0.0.1 -p 5335 is
; <<>> DiG 9.16.42-Raspbian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 26082
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sun Sep 03 11:35:11 CEST 2023
;; MSG SIZE rcvd: 12
The output of dig dnssec.works @127.0.0.1 -p 5335 is
; <<>> DiG 9.16.42-Raspbian <<>> dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14779
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sun Sep 03 11:36:19 CEST 2023
;; MSG SIZE rcvd: 12
The output of sudo ufw status is
Status: active
To Action From
-- ------ ----
22/tcp ALLOW 192.168.178.0/24
80/tcp ALLOW 192.168.178.0/24
53/tcp ALLOW 192.168.178.0/24
53/udp ALLOW 192.168.178.0/24
4711/tcp ALLOW 127.0.0.0/8
47111/udp ALLOW Anywhere
53/tcp ALLOW 10.100.0.0/24
53/udp ALLOW 10.100.0.0/24
Anywhere on eth0 ALLOW FWD Anywhere on wg0
Yes for the IP.
No for the port.
The port displayed in the journals is the source port initiated from the client.
And should connect to destination port 5335 where unbound should be listening. unbound will reply to the same source port that was initiated by the client.
But if configured unbound according to the official guide, unbound shouldn't be listening or replying to any IP's besides the ones on the loopback interface named lo:
pi@ph5b:~ $ less /etc/unbound/unbound.conf.d/pi-hole.conf
[..]
interface: 127.0.0.1
port: 5335
pi@ph5b:~ $ sudo ss -nltup sport 5335
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.1:5335 0.0.0.0:* users:(("unbound",pid=19820,fd=3))
tcp LISTEN 0 256 127.0.0.1:5335 0.0.0.0:* users:(("unbound",pid=19820,fd=4))
pi@ph5b:~ $ ip -br link show lo
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
pi@ph5b:~ $ ip -br address show lo
lo UNKNOWN 127.0.0.1/8 ::1/128
This would suggest that either your unbound isn't configured as a recursive resolver, or unbound itself is having difficulties to perform the recursion.
Your unbound.conf* configuration as shared above would rule out the former (and so would your previous successful use of unbound, prior to installing Wireguard).
That may suggest that Wireguard's installation introduced some quirk that prevents unbound to operate correctly.
The most likely source of interference would be your firewall rules.
As stopping your ufw firewall did not seem to affect your observation, it could be the PostUp/PreDown rules for Wireguard that may be causing you troubles, especially since you seem to have been mixing information from Digital Ocean's and Pi-hole's own
recommendations for setting up Wireguard. In addition, both of those would manipulate iptables/nft directly, and I'm unsure how that would impact a firewall frontend like ufw.
This does not seem like a Pi-hole issue, but if you'd share your Wireguard's PostUp/PreDown sections, I see if I can spot something obvious.