Accessing http://pi.hole/ produces "400 Bad Response" error on Ubuntu Server 19.04

[MarkRMonaco]

In raising this issue, I confirm the following:

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?: 8

---

Expected behaviour:

• Browsing http://pi.hole/ or http://serverIPaddress/ results in the Pi-hole landing page being displayed.

Actual behaviour:

• On this particular release, browsing that URL results in a page displaying "400 Bad Response".
• However, on 18.04 LTS (which I have loaded on another VM), it works as intended.

Steps to reproduce:

1. Setup VM and install Ubuntu Server 19.04.
2. Perform "apt update && apt upgrade".
3. Install (from Terminal) using "curl -sSL https://install.pi-hole.net | bash".
4. When setup is complete, attempt to browse URL.

Debug token provided by uploading pihole -d log:

• n3hwj1v0bk

Troubleshooting undertaken, and/or other relevant information:

• Deleting and recreating VM
• Uninstalling/reinstalling the application
• Trying from different devices, etc.
• Posted on another issue thread, and was advised to open a new issue.

[AzureMarker]

Are you able to reproduce after switching to the development branch? pihole checkout dev

[MarkRMonaco]

@Mcat12, no. The problem went away on the development branch.

[MarkRMonaco]

@Mcat12, is there a way to get the pi-hole "block page" to appear while on the development branch? I have it configured, per prior instructions. However, it's not working. - Instead, I'm only seeing the typical error (in Chrome) ERR_CONNECTION_REFUSED.

What I should see:

[MarkRMonaco]

Just tried from a PC (last attempt was from an Android phone), and am now seeing the following error in Chrome:

[ERROR] File not found: /etc/pihole/adlists.list

[AzureMarker]

This issue is fixed in the same way as #2605, so I'm marking it as fixed in next release.

The block page is currently broken on development, it requires this PR to fix it: #2831

[MarkRMonaco]

Thanks @Mcat12. - From what I saw in that PR, it is still pending review/merging. Therefore, there is nothing that I can do from my end yet (in terms of patches, workaround, reconfiguration).

As for this particular bug, should I remain on the development release/track?

Also, do you need me to close this out or leave it open until the next version is released?

[AzureMarker]

You can checkout that particular branch before it is merged to dev: pihole checkout core fix/block-page-adlists

We usually leave these "fixed in next release" issues open until the release is out.

[MichaIng]

@Mcat12
Just for clarification:

• With proper blocking mode, blocked requests are redirected to webroot.
• In webroot there is by default no index page and no symlink to the blocking page at /pihole/index.php. Also the default lighttpd.conf, installed by Pi-hole does not include any related redirect/rewrite.
• Is it some "feature" of Lighttpd to just search the next sub dir for an index page, since (on dev branch) the blocking page is presented? Although strange that curl -v pi.hole instead shows a 302 to /admin not /pihole, while curl localhost directly shows the blocking page without 302. Is there some more magic that I do not understand yet? 😄

Since this is IMO not a very reliable solution and any custom website in webroot breaks blocking page, I suggest blocked requests being redirected to /pihole/index.php directly. This is failsafe and enhances compatibility if Pi-hole is not the only website on this webserver.

Another reason why I am looking for this, is that we (DietPi) aim to deny access to the Pi-hole blocking page by default for non-LAN access: MichaIng/DietPi#3054
This makes sense since no-one would open the DNS to public, most likely, and without using the Pi-hole DNS, the blocking page is at best an information leak (LAN IP leak reported once, although I could not replicate: https://dietpi.com/phpbb/viewtopic.php?p=18611#p18611).

• Since Lighttpd does not allow to block per local file path, but only based on $HTTP["url"], it would require to block access to webroot, and when blocking page is disabled afterwards, it would then require to unblock webroot access again. A bid unhandy.
• Other webservers do not redirect webroot to any subdir automatically, thus Pi-hole blocking page there (Apache, Nginx tested) a symlink from webroot to /pihole/index.php is required. Also this would not be required anymore if blocked requests would be redirected there directly. At least other webserver allow to block access to explicit file paths, although I did not yet test it this includes access via symlink to the blocked dir/path.

Perhaps I should open a separate issue/request for this, but for now I most importantly aim to understand (or verify that I did) how the current implementation really works 😉.

[AzureMarker]

With proper blocking mode, blocked requests are redirected to webroot.

The default blocking mode returns 0.0.0.0 for blocked domains, so the web server is never hit. For IP-based blocking modes the Pi-hole's IP address is returned. Because DNS has no control over the path, the blocked request's path is unchanged.

https://docs.pi-hole.net/ftldns/blockingmode/

In webroot there is by default no index page and no symlink to the blocking page at /pihole/index.php. Also the default lighttpd.conf, installed by Pi-hole does not include any related redirect/rewrite.

The lighttpd.conf that we ship sets pihole/index.php as the 404 page.

Is it some "feature" of Lighttpd to just search the next sub dir for an index page, since (on dev branch) the blocking page is presented? Although strange that curl -v pi.hole instead shows a 302 to /admin not /pihole, while curl localhost directly shows the blocking page without 302. Is there some more magic that I do not understand yet? 😄

The Lighttpd config that we ship sets the 404 page, so when a 404 is hit the block page is rendered. The block page is returned for http://pi.hole, however it will send a redirect to /admin because the domain equals pi.hole:

pi-hole/advanced/index.php

Lines 53 to 55 in 1a741f6

	if ($serverName === "pi.hole") {
	// Redirect to Web Interface
	exit(header("Location: /admin"));

Since this is IMO not a very reliable solution and any custom website in webroot breaks blocking page, I suggest blocked requests being redirected to /pihole/index.php directly. This is failsafe and enhances compatibility if Pi-hole is not the only website on this webserver.

It is impossible to change the path of a request through DNS. We cannot influence the client's request other than to change the IP that it is made to.

Another reason why I am looking for this, is that we (DietPi) aim to deny access to the Pi-hole blocking page by default for non-LAN access: MichaIng/DietPi#3054

This would can be done either at the web server level (assuming it can change the 404 handler based on the incoming request) or at the block page level (custom code to check if it is a local request).

Perhaps I should open a separate issue/request for this, but for now I most importantly aim to understand (or verify that I did) how the current implementation really works 😉.

This does seem a little unrelated to the issue we are currently in.

[MichaIng]

@Mcat12
Many thanks for clarification. Indeed this totally makes sense as the DNS only resolves domain to IP but cannot influence path, query or anything else.

Of course, now I remember the 404 to blocking page, which I found confusing when you have other websites on the webserver, and when accessing wrong one is presented the blocking page, which is out of context there.
But it is a necessity, when blocking page is wanted, since otherwise there is no way to present it for random ad request paths.

however it will send a redirect to /admin because the domain equals pi.hole

Ah that's it and it's a reasonable redirect as well.

assuming it can change the 404 handler based on the incoming request

Good idea. Jep should be easily possible to set 404 handler to blocking page only for remote IPs matching ^1(27|92\.168|0|72\.(1[6-9]|2[0-9]|3[0-1]))\. (all IP ranges reserved for LANs).

For DietPi it is no viable solution to change the Pi-hole code, since users want and should run pihole -up regularly which would break things. But probably this is indeed something considerable to add to the blocking page upstream code, so it shows a 404 or related error text instead of executing any further PHP code that could include info unwanted for public?

However other topic. Many thanks for clarifying things and sorry for the OOT posts.

---

Related to this topic, since the mention PR (fix) has been merged, I can confirm that the current dev branch fixes the 400 Bad Response error when accessing webroot.

[DL6ER]

Pi-hole v5.0 has just been released.