Pi-hole blocking internet access

Help Community Help
1

I'm a newbie here but have searched through the help pages and tried several suggestions but still having an issue so apologies if I've missed a previous solution.

Expected Behaviour:

I'm running the following hardware and OS to run Pi-hole. Everything seems to be working fine on that end and I can access Pi-hole web interface. While the logs seem to show traffic and I would expect to have full internet, not the case unfortunately. Raspberry Pi is connect via ethernet to the providers router.

-OS: Operating System: Raspbian GNU/Linux 10 (buster)
-Hardware: Raspberry Pi 4 Model B

Actual Behaviour:

Every time I change the DNS on the router to point at Pi-hole the internet goes dead and I cannot access any sites.

Tried all of the following but with no luck, but would appreciate any suggestions.

  • nslookup flurry.com responds with DNS request timed out.
  • I have set the Pi-hole to a static IP and confirmed that is the address in the /etc/dhcpcd.conf
  • I have set "Interface listening behaviour" to "Listen on all interfaces, permit all origins"
  • I have flushed the cache on Windows machine, browser and Pi-hole
  • Gateway address does seem to be set correctly for IPv4, nothing listed for IPv6

Debug Token:

https://tricorder.pi-hole.net/q1yl7dly2w

2

Can anyone provide input to the issue above? I'm scratching my head as to what steps to try next so would be very grateful for any feedback.

3

There are a few irregularities in your log:

Your router distributes itself as DNS server alongside Pi-hole, and your RPi could request an IPv4 address for both your wlan0 as well as your eth0 interface.

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 352 bytes from eth0:192.168.1.1
     Offered IP address: 192.168.1.24
     Server IP address: N/A
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.1.1
      dns-server: 192.168.1.1
      dns-server: 192.168.1.24
      --- end of options ---

   * Received 352 bytes from wlan0:192.168.1.1
     Offered IP address: 192.168.1.11
     Server IP address: N/A
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.1.1
      dns-server: 192.168.1.1
      dns-server: 192.168.1.24
      --- end of options ---
    
   DHCP packets received on interface lo: 0
   DHCP packets received on interface eth0: 1
   DHCP packets received on interface wlan0: 1

Your Pi-hole host machine fails when trying to resolve through a public DNS server:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] adj52.thruport.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] adj52.thruport.com is 0.0.0.0 via Pi-hole (192.168.1.24)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

Also, your Pi-hole fails to resolve the domain for checking supported OS:

*** [ DIAGNOSING ]: Operating system
[i] dig return code:  10
[i] dig response:  dig: couldn't get address for 'ns1.pi-hole.net': failure

Those failures may be explained by something blocking DNS to public IP addresses in your network.
Check whether your RPi's firewall would block outgoing DNS/port 53 connections.

4

Thanks a million for the feedback.

The RPi eth0 is set as the static IP in the router. However is it advisable to turn off the wifi on the RPi?

I'm not sure why the router is distributing itself as a DNS server but perhaps it could be to do with the configuration. The providers router (Vodafone THG3000) has crap wifi and so I disabled the wifi on it and have a Netgear R7000 in AP mode connected to provide wifi. Would that possibly cause the providers router to distribute itself as a DNS?

RPi is plugged into ethernet port of the providers router.

In relation to blocking outgoing DNS/port 53 connections, it looks as though the system is set to accept connections. Should I be implementing all the rules listed in the firewall link you provided or is my current config shown below sufficient?

Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)
5

Yes, if only to reduce complexity (and maybe your power bill).

I cannot know that, but often, router firmware fills in a second DNS slot that way if you do not provide one. If you can configure more than one local DNS server in your router, try to fill every slot with Pi-hole's address.

There are also routers that always add themselves to the list of DNS servers they distribute via DHCP. This can only be fixed by installing a (custom) router firmware.

If that's not an option, you could disable your router's DHCP server and enable Pi-hole's.

Your output (from iptables -L, I guess) suggests you are not blocking any ports. DNS may also be blocked by your router.

Let's try to get a hold on this.
What's the output from the following commands, run from a client:

nslookup pi.hole

nslookup flurry.com

nslookup flurry.com 8.8.8.8
6

Ok I've turned off wifi, albeit temporarily for the moment.

I've filled each of the two DNS slots with Pi-hole address, however ipconfig/all on the client is showing 3 addresses, one of which is still the router.

I'm not sure if the Vodafone router would accept custom firmware. I did some googling and it seems the R7000 does the same thing with stock firmware, but resolved with custom firmware. However I need to investigate if I can connect the R7000 to the fibre point and whether there is a provider username/password to access it.

Might be my only option if all else fails.

Yes

I'm not sure, providers router does have firewall services on it, however I ran the nslookup tests below with it on and with it off temporarily and got the same results for either option as per below.

