PiHole admin pages 403 Forbidden via FQDN/admin after enabling ipv6

[dunxd]

Creating a bug report/issue

Required Information

• DietPi version | 7.3.2
• Distro version | buster
• Kernel version | Linux pihole 5.10.17+ #1421 Thu May 27 13:58:02 BST 2021 armv6l GNU/Linux
• SBC model | RPi B (armv6l)

Additional Information (if applicable)

• Software title | PiHole

Steps to reproduce

1. Enable IPv6 in dietpi Network adaptor and PiHole
2. Visit PiHole admin page using fqdn/admin.

Expected behaviour

PiHole admin page should be accessible

Actual behaviour

403 Forbidden message

Extra details

The page is blocked by the directive in 99-dietpi-pihole-block_public_admin.conf - without the symlink to this in /etc/lighttpd/conf-enabled the page is available.

In #3024 (comment) there was mention of using fd??:* to identify local hosts - was this abandoned or overlooked?

[MichaIng]

Many thanks for your report.

We missed to add IPv6 ULA addresses to the whitelist in those configs.

The issue you linked was about the initial implementation of this optional feature. Interesting indeed that we collected the regex for IPv6 addresses there already but the final PR did not contain it anymore.

[MichaIng]

Please try this one:

curl -sSfL 'https://raw.githubusercontent.com/MichaIng/DietPi/pihole/.conf/dps_93/lighttpd.block_public_admin.conf' -o /etc/lighttpd/conf-available/99-dietpi-pihole-block_public_admin.conf
systemctl restart lighttpd

[dunxd]

I get a 404 error when I try that command, or going to the URL in my browser. Duncan

…

On Fri, 23 Jul 2021 at 12:16, MichaIng ***@***.***> wrote: Please try this one: curl -sSfL 'https://raw.githubusercontent.com/MichaIng/DietPi/pihole/.conf/dps_93/lighttpd.block_public_admin.conf' -o /etc/lighttpd/conf-available/99-dietpi-pihole-block_public_admin.conf systemctl restart lighttpd — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6W2HIBE5PDJMGOGDBHMTTTZFFPXANCNFSM5A2MEPGQ> .

[MichaIng]

Sorry, I merged it too fast:

curl -sSfL 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.conf/dps_93/lighttpd.block_public_admin.conf' -o /etc/lighttpd/conf-available/99-dietpi-pihole-block_public_admin.conf
systemctl restart lighttpd

[dunxd]

Thanks - it worked this time. However I am still getting the 403 Forbidden message when browsing to the pihole with the hostname. I suspect that my local clients are being detected with their Global Addresses, which aren't approved by the regex. Duncan

…

On Fri, 23 Jul 2021, 5:12 pm MichaIng, ***@***.***> wrote: Sorry, I merged it too fast: curl -sSfL 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.conf/dps_93/lighttpd.block_public_admin.conf' -o /etc/lighttpd/conf-available/99-dietpi-pihole-block_public_admin.conf systemctl restart lighttpd — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6W2HPOIBVBIGQVIU5MOKLTZGIGBANCNFSM5A2MEPGQ> .

[Joulinar]

You always need to go to the sub page directly. Like pi.hole/admin

[dunxd]

pi.hole/admin works. I guess the pihole DNS translates this hostname to only an ipv4 address, so browser uses ipv4 for which private addresses are allowed. pihole.home.arpa/admin gives the 403 forbidden message, presumably because link local ipv6 addresses are allowed, but the request appears to come from a global ipv6 address.

…

On Sat, 24 Jul 2021, 11:44 am Joulinar, ***@***.***> wrote: You always need to go to the sub page directly. Like pi.hole/admin — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6W2HJD6JF7WHPIXX3QFD3TZKKPZANCNFSM5A2MEPGQ> .

[MichaIng]

Ah yes, please assure that, as Pi-hole moves the index page away (it did until we fixed it with DietPi v7.3 for new installs AFAIK), and Lighttpd shows a 403 when no index page is present and directory listing not enabled.

But the thing with the global addresses is possible. Actually I think the IPv6 prefix is the issue.

• In my LAN IPv6 devices, as expected, a link-local address, based on their MAC address and with fe80:: prefix, which we added to the whitelist accordingly. But those are not routed reliably by the router, e.g. from the Windows system, not sure why. I can ping via this LLA from my Windows system everything else, but from my DietPi server this does not work (tested with ping and curl).
• Now the router additionally assigns addresses with a prefix that starts with 2a01: and ending with the same MAC-derived identifier. It's not the public prefix, but it defers only from the 3rd segment on and is not a reserved local/LAN address range. I think it is just another address range from the one that was assigned to me from the ISP, so probably I got a /40 address range or so. Using IPv6 addresses with this prefix in my LAN works reliably, but there is no way I can detect whether this is a public IP or a local/LAN IP, in fact it is from the public address range.
• Now I can enable ULA assignment in my router. Then all IPv6 devices get a third IPv6 address with an fc00::/7 ULA prefix and again the same ending identifier. These ULA addresses can now also be reliably used for connections in the LAN and as ULA prefixes can never be assigned on a public device, I know this must be coming from within a connected local network.

The remaining questions form my end:

