Pi-Hole and Google Nest Wifi brings my modem down

Help
1

Expected Behaviour:

I have a Raspberry Pi 5 (8GB) running the latest Raspbian OS and connected the Google Nest Wifi Router via Ethernet. The router is connected to my cable modem which is setup as a bridge via Ethernet cable as well. On my wifi network there’s one Nest Mesh Node and a few Google home speakers and one display as well as a couple of TV. The Raspberyy Pi has a static IP and that IP is reserved on the router. The raspberry pi is used for Plex (no transcoding at all so no resource congestion happening) as well as PiVPN for one client.

I have tried setting pihole as the upstream dns for my router as well as tried setting it up as the dhcp server and the dns server while leaving the router upstream server as default. (Since I can’t disable the Google wifi dhcp server, I limited the pool to the raspberry pi IP and let pihole handle the rest.

Actual Behaviour:

The issue is that at least once every day and sometimes twice a day I get Pi-Hole errors (rate limited or dnsmasq concurrent requests) followed by the wifi mesh node losing connection then the modem craps out. The only to fix it is to restart the modem, router and raspberry pi.

Debug Token:

https://tricorder.pi-hole.net/y9v1yKiV/

2

It's a bit difficult to give clean advice, as your debug log has remnants of those different approaches here and there.

Currently, it shows your router is distributing itself as local DNS server:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 300 bytes from eth0:192.168.86.1
     Offered IP address: 192.168.86.30
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 192.168.86.1
      dns-server: 192.168.86.1
      --- end of options ---

That would be a valid configuration if you'd pointed your router to use Pi-hole as its only upstream, but you won't be able to attribute queries to individual clients and take advantage of Pi-hole's client-specific filtering in such a scenario, as your router would aggregate your network's DNS requests and appear as Pi-hole's only client.

The latter would also contribute to your rate limit observation.
If you would decide to keep using Pi-hole as your router's only upstream, you should consider to readjust Pi-hole's rate limit.
I can see from your debug log that you've already upped it a little, but given your number of clients, that may not be enough. If n would be the number of clients, I'd probably set it to (n ÷ 2 *1000), so e.g. RATE_LIMIT=4000/60 for 8 clients.

You should also disable Pi-hole's Conditional Forwarding in that scenario, as that would close a partial DNS loop, which is quite likely to trigger the max concurrent warning in turn.

But your debug log also shows that you've some client-specific filtering in place, so you should really configure your router to distribute your Pi-hole host machine's IP as local DNS server.

Likely unrelated to your issue, you have disabled Pi-hole for devices using Apple's iCloud Private Relay, and enabled extensive query debugging:

-rw-rw-r-- 1 pihole root 201 Nov  3 12:03 /etc/pihole/pihole-FTL.conf
   BLOCK_ICLOUD_PR=false
   DEBUG_QUERIES=true

You should consider to remove those lines, to have your Apple devices filtered by Pi-hole, and to avoid excessive log file growth.

3

That’s exactly what’s happening now. Google Nest routers are very limited in terms of configurations. As for the clients that I need specific rules for, I configure their DNS manually. Pi-Hole does recognize the PiVPN clients either way though.

I have Conditional Forwarding disabled, did the log tell you otherwise? I figured it’s useless for my current network setup anyway as I can only see the router IP address if I’m not already using the Pi-Hole DCHP server.

Thank you so much for your help, I’ll keep an eye on the setup for the next 24 hours.

4

I’m happy to report that it has been more than 36 hours and the network has been stable so far.

One thing that I’ve noticed is that the DNS Interface Settings sometimes gets reset to permit only local requests, I’m not sure yet if it’s related to PiVPN settings change or when I restart my Pi. I’ll do more troubleshooting later but it appears that this is related. Looking at the logs, my modem pings random urls once every minute apparently to know if the connection is still alive.

5

Yes, as VPN configurations would also explicitly point clients to use Pi-hole for DNS.

No, but it showed that you had enabled it at some time, and given your reported trials, it may well have contributed to your observations in the way explained above. :wink:

I'm glad it's working for you now.
What settings did you actually change?

6

:pensive: looks like I should do a clean install at some point to clean up all these bits and pieces.

I increased the rate-limiting limit to 12000 and made sure that permit all origins is active in interface settings, as well as deleted (commented out) the debug line DEBUG_QUERIES=true.

I’m a little surprised the rate limit worked though as if that’s the case then why did it fail when Pi-Hole was setup as the DHCP server. I have a suspicion that the persistency of the interface settings contributes to this issue too. What do you think?

7

Rate limit is enforced per client, so it is much less likely to kick in when a DHCP server is distributing Pi-hole as local DNS server to be used by DHCP clients.
Instead of a rate limit, you may have seen a max concurrent warning then, probably due to closing a DNS loop of sorts.

1 Like
8

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

9

Posting here as the original help post was auto-closed.
(Mod Note: Post moved to original topic)

After weeks of troubleshooting I figured out that the root cause was a couple of cheap Gosund branded smart plugs. Switching the DNS while they were online probably was not propagated to the smart plugs properly and as a result a DNS loop occurred and subsequently thousands of requests per second crashed my router.

The solution was simple. I took the plugs offline, made my changes on the router and PiHole, waited for 24 hours to ensure all DHCP leases are assigned by PiHole then plugged them back in.

The plugs are built on the Tuya Smart platform. Hope this posts helps anyone else and they won’t have to pull their hair out while tracing the culprit device.

Thanks to @Bucking_Horn for your help.

2 Likes