Pihole Not Properly Blocking Ads

Hades999 · May 13, 2021, 8:25am

The issue I am facing:
Pihole is not blocking ads properly despite reinstalling multiple times. It will only block ads on the pi itself. The query statistics are also wrong as I have a 35+ client network that is all routing through pihole via my router, so I should be getting at least 50,000-100,000+ queries a day but it only shows queries for my Network Switch as well as my Secondary Pihole(Backup/Load Balancing) server. Network so far works fine in terms of internet connection but both Piholes are not blocking ads whatsoever(Unless the requests are coming from the pihole itself). I have tested both pi devices with Both Raspbian and DietPi and have gotten the same results unfortunately.

Debug Token for 3B+(DietPi-One): 3b0pedmbvl
Debug Token for Zero W(DietPi-Two): zptjczsg1g
Details about my system:
Dietpi-One is a Raspberry Pi 3b+ connected to ethernet also with wifi disabled.
Dietpi-Two is a Raspberry Pi Zero W with wifi disabled and connected to ethernet cable via a dongle.
These are STRICTLY Pihole devices only.
What I have changed since installing Pi-hole:
The only other things I have installed are stubby, and UFW.
From what I understand, according to my pihole debug logs, I have properly opened the ports necessary for Pihole to function. Stubby(For sending my dns over tls, DoT) is also listening on a different port than Pihole. Also Avahi-daemon is installed so I can easily ssh into the piholes as well.(Also Software installs mentioned above are mirrored on both Piholes.) This is also on a clean new install thats about a day old on both devices. Other than that, that is it for my setup.

Bucking_Horn · May 13, 2021, 12:18pm

Pi-hole isn't involved in routing, nor would it require for all traffic being routed its way.

Do you perhaps mean to convey that you assume all your clients are using your Pi-holes for DNS instead?

That would be supported by your 3B+'s debug logs (the one from your Zero is empty):

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 308 bytes from eth0:192.168.1.1
     Offered IP address: 192.168.1.101
     DHCP options:
      Message type: DHCPOFFER (2)
      lease-time: 3600 ( 1h )
      router: 192.168.1.1
      dns-server: 192.168.1.101
      dns-server: 192.168.1.104

This indicates that the DHCP server on Pi-hole's link is correctly distributing your two Pi-hole's IP addresses to DHCP clients.

Given your 1 hour lease time (which is on the low end), all of your clients would have acquired a lease during Pi-hole's 24 hour dashboard period, and thus would be expected to register on one or both of your Pi-holes - provided those clients are on the same link.

But as you state:

Your switch could be splitting your network into multiple segments, and from that description, it would seem it would NAT packets as well (or some other network equipment does that).

Let's have a look at your Pi-hole's statistics and clients.
What's the output of:

echo ">stats >quit" | nc localhost 4711

echo ">top-clients (12) >quit" | nc localhost 4711

I also noticed you are using your (respective?) other Pi-hole as one of your Pi-hole's upstreams:

*** [ DIAGNOSING ]: Setup variables
    PIHOLE_DNS_1=127.0.0.1#1153
    PIHOLE_DNS_2=192.168.1.104#53

This likely isn't related to your issue, but if this were done on both Pi-hole's, this would potentially close a DNS loop.

(Also not related, and probably not significant at all, since your stubby is strictly listening on localhost (and I don't think it's a standard tracks port anyway), but note that 1153 is a port used in smart metering environments.)

Hades999 · May 13, 2021, 10:42pm

Yes. I am very sorry that is exactly what I meant.

If the lease time is on the low end, how long of a lease time would you recommend?

So I have a Modem connected to my Router(Linksys LRT224), which has 5 vlans that are all pushing dns to the piholes, which my switch is connected to handling the vlans, etc. However my piholes are connected directly to the router using the default vlan which has access to all the other devices in their respective vlans.

Pihole 1: echo ">stats >quit" | nc localhost 4711
domains_being_blocked 1147146
dns_queries_today 4841
ads_blocked_today 3
ads_percentage_today 0.061971
unique_domains 82
queries_forwarded 3205
queries_cached 1596
clients_ever_seen 7
unique_clients 6
dns_queries_all_types 4841
reply_NODATA 10
reply_NXDOMAIN 116
reply_CNAME 9
reply_IP 993
privacy_level 0
status enabled

echo ">top-clients (12) >quit" | nc localhost 4711
0 3193 192.168.1.104
1 1446 192.168.1.12
2 196 127.0.0.1 localhost
3 18 192.168.1.101 DietPi-One
4 6 192.168.1.2
5 1 192.168.4.13

Pihole 2:

echo ">stats >quit" | nc localhost 4711
domains_being_blocked 1147144
dns_queries_today 4881
ads_blocked_today 2
ads_percentage_today 0.040975
unique_domains 41
queries_forwarded 3205
queries_cached 1641
clients_ever_seen 6
unique_clients 6
dns_queries_all_types 4881
reply_NODATA 0
reply_NXDOMAIN 10
reply_CNAME 0
reply_IP 0
privacy_level 0
status enabled

