Please follow the below template, it will help us to help you!
Expected Behaviour:
Pihole should be able to have blocking enabled without causing AP to crash.
Actual Behaviour:
Pihole operates seemingly for a little bit until it causes my AP to crash. In testing this varies time wise how long until issues arise. This only occurs when blocking is enabled.
I got a few FTL (PTR related) errors, I think a lot of ipv6 because when I ran this I also tried messing with DNS setting on my pi. It is now back on Cloudlflare IPV4 DNS only. There are a few IPV4 examples in there as well including 192.168.0.142 which is my pihole itself? It also attempted to do my OPNSense router on 192.168.0.1. My access point is 192.168.0.2, I noticed in the past it has done it too. The Pi I am using is a Zero2W as well.
Rather new to this all and trying to dive head first into a homelab. Hoping there’s some kind of solution here though that I have been unable to find in my searches to explain for the AP to state No Internet. I will say it does come back online but it then will have a no internet hiccup again.
My gut reaction is that there's a DNS loop somewhere and the AP is dying from running out of memory.
First step would be to make sure that Pi-hole isn't using itself and that the Pi-hole upstream DNS server is not also pointing to Pi-hole. And disabling IPv6 until things are stable will help eliminate a variable.
Edit: Your router is handing out IPv6 addresses and Router Advertisements but it doesn't look like your network has IPv6 connectivity. Can you check https://test-ipv6.com and see if you are even able to use IPv6 on the Internet.
Edit2: Turn off the conditional forwarding as well to test. I see you had to increase the DNS limits which tells me there's a loop somewhere. If you have the router using Pi-hole and then telling Pi-hole to forward some queries to the router then things go off the rails quickly.
In my research I also started to think there is a DNS loop. The router hands out 192.168.0.142 to all dhcp requests for DNS. That’s also where the static IP is set for the Pihole and AP.
IPV6 has been disabled on both the router (I believe) and now the pihole only is set to IPV4 (Cloudflare DNS for now). How do I ensure the Pihole isn’t using itself? I also just removed the conditional formatting.
Here’s a new debug (No internet happened quickly after enabling blocking):
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
Scanning all your interfaces for DHCP servers and IPv6 routers
Timeout: 6 seconds
* Received 310 bytes from 192.168.0.1 @ wlan0
Offered IP address: 192.168.0.142
Server IP address: 192.168.0.1
Relay-agent IP address: N/A
BOOTP server: (empty)
BOOTP file: (empty)
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 192.168.0.1
lease-time: 86400 ( 1d )
renewal-time: 43200 ( 12h )
rebinding-time: 75600 ( 21h )
netmask: 255.255.255.0
broadcast: 192.168.0.255
router: 192.168.0.1
domain-name: "internal"
hostname: "Pihole"
dns-server: 192.168.0.142
--- end of options ---
* Received 72 bytes from fe80::b610:7aff:fe5b:5b34 @ wlan0
Hop limit: undefined
Stateful address conf.: No
Stateful other conf.: No
Mobile home agent: No
Router preference: Medium
Neighbor discovery proxy: No
Router lifetime: 0 s
Reachable time: N/A
Retransmit time: N/A
Unknown option 26: 1a 01 80 00 00 00 00 00
- Prefix: fd6f:464a:2458:eb51::/64
Valid lifetime: 1800 sec
Preferred lifetime: 1800 sec
On-link: Yes
Autonomous address conf.: Yes
- Route: fd8e:726b:3de6:1::/64
Route preference: Medium
Route lifetime: 1800 sec
Received 1 DHCP (IPv4) and 1 RA (IPv6) answers on wlan0
So Pi-hole is still operating on IPv6, there isn't any IPv6 global access though:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] image.ard.de is NOERROR on lo (::1)
[✓] image.ard.de is NOERROR on wlan0 (fd6f:464a:2458:eb51:c0a4:80f1:b2ce:b61a)
[✓] image.ard.de is NOERROR on wlan0 (fe80::3445:a4e:62cf:33ce%wlan0)
[✓] image.ard.de is NOERROR on tailscale0 (fd7a:115c:a1e0::501:767d)
[✓] image.ard.de is NOERROR on tailscale0 (fe80::2801:28fe:bcf8:7e30%tailscale0)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
The Pi-hole log doesn't show anything that says a DNS loop, that's good. And no conditional forwarding.
What is the router? I see you have a static entry for a common self-hosted firewall (same one I run, good choice!) but then also a static entry for a common off the shelf hardware brand that makes routers. (I'm trying to be obtuse so that I don't expose any information that you might not want to be known.)
The router (OPNSense Box 192.168.0.1) is the DHCP server. The AP does in fact have that annoying Smart DHCP. It’s my old router set in AP mode. It is set this way as I have some ubiquiti APs I’m getting next week so I was trying my best to prepare ahead of time.
I’ve tried changing somethings and now also have it pointing to unbound running on OPNSense. Still getting the same error, it actually takes down my whole network including wired now even when I enable.
Not sure if discord or something is allowed, starting to think the issue here is within OPNSense or something and I’m unsure of the cause. I am willing to call or something and figure it out though if it helps.
It does sound like an issue outside of Pi-hole. I'm not sure how DNS could take down the entire network. I can see if the Pi-hole server was using the same IP address as the router and then nobody could reliably talk to the router.
What symptoms are you seeing when the network is down. Can't ping remote Internet like ping google.com or can't ping 8.8.8.8? Can you talk to local clients, ping the Pi-hole IP address?
We generally don't do direct support like that, mostly for liability sadly. There is a Pi-hole community supported Discord channel but I'll have to ask around to see what the channel name is, I've never been on it.
I would appreciate if a link could be found. I changed a few other things and it’s functioning with the occasional hiccup here and there. Working on stabilizing but in a much better spot now at least. Getting 2 Ubiquiti APs next week so that’ll change some things too.