Bricked Rbpi - new install on v6 no clients

Expected Behaviour:

Rbpi 4b 1GB with pihole: Core v6.0.6
RBPI desktop 64 bit
Have the static IP set on my unifi by port
Expecting to see traffic and clients and blocking / traffic streaming
Had prior v5 legacy before lost microSD card/died ->
Was working across network

Actual Behaviour:

Able to connect to the portal -> no clients/ no activity / have not loaded any crazy block lists only default. Have full wiped and reinstalled pihole - several times / have tried to roll back versions and been unsuccessful. Clean install with clean pihole install. This RBPI's sole purpose is to support the DNS

I appreciate any and all help. I am just at a loss.

Debug Token:

Replace this text with the debug token provided from running pihole -d

Run from a client, please share the results of:

nslookup pi.hole
nslookup flurry.com
nslookup discourse.pi-hole.net
1 Like

I might be missing something here, but I believe the RPi itself needs to be configured with a static IP. This has been mentioned in other posts, and I am assuming it applies to v6, too.

1 Like
pi@pihole:~ $ nslookup pi.hole
Server:         192.168.1.1
Address:        192.168.1.1#53

** server can't find pi.hole: NXDOMAIN
pi@pihole:~ $ nslookup flurry.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::
pi@pihole:~ $ nslookup discourse.pi-hole.net
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   discourse.pi-hole.net
Address: 157.180.42.82

Just attempted to set a static with: Raspberry Pi set static IP Address for Raspberry Pi OS - > just restarting

Updated log: https://tricorder.pi-hole.net/HzYXY859/

So to your point on: Server can't find pi.hole: NXDOMAIN - I think it is calling the gateway but not the IP associated with the Pi-hole - so I am going to go look at your other reference material regarding the router settings and see if I have an issue there

Just replicated this result with an attempt at resolving. Still getting no clients.

Current log: https://tricorder.pi-hole.net/YDp9JFYA/

From a firewall perspective - I have checked on each of the VLANs and am able to connect Connection to 192.168.1.10 port 53 [tcp/domain] succeeded!

Your debug log shows your router's DHCP server to distribute ist own IPv4 address as local DNS server:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
   Scanning all your interfaces for DHCP servers and IPv6 routers
   
   * Received 305 bytes from 192.168.1.1 @ eth0
     Offered IP address: 192.168.1.10
     (…)
     DHCP options:
      Message type: DHCPOFFER (2)
      (…)
      lease-time: 86400 ( 1d )
      dns-server: 192.168.1.1
      router: 192.168.1.1
      --- end of options ---

Accordingly, your nslookup results show that the client has not been using Pi-hole for DNS, but your router at 192.168.1.1.

While it would be preferred if your router would distribute your Pi-hole host machine's IPv4, this could still be a valid configuration - as long as your router would forward DNS to your Pi-hole exclusively (but note that you won't be able to attribute DNS requests to individual clients in such a configuration).

As resolution for flurry.com returns 0.0.0.0, that would indicate that your router has forwarded the request to a DNS server that blocks flurry.com.

To confirm that flurry.com was indeed blocked by Pi-hole:
How does that request register in Pi-hole?

This is the first time that you mention VLANs.

Since you are able to connect to your Pi-hole host machine on port 53 from each of your VLANs, that would indicate that your router allows inter-VLAN communication, at least to 192.168.1.10.

However, if your router would also distribute its respective own IPv4 as local DNS in each of its VLANs, this wouldn't be relevant:
Clients would talk to your router for DNS, with your router aggregating all your VLANs traffic under its own 192.168.1.1.


Unrelated to your observation, your debug log shows you are trying to block quite a few entries using a URL (starting with https://) rather than a domain, e.g.

*** [ DIAGNOSING ]: Domainlist (0/1 = exact white-/blacklist, 2/3 = regex white-/blacklist)
   id  type enabled group_ids  domain
   --- ---- ------- ---------- --------------------------------------------------------------------
   (…)
   27     3       1 0          ^https?://([A-Za-z0-9.-]*\.)?doubleclick(\.\w{2}\.\w{2}|\.\w{2,4})/

You should either convert those entries to match domains or remove them.

1 Like

Thanks @Bucking_Horn for the thorough response. Sorry havent had a chance to write back. I will do some testing with full DHCP being handed over to the pihole. That definitely makes sense... but kind of confused why.. guessing there was an update or something on the unifi side - but odd its not following its DNS inputs.. I will open a ticket with unifi.

When I can run it directly against the pihole - I see the blockage but yeah if I normally run it - it looks like the unifi adblocking is kicking it off. Wondering if it isnt some combo of adblocking removal (unifi) / establishing that the DNS is working.

I removed a fair amount of the regex filtering and need to do some work to further cut it down. It probably takes overhead and is less accurate overall.

Thank you for all the help. I have some testing to do for sure - but starting to think it was just a dead SD driving an upgraded pihole happening at the same time as maybe a unifi update and DHCP not respecting the DNS input.. More to dig into!

Of course also taking into respect DHCP lease expiration and its impact on timing.

Raspi's have a tendency to crash and corrupt storage on SD cards etc if the power isnt sufficient.
Have a read below:

1 Like

I rechecked all of the DNS references and one VLAN was missing the repoint on default network and then restarted the UniFi gateway and reduced regex - now seeing clients and block % is increasing. Thanks for all the help everyone ! Shout out to @Bucking_Horn

1 Like