Server: vodafone.station
Address: 192.168.1.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to vodafone.station timed-out

Same as above

DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

7

Those first two nslookup results are unexpected: They should have returned Pi-hole's IPv4 and 0.0.0.0 respectively, if they would have been handled by your Pi-hole.
Instead, they show that your client is using your router at 192.168.1.1 for DNS, with your router timing out. It's unusual that the router itself also cannot provide resolutions.

What is your router using as its upstream DNS server?

The last nslookup through Google's public DNS at 8.8.8.8 should have returned a bunch of IP addresses.
Instead, it looks as if your router would block outgoing DNS/port 53 to public IPs for that client.

8

Looks like they are using two DNS servers (primary & secondary) belonging to Vodafone themselves. Those servers have a habit of going down which is why I started to look into Pi-hole in the first place.

Other than the router's own firewall services I'm not sure what could be blocking it. I did turn off that firewall temporarily to confirm it wasn't causing the issue. Is there any way I can test to see what's blocking it?

9

So far, we've identified two issues:

i) your router is distributing itself as local DNS server via DHCP, alongside any DNS servers you manually configure
This will allow clients to by-pass Pi-hole via your router's IP.
ii) something is blocking access to public DNS servers (at least to 8.8.8.8)
This will render Pi-hole inoperational when using those public DNS servers as Pi-hole's upstream DNS resolvers.

If i) can't be addressed by a router setting, your only option is to disable your router's DHCP server and switch to Pi-hole (or your other router, provided that doesn't exhibit the same misbehaviour) for DHCP.
This would solve your issue for IPv4.
(I think I recall that your (now expired) debug log was showing you were on a strictly IPv4 connection. Still, note that chances are that your Vodafone router would also advertise its own IP for DNS via IPv6 (if IPv6 would become available).)

With regards to ii), we are seeing consistent failures to resolve DNS via 8.8.8.8 from both your Pi-hole host machine as well as from a client, making it rather unlikely that would be a client specific issue.

This could be caused by
a) a temporary failure of 8.8.8.8
b) dedicated firewall equipment on your network
c) your router
d) your ISP blocking (certain) public DNS in their network

I might add that a quick web research suggests Vodafone to have applied d) in the past on occasions, if temporarily.

No, not directly, unfortunately.

Not every public DNS answers to ping - 8.8.8.8 does.
If ping 8.8.8.8 would succeed while nslookup flurry.com 8.8.8.8 fails, that would make a) unlikely, leaving c) and d) (skipping b), assuming you would have told us already if b) would be in place in your network).

I cannot tell whether switching off your router's firewall would also remove a router configured blockage of public DNS, as I am not familiar with that router at all. Even if I were, most router's only ever expose a subset of cofiguration options via their UI, so it's hard to tell what actually gets applied when you press some buttons.

You could probably try to alternate between a set of public DNS servers, in an attempt to find out whether that blockage affects DNS/port 53 or rather specific public IPs.
Do so by replacing 8.8.8.8 in the nslookup with respective other public IPs like 1.1.1.1, 9.9.9.9 or maybe some less popular ones like 91.239.100.100 (censurfridns.dk) or 80.241.218.68 (dismail.de).
If some of them succeed, consider configuring those as your Pi-hole's upstreams.

10

Yes, it seems to be only IPv4. No options within the router UI to configure IPv6 also it seems. However I believe previous versions of the router software did allow some IPv6 options.

Yes, ping 8.8.8.8 works even when nslookup doesn't. I tried this will the multiple DNS IPs listed below and it is the same with all.

If I'm reading it correctly, it looks like there might be some block on the DNS/port 53.

So ping to 8.8.8.8 gave the the following

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=17ms TTL=117
Reply from 8.8.8.8: bytes=32 time=8ms TTL=117
Reply from 8.8.8.8: bytes=32 time=9ms TTL=117
Reply from 8.8.8.8: bytes=32 time=8ms TTL=117

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 17ms, Average = 10ms

nslookup flurry.com 8.8.8.8 gave the following

Server: dns.google
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to dns.google timed-out

Ping to 9.9.9.9 gave similar to 8.8.8.8 above.

nslookup flurry.com 9.9.9.9 gave similar enough to 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 9.9.9.9

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

However, if I set my DNS settings back to the vodafone router's default settings then nslookup flurry.com 8.8.8.8 gives the following result.

Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: flurry.com
Addresses: 74.6.136.150
98.136.103.23
212.82.100.150

And nslookup flurry.com 9.9.9.9 using router defaults gives.

Server: dns9.quad9.net
Address: 9.9.9.9

Non-authoritative answer:
Name: flurry.com
Addresses: 74.6.136.150
212.82.100.150
98.136.103.23

