Disable reserved local IP check


I have just installed DietPi on my Pi2B as an alternative to Raspbian.

I want to run pihole and pivpn on there. However I have found something that DietPi is doing that stops it from working properly.

I run my network on 172.0.0.x rather than 192.168.x.x and as such DietPi won’t allow me to connect to the web services (or pivpn for that matter).

I believe it is related to this: https://dietpi.com/forum/t/rpi-4-pihole-web-interface-forbidden/3608/1

Re: RPi 4 | pihole web interface forbidden
Post by MichaIng » Fri Dec 06, 2019 5:53 pm

Glad you found it. X-Frame-Options: DENY is just a security header which denies to add the web page as frame into another website. But the direct access is not affected by this.

Yeah we check for local IP by comparing with the pattern for reserved local IPs. Using any other IPs for local networks means that you break access to those on www, hence there is high likely a host out there that you cannot reach anymore, since you local LAN host duplicates it and takes priority probably from within local network > :wink:> . Always use 192.168./10. or 172.[16 to 31].* for local networks, the first pattern is most common. 10.* is mostly found for VPNs, 127.* btw. is reserved/resolved as loopback to the localhost itself.

Any way to stop DietPi from doing this? I’m not sure it needs to be done and is restrictive for no real reason?

This is not private space and you shouldn’t be using it.
Use some subnet from instead (

I appreciate that, but it doesn’t answer my question.

Is there anyway in dietpi to stop it deciding what’s acceptable and what’s not? I don’t feel it should be up to dietpi to make that decision for me.


nope, this check is hard coded and DietPi is following international standards by respecting RFC1918



  1. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets: - (10/8 prefix) - (172.16/12 prefix) - (192.168/16 prefix)

“Hardcoded” is probably a bid too “hard”. Of course the config can be changed or overwritten with a custom file. Nathanio Which webserver do you use?

But actually we block public access to the blocking page only, which you should usually not enable, since it only works on non-HTTPS content anyway, which should not be much (hopefully) anymore nowadays. And since one usually does not want to make the private DNS resolver public to www, the blocking page has no meaning there and has been reported as info leak only (although I actually wanted to verify that with current Pi-hole 5.1).

The admin panel is by default not blocked. You are asked interactively (if not installed automated) if you want that and commands are provided to switch the choice.
On Apache:

a2ensite dietpi-pihole-block_public_admin # block
a2dissite dietpi-pihole-block_public_admin # unblock
systemctl reload apache2 # afterwards to load the change

On Nginx:

mv /etc/nginx/sites-dietpi/dietpi-pihole-block_public_admin.{off,on} # block
mv /etc/nginx/sites-dietpi/dietpi-pihole-block_public_admin.{on,off} # unblock
systemctl reload nginx # afterwards to load the changes

On Lighttpd:

lighty-enable-mod dietpi-pihole-block_public_admin # block
lighty-disable-mod dietpi-pihole-block_public_admin # unblock
systemctl reload lighttpd # afterwards to load the changes

But really, you should not use public IP ranges for your private network. Not only will you not be able to access the resources behind those IP, but also I’m not sure how network programs handle incoming requests from those hosts if the IP range is by netmask taken as the local network. Information might be leaked or access granted that you never wanted. E.g. Pi-hole/dnsmasq has this feature to allow DNS requests from all origins or only local network (“at most one hop away”) and the question is how this is checked. I was digging into it once for another reason but forget the details :wink:. But in theory when the local network member is derived from the own IP + netmask/CIDR then those public hosts will have access to your Pi-hole.
Yes yes, the chance that one of this relatively small share of hosts tries to access your server may be small, same for the outgoing broken requests, but why accepting this potential issues and security risks when you can simply (?) switch to a range that never any public host can have?