Ignoring query from non-local network - Wireguard on Unifi DMPro SE

The issue I am facing:
When I connect to a Wireguard VPN I have setup on my Unifi DreamMachine Pro SE (subnet and specify my Pihole as the DNS server (on, I can't resolve any Internet hostnames even though I am showing no firewall rules denying access.

If I use another DNS like, the Wireguard client connects to the VPN successfully and is able to resolve names.

Specifically, the error is "ignoring query from non-local network (logged only once)". is the IP of the Wireguard client that is connecting but can't get out to sites on the Internet.

Details about my system:
I have firewall rules allowing all VLANs access to (Pihole).

What I have changed since installing Pi-hole:
I have a working PiVPN setup with Wireguard running on the RPi, trying to run the Unifi-native Wireguard if I can get it running. PiVPN continues to work as expected on the RPi connected to the UDMPro. UDMPro is a new device, was previously running on a different router.

Debug token is https://tricorder.pi-hole.net/3osmfcHL/

Thank you in advance for any advice you can offer.

Pi-hole by default responds to queries from clients in the same subnet (192.168.1.x range in your case). Your queries from 10.5.0.x are classed as "non-local" and are ignored and logged.

If you go to Settings > DNS > Interface settings you can see where this is controlled. Assuming the same interface xxx is used for both networks, you can change it to "Respond only on interface xxx" and scroll down to hit Save. Does that fix it?

Part of the issue turned out to be on the Wireguard server side (pausing and resuming fixed that), and using "Respond only on interface eth0" allows lookups as expected.

Unfortunately, I have two interfaces that normally should be monitored: wlan0 and eth0.

So that means I should select "permit all origins," right? Pihole is behind a firewall, by the way.

I think so, not sure if there's a more elegant way to handle it. As long as only authorised requests can reach your Pi-hole you'll be okay with that.

Thank you, that seems to do the trick for now. I appreciate you walking me through it, @chrislph!

1 Like

Hmm, I don't think that to be related to your issue.

Pi-hole's recommended default Interface setting is 'Allow only local requests'.
This will add the local-service to pihole-FTL's dnsmasq configuration.

With that setting, Pi-hole will consider all subnets as derived from ip addresses as observed on all of its hostnetwork interfaces as local. This seems to match your requirements.

In fact, I co-host a wireguard server on my Pi-hole machine without issues using the default 'Allow only local requests'.

Your debug log shows your Pi-hole to be configured for that same setting:

*** [ DIAGNOSING ]: Setup variables
*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d

-rw-r--r-- 1 root root 1.4K Jan 24 09:29 /etc/dnsmasq.d/01-pihole.conf

It also shows your Wireguard interface wg0 to have been up and usable by Pi-hole:

   4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
       inet scope global wg0
          valid_lft forever preferred_lft
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] www.jnpost-shopping.645874512.xyz is on lo (
[✓] www.jnpost-shopping.645874512.xyz is on eth0 (
[✓] www.jnpost-shopping.645874512.xyz is on wlan0 (
[✓] www.jnpost-shopping.645874512.xyz is on wg0 (
[✓] doubleclick.com is via a remote, public DNS server (

But note that wg0 is carrying an IP address from the range.
And that subnet does not comprise the address you were seeing in your message:

So I'm guessing that the following is was caused your issue originally:

All of the above makes me think that you should be able to switch back your Pi-hole's Interface settings to 'Allow only local requests'.

Your debug log doesn't show any, but you'd probably also want to verify that your Wireguard tooling does not add any interface or listen-address options to any file in your dnsmasq configuration folder, as those would take precedence over local-service and render it completely ineffective.
Something like grep -nR -E 'interface|listen-address' /etc/dnsmasq.* may help with that.

@Bucking_Horn, thanks for that additional info.

Everything you said makes sense, but what I may not have explained adequately is that is my pre-existing PiVPN server running on the same device as Pihole. The "ignoring non-local" messages came up when I tried to set up an additional Wireguard server on my new UDM-Pro SE router, which has built-in Wireguard VPN support, on

At this time, my initial issue has been handled by switching to "Permit all origins." The real problem is that the connection with Wireguard on won't initialize properly in about 50% of the attempts (as in it never shows an established connection on the VPN server side). This is clearly not a Pihole issue, and something I will take up with Unifi support while I continue to use my working PiVPN. :slight_smile:

Of course, I may be going down a rabbit-hole here, because I'm trying to set up additional "locked-down" networks for IoT devices; these encounter the same "ignoring query from non-local network" messages when I am set to "allow only local requests." Just trying to make sure I pick the best and safest option for my particular situation.

Edit: to add, the grep command you gave me returns:


Edit 2:
I'm wondering if I haven't made this far more complicated than it needs to be. My initial use in having my RPi on eth0 and wlan0 was so that it could server my Guest network on a separate subnet from my main LAN, as I couldn't seem to get the old Synology router to communicate from the Guest gateway to the Pihole on my main LAN.

With the new router, that doesn't seem to be an issue. So I'm thinking tell all my subnets to use the main LAN IP for Pihole on eth0. Then I can go back to either "local requests only" or maybe "respond only on interface eth0" if needed. I will experiment with this and see what happens.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.