Conflict with other webservices running on Pi (Ports 80 and 443)

On Pi if you include dnsmasq etc:

sudo netstat -nltup | grep 'Proto\|lighttpd\|nginx\|dnsmasq\|dhcpcd'

That gives

HTTP/1.1 200 OK
X-Pi-hole: A black hole for Internet advertisements.
Content-type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 13 Apr 2017 21:26:35 GMT
Server: lighttpd/1.4.35

<!DOCTYPE html>
<head>
	<meta charset='UTF-8'/>
	<title>Website Blocked</title>
	<link rel='stylesheet' href='http://pi.hole/pihole/blockingpage.css'/>
	<link rel='shortcut icon' href='http://pi.hole/admin/img/favicon.png' type='image/png'/>
	<meta name='viewport' content='width=device-width,initial-scale=1.0,maximum-scale=1.0, user-scalable=no'/>
	<meta name='robots' content='noindex,nofollow'/>
</head>
<body id="body">
<header>
	<h1><a href='/'>Website Blocked</a></h1>
</header>
<main>
	<div>Access to the following site has been blocked:<br/>
	<span class='pre msg'>192.168.0.9/test</span></div>
	<div>If you have an ongoing use for this website, please ask the owner of the Pi-hole in your network to have it whitelisted.</div>
	<input id="domain" type="hidden" value="192.168.0.9">
	<input id="quiet" type="hidden" value="yes">
	<button id="btnSearch" class="buttons blocked" type="button" style="visibility: hidden;"></button>
	This page is blocked because it is explicitly contained within the following block list(s):
	<pre id="output" style="width: 100%; height: 100%;" hidden="true"></pre><br/>
	<div class='buttons blocked'>
		<a class='safe33' href='javascript:history.back()'>Go back</a>
		<a class='safe33' id="whitelisting">Whitelist this page</a>
		<a class='safe33' href='javascript:window.close()'>Close window</a>
	</div>
		<div style="width: 98%; text-align: center; padding: 10px;" hidden="true" id="whitelistingform">
			<p>Note that whitelisting domains which are blocked using the wildcard method won't work.</p>
			<p>Password required!</p><br/>
		<form>
			<input name="list" type="hidden" value="white"><br/>
			Domain:<br/>
			<input name="domain" value="192.168.0.9" disabled><br/><br/>
			Password:<br/>
			<input type="password" id="pw" name="pw"><br/><br/>
			<button class="buttons33 safe" id="btnAdd" type="button">Whitelist</button>
		</form><br/>
		<pre id="whitelistingoutput" style="width: 100%; height: 100%; padding: 5px;" hidden="true"></pre><br/>
		</div>
</main>
<footer>Generated Thu 11:26 PM, Apr 13 by Pi-hole v2.13.2</footer>
<script src="http://pi.hole/admin/scripts/vendor/jquery.min.js"></script>
<script>
// Create event for when the output is appended to
(function($) {
    var origAppend = $.fn.append;

    $.fn.append = function () {
        return origAppend.apply(this, arguments).trigger("append");
    };
})(jQuery);
</script>
<script src="http://pi.hole/admin/scripts/pi-hole/js/queryads.js"></script>
<script>
function inIframe () {
    try {
        return window.self !== window.top;
    } catch (e) {
        return true;
    }
}

// Try to detect if page is loaded within iframe
if(inIframe())
{
    // Within iframe
    // hide content of page
    $('#body').hide();
    // remove background
    document.body.style.backgroundImage = "none";
}
else
{
    // Query adlists
    $( "#btnSearch" ).click();
}

$( "#whitelisting" ).on( "click", function(){ $( "#whitelistingform" ).removeAttr( "hidden" ); });

// Remove whitelist functionality if the domain was blocked because of a wildcard
$( "#output" ).bind("append", function(){
	if($( "#output" ).contents()[0].data.indexOf("Wildcard blocking") !== -1)
	{
		$( "#whitelisting" ).hide();
		$( "#whitelistingform" ).hide();
	}
});