echo ">top-clients (12) >quit" | nc localhost 4711
0 3122 192.168.1.101 DietPi-One
1 1485 192.168.1.12
2 216 127.0.0.1 localhost
3 51 192.168.1.104 DietPi-Two
4 7 192.168.2.4
5 6 192.168.1.2

Interesting, I have never actually heard of a dns "loop" can you further explain this?

Ok is there a different port that you would recommend that is better for this situation?

MichaIng · May 14, 2021, 1:35am

If I didn't interpret it wrong, a DNS loop is what you see in you Pi-hole's top client stats. Pi-hole 1 is the by far top client of Pi-hole 2 vice versa. The request may go in a loop, being sent from one Pi-hole to the other and back.

AFAIK multiple upstream DNS entries in Pi-hole don't have a specific priority, so even if stubby is working fine, requests may be sent to the second upstream, hence the other Pi-hole. Requests exit the loop by chance when the first upstream, hence stubby is used.

I don't see how such a partial DNS loop load to no ad blocking, but at least non-blocked requests can be counted multiple times on both Pi-hole's, distorting the statistics. So try to set stubby as only upstream DNS in both Pi-hole's and see if that helps.

Hades999 · May 14, 2021, 4:00am

Thank you for your answer, so far though the statistics, and client numbers are all not where they should be I have a 35+ client network so it should be shown here, right? Or am I missing something? Or should I try another clean install?

Also have removed any other upstreams(except for stubby) on both piholes away.

DanSchaper · May 14, 2021, 5:06am

What does http://pi.hole/admin/network.php show for known network users?

Hades999 · May 14, 2021, 5:40am

Pihole 1:

Pihole 2:

Here they are.

Bucking_Horn · May 14, 2021, 2:56pm

(You would only care about my side note (marked as not related) if you were to run your Pi-hole in such a smart metering environment (and maybe not even then, given its strictly localhost).)

Pi-hole is a DNS forwarder, i.e. it doesn't know anything about public domains a client requests resolution for but whether such a domain should be blocked or not. To retrieve the IP address for a domain, Pi-hole will forward a non-blocked request to one of its upstream DNS servers.
If that DNS server doesn't know the answer either and happens to use Pi-hole as its own upstream, the respective DNS request would get forwarded from one to the other forever, or until timeout.
At worst, this may lead to a total loss of DNS resolution for your network.

In your case, resolution will ultimately succeed in resolving a domain by using stubby, but it would be slower than it could be, as requests are unnecessarily passed between your two Pi-holes.

As MichaIng has correctly observed, this will distort your statistics by artificially inflating your number of overall requests (from your reported stats, by 3,193 and 3,122 resp.), and thus decrease your blocking rate as well, e.g. the actual percentage for your first Pi-hole would be something like (3 / (4,841 - 3,193)) = 0.18% instead of 0.06%.

0.18% would still be a low value, indicating either very well-behaved clients predominantly accessing allowed domains (like Pi-hole itself would, or a router) or a set of DNS requests that already has passed prior filtering.

VLANs would indeed split your network into separate segments.

You'd have to allow and configure inter-VLAN routing for Pi-hole's DNS server to be accessible from each segment/VLAN.

That's not enough for DHCP, though:
A device located in VLAN-5 will broadcast for a DHCP server on its link - and broadcasts are always limited to the same link.

Hence, it could be that your other devices would still use whatever your router distributes for DNS.

To have such a DHCP broadcast reach Pi-hole, it has to be relayed to the segment that your Pi-hole resides in, or your Pi-hole has to have an IP address on that segment, or -if your router would already treat your Pi-hole's host MAC address as present on all segments for being part of its default VLAN- you may just have to change Pi-hole's Interface listening behavior to one of its Listen on all interfaces options.

I'd start experimenting with those latter options to see if this fixes your issue.

Hades999 · May 15, 2021, 5:48am

That was it! For some reason my router bugged out and dhcp was not working properly . I proceeded to upgrade the firmware, reset to factory defaults, set my network up again from scratch, reinstall both piholes' from scratch, as well as make the pihole static ip's outside of the normal DHCP range. And that has seemed to fix the issue. However, this time the piholes' don't seem to be able to resolve by hostname to be able to ssh into the pi without knowledge of IP's. SSH works just fine by using the IP's themselves but not by hostname.

I get this error when trying to ssh: ssh: Could not resolve hostname dietpi-one: Name or service not known.

Bucking_Horn · May 15, 2021, 6:04am

That seems unrelated to your original issue.

Please consider opening a new topic.

Hades999 · May 15, 2021, 8:35am

Oops, it seems so! Thank you for all your help..

system · June 5, 2021, 8:35am

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