Router can not use PiHole, rest of network can

Hello everybody,

I really enjoy using Pi-Hole. Unfortunately since three days I am running in big trouble (while I thought I did not change anything)!

Expected Behaviour:

I am using Pi-Hole as the only DNS server in my network. It shall forward all requests to the Mullvad DNS (193.138.218.74). In my network there are two VLANs, one is using Mullvad VPN, one is not. This setup used to work perfectly since the pi-hole is in the VLAN not using Mullvad, but access is allowed for the other VLAN via a routing rule. I am using OpenWRT on a TPLink router. On there I have chosen the pihole Ip (192.168.100.2 in my case) as forwarding address in DHCP and DNS settings and also as Custom DNS server in Interface "WAN". There is no other DNS configured anywhere.
When I start the router it shall connect to Mullvad VPN, update the time and the dyndns. This requests are send to the pi-hole.

Actual Behaviour:

All this is not possible since three days. The router's syslog is telling me that servers like dynupdate.no-ip.com could not be resolved from the router. The question for this is send to the pi-hole. I see the questions in the pi-hole but it does not to answer. All other members in the network are working fine. In the moment I add "8.8.8.8" in the DNS forwarding option of the router it connects to mullvad and let me surf perfectly. I can delete the option afterwards. Then I see in the OpenWRT syslog that all requests are send to the pi-hole as should and also are aswered. Blocking works too (tested with facebook).
I also experience messages like "Rejected request from RFC1918 IP to public server address" when I try to contact my nextcloud via dyndns name running in the same network. This was working before. I also experience a lot more PTR messages than before in pi-hole log.
I tried many things in OpenWRT and also opend an issue in their forum (https://forum.openwrt.org/t/router-can-not-resolve-dns-requests-but-rest-of-network-can/52591/14) without success. So I went back to an old OpenWRT config which was running perfectly. Same behaviour. Since I see the messages going to the pi-hole I guess the problem might lay there. I upddated two days ago, and also tried repari without success. Can you help me here?

Debug Token:

I could not upload the output to tricorder: "
[✗] There was an error uploading your debug log."
Here it is nevertheless:
Output_PiHole-d.txt (20.5 KB)

Not quite getting your settings ...
First thing that stands out is:


*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the dummy0 interface.

Is that a pseudo interface you created on the raspberry ?

If yes, what is it's purpose ?

Pi-hole IS working properly, considering your settings.

It will not answer to that interface ...
Why didn't you configure it/attach it to eth0 (and set it up as allow all, permit all origins)?

Hi thanks for helping!

dummy0 is nothing I wanted to create. I thought this was there after installing (???).

When I repaired it some hours ago I have chosen eth0.

I set permit all origins since it started to work then with my VLAN config. I can try to disable but as far as I understood this is more a privacy thing which should not be the reason it stopped working, right?

Nope. The istaller does not create (virtual) interfaces (or any for that matter). It was there and something created it...

run another repair and ensure eth0 is selected.

Weeeeelllll... not really.

Pi-hole cannot (out of the box) answer to certain hosts (all of your network) and deny 1 (the router).

The problem lies between the router and pi-hole.

The router might not play well with internal lan IPs as the DNS.

Check for rebind protection or anything/something related to that nature.

Also, you if your router is the DHCP server, you should set the DNS parameter for your DHCP server so that all clients get the DNS parameter from it as your Pi-hole IP. You can keep a public one under your router WAN DNS, as that will NOT be used by the clients.

It will be used only for ntp updates by it (the router).

Alright I did rerun the repair command. Same.

I already tried disabling DNS Rebind Protection but this did not help. Since it worked for 3 months I also would not understand why I would have to disable it now. But I tried again. Same.

The setting of DNS for clients was also realized by me before by having the DNS entries also in the LAN interfaces (for the clients). But in the OpenWRT forum I was told this would not be the right way...

I tried setting the mullvad DNS in WAN interface and the pihole in LAN but still the same. The only way it works is chosing "8.8.8.8" in DHCP and DNS options, wait until everything is started, then remove it. Since this entry seems to be used also for connecting Mullvad VPN when booting and later to contact dyndns instace and updating time, it is obvious that the router can not use the pihole. Is there a setting in pihole avoiding answering the router?

I do believe that your issue(s) are related to OpenWRT as this particular error, relates to port forwarding.

Something is messed up there with the (firewall/routing) rules.

Strange thing since I did not change the OpenWRT config, but updated the pihole...

Would it help to have more information from the router settings for you?

From my standpoint of view (based on your debug log and and also by the overall symptoms where everything BUT the router works), Pi-hole is working as expected.

Unfortunately I am not familiarized with OpenWRT (even though i have some test devices - i never got to work with yet - ) so I don't know how it behaves and how it works at firewall/routing level.

In my limited experience that occurs when the pihole forwards the query to the upstream DNS server, which does not reply.

You could try resolving that name from one of the other hosts in your network.
If it resolves correctly, the pihole should then answer from the cache, including possibly to your router.

That entry will age out , and stop resolving again if your router is the only device that asks for that name. That aging out would account for the "works for a while and then stops for no apparent reason" symptom.

As to the underlying cause I've no clue.

Harry

I did not really understood the problem, but it indeed seems to be a question of wrongly combining DNS options in OpenWRT (since there are some of them).

I now have reset everything (also using ISP default DNS in WAN interfaces) and only have told all lan clients via DHCP option 6 to use the pihole. This works. My Wireguard clients are using directly the pihole via DNS option in the Android Wireguard app. This made it working for me. I can live with the fact, that initial connection, time synch and OpenWRT updates do not run via the pihole since these are connections directly from the router. But maybe I can fix this too in the future. Thanks for helping nevertheless!

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