I have a pretty basic setup running on my NanoPi with DietPi 6.24.1, Nextcloud (nginx), Pi-hole, Certbot and PiVPN installed.
When using my internal IP http://192.168.x.x I get the usual Pi-hole default page
When I use my https://subdomain.domain.tld I get this page which exposes my internal IP. It also happens with URL/pihole. Is this supposed to happen or is it a misconfiguration on my side? Can someone confirm this on his setup?
The other question is, if there is a way to set URL/nextcloud to my default page instead of Pi-hole? I’ve tried to change the web root to /nextcloud in the nginx config, but I couldn’t get it to run without breaking Pi-hole web pages. I don’t mind reverting the settings after every update as long I get my desired result 
Are there any news on this issue? DietPi-Software | Option to allow access to single website on webroot · Issue #1608 · MichaIng/DietPi · GitHub
Sounds like it would be the perfect solution to my second request.
anubis
Pi-hole requires it’s admin and blocking page to be related to the webroot. So if you change webroot to /nextcloud, the Pi-hole admin/blocking page sub dirs need to be at least linked from there. And in case of Nextcloud AFAIK this conflicts with their .htaccess and rewrite rules, but could be tested.
But all this is not very recommended. If you have different websites (including Pi-hole web UI) I would stay with sub directories. Also the feature request you linked would only allow this when a single webserver application is installed and be reverted when you install multiple ones. Otherwise application internal rules can conflict/break each other.
About the internal IP leak, that is indeed not intended! I will check if some some official Pi-hole webserver configs solve this that need to be added to DietPi install then, or if we need to report this to Pi-hole devs.
Actually blocking page should only be shown when calling from internal network, as also the DNS server is. External access only via VPN.
MichaIng
Pi-hole requires it’s admin and blocking page to be related to the webroot. So if you change webroot to /nextcloud, the Pi-hole admin/blocking page sub dirs need to be at least linked from there. And in case of Nextcloud AFAIK this conflicts with their .htaccess and rewrite rules, but could be tested.
Could you please give me a hint how the link to the Pi-hole sub dirs is supposed to look like?
About the internal IP leak, that is indeed not intended! I will check if some some official Pi-hole webserver configs solve this that need to be added to DietPi install then, or if we need to report this to Pi-hole devs.
Actually blocking page should only be shown when calling from internal network, as also the DNS server is. External access only via VPN.
Did you manage to prevent the IP from leaking with additional configs?
Please let me know if there’s a need for logs or configs from my setup.
anubis
Sorry for the late reply.
I could actually not replicate the IP leak. When installing Pi-hole with Nginx (and any other webserver), accessing either plain IP/URL or with /pihole URI, i am presented with a simple html page that allows me to head over to admin panel. Page source:
<html><head>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
<link rel='stylesheet' href='/pihole/blockingpage.css' type='text/css'/>
</head><body id='splashpage'><img src='/admin/img/logo.svg'/><br/>Pi-<b>hole</b>: Your black hole for Internet advertisements<br><a href='/admin'>Did you mean to go to the admin panel?</a></body></html>
So not containing any IP or other unwanted info.
The Pi-hole admin page as well does not contain any further info (when not logged in), besides version strings of Pi-hole itself, the machines hostname (not IP) and blocklist/query stats.
The plain page that you were facing above actually looks like PHP is not working properly, thus the PHP file is presented/called as plain HTML.
Check out for errors:
systemctl status php7.3-fpm
journalctl -u php7.3-fpm
However when you want webroot at /nextcloud, it is anyway not available, since this requires a special index.php file in webroot, but Nextcloud has its own.
Disable the blocking page Pi-hole side:
G_CONFIG_INJECT 'BLOCKINGMODE=' 'BLOCKINGMODE=NULL' /etc/pihole/pihole-FTL.conf
systemctl restart pihole-FTL
This is faster anyway, requests are immediately nulled instead of being forwarded again. I don’t not much use cases where the blocking page would be helpful. Any whitelisting etc anyway requires login and I would simply do this manually from admin panel instead of via blocking page.
Okay just tried to achieve the /nextcloud webroot + Pi-hole admin panel. Was able to get it working, but the issue is that the whole dietpi-nextcloud.conf needs to be adjusted.
First the admin panel symlink:
ln -s /var/www/html/admin /var/www/nextcloud/admin
To adjust dietpi-nextcloud.conf Nginx config, so it applies to webroot instead of /nextcloud subpath, do the following:
mv /etc/nginx/sites-dietpi/dietpi-nextcloud.conf /etc/nginx/sites-dietpi/dietpi-nextcloud.conf.bak
sed -Ei 's|/nextcloud\\?/?|/|' /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
Also CLI URL must be adjusted:
sed -i 's|localhost/nextcloud|localhost|' /var/www/nextcloud/config/config.php
And finally to remove doubled location match and instead override Nextcloud location rules for the Pi-hole admin panel URIs:
In /etc/nginx/sites-available/default and the related HTTPS/SSL config (currently not sure about SSL/HTTPS config file that CertBot creates there, or you created manually)
Replace “location / {” with “location /admin {”
and “location ~ .php(?:$|/) {” with “location ~ ^/admin/.+.php(?:$|/) {”
With the above I got it working.
MichaIng
Thanks for taking the time to investigate this weird issue I am dealing with.
I’ve checked for errors, but couldn’t find anything useful to narrow it down.
Looks like I’ll have to install my setup from scratch.
Thanks again for the webroot adjustments!
Hello, first of all, sorry for my bad English
I had the same problem, in fact I use almost the same as you.
You have to modify the configuration of lighttpd, at least I am the one I use.
Since it is your Web server, and it exposes everything you have to the internet, within lighttpd it is / admin (pi-hole) and / nextcloud
this is inside / var / www
Go to / etc / lighttpd
and modify the lighttpd.conf file (first make a copy with “cp”)
server.modules = (
“mod_access”,
“mod_accesslog”,
“mod_auth”,
“mod_expire”,
“mod_compress”,
“mod_redirect”,
“mod_setenv”,
“mod_rewrite”
)server.document-root = “/var/www”
server.error-handler-404 = “pihole/index.php”
server.upload-dirs = ( “/var/cache/lighttpd/uploads” )
server.errorlog = “/var/log/lighttpd/error.log”
server.pid-file = “/var/run/lighttpd.pid”
server.username = “www-data”
server.groupname = “www-data”
server.port = 80
accesslog.filename = “/var/log/lighttpd/access.log”
accesslog.format = “%{%s}t|%V|%r|%s|%b”
index-file.names = ( “index.php”, “index.html” )
url.access-deny = ( “~”, “.inc”)deny access to /raiz lighttpd
$HTTP[“remoteip”] !~ “192.168.2.*” {
$HTTP[“url”] =~ “” {
url.access-deny = (“apc.php”, “opcache.php”, “phpinfo.php”, “index.html” )
}
}deny access to /admin Pihole
$HTTP[“remoteip”] !~ “192.168.2.*” {
$HTTP[“url”] =~ “^/admin/” {
url.access-deny = ( “” )
}
}deny access to /html
$HTTP[“remoteip”] !~ “192.168.2.*” {
$HTTP[“url”] =~ “^/html/” {
url.access-deny = ( “” )
}
}deny access to /Pihole
$HTTP[“remoteip”] !~ “192.168.2.*” {
$HTTP[“url”] =~ “^/pihole/” {
url.access-deny = ( “” )
}
}deny access to /cgi-bin
$HTTP[“remoteip”] !~ “192.168.2.*” {
$HTTP[“url”] =~ “^/cgi-bin/” {
url.access-deny = ( “” )
}
}
static-file.exclude-extensions = ( “.php”, “.pl”, “.fcgi” )compress.cache-dir = “/var/cache/lighttpd/compress/”
compress.filetype = ( “application/javascript”, “text/css”, “text/html”, “text/plain” )default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell “/usr/share/lighttpd/create-mime.assign.pl”Prevent Lighttpd from enabling Let’s Encrypt SSL for every blocked domain
#include_shell “/usr/share/lighttpd/include-conf-enabled.pl”
include_shell “find /etc/lighttpd/conf-enabled -name ‘*.conf’ -a ! -name ‘letsencrypt.conf’ -printf ‘include "%p"\n’ 2>/dev/null”If the URL starts with /admin, it is the Web interface
$HTTP[“url”] =~ “^/admin/” {
Create a response header for debugging using curl -I
setenv.add-response-header = (
“X-Pi-hole” => “The Pi-hole Web interface is working!”,
“X-Frame-Options” => “DENY”
)$HTTP[“url”] =~ “.ttf$” {
Allow Block Page access to local fonts
setenv.add-response-header = ( “Access-Control-Allow-Origin” => “*” )
}
}Block . files from being served, such as .git, .github, .gitignore
$HTTP[“url”] =~ “^/admin/.(.*)” {
url.access-deny = (“”)
}Add user chosen options held in external file
This uses include_shell instead of an include wildcard for compatibility
include_shell “cat external.conf 2>/dev/null”
This is my configuration file modified by me, my internal network is 192.168.2.X modifies if yours is different
With this config, you access the Internet only to Nextcloud, the rest denies
But from local network it allows access to everything (Pi-hole etc)
krtpowa
Thanks for providing this. I am actually wondering if there is a “does not match” syntax to exclude every URI (block for non-local access) that does not match /nextcloud in this case.
Ah: $HTTP[“url”] !~ “^/nextcloud” should do it.
Why not merging all the checks into a single remote IP block? E.g.
$HTTP["remoteip"] !~ "192.168.2.*" {
# deny access to /admin Pihole
$HTTP["url"] =~ "^/admin/" {
url.access-deny = ( "" )
}
# deny access to /html
$HTTP["url"] =~ "^/html/" {
url.access-deny = ( "" )
}
# deny access to /Pihole
$HTTP["url"] =~ "^/pihole/" {
url.access-deny = ( "" )
}
# ... etc
}
Or with above:
$HTTP["remoteip"] !~ "192.168.2.*" {
# Deny access to all by Nextcloud
$HTTP["url"] !~ "^/nextcloud" {
url.access-deny = ( "" )
}
}
Aside from that, generally it makes sense to grant access to Pi-hole, at least to the blocking page, to the local network only. One anyway would never want to open the DNS server to the web, so the blocking page has no use there as well, besides possible leaking information about the server.
We’ll probably add this to all webserver configs by default when installing Pi-hole.
That would be great, it is true that it would be much more comfortable preventing access to everything that “does not match” with / nextcloud, or whatever you want to configure.
I did it this way because I was learning to modify this file and I was testing, at the time it worked, I left it.
But if what you put there works is much better, I don’t have to be blocking file by file or directories.
I will try it! cool
I just tried it, it works perfectly!!
$HTTP["remoteip"] !~ "192.168.2.*" {
# Deny access to all by Nextcloud
$HTTP["url"] !~ "^/nextcloud" {
url.access-deny = ( "" )
}
}
krtpowa anubis
We’re about to implement a solution to block the Pi-hole blocking page by default for non-local access: https://github.com/MichaIng/DietPi/pull/3054
This makes sense since no one would ever share ones local Pi-hole DNS to the public www, although would be cool to have a public DNS with Pi-hole integrated 
. And without having something blocked by this Pi-hole instance, the blocking page has no meaning, thus denying access totally makes sense to prevent any possible information leak.
The question is now if we should do the same for the admin page:
- Block it by default for remote access? Or keep it possible to monitor/administer your Pi-hole instance from remote networks as well?
- Give a choice during install process? The Pi-hole installer anyway asks a lot of question, so one more does not hurt much?
The block is implemented a way that all client IPs have access, that match the address ranges that are reserved for local networks. This means also VPN clients and otherwise directly connected local networks have access, which is important of course.
We are thinking of allowing this for local IPv6 networks as well, but I doubt that anyone has an IPv6-only local network, meaning having only IPv6 addresses assigned and using them to connect to devices within the local network?
Otherwise it is not too hard to add those Link Local Unicast and Unique Local Unicast address ranges to the pattern, after all. There is just still to possibility to access individual local devices via external IPv6 prefix+internal address, so the device will receive the external prefix as well as remote IP, thus block access. Not sure if there is any reasonable way to check this, but there is really no point in accessing local deices by their external IPv6 address from within the local network anyway…
Thank you for making this improvement, especially when it facilitates the user.
I would put the question in the installer, or the web server (Ngix, apache etc, or when you install Pi HOle)
Very good work
By the way, a DNS server with Pi-Hole would not be bad, because sometimes I use VPN to avoid advertising on my mobile, but OpenVpn consumes a lot of battery. a DNS would be a good idea, but I don’t know if this is a danger to the security of the equipment (DNS server / Rpi / other computers with Dietpi)
krtpowa
Thanks for your kind feedback. Jep about the admin panel it is now asked during install. The Pi-hole installer requires much manual input anyway, one more question does not hurt much 
.
Some use unbound as local DNS resolver to be used by Pi-hole then. So unbound e.g. listens to 5353 and Pi-hole uses 127.0.0.1:5353 as upstream DNS.