Please follow the below template, it will help us to help you!
Expected Behaviour:
Pihole should work as expected as it did with v4.3.1 (i.e clients connect to dhcp server on pi, get IP addresses) all connections from those clients are logged and either allowed/blocked.
Actual Behaviour:
Now it seems to only show queriers logged that have come from the pi itself (127.0.0.1). I have DHCP turned on on the pi, turned off on my router, This seems to be working as all my clients on the network have internet access but the Pi isn't doing any blocking or registering them as even being connected according to the web admin interface. As I say in 4.3.1 it worked fine but I saw there was an update, so I logged onto the pi via ssh and firstly, did apt-get update and apt-get dist-upgrade, then ran pihole -up. It was after this it seemed to be working but then when I checked it a couple of days later the above issue had arisen. I ran pihole -r which seemed to fix it again, but yet again after a few days it broke again in the same way.
I thought perhaps I had file system corruption so I went and completely wiped the SD card in my pi, reinstalled Raspbian Buster Lite image to it, updated it with apt-get update and dist-upgrade, set that up how I had it setup before, installed pi-hole with the curl command, set that up how I had it set up before, turned on DHCP etc. plugged the pi into my network and powered it up and I had issues right away with the web interface stating the connection was lost and that DNS service wasn't running. So I ran pihole -r via ssh and that fixed that problem but then it just went right back how it was before I reinstalled everything as explained above.
I know it isn't blocking anything because when I look at one of those adblock test pages it says i'm not blocking ads.
From a client that you believe should be using Pi-Hole as DNS server, run the following and see what server replies and the answer. The only DNS server that know the IP of pi.hole is Pi-Hole.
Well I fixed the problem by reverting back to raspbian stretch. Using exact same configurations it all works like a charm right from the get go just like v4.3.1 did with buster before I updated.
I did try reinstalling buster yet again first but without running apt-get update or dist-upgrade and instead installed pihole. That didn't work either. So presumably, this is a issue with 4.3.2 specifically running on buster?
I'm running Buster and earlier today I updated Pihole with pihole -up and it has been updated to 4.3.2.
Since then, Pihole no longer works. I can run pihole -d and it seems to show everything as fine. But, if I point a device purely at Pihole for DNS, nothing gets resolved. I've checked my Query log and since the update to 4.3.2. the only client has been "localhost".
Everything was working fine before the update and nothing else has changed on the Pi. Is there any way of rolling back or trying anything else to test or help fix?
EDIT:
I seem to be getting this a lot in the log now, and it doesn't look like I had it before:
Sep 21 19:50:30 dnsmasq[6254]: query[PTR] 50.0.168.192.in-addr.arpa from 127.0.0.1
Sep 21 19:50:30 dnsmasq[6254]: forwarded 50.0.168.192.in-addr.arpa to 192.168.0.1
Sep 21 19:50:30 dnsmasq[6254]: reply 192.168.0.50 is NXDOMAIN
EDIT 2:
From a device using just pihole, if I try an nslookup, I get DNS request timed out.
NSlookup is successful on the Pi itself though.
A pihole status shows
[✓] DNS service is running
[✓] Pi-hole blocking is Enabled
Please provide some more information on the Buster install that will help us debug the potential issue. The information provided is insufficient for use to be able to look in to anything.
What more can I tell you about it? I downloaded the buster lite image from the official page, released in July. I restored the image to an sd card. I changed the default pi username and the password and gave it a static ip in etc/dhcpcd.conf and enabled auto login and the ssh server and altered the hostname using raspi-config. That was all i did to it in terms of changing default values.
After I Installed pi-hole and set that up with defaults values except i set the dns servers to use cloudflare. Turned dhcp on, and hey presto it worked for over a month until i updated pi-hole to v4.3.2 the other day.
Are you sure it fixed it? It seems running pihole -r fixes the thing for me but only for a short amount of time before it breaks again. Also I reinstalled Buster and pihole again just to see if the interface got changed to tun0 but it didn't; it stayed as eth0 for me the whole time. As I say though I ran pihole -r and that fixed the thing, only for it to break a few hours later.
I've gone back to Stretch, again, and unsurprisingly it has worked flawlessly since.
OK so I've realised some things. Long story short the pihole is working on buster, it's my wifi clients that aren't using the pihole as their dns for some reason. Turned out using my wireless laptop to do the configuration and testing was why it appeared broken; when I was configuring and testing stretch I did it with my wired PC which works with the pihole as expected.
So essentially; pihole works for wired clients only. And I have absolutely no idea why. If I do nslookup pi.hole from my laptop it has the correct ip but gives a server fail error. And yet all wireless clients gain their ips from the pi's dhcp server still, and they all claim their dns is the pihole's IP. I had a look for similar issues on this and couldn't really find much help other than someone else who has the same router as I do (netgear r7800) and it he had this exact same issue pop up when he updated his router's firmware. His solution was to revert to an older firmware.
However the firmware he updated that he thought caused the problem was the same firmware my router has been using since january, but I didn't have this issue until I updated to pihole v4.3.2 at the end of last month. Is it possible 4.3.2 has introduced some sort of incompatibility with my router?
I've fixed it. Downgraded the router firmware to 1.0.2.60 which was the one it was on before January this year. Just like the other person I mentioned it has fixed the issue.
What I will never understand is how the Router, after being updated to 1.0.2.62 in January by myself, went for 9 months give or take a few days without any issue at all, against all odds apparently working fine with the pihole, then decided to suffer the problems related to this latest firmware only and apparently completely coincidentally when I updated pihole. That's one hell of a coincidence.