Pi.hole/admin not accessible when DHCP is enabled. Pi Hole installed from diet pi

[wasabi-dog]

The issue I am facing:
My router's DHCP server is disabled, I have pointed my router's DNS address to PiHole's IP
A static IP has been set for my PiHole
PiHole has DHCP enabled and has IP range from 50 to 255
My device network successfully get new IP address with PiHole's DHCP range
Only some requests from my IoT devices passes through PiHole. But most of my devices on my network doesn't.

I also cannot access PiHole Admin from pi.hole/admin. I have to use {IP address}/admin even though my current device has an address within the range of PiHole's DHCP.

Also tried all kind of dnsflush, but it still doesn't work.

Any help is much appreciated.

Details about my system:
Raspberry Pi 3
DietPi OS

What I have changed since installing Pi-hole:
It is a fresh install, I used teleporter to get my last configs. They look fine.

[rdwebdesign]

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

[REz]

It seems like your router and pi-hole configuration are ok, since all devices on your network get the right ips and also your IoT devices query pi-hole's DNS.
I'm going to ask a dumb question, but I have to. Have you checked your devices configuration for forced DNS resolver?
If you can't access pi.hole/admin but you can access it by his ip address it seems your devices isn't using pi.hole dns and since pi-hole dhcp automatically set itself as the default dns the only reason why you shouldn't be able to reach him is because you set a custom dns on your devices...
Is it possible? Which devices doesn't query pi-hole?

[wasabi-dog]

Thanks for the recommendations. After I went through my logs, I found out what's causing my problems and why it isn't documented anywhere on Pi Hole documentation.

Since I used Diet Pi to install my Pi Hole and not curl directly from git, there are a few custom configs from Diet Pi.

First one being the wrong (or should I say different) type of web server is recommended.I was given the choice of Apache, Nginx, and lighttpd. Oddly enough, the default one is lighttpd (if none is chosen), but recommended one is Apache.

Since I have custom Apache config on my pi. It created a conflict with domain resolution which made the page inaccessible.

Second problem is another config from diet pi side. There is another recommended protection from diet pi side which block public access to Pi Hole. This is a thread from diet pi which explains the issue. Quite straightforward once you see it. But it isn't well documented.

Whoever have similar problem after Pi Hole is installed from diet pi. I recommend simply reinstall using lighttpd. Unless you have a specific reason to use Apache or Nginx and you know how to configure it.

I hope this help whoever stumble on this issue.

[MichaIng]

@wasabi-dog

Since I have custom Apache config on my pi. It created a conflict with domain resolution which made the page inaccessible.

The webserver config has no effect on DNS resolution of pi.hole on your clients at all. This is entirely a question of whether clients use Pi-hole to resolve DNS names, or something else. My guess is DoH, being widely available, maybe enabled by default in some cases, in browser and even on OS level in the meantime (Windows 11 at least). It overrides the DHCP-provided DNS.

@wasabi-dog

Second problem is another config from diet pi side. There is another recommended protection from diet pi side which block public access to Pi Hole. This is a thread from diet pi which explains the issue. Quite straightforward once you see it. But it isn't well documented.

This is not enabled/blocked by default, but needs to be selected manually from this dialogue:

│ In order to increase security, it is recommended to block public access to the Pi-hole admin panel, so that only     │
│ connections from within your LAN or via VPN are possible.                                                            │
│                                                                                                                      │
│ Practically this means to deny access from all IPs that do not match the reserved loopback and LAN ranges:           │
│  - 127.*                                                                                                             │
│  - 192.168.*                                                                                                         │
│  - 10.*                                                                                                              │
│  - 172.16.* - 172.31.*                                                                                               │
│  - ::1                                                                                                               │
│  - fe80:* - febf:* (LLAs)                                                                                            │
│  - fc00:* - fdff:* (ULAs)                                                                                            │
│                                                                                                                      │
│ Note that if you use IPv6 and hostnames within your LAN, but no ULAs (Unique Local Addresses), this might also block │
│ accesses from within your LAN, as then GUAs (Global Unicast Addresses) are used, which cannot be distinguished from  │
│ public accesses.                                                                                                     │
│                                                                                                                      │
│ You can always enable/disable this later using the commands:                                                         │
│  - <webserver_depending_command>                                                                                     │
│  -  webserver_depending_command>                                                                                     │
│                                                                                                                      │
│ Do you want to block public access to the admin panel now?                                     

with this being the relevant note:

Note that if you use IPv6 and hostnames within your LAN, but no ULAs (Unique Local Addresses), this might also block accesses from within your LAN, as then GUAs (Global Unicast Addresses) are used, which cannot be distinguished from public accesses.

But I agree this is probably not clear enough/too much text etc, and you are not the only one enabling the block, and then recognising that pi.hole does not work. However, it cannot explain why "only some" of your IoT devices pass trough Pi-hole, as DNS requests can only be done with IP addresses, and this block affects the websever/web UI only, no DNS traffic.

@wasabi-dog

Whoever have similar problem after Pi Hole is installed from diet pi. I recommend simply reinstall using lighttpd. Unless you have a specific reason to use Apache or Nginx and you know how to configure it.

Again, the webserver question is not related to bypassing DNS requests, and choosing Lighttpd does not bypass the dialogue where you can enable the public web UI access lock. We somehow need to rephrase the dialogue to motivate users not doing the block, unless they understand the possible implication with pi.hole (any hostname for the Pi-hole server system) when doing so. Or we just remove that option, and leave it to the admin. As DNS is such a sensitive thing for security of the whole local network, we'd then at least replace the dialogue with another one, recommending to switching the Pi-hole web UI password ASAP.

[wasabi-dog]

Thanks for the reply @MichaIng and thanks for developing and maintaining dietpi.

The problem reappeared after a few days and I am now really clueless.

I retried to do a fresh install using curl -sSL https://install.pi-hole.net | bash and kept all settings default. I still have trouble accessing http://pi.hole/admin/

@rdwebdesign Here is the debug token 0XTLIAtx

I still cannot see anything out of place. It is configured as the only dhcp server on my network.

[rdwebdesign]

As MichaIng explained, the web server configuration has nothing to do with DNS settings.

This seems to be a local issue in the browser, the OS used to access the web interface or on your router.

@wasabi-dog

Here is the debug token 0XTLIAtx

Your debug log doesn't show any issues, but DietPi is configured to delete logs every hour, so some logs are empty:

• /var/log/lighttpd/error-pihole.log and
• /var/log/pihole/FTL.log

We need to make sure your machine is really using Pi-hole as DNS server and we need to check if it is able to resolve pi.hole domain.

From a terminal window (or command line prompt) on your computer what is the full output of these commands?

nslookup pi.hole
nslookup pi.hole 192.168.0.12

[wasabi-dog]

> nslookup pi.hole
Server:  UnKnown
Address:  2607:fa48:2:f000::1

*** UnKnown can't find pi.hole: Non-existent domain

> nslookup pi.hole 192.168.0.12
Server:  pi.hole
Address:  192.168.0.12

Name:    pi.hole
Addresses:  2607:fa49:427c:dc00:ba27:ebff:fe3a:dbe1
          192.168.0.12

Looks like it's not resolving pi.hole domain properly.

[Bucking_Horn]

@wasabi-dog

> nslookup pi.hole
Server:  UnKnown
Address:  2607:fa48:2:f000::1

It's not Pi-hole answering that request, but a DNS server at 2607:fa48:2:f000::1 -probably your router.

Likely, your router is advertising its own IPv6 address as DNS server (or those of your ISP's DNS servers), allowing your clients to by-pass Pi-hole.

You'd have to find a way to configure your router to stop advertising its own IPv6 as DNS server, or to advertise your Pi-hole host machine's IPv6.

You'd have to consult your router's documentation sources on further details for its IPv6 configuration options.

If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether, provided you'd not depend on IPv6 for reasons.

If your router doesn't support that either, your IPv6-capable clients will always be able to bypass Pi-hole via IPv6.

[MichaIng]

IIRC, in case of the router software provided by some ISPs, like Deutsche Telekom in Germany (likely all DTAG daughter ISPs around the world), it forcefully advertises its own IPv6 as DNS server, even if DHCP is disabled, and IPv6 cannot be disabled either router-wise. So the only solution in this case is, to disable IPv6 client-wise, or switch to a router from a common manufacturer, away from those home grown ISP products.

You could check for those router advertisements from a Linux client:

tcpdump -n -i eth0 icmp6

In case apt install tcpdump first. Or to see the content and hence advertised DNS explicitly:

apt install radvdump
radvdump

It might take some minute(s) before it receives an RA, which then looks like this:

#
# radvd configuration generated by radvdump 2.19
# based on Router Advertisement from fe80::1
# received by interface eth0
#

interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag on;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 255;
        AdvDefaultLifetime 180;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvLinkMTU 1492;
        AdvSourceLLAddress on;

        prefix 2003:MASKED::/64
        {
                AdvValidLifetime 172800;
                AdvPreferredLifetime 86400;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        }; # End of prefix definition


        RDNSS fe80::1
        {
                AdvRDNSSLifetime 180;
        }; # End of RDNSS definition


        DNSSL speedport.ip
        {
                AdvDNSSLLifetime 180;
        }; # End of DNSSL definition

}; # End of interface definition

The RDNSS shows that it advertises itself (fe80::1 is the default route/standard gateway in IPv6) as recursive DNS server.

[wasabi-dog]

@Bucking_Horn

Likely, your router is advertising its own IPv6 address as DNS server (or those of your ISP's DNS servers), allowing your clients to by-pass Pi-hole.

You'd have to find a way to configure your router to stop advertising its own IPv6 as DNS server, or to advertise your Pi-hole host machine's IPv6.

I double checked everything and all settings on pi hole looks okay.

I think it is indeed a problem with the ISP/router. Probably a firmware update on the router changed some settings.

@MichaIng

IIRC, in case of the router software provided by some ISPs, like Deutsche Telekom in Germany (likely all DTAG daughter ISPs around the world), it forcefully advertises its own IPv6 as DNS server, even if DHCP is disabled, and IPv6 cannot be disabled either router-wise. So the only solution in this case is, to disable IPv6 client-wise, or switch to a router from a common manufacturer, away from those home grown ISP products.

I will have to keep digging on what's going on with the router and if there's a way to disable IPv6 DNS. Otherwise, I will have to use an older router with openWrt
Unfortunately radvdump is taking forever to get a response.

[deHakkelaar]

@wasabi-dog

Unfortunately radvdump is taking forever to get a response.

Forget radvdump or rdisc6 (which has a shorter time-out)!
Try out Pi-hole's own upcoming IPv6 Router Advertisement scanner:

Pihole not working on other devices

You could try play with those settings and check results with below? If you want to post the output here, redact the later part of IPv6 addresses displayed and also the "link layer address" which is a MAC address! EDIT: Oh above is for 64 bit Pi-OS! For 32 bit and depending Pi model, you need to down the appropriate version. For below example (armhf is 32 bit OS): $ dpkg --print-architecture armhf $ arch armv6l You would need to wget the pihole-FTL-armv6 binary from below:

They did a great job so you dont need any external tools anymore

[MichaIng]

Nice, good to know such exist.

I did not know that radvdump has a timeout. It can take as long as it takes for the router to send out another RA at least. If nothing happens within an hour, then maybe the router indeed does not send our RAs.

Right rdisc6 is actually better, since it explicitly asks for an RA via ND, IIRC? So it should get an answer moreless instantly.

[deHakkelaar]

I didnt realize radvdump is just waiting passively for an RA.
Vs actively broadcasting a discovery (EDIT via multicast) like rdisc6 does.

Below from rdisc6 on my IPv4 only LAN:

$ rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...
Timed out.
Timed out.
Timed out.
No response.

$ sudo tcpdump -nti eth0 icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP6 fe80::216:xxxx.xxxx.xxxx > ff02::2: ICMP6, router solicitation, length 8
IP6 fe80::216:xxxx.xxxx.xxxx > ff02::2: ICMP6, router solicitation, length 8
IP6 fe80::216:xxxx.xxxx.xxxx > ff02::2: ICMP6, router solicitation, length 8

For radvdump, I waited a long time and nothing appeared while sniffing.

EDIT: Oh below when running pihole-FTL dhcp-discover (on my IPV4 only LAN so no RA reply)

$ sudo tcpdump -nti eth0 icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP6 fe80::216:xxxx.xxxx.xxxx > ff02::2: ICMP6, router solicitation, length 8
IP6 fe80::216:xxxx.xxxx.xxxx > ff02::2: ICMP6, router solicitation, length 8
IP6 fe80::216:xxxx.xxxx.xxxx > ff02::2: ICMP6, router solicitation, length 8

[MichaIng]

Yeah, so radvdump really is the wrong tool for this. Respectively, actually both in combination are nice then: rdisc6 or Pi-hole's dhcp-discover (when getting the feature branch build) to trigger an RA, and radvdump on a parallel shell session to have it nicely decoded with the DNS information it provides visible .