function add() {
	var domain = $("#domain");
	var pw = $("#pw");
	if(domain.val().length === 0){
		return;
	}

	$.ajax({
		url: "admin/scripts/pi-hole/php/add.php",
		method: "post",
		data: {"domain":domain.val(), "list":"white", "pw":pw.val()},
		success: function(response) {
			$( "#whitelistingoutput" ).removeAttr( "hidden" );
			if(response.indexOf("Pi-hole blocking") !== -1)
			{
				// Reload page after 5 seconds
				setTimeout(function(){window.location.reload(1);}, 5000);
				$( "#whitelistingoutput" ).html("---> Success <---<br/>You may have to flush your DNS cache");
			}
			else
			{
				$( "#whitelistingoutput" ).html("---> "+response+" <---");
			}

		},
		error: function(jqXHR, exception) {
			$( "#whitelistingoutput" ).removeAttr( "hidden" );
			$( "#whitelistingoutput" ).html("---> Unknown Error <---");
		}
	});
}
// Handle enter button for adding domains
$(document).keypress(function(e) {
    if(e.which === 13 && $("#pw").is(":focus")) {
        add();
    }
});

// Handle buttons
$("#btnAdd").on("click", function() {
    add();
});
</script>
</body>
</html>
sudo netstat -nltup | grep 'Proto\|lighttpd\|nginx\|dnsmasq\|dhcpcd'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.0.9:80          0.0.0.0:*               LISTEN      19492/lighttpd
tcp        0      0 192.168.0.15:80         0.0.0.0:*               LISTEN      7667/nginx -g daemo
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      3483/dnsmasq
tcp        0      0 192.168.0.15:443        0.0.0.0:*               LISTEN      7667/nginx -g daemo
tcp6       0      0 :::53                   :::*                    LISTEN      3483/dnsmasq
udp        0      0 0.0.0.0:53              0.0.0.0:*                           3483/dnsmasq
udp        0      0 0.0.0.0:68              0.0.0.0:*                           29477/dhcpcd
udp6       0      0 :::53                   :::*                                3483/dnsmasq

OK I detected a small but quite RELEVANT error:

The router (192.168.0.1) was still referring to 192.168.0.15 as DNS server (FritzBox --> IP settings --> IPv4 --> "Local DNS server"). I changed it to 192.168.0.9 (= pi.hole/lighttpd).

After ipconfig /release and ipconfig /renew on Windows machine DNS server now is 192.168.0.9.

Now curl -I http://doubleclick.com/test on the pi.hole pi gives:

HTTP/1.1 302 Found
Location: https://www.google.com/doubleclick/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Thu, 13 Apr 2017 21:33:39 GMT
Server: sffe
Content-Length: 232
X-XSS-Protection: 1; mode=block

Don´t know if this is a big improvement. What is the "final test" so I can check pi-hole is working as it should?

Is there a different output if you compare below 2 on a Windows client ?

nslookup doubleclick.com

&

nslookup doubleclick.com 192.168.0.15

Am getting confused now bout how you have setup things as am unfamiliar with Fritzbox settings.
If you want to use the DNS records provided by Pi-Hole as well as those coming from Fritsbox, you should chain the uplink DNS resolving path like so:

[Clients] --> [Pi-Hole] --> [Fritzbox] --> [ISP DNS servers] --> [Root DNS servers]

Configure Fritzbox to be the upstream DNS server for Pi-Hole and
on Fritzbox, revert upstream DNS settings back to default to use those provided by your ISP.

nslookup doubleclick.com
Server:  HostnameOf19216809
Address:  192.168.0.9

Name:    doubleclick.com
Addresses:  2a00:1450:4001:817::200e
          192.168.0.9


nslookup doubleclick.com 192.168.0.15
Server:  UnKnown
Address:  192.168.0.15

Name:    doubleclick.com
Addresses:  2a00:1450:4001:817::200e
          192.168.0.9

DNS setup is:

  1. Router (FritzBox) provides DNS server address (pi-hole) via DHCP to endpoints/clients
  2. Pi-hole: primary DNS is router/FritzBox, secondary a public DNS
    3) router/FritzBox: primary and secondary DNS other public DNS. Don´t use provider one´s anymore.

According to forward destination graph of pi-hole admin page 75% of DNS requests go to router, 25% to the public DNS.

So... what about a "final function test"? Is it the curl -I http://www.doubleclick.com/test ?

Remove the secondary public DNS upstream for Pi-Hole or you get responses from both so sometimes could be a wrong response.
Secondary doesnt mean it is only going to be used once the primary fails.

What would a "wrong response" look like?