If I'm not mistaken the above two tests indicate that the ISP is not blocking the public DNS in their network. Not sure if this actually helps or provides more confusion at this point.

There is no dedicated firewall equipment on the network. Router firewall services have been tested in the on and off state, as have the client antivirus firewall services. Same result in all cases whether these firewall services are on or off. However there is other equipment that may be interfering that I need to investigate based on the above result that indicates that the ISP is not blocking the public DNS.

There is a powerline adapter to provide stable hard line connection from router location on ground floor to office on third floor. There is a wifi booster also to boost coverage to third floor.

By way of initial test I connected a laptop directly to the vodafone router via ethernet. I set router to point at Pi-hole and ran nslookup tests as per below. ipconfig/all still shows vodafone router distributing itself as a DNS along with Pi-hole in the other two slots.

nslookup flurry.com

Server: vodafone.station
Address: 192.168.1.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Addresses: 74.6.136.150
98.136.103.23
212.82.100.150

nslookup flurry.com 8.8.8.8

Server: dns.google
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Addresses: 74.6.136.150
98.136.103.23
212.82.100.150

nslookup flurry.com 9.9.9.9

DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 9.9.9.9

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Addresses: 74.6.136.150
98.136.103.23
212.82.100.150

11

I'm referring to our previous findings:

Given your recent results, all in all, I think it's definitely your router that's not playing along nicely, especially with:

You could give the following configuration a try:
1 - set your router's upstream DNS servers to your ISP default
2 - configure your router to distribute Pi-hole as local DNS server
3 - configure Pi-hole to use your router's IP as its only upstream DNS

Verify if this works by using the following nslookups, run from a client (assuming your Pi-hole still resides at 192.168.1.24):

nslookup pi.hole 192.168.1.24

nslookup flurry.com 192.168.1.24

nslookup flurry.com 8.8.8.8

If it does, this would solve item ii) from our findings.

To address i), you'd then have to disable your router's DHCP server and switch over to Pi-hole for DHCP, effectively replacing Pi-hole for your router in step 2.

12

Unfortunately I cannot configure the upstream DNS. I can only configure what the router distributes locally, so I can choose automatic or manual.

image
image2187×1197 184 KB

However assuming the upstream DNS are handled automatically, I've configured the rest as per above.

Results:

Server: raspberrypi
Address: 192.168.1.24

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Name: pi.hole
Address: 192.168.1.24

Results:

Server: raspberrypi
Address: 192.168.1.24

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Addresses: ::
0.0.0.0

Results:

DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

Not sure if this is what was expected or provides any clarity.

Looks like this is the only option given the Vodafone router behaviour.

13

The result of the third nslookup via 8.8.8.8 again suggests that upstream DNS resolution to public DNS servers won't work with your ISP's router.

The two first nslookups return the corect results, but the intermittent timeouts show that something is still amiss. It probably also means your DNS resolution will be slower than it could be, especially when looking up a domain for the first time.

Since it is slow or unreliable DNS resolution that made you look into Pi-hole in the first place, this doesn't seem like a satisfactory solution.

You may try to evade your router's interference by using a DoH/DoT/DNSCrypt-Proxy as Pi-hole's only upstream DNS server.
Those protocols communicate via port 443, 853 or 443/5443/8443, avoiding port 53 altogether.

