The issue I am facing:
Pihole not blocking ads as effectively as it was earlier this year (2022).
Ads showing up where they weren't before
Details about my system:
Dual-head pihole setup for redundancy: one pi 0, another pi 4.
Both piholes running directly on the pi's, not in docker containers
both piholes up to date as of this post
What I have changed since installing Pi-hole:
docker containers added to pi 4, all installed a few months after pi
pi 0 is solely for pihole, and does not have other services added to it
(entire setup is about 2 years old)
updates to both the raspberry pis' OS, installed applications, docker containers and piholes have all be regular
Behaviour I've noticed
The ad blocking was so good for 1-2 years to the point where I wasn't even seeing ads in apps or games on my phone (exception: youtube ads, which I learned later Pihole is not intended to block). But over the last few weeks all of the ads I was previously not seeing have come back.
Yet the pihole statistics show that 30% of traffic is blocked, which is in line with what it was when the pihole was working effectively.
I'm wondering if ad servers have changed and caused the piholes to become less effective? Does anyone know if this is the case? Or have i done something wrong with my setup?
We've already asked for this in our template, but here we go: Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Even if you didn't change which lists you use and still visit exactly the same sites, the lists might have changed during the years. The same can be said for the websites (they can change their AD servers).
The number of blocked queries changes based on many factors:
if the adlists you use are updated (modifying which domains are blocked), the numbers change;
if the residents of the house change the sites they visit, the numbers change;
if you always visit the same sites, but those sites change the domains where their ads come from, the numbers change too.
Looks like only the VPN connection is using pi-hole as DNS.
Maybe something is bypassing Pi-hole on your normal connection.
Note that those percentages would apply to the DNS traffic that has been received by one of your two Pi-holes
Since those percent figures have been fairly constant over your usage, but you are seeing ads in places where you haven't seen them before, this may suggest that your Pi-hole could have been by-passed on occasions.
If that would be the case, you probably should see a drop in the number of absolute requests reaching that Pi-hole, and more importantly, if you monitor your Pi-hole's Query Log when a client shows ads unexpectedly, you would note the absence of that respective client from those logs.
From a client that you expect to use Pi-hole for DNS, what's the output of
Been doing some testing on and off the last couple days both on various devices, using both the local wifi and well as accessing my network over the VPN I've got on one of my PI's.
I confirm that accessing over the VPN is indeed blocking ads, as expected (it is not a split tunnel and I setup that VPN connection to be able to access files on some things while not at home).
This being said, the only device currently having "issues" is my own phone. It will receive ads when I'm on wifi but will not see ads in the same applications/pages when on the VPN network.
I just tried to clear the DHCP lease on my pihole to see if that might be doing it (I meant to mention this before: the piholes are both running DHCP because my router will not allow me to route traffic through the piholes otherwise. they do not have conflicting IP address ranges they assign devices)
@yubiuser When I find the offending ad server, how can I make sure it is blocked?
@Bucking_Horn I ran the commands on my laptop (which seems to have ad blocking working) and I got these results in command prompt:
(edit: whie tailing pihole.log I do not notice any entries that pertain to my phone's local IP address there after a few minutes. Now I'm wondering how it's bypassing the piholes (both of them))
The output from the command above shows PI-hole is correctly working and blocking ads for your laptop.
__
This strongly indicated that your phone is bypassing Pi-hole. One reason could be that IPv6 is enables on your network and your phone prefers this over IPv4 and using a IPv6 DNS server other than Pi-hole. Check your phone's setting if it uses IPv6 when connected to your wifi.
Your nslookup results show that Pi-hole has been used, at least for those requests.
Let's try to rule out those IPv6 by-passes that yubiuser mentions.
It seems you've been running those nslookups from a Windows client?
If so, please run the following command on that client:
ipconfig /all
We'd only be interested in the DNS server section of that output.
In particular, look for any IPv6 DNS addresses showing up there - if they would belong to your router, that would allow all IPv6-capable clients to by-pass your Pi-hole at their discretion.
As it happens I have figured out the problem. There is a setting on newer android OS's that disables the DNS used by wifi connections. It's called "private DNS" and this is why it was bypassing the piholes. As soon as I disabled private DNS system wide on the phone, it started using the pi-hole.
I had run into this when searching a hunch online, and this is how it was figured out:
This behaviour also explains why using a VPN -- where a DNS would be enforced -- made the phone use the piholes.
Very frustrating that this was the fix. I'm glad though that in this flurry of activity I was able to update the adlists on my pihole. I should set a reminder to do this a bit more often.
Thank you all... I'll keep an eye on the pihole.log to make sure that the ads I want to be blocked are blocked on all devices connected to the network (I do not have immediate plans to whitelist any device)
(In addition to jfb's comment, the sensitive information in your output are your device MAC address, and probably the DUID if it has been constructed usig your device MAC.)
I'm happy that your issue has been resolved.
But I don't think that the topic you've linked is related to your observation:
This feature was added with Android 9 in August 2018.
Both the specific post you've linked as well as the original topic it was posted under were created in 2017 - so well before Android introduced Private DNS (i.e. DNS-over-TLS (DoT) support).
In particular, VPN usage would not necessarily block access to port 853/DoT and have an impact on DoT.
Android's default setting would be 'Automatic', which has Android try to negotiate DoT with the DNS servers as supplied by the network.
This is usually safe to use - unless your router would propagate an alternate DNS server that would support DoT.
This feature was added with Android 9 in August 2018.
Both the specific post you've linked as well as the original topic it was posted under were created in 2017 - so well before Android introduced Private DNS (i.e. DNS-over-TLS (DoT) support).
Yeah I didn't check the dates on the posts. Thanks for this. But yeah not sure why the VPN bypasses the DoT setting. Either way, turning that setting off worked for me. I would suspect my router too given that it's provided by my ISP, and I can't configure much on it besides the usual stuff they let you play with.
You don't need to redact or obfuscate local IP's. Everybody is using the same pool of local IP's, and they are not visible to the internet.
Thanks. And didn't know MAC addresses were considered sensitive information either. Will keep this in mind for future reference.
Thanks again to both of you and everyone above who helped
