Install of Wireguard broke Unbound - NFTables?

The issue I am facing:

In my attempts to get a Wireguard server working, unbound is now refusing inquires and not acting as a custom server. With Pi-hole using a different public upstream DNS, works fine.

Details about my system:

Hyper-V Ubuntu - Win 11 - Fiber Router - Android

What I have changed since installing Pi-hole:

I followed the documentation to install Wireguard. It didn't work at first when going through the first set of steps to install server and add clients. With some troubleshooting, I got a handshake from Android to Wireguard (after enabling port 47111 on ufw and getting my port forwarding on my router correct). Path was ubuntu server to hyper-v switch to router to android.

But no joy on DNS. Android was sending queries to pi-hole, but they were being refused as outside the network.

I noticed the instructions to enable all local traffic on the android. I finally was able to get the android to see the pihole server and admin panel and saw the android was making queries to pihole. But the results were not getting to the android. *I then reread the instructions and realized I missed the some steps (and, yikes, the warning about being hard to debug).

Went back to the missing steps in the guide to make local devices accessible. After a few more rounds of wrangling, I managed to get the android to receive DNS results and get to the Internet. But only when I enabled a public upstream DNS server on the Pi-hole. My custom unbound server did not produce results.

Unbound appear broken locally:

dig pi-hole.net @127.0.0.1 -p 5335 gives the result of REFUSED on the ubuntu VM

taking the wg0 interface down (wg-quick down wg0) restores the functionality of unbound

I'm wondering if the nftables step in setting up the wg0 interface broke unbound? Or did my improper out of order setup do something?

Thanks in advance!

Not sure what the root cause of the problem was, but I was able to solve it by adding an access control for my local network into unbound. Specifically, adding the line access-control: 192.168.1.0/24 allow into the file /etc/unbound/unbound.conf.d/pi-hole.conf and restarting unbound with sudo /etc/init.d/unbound restart.

What I'd suspect is that adding the wg0 interface created an implicit local hop for requests to 127.0.0.1 to source from the local network, which were blocked because they lacked an access control.

If anyone can confirm this behaviour is not specific to my system, I'll propose an update to the 6.0 guide to alert that this change may be needed. For now, I'll add something to Customizing Pi-hole.