Please follow the below template, it will help us to help you!
If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.
Expected Behaviour:
clients access internet
Actual Behaviour:
clients cannot access internet
Actions
Received new work laptop. I assign static dhcp leases to all known devices, so I added these through the web interface. I forgot to click "save" button after adding lines, so no actual changes were made.
The text at the bottom of the webpage showed a new version was available. I connected to Raspberry Pi 4 that is running this and noticed it also had an update. Tried running "sudo dietpi-update", and that failed because it couldn't access the repository.
refreshed pihole webpage and version had not updated, but since webpage could no longer access internet, it no longer notified me a new version was available. I then noticed none of the clients could access the internet
I then tried rebooting all network devices (raspberry pi, router, cable modem, PCs). no improvement.
Then I contacted Comcast via their webpage to check that there wasnt any network outages, and had them successfully send the signal to reboot the cable modem.
I changed this PC to use a static address could I could direct the DNS servers to use 1.1.1.1 and 1.0.0.1 instead of letting DHCP assign the raspberry pi that pihole is operating on as the dns server and restored internet access on this PC.
I'm very confused by this next test, but the same raspberry pi that is running pihole is also running an Emby server. I can access and play media through the emby server on my phone when i connect wifi to the local network or disable wifi and access it through the cellular data network. Emby can access the internet, but pihole and dietpi-update cannot.
on the pihole web interface, tools - network confirms a SquareD Sense power monitor uses pihole, but this device is continuing to successfully report to the internet. It is the only network device that I did not reboot
I'm not sure which action caused pihole to stop accessing the outside network -- viewing the pihole webpage, viewing my router's webpage, or starting the dietpi-update, but no other events occurred during that time.
Debug Token:
no internet access for the script to upload. I would copy the local log, but the log includes links and user names, and this form wont let new users upload those
I still cant figure out why the network broke today, but disabling the conditionally routing the requests back to the openwrt router and using cloudflare as the upstream dns server returned my access to the internet. I forget what this change from default was trying to accomplish or which webpage toutorial suggested I change that.
As another note. my internet has been getting slower and weirder on all devices for the last several months. It was fine for the first year or two that I had this system setup, but it seems like it was dropping more and more packets. That issue also seems to be resolved due to the above fix. Today, it wasn't 10% drop like I have seen before, but a complete 100% after the moment I launched the configuration webpage. Maybe the incremental issues started after an update of pihole, dietpi, or openwrt?
For instance, last night I was downloading scenery for X-Plane 11 using Ortho4XP and almost half of the downloads failed and the program auto-retried after a few second delay. Since changing the pihole configuration, I haven't seen any errors
How did you configure conditional forwarding? To reverse-resolve local IPs only to to resolve local hostnames as well? However, both should not be responsible for lost packets: The first only affects whether IPs or local hostnames are shown in the Pi-hole UI, the second allows local clients to use local hostnames, but either this works, or this works not, but shouldn't affect external connection packets.
With configuration webpage you mean the Pi-hole dashboard?
Generally Pi-hole should not have any effect on lost packets, stable downloads and such, as it does only the initial DNS resolving, while the remote connection/download is done completely by the client. So if downloads break in the middle, packets get lost and such, it is an unstable network connection, but should have nothing to do with Pi-hole.
DietPi updates are mainly APT package upgrades. Upgrades from a stable/released Debian repository are extremely unlikely to break anything, as they are tested intensively in multiple stages and only security patches and important bug fixes are merged into stable Debian repositories anyway. So if it is not the router/OpenWRT or ISP side network issues, I would check whether a kernel upgrade from the Raspberry Pi repository was applied (which is done usually 1-2 times a month). A new kernel or firmware version does from time to time cause issues, the 2nd latest one broke HDMI CEC e.g. and other issues may occur. So an idea would be to downgrade the kernel to an earlier stage and see if that helps.
But do some regular health checks first, kernel and system logs, to see if there is anything unusual/suspicious present: