Admin gets 403 when trying http://pi.hole/admin . Using nginx on dietpi

The router has the pi-hole IPv4 and IPv6 addresses listed as DNA servers. I'm just using the primary DNS server address and the secondary is blank for both v4 and v6.

1 Like

Did you change it just now or was it like that already? In case it does not seem to work for IPv6 for some reason. Can you remove the primary address for IPv6 as well, and see whether this removes the router's IPv6 from sudo resolvectl status (might take up to 30 minutes until a new RA is sent out, to have the output updated)? For resolving hosts to IPv6 addresses, the DNS server does not need to be accessed via IP6, so it is generally not needed.

Also, are these the router's DHCP settings, or is it the upstream DNS servers use by the router itself? Theoretically this can be two different settings, and possibly the router enforces itself as DNS resolver in addition to what has been configured for DHCP, and uses a different upstream DNS.

2 Likes

I removed the IPv6 DNS entry on the router, and set it to auto and pi.hole/admin now works! Thank you :slight_smile:

udo resolvectl status
[sudo] password for rob:          
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp3s0f2)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.20
       DNS Servers: 192.168.1.20 fe80::<redacted>d6 fe80::<redacted>ed
        DNS Domain: home

Link 4 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (br-d843fb2138b9)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (veth58b078b)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

My router's IPv6 address is still listed there above as a DNS server, but I'm hoping that it is still sending traffic to my pi-hole rather than to it's built-in upstream DNS servers, which are still shown in the router config, but hopefully are fully bypassed by the custom DNS server entry that points to my pi-hole.

I'm not sure I fully understand your question/point about DHCP.

1 Like

Your machine is still aware of two IPv6 link-local addresses DNS servers, it's just not using them at the moment.
fe80::d6 is your router, fe80::ed is a Raspberry Pi, likely the one that is running Pi-hole.

Did you try adding your RPis link-local in all of your router's IPv6 DNS slots?

1 Like

Adding the RPis IPv6 into both primary and secondary slots also still works. It makes me wonder if I should add in the IPv4 into the secondary v4 DNS slot for completeness.

no change from the client machine:

sudo resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp3s0f2)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.20
       DNS Servers: 192.168.1.20 fe80::7297:41ff:fe43:63d6 fe80::ba27:ebff:febc:9ced
        DNS Domain: home

Link 4 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (br-d843fb2138b9)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (veth5032d1a)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
1 Like

The router's IPv6 address is still there. Should be currently random whether Pi-hole or the router is used as DNS, and can change with any router advertisement and hence resolved update.

You do change this currently in the DHCP or LAN settings or the router, right?

1 Like

No, that didn't work.
If it would, your router's link-local should have vanished from resolvectl status output.

Could you share a screenshot of your router's configuration screen for those IPv6 addresses?

1 Like

I meant that pi.hole/admin still resolves.

Screenshots of IPv4 and IPv6 router config pages attached.


1 Like

I think so yes. My router is still the DHCP server

1 Like

Please run

sudo pihole-FTL dhcp-discover | pihole tricorder

and share the token.

1 Like

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

1 Like

Hmm, I was hoping to see your router's RAs, but RAs are only solicited with v6, so your results suggest they were produced by a v5 pihole-FTL binary?

What's the output of

pihole -v
dig version.ftl chaos txt
root@DietPi:~# pihole -v
  Pi-hole version is v5.18.4 (Latest: v6.0.4)
  web version is v5.21 (Latest: v6.0.1)
  FTL version is v5.25.2 (Latest: v6.0.3)

root@DietPi:~# dig version.ftl chaos txt

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> version.ftl chaos txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29169
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;version.ftl.			CH	TXTtype or paste code here

;; Query time: 30 msec
;; SERVER: 192.168.1.254#53(192.168.1.254) (UDP)
;; WHEN: Sat Mar 01 13:38:13 GMT 2025
;; MSG SIZE  rcvd: 40

192.168.1.254 is my router...

1 Like

Seems you are still running Pi-hole v5.

Is that by intention?

1 Like

At the moment, yes. I will upgrade, but it seemed worth just letting the dust settle a bit before jumping in. I wasn't sure it would run well on a RPi2b, so I needed to be sure it would (and wait for the dietpi upgrade which has now come). I also wanted to get the pi.hole URL working first (hence this thread).

Is the upgrade path 100% reliable now, or is a clean install preferred?

1 Like

If you are on DietPi v9.10 or lower, best is to upgrade Pi-hole first, DietPi afterwards. The update will do some further cleanup of DietPi-specific stuff that is obsolete with Pi-hole v6, and offers to uninstall webserver and PHP, unless something else is installed which requires it.

If you are on DietPi v9.11 already, you can re-apply the update, after Pi-hole was updated:

dietpi-update -1

We are thinking of a dedicated script, check and notification to offer said cleanup steps, but for now re-applying the DietPi update works well, as it was a release which almost only added proper Pi-hole v6 support to dietpi-software.

100% guarantee does not exist, but I am not away of any general left issues, and if anything goes wrong, we are here to help :slight_smile:.

1 Like

That all worked fine, thanks a million! DietPi is great :slight_smile:

3 Likes

I updated to v6 and this is the resolvectl status on my problem client:

sudo resolvectl status
[sudo] password for rob:         
Sorry, try again.
[sudo] password for rob:          
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp3s0f2)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::7297:41ff:fe43:63d6
       DNS Servers: 192.168.1.20 fe80::7297:41ff:fe43:63d6 fe80::ba27:ebff:febc:9ced
        DNS Domain: home

Link 4 (br-d843fb2138b9)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (vethc9aa558)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

tricorder token result:

sudo pihole-FTL dhcp-discover | pihole tricorder
/usr/local/bin/pihole: line 34: /etc/pihole/versions: Permission denied
Upload successful, your token is: https://tricorder.pi-hole.net/Usnr2Bbf/

1 Like

As far as RAs are concerned, that looks better:

* Received 104 bytes from fe80::<redacted>d6 @ eth0
  Hop limit: 64
  Stateful address conf.: No
  Stateful other conf.: Yes
  Router preference: Medium
  Router lifetime: 180 s
  - Prefix: 2a<redacted>::/64
    Valid lifetime: 300 sec
    Preferred lifetime: 120 sec
    On-link: Yes
    Autonomous address conf.: Yes
  Recursive DNS server 1/2: fe80::<redacted>ed
  Recursive DNS server 2/2: fe80::<redacted>ed
  DNS server lifetime:60 sec
  MTU: 1492 bytes (valid)

Your v6 pihole -FTL did solicit above router advertisement (RA) from your router, and it correctly shows your Pi-hole's LLA ending in ed in both slots.

But your client is a still aware of your router's LLA, ending in d6:

This could be a leftover from a previous RA.

Please monitor if that would vanish within the next 5 minutes (the longest lifetime from the RA, at 300 seconds).

1 Like

Still there after an hour.

1 Like