I believe Fritzbox uses own records for particular things that I dont know of.
So if a Fritzbox specific name is queried by one of the clients, it could be that Fritzbox is not being asked to resolve but the other puclic DNS server is going to answer and he doenst know the Fritzbox records so you get "couldnt resolve" errors.

 $ nslookup bs.link
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find bs.link: NXDOMAIN

Okay, don´t wanna get (more) lost. Back to the roots or let´s call it "the last remaining issue":

The blocked page not showing up. I talked to a few friends of mine also running pi-hole on their networks and performed some tests with different browsers (on "zum Angebot" at Leifheit Dry&Clean Komplett-Set (51013) ab € 57,90 (2021) | Preisvergleich Geizhals Deutschland):

  • Firefox: "error: connection failed"
  • Chrome: Automatically closes ad tab
  • EDGE: Asks for closing the ad tab
  • IE: Asks for closing the ad tab
  • Safari on iDevices: Automatically closes ad tab

So that knowing AND already reached the state "other web service isn´t responding to pi-hole forwarding requests for ads" makes me feel "JAP, Pi-hole is finally working as it should (and/or does for other users)".

Try clearing browser cache and cookies.
And on the Windows clients, run below one to flush DNS cache:

ipconfig /flushdns

Or if that doesnt work, reboot the Windows client.

Doesn´t change anything. IE/EDGE based on Windows DNS cache (flushed it), Firefox uses it´s own DNS cache --> using DNS Flusher addon.

What do YOU guys see when trying to open 1) and/or 2) below in a specific browser?

  1. https://www.econda-monitor.de/link/st?emkd=2235083&pbid=1&advid=461&campaign=feed%2Fde%2F11006%2Fgeizhalsde%2F557885&target=https%3A%2F%2Fwww.hagebau.de%2Fp%2Fleifheit-fenstersauger-20-dry-clean-set-vs-an560460608%2F%3FitemId%3DB557885%26AffiliateID%3D300214%26utm_medium%3DPSM%26utm_source%3DGeizhals_de%26utm_campaign%3Dfenstersauger%26utm_term%3D557885
  2. https://ad.zanox.com/ppc/?35013701C330475540&ULP=[[557885&target=http%3A%2F%2Fsv.schwab.de%2Far%2F%3Fc%3D1%26id%3D40567%26ArticleNo%3D557885]]

?

For both with FF:

This site can’t be reached

Perfect. So I´m done. Pi-hole finally running as it should.

Cheers!

123456789 characters

For all of the times that it asks to close the tab, it reached the block page. However, there's some code which determines whether or not to show the full block page or just the empty response with the code to close the tab (don't show the full page if it's an in-page ad). Try going to the plain domain, and it should show the full block page.

Okay, got it. www.econda-monitor.de is showing the blocking page.

Just to summarize (e. g. for other users facing similar issues / having similar setups with other web services running on the Pi-hole Pi):

  1. Using a second IP address is the basis for a clean service separation (not only but especially when your other web service is running on ports 80 oder 443).
  2. Don't forget to set the same IP address as lighttpd uses for Pi-hole/dnsmasq. Easiest way is to reconfigure Pi-hole (pihole -r) and say NO to "do. you want to use the current IP settings as static IP address for Pi-hole?" and specifying the right IP settings.
  3. There are several places to check and/or edit when using two IP addresses:
    a) Lighttpd/Pi-hole Webserver config file
    b) nginx/other webservice webserver config file
    c) /etc/network/interfaces and/or /etc/dhcpcd/dhcpcd.conf files
    d) Browser Bookmark for Pi-hole
    e) /etc/pihole/adlists.list IF using additional hosts file (e.g. http://localhost/adhosts.txt where localhost needs to be changed to the lighttpd IP address)
    f) Router port forwarding in case your other web service is provided to the internet
    g) Router config for DNS server (hardly depending on how the Pi-hole DNS service is distributed to the clients - in my case the router points the clients to the Pi-hole)
  4. I'd also like to highlight I only use IPv4 and disabled IPv6.

So there are a few things to keep an eye on but at the end it's absolutely possible to run Pi-hole next to other web services on the same Pi without negative impacts.

Thanks to @Mcat12 and @deHakkelaar for their excellent support on this.

3 Likes

Nice summarizing things a bit.
I modded my posting a bit to have it more look like an HowTo with lots of sudo's and one liners:

Another information on why only Firefox handles some requests different (which results in error pages):

I didn´t find the right setting in uBlock addon yet but at least it´s a well documented behaviour.