You'd have to install respective proxy software for the protocol of your choice and then point your Pi-hole to use that proxy as its only upstream (instead of your router).
A guide for the cloudflared DoH proxy is available, but I won't conceal that we've received occassional reports that cloudflared itself is not without resolution issues in some installations. Some of the users encountering such issues switched to DNSCrypt (or unbound, which isn't an option for you due to your router interfering with accessing public DNS).

14

Thanks for the feedback, really appreciate all the help.

It does look like I'm going to have to play around with the configuration to figure out what works best. I might look into which is the easier option between cloudflared DoH or removing the providers router and seeing if the R7000 with custom firmware can be done.

I'm still trying to get my head around what this test was doing. If I'm understanding it correctly, the router was passing DNS requests to Pi-hole. Pi-hole was screening for ads etc. and passing back all "good" DNS requests to the router for it's upstream DNS servers to resolve? Have I got that correct?

In relation to the above, when in it's default state the router has no issue with nslookup flurry.com 8.8.8.8, however when using the configuration above passing through the Pi-hole it does seem to have an issue. Is Pi-hole amending the command in some way by any chance?

I ran that test again just out of curiosity and I got the following result the first two times I ran it.

Server: dns.google
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Addresses: 98.136.103.23
212.82.100.150
74.6.136.150

The next few times I ran it it timed out as per yesterday's result.

Reset the router to default and then back to config above again and nslookup is giving the response above consistently now. Not sure if that helps or confuses things now.

15

No.
That nslookup is sending a DNS request for resolution of flurry.com to the DNS server at 8.8.8.8. Pi-hole is not involved here at all.

Your router is responsible for routing that request to the chosen destination, i.e. from a machine in your network to that public IP.
The expected outcome in this case would be a straight answer, without any time-outs. It is definitely your router (or ISP) that is doing something behind veils here.

That isn't a diagnostic test as much as a configuration attempt to have Pi-hole coexist with your router, despite the latter one's misbehaviour with regard to public DNS servers.

No.
Step 2 asks to distribute Pi-hole as local DNS server.
In that setup, DNS requests would travel from a client as follows:
client -> Pi-hole -> router -> ISP DNS server

Please verify that assumption by consulting your router's documentation sources.

The opposite may be true:
Your router may just allow you to configure its upstream DNS, but not to distribute a local DNS server via DHCP, or you may have overlooked or not found that setting yet.

16

Ok, good to know! I wasn't sure if it would bypass Pi-hole entirely or passthrough through it.

Timeouts are quite unusual so.

Had a bit of a brain freeze here. I forgot the client has the DNS address and for some reason thought it was querying the router for a DNS first.

I can see the upstream Vodafone DNS IPs but cannot change them. Only DNS changes I can make are per the screenshot shared in a post above. When I make changes in that screen the IPs are distributed to the client machines along with the router's own IP.

17

I do not know your router (or the majority of routers out there), so my advice can only be somewhat generic when it comes to configuring it.
You'd have to figure for yourself if and how your router supports it.

Your screenshot would allow multiple interpretations.
An Internet setting would suggest you are configuring upstream DNS, while the Configure the DNS for all devices option suggests otherwise.
Maybe it's doing both, which would definitely by dodgy, since that would close a DNS loop.

Distribution of a local DNS server via DHCP is commonly a LAN/DHCP setting.

You'd really have to consult your router's documentation sources to be sure. :wink:

18

Unfortunately Vodafone documentation is poor on this bar a very basic manual.

I decided to try test this and see if I could figure out which it is. I could be wrong but from tests below it could be that they are upstream DNS.

So I disabled DHCP on the ISP router and enabled it on Pi-hole. Set ISP router to distribute Pi-hole as DNS. Internet traffic returned, however it was intermittent, some sites worked some didn't. Ran the following tests.

C:>nslookup flurry.com
Server: raspberrypi.lan
Address: 192.168.1.24

Name: flurry.com
Addresses: ::
0.0.0.0

C:>nslookup pi.hole 192.168.1.24
Server: raspberrypi.lan
Address: 192.168.1.24

Name: pi.hole
Address: 192.168.1.24

C:>nslookup flurry.com 192.168.1.24
Server: raspberrypi.lan
Address: 192.168.1.24

DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Address: 0.0.0.0

C:>nslookup flurry.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: flurry.com
Addresses: 74.6.136.150
98.136.103.23
212.82.100.150

So out of curiosity I set the ISP router DNS to cloudflare IPs (primary & secondary) and ran the tests again. Internet traffic returned to normal with no issues. I blacklisted facebook on Pi-hole to see if it would be blocked or not. It was blocked.

C:>nslookup flurry.com
Server: raspberrypi.lan
Address: 192.168.1.24

Name: flurry.com
Addresses: ::
0.0.0.0

C:>nslookup pi.hole 192.168.1.24
Server: raspberrypi.lan
Address: 192.168.1.24

Name: pi.hole
Address: 192.168.1.24

C:>nslookup flurry.com 192.168.1.24
Server: raspberrypi.lan
Address: 192.168.1.24

Name: flurry.com
Addresses: ::
0.0.0.0

C:>nslookup flurry.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: flurry.com
Addresses: 74.6.136.150
98.136.103.23
212.82.100.150

Looks like everything is working.

I tried one or two ad block test sites (Test your ad blocker (in a few simple steps) - Ads-blocker.com , Block Adblock — The Test page - Oli Warner) to see if ads are blocked and they are.

Would the above test results indicate that the ISP router DNS settings I can change are in fact upstream?

19

If you disabled DHCP on the ISP router, it is no longer distributing any DNS servers.

20

I think so
(though it's a bit hard to tell with that many intermittent config changes).

We can't be entirely sure about that yet.

The nslookups forced through Pi-hole's IP 192.168.1.24 demonstrate that Pi-hole is blocking as expected - if it is used for DNS, that is.

Use a command like nslookup google.com 192.168.1.24 to establish whether Pi-hole would be able to resolve non-blocked queries through its public upstreams.

Then omit that IP and run all those nslookups from a client.
That will reveal what that client has used as DNS server for that request.

If that's Pi-hole, switching to Pi-hole's DHCP server has worked.
If it's not (yet), then that client may have to acquire its DHCP lease through Pi-hole before it would start using Pi-hole for DNS.