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

Alright, after a few weeks there´s only one thing freaking me out: from time to time the router mixes up the MAC-to-IP-binding for the system running pi-hole and other web services. I need to edit the static IP in the router (FritzBox) config and need to restart the pi (only restarting networking service or anything like that doesn´t work). I think it´s a FritzBox bug, unable to manage two IPs for one MAC address. It´s like a "race condition", and sometimes the wrong IP address wins... :frowning:

Try the "arp" command.
My router allows telnet so I can check ARP on Pi as well as router.

Ohw Ps, I managed to have the relevant Pi-Hole daemons running on the aliased interface instead of the physical:

My router doesn´t, so ARP is a one-side tool :frowning:

I installed pi-hole exactly like in the link described, only on eth0:0 instead of wifi interface.

Thats bummer.
But is it this simple to enable the Fritzbox telnet daemon ?

https://www.fritzmod.net/modification/telnet/

It says you have to connect phone and dial the numbers :smiley:

#96*7* Telnet einschalten
#96*8* Telnet ausschalten

Was thinking, if get in, and things go wrong again, below one will clear ARP so router and/or Pi need to rediscover MAC (try instead of reboot etc):

ip -s -s neigh flush all

Might need sudo.

UPDATE: Don´t read until the "UPDATE" section at the end, just ignore it...

It´s really strange. This time, the problem is slightly different:

After adding "sunmaker.com" and "www.sunmaker.com" to the blocking list (at least that´s the only trigger imaginable for me, because there´s no router involved this time), on a Windows machine a "nslookup piholeandwebservername" gave me:

Server:  sunmaker.com
Address:  192.168.0.9"

*** piholeandwebservername hasn´t been found by sunmaker.com: Non-existent domain.

So i did a "ipconfig /flushdns" and again nslookuped to the piholeandwebservername while tailing the pihole.log. That log told me:

dnsmasq[10323]: /etc/pihole/local.list 192.168.0.9 is piholeandwebservername

local.list content:
192.168.0.9 piholeandwebservername
192.168.0.9 pi.hole

So, QUIZ QUESTIONS:
1) Why the hell is local.list using 192.168.0.9 (and not 192.168.0.15 as it should) for the piholeandwebservername?!?
2) What triggers the creation of local.list content?

Instant workaround (editing local.list manually) didn´t help.

UPDATE:
Forget everything above. A closer look to tail pihole.log pointed out that pi.hole forwarded the DNS request to the router... which - again - told pi.hole that piholeandwebservername is 192.168.0.9 instead of 192.168.0.15...

So once again: no telnet or ssh or ANY other baseline access to the router. AVM killed the enabling/disabling using phone code in it´s firmware around 2015.

Update:

More debugging pointed out:

  1. Using FQDN is very important. "nslookup piholeandwebservername" is NOT the same like "nslookup piholeandwebservername.fritz.box"
  2. Specifing the DNS server helped a bit:

nslookup piholeandwebservername pi.hole

gave 192.168.0.9 --> WRONG (because pi.hole forwards the request to fritz.box)

nslookup piholeandwebservername fritz.box

gave 192.168.0.9 --> WRONG

nslookup piholeandwebservername.fritz.box pi.hole

gave 192.168.0.9 --> WRONG, BUT there´s a workaround:

a) Pi: nano /etc/pihole/local.list
b) Pi: Adding line "192.168.0.15 piholeandwebservername.fritz.box"
c) Pi: pihole restartdns
d) Windows endpoint: "ipconfig /flushdns" and now...

nslookup piholeandwebservername fritz.box fritz.box

still gives 192.168.0.9 --> WRONG, but:

nslookup piholeandwebservername.fritz.box pi.hole

now gives 192.168.0.15 --> RIGHT, because pi.hole uses the new line of local.list.

So finally: Not a nice workaround (especially because i still don´t know the root cause (what´s going on in the router/fritz.box?!?)), but at least it avoids rebooting the pi.

pihole -r

As described in the concept howto:

Basically that´s what I did (weeks ago already). The wrong IP for the webserver name comes from FritzBox als already mentioned.

Meanwhile I made my workaround (editing /etc/pihole/local.list) permanent with a "sudo chattr +i /etc/pihole/local.list" so it can´t be updated with wrong values, not even by root.

Will be excited to see what happens on the next pihole (core) update - just in case the setup/update routine tries to write the local.list.

But at the moment I´m quite happy with this "solution" and it seems I need to live with that because the router doesn´t properly handle the two IPs for my webserver/pihole machine.

The local.list file is written every time you run gravity, so it probably will work fine with the update.

A post was split to a new topic: Conflict with other port 80 services