• Why do the LLAs (fe80:: prefix) not work reliably?
  EDIT: This seems to be expected: https://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113328-ipv6-lla.html
  If I understand it right, those are supposed to work only for a single link, hence in my case e.g. the link between my Windows system and the router, but the router does not forward/route a request with LLA source or destination, e.g. from my Windows system to my DietPi server, or the other way round.
• How can I disable the assignment of 2a01: addresses in my LAN so that all LAN connections are assured to be either via LLAs or ULAs which I can whitelist just fine.
  EDIT: Nope cannot work, without a "global" prefix, the devices in my LAN cannot access public hosts via IPv6 anymore, so that one is obviously needed. So then the question is how to assure that LAN connections are done via LLA or ULA addresses. When I ping the router via LAN hostname, it resolves to its LLA, when I ping my Windows notebook via local hostname, it resolves to ULA, when I ping my phone via local hostname, it resolves to the IP with global prefix, and of course the answer is always coming from the same address the request was sent to. This doesn't follow any consistent logic on my router, at least none that I understand.

[MichaIng]

So I think enabling and using ULAs in the router is one important step to make this work. This should solve the issue in your case, as long as you use those IPs consequently, or otherwise if the router resolves local hostnames with the ULAs instead of the IPv6 prefixes that begin with 2. Somehow my router tells me that it's not recommended to enable ULAs, so that is to find out why, e.g. if it's seen only as an additional overhead, not required as devices can communicate with their global-style prefixes just well, or if there is other negative impact.

[dunxd]

Here is a discussion of ULAs and why not too use them: https://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html?m=1 TL;DR ULAs run counter to the ipv6 way of doing things. Why isn't my server seeing requests coming from the link local address? I don't expect an answer to that here 😀 Learning about IPv6 was my reason for enabling it in the first place. If I figure out out I'll try to remember to post here.

…

On Sat, 24 Jul 2021, 1:01 pm MichaIng, ***@***.***> wrote: So I think enabling and using ULAs <https://en.wikipedia.org/wiki/Unique_local_address> in the router is once important way to make this work. This should solve the issue in your case, as long as you use those IPs consequently, or otherwise if the router resolves local hostnames with the ULAs instead of the IPv6 prefixes that begin with 2. Somehow my router tells me that it's not recommended to enable ULAs, so that is to find out why, e.g. if it's seen only as an additional overhead, not required as devices can communicate with their global-style prefixes just well, or if there is other negative impact. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6W2HOQJOTVEEM24W6MHSDTZKTQJANCNFSM5A2MEPGQ> .

[MichaIng]

Thanks for sharing:

the role of NAT and address conservation are entirely thrown out the window

The question is whether this is always good. A NAT is still a natural kind of firewall (not a real firewall, but practically when not everything is forwarded by default) and isolates the LAN from WAN, which personally always prefer to often eliminate the need for a dedicated firewall on LAN devices.

If you disagree, I'm sorry, you are wrong.

Typical statement of theory vs practice. I'm not talking about professional networks where proper firewalling is strictly required as well as isolation in other ways, and one might want to avoid the overhead of a NAT for high traffic public websites. But for home networks of ordinary users who simply want to setup their home cloud or DNS solution, the default router setups with NAT protect their home servers naturally unless ports are explicitly forwarded, without the need to mess with a firewall first, which is especially on Linux absolutely not trivial and many things can be done wrong without recognising. End user forums are full of reports caused exactly by missing NAT, e.g. accidentally running Pi-hole as open resolver because some rules on the ISP or server-side firewall was set wrong, or other broken features because something was set too strict or in a conflicting way, where a NAT would have been an initial barrier.

So the article does not contain any argument to not use ULAs, but basically says that there is no reason to use them. Since most routers by default (and for reason) still play as NAT, regardless whether and how IPv6 is used in the home network, and in the LAN ULAs and GUAs work mostly the same way, I basically agree. But it causes exactly the issue that we have here, that with GUAs there is no way to know whether a client accesses from LAN or from WAN, without doing complicated prefix comparisons or such.

Finally, keep ULAs disabled, if you don't require them, but in your case they enable a way to block public IPv6 access to your Pi-hole admin panel or any other resource, as the webserver can check whether the prefix is GUA or not. Other than that, ULAs do not add any negative or security issues (as of the article), which is also good to know.

Last question is if LAN clients consequently use ULAs for LAN connections.

Why isn't my server seeing requests coming from the link local address? I
don't expect an answer to that here 😀

As said, they seem to be valid indeed only for the two ends of a single cable, or likely as well when multiple clients are connected via switch so that clients can directly connect to each other without being routed through the router. But when they are connected all to the router, via cable or WiFi, then only the router can be accessed via LLAs, respectively the router can reach connected clients with them.

Learning about IPv6 was my reason for enabling it in the first place.

Jep, was definitely worth it 👍. I know about SLAAC, RAs (router advertisements) and NDs (neighbor discovery) and how with that IPv6 networks can self-configure without DHCP. But I didn't know details about the different IPv6 address/prefix types and especially the LLA limitation. I had the impression that clients with only a LLA could still use IPv6 without issue, but that is obviously wrong when any routing above the next link is involved 😅.

[MichaIng]

I added an issue on our docs to add a hint about this: MichaIng/DietPi-Docs#540

Probably we should add it to the question prompt during Pi-hole install as well. But I mark this issue as closed, as we did what we can for the webserver config part.