Web Interface not reachable with pi.hole

Now that you mention it, it does appear to do so. The output is:

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-N 7260
   Physical Address. . . . . . . . . : ##-##-##-##-##-## (annonymized)
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::c492:9df4:c9e4:6075%18(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.12(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 15. september 2019 02:46:08
   Lease Expires . . . . . . . . . . : 15. september 2019 02:52:08
   Default Gateway . . . . . . . . . : 192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 142640882
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-23-F0-E8-F7-10-C3-7B-1B-F3-48
   DNS Servers . . . . . . . . . . . : 192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

At 192.168.0.1 is my router. I fail to see why my PC doesn’t go for 192.168.0.24 given that the output of pihole status is:

  [✓] DNS service is running
  [✓] Pi-hole blocking is Enabled

I have before your latest reply restarted both the router and the pihole. The same issue is observed when I attempt to access pi.hole/admin from my phone, too.

Your router does not appear to be passing the DNS of the Pi-Hole to your clients or the router is not correctly routing DNS queries to Pi-Hole. As a test, manually assign the DNS of Pi-Hole on the PC and see if that changes the output.

Good test. When I set it manually on my PC to the correct IP, I can access the web interface with the http://pi.hole/admin.

What is curious is that I have not changed anything on the router for it to suddenly stop announcing that DNS server.

I would reboot the router at least. Routers can do odd things with a power interruption, for example.

1 Like

I must have tried that so many times, I have lost count. Also with the server of the Pi-Hole. No luck.

Another weird thing is that even though I have assigned it a static IP with the router’s interface - see picture:

Assigned Static IP

the board itself does not appear under the current DHCP leases table. It does, however, use the correctly assigned IP, but apparently the router may have trouble recognizing it - see picture:

Current devices

The only way for me to get it to appear there is if I remote to it (since it’s headless) and run this:

$ sudo dhclient -r eth0 && sudo dhclient eth0

Then it appears like so:

Orange Pi Zero on DHCP List

but only until router is restarted or lease expires. It does not reacquire a new lease.

“IP Address Lease Reservation” is not the same as assigning a “static IP address”.
The first is really a reservation for clients that are configured to get IP details automatically via DHCP.
The later can only be configured on the client itself and if set, makes this device IP settings independent from DHCP.

When you run the Pi-hole installer, it will install the software package dhcpcd5 (if not installed already) to deal with network settings and applying them:

pi@noads:~ $ apt policy dhcpcd5
dhcpcd5:
  Installed: 1:6.11.5-1+rpt7
  Candidate: 1:6.11.5-1+rpt7
[..]

pi@noads:~ $ apt show dhcpcd5
[..]
Description: DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
 dhcpcd is a one stop network management daemon which includes
  * RFC compliant DHCPv4 and DHCPv6 clients
  * DHCPv6 Prefix Delegation support
  * IPv4LL (aka ZeroConf) support
  * ARP address conflict resolution
  * Link carrier detection
  * Wireless SSID profiles
  * ARP ping profiles

The installer also tries to set a static IP on the box thats running Pi-hole:

pi@noads:~ $ tail /etc/dhcpcd.conf
[..]
interface eth0
  static ip_address=10.0.0.2/24
  static routers=10.0.0.1
  static domain_name_servers=127.0.0.1

During boot, this is what happens:

pi@noads:~ $ journalctl -u dhcpcd
[..]
Sep 08 22:28:43 noads.dehakkelaar.nl systemd[1]: Starting dhcpcd on all interfaces...
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: dev: loaded udev
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: DUID xx:xx:xx
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: eth0: IAID xx:xx:xx:xx
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: eth0: using static address 10.0.0.2/24
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: eth0: adding route to 10.0.0.0/24
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: eth0: adding default route via 10.0.0.1
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30082]: forked to background, child pid 30098
Sep 08 22:28:43 noads.dehakkelaar.nl systemd[1]: Started dhcpcd on all interfaces.
Sep 08 22:28:43 noads.dehakkelaar.nl dhcpcd[30098]: eth0: soliciting an IPv6 router
Sep 08 22:28:55 noads.dehakkelaar.nl dhcpcd[30098]: eth0: no IPv6 Routers available

When you run sudo dhclient eth0 , it probably discards the active static IP configuration and tries to acquire IP details via DHCP for the given interface.
This is totaly unnecessary as Pi-hole is suppose to have a static IP assigned and not acquiring via DHCP.

Back to the issue of pi.hole not resolving on the clients, better post screenshots here from your router’s DNS and DHCP settings for us to have a look.
Or Switch off DHCP service on the router and enable DHCP service on Pi-hole as a replacement:

1 Like

Thank you deHakkerlaar for your very detailed answer! I learned something new from it.

The screenshots you requested, I have added just in my previous reply. I have only missed the DNS settings on my router, so I add them here now:

DNS Configuration

For completeness’s sake, here is the full configuration page under DHCP in my router:

Output from journalctl -u dhcpcd

root@orangepizero:~# journalctl -u dhcpcd
-- Logs begin at Sun 2019-09-15 20:29:20 CEST, end at Sun 2019-09-15 20:39:18 CEST. --
Sep 15 20:29:25 orangepizero systemd[1]: Starting LSB: IPv4 DHCP client with IPv4LL support...
Sep 15 20:29:26 orangepizero dhcpcd[767]: no interfaces have a carrier
Sep 15 20:29:26 orangepizero dhcpcd[693]: no interfaces have a carrier
Sep 15 20:29:26 orangepizero dhcpcd[693]: forked to background, child pid 826
Sep 15 20:29:26 orangepizero systemd[1]: Started LSB: IPv4 DHCP client with IPv4LL support.
Sep 15 20:29:26 orangepizero dhcpcd[826]: dummy0: waiting for carrier
Sep 15 20:29:26 orangepizero dhcpcd[826]: eth0: waiting for carrier
Sep 15 20:29:26 orangepizero dhcpcd[826]: dummy0: carrier acquired
Sep 15 20:29:26 orangepizero dhcpcd[826]: dummy0: adding address ####::###:###:####:####
Sep 15 20:29:27 orangepizero dhcpcd[826]: DUID ##:##:##:##:##:##:##:##:##:##:##:##:##:##
Sep 15 20:29:27 orangepizero dhcpcd[826]: dummy0: IAID ##:##:##:##
Sep 15 20:29:27 orangepizero dhcpcd[826]: dummy0: soliciting a DHCP lease
Sep 15 20:29:27 orangepizero dhcpcd[826]: eth0: carrier acquired
Sep 15 20:29:27 orangepizero dhcpcd[826]: eth0: adding address ####::####:####:####:####
Sep 15 20:29:27 orangepizero dhcpcd[826]: eth0: IAID ##:##:##:##
Sep 15 20:29:27 orangepizero dhcpcd[826]: eth0: using static address 192.168.0.24/24
Sep 15 20:29:27 orangepizero dhcpcd[826]: eth0: adding route to 192.168.0.0/24
Sep 15 20:29:27 orangepizero dhcpcd[826]: eth0: adding default route via 192.168.0.1
Sep 15 20:29:28 orangepizero dhcpcd[826]: eth0: removing route to 192.168.0.0/24
Sep 15 20:29:28 orangepizero dhcpcd[826]: eth0: removing default route via 192.168.0.1
Sep 15 20:29:28 orangepizero dhcpcd[826]: eth0: soliciting an IPv6 router
Sep 15 20:29:40 orangepizero dhcpcd[826]: eth0: no IPv6 Routers available

I find it weird it close to the end how it adds route to the correct IP (192.168.0.24) and then it removes it just two lines down. That behavior is unlike from your post. Could it be a clue to the problem?

Lastly, I would like to not have to resort to using the Pi-Hole’s DHCP service, as it used to work fine with that of my router for 1+ years.

1 Like

Alright, it appears your router is lacking a DHCP setting to push DNS servers to the clients.
It only allows you to configure the upstream DNS server for your router.
This setup should work but resulting in no stats being displayed on the admin web GUI for individual clients.
Only the router DNS queries will be logged and displayed!

Yes thats weird.
What are your routes now ?

pi@noads:~ $ ip r
default via 10.0.0.1 dev eth0 src 10.0.0.2 metric 202
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2 metric 202

Can you run below ones on a client device (Linux/Windows/MacOS) and post results here :

nslookup pi.hole 192.168.0.24

nslookup pi.hole 192.168.0.1

I am not certain that is the case. I have been running this exact same setup with this router for approx. 6 months now. The only difference has been updates to the Pi-Hole and the OS on the Orange Pi Zero. All devices on my wireless network used to be able to access pi.hole/admin - from phones, to Macs and PCs. I also had their queries logged in the Web UI. This issue new behavior I cannot track for the life of me. I looked closer based on what you said:

Only the router DNS queries will be logged and displayed!

and CURRENTLY, I believe you are correct because this is what I see in http://192.168.0.24/admin:

image

My routes when I run ip r are:

root@orangepizero:~# ip r
default via 192.168.0.1 dev eth0 src 192.168.0.24 metric 203
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.24 metric 203

Result of nslookup pi.hole 192.168.0.24 on a Windows 10 PC (a client in this scenario):

C:\WINDOWS\system32>nslookup pi.hole 192.168.0.24
Server:  orangepizero
Address:  192.168.0.24

Name:    pi.hole
Address:  192.168.0.24

Result of nslookup pi.hole 192.168.0.1 on same Windows 10 PC:

C:\WINDOWS\system32>nslookup pi.hole 192.168.0.1
Server:  UnKnown
Address:  192.168.0.1

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for pi.hole

Short answer, Pi-hole is working as expected … nothing wrong with Pi-hole.

Long, ipconfig /all shows the client is getting IP details via DHCP from 192.168.0.1.
This same router is pushing IP address 192.168.0.1 to the clients for DNS resolution and not Pi-hole’s address 192.168.0.24.
The client queries the router for pi.hole and the router should forward the query to Pi-hole and return answer to the client which it is not doing " No internal type for both IPv4 and IPv6 Addresses".

So trouble is in the router.
As nslookup shows, Pi-hole is working as expected.
Did you update firmware for the router ?
It might also be that your ISP pushed a firmware update or change.

Ps. routes seem to be ok so ignore :wink:

1 Like

I asked my ISP the same question about 6h ago over email, since they’re not working for the day. I expect they answer first thing tomorrow morning. It would be a major letdown if that were the case.

I will write back when I have more news. In the meantime, I am open to suggestions. The router’s brand is Sagemcom FAST3890V3 Rev:V3.0.

General info (hope nothing identifiable is present in the screenshot :smiley: ):
chrome_2019-09-15_22-12-37

One more I can think of, live tail the logs on Pi-hole (replace “<WIN10_PC_IP_ADDRESS>” with actual IP):

tailf /var/log/pihole.log | grep <WIN10_PC_IP_ADDRESS>

And run that query again on the WIN10 PC to see if it triggers a log response:

nslookup pi.hole 192.168.0.1

Yes, activate Pi-hole’s DHCP :wink:

1 Like

Running the tailf command produces no output as I browse the web with my PC. This leads me to conclude your earlier statement about the pi-hole not logging any of the clients’ activities is true.

Further, this:

Has no change in status. Result:

C:\Users\dimitar>nslookup pi.hole 192.168.0.1
Server:  UnKnown
Address:  192.168.0.1

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for pi.hole

I made mistake, it should have been below:

tailf /var/log/pihole.log | grep 192.168.0.1

Or better:

tailf /var/log/pihole.log | grep pi[.]hole

And run the nslookup again on PC:

nslookup pi.hole 192.168.0.1

Lets see if the router forwards the query to Pi-hole.

EDIT: added another tailf

Running tailf /var/log/pihole.log | grep 192.168.0.1 produces the following:

root@orangepizero:/etc/pihole# tailf /var/log/pihole.log | grep 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] www.facebook.com from 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] connect.facebook.net from 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] connect.facebook.net from 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] www.reddit.com from 192.168.0.1
Sep 15 22:49:16 dnsmasq[1130]: query[A] safebrowsing.googleapis.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditmedia.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditstatic.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditmedia.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditmedia.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gql.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gateway.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gql.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gql.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] preview.redd.it from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] googleads.g.doubleclick.net from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] www.googletagmanager.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] www.googletagservices.com from 192.168.0.1

HOWEVER, running CODE produces:

root@orangepizero:/etc/pihole# tailf /var/log/pihole.log | grep pi[.]hole
Sep 15 22:51:31 dnsmasq[1130]: query[A] pi.hole from 192.168.0.1
Sep 15 22:51:31 dnsmasq[1130]: /etc/pihole/local.list pi.hole is 192.168.0.24
Sep 15 22:51:51 dnsmasq[1130]: query[A] pi.hole from 192.168.0.1
Sep 15 22:51:51 dnsmasq[1130]: /etc/pihole/local.list pi.hole is 192.168.0.24

This last input I was only able to get when trying to access pi.hole/admin from the Windows 10 PC (client).

No change in the nslookup pi.hole 192.168.0.1:

C:\Users\dimitar>nslookup pi.hole 192.168.0.1
Server:  UnKnown
Address:  192.168.0.1

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for pi.hole

So it appears Pi-hole receives the query, answers correctly to the router, but the router not returning the expected reply to the client.
Am clueless.
Might be some safety feature/hidden setting etc.

1 Like

Thank you for your quick reply!

Might I bother you for an elaboration on how you reached that conclusion? I feel like there’s a learning opportunity here.

Look for DNS Rebind Protection. This is a feature that is designed for security and preventing a rogue DNS server on the local network from doing bad things. In our case though we want it to be able to answer queries and return local addresses.

1 Like

When you access pi.hole/admin in the browser, the browser looks up pi.hole against the DNS server(s) configured in ipconfig /all --> 192.168.0.1.
Same way as how nslookup does.
The router doesnt know the pi.hole domain so it forwards the query to Pi-hole as the logs show.
Pi-hole replies with the correct answer:
/etc/pihole/local.list pi.hole is 192.168.0.24”.

But your router doesnt:
No internal type for both IPv4 and IPv6 Addresses

But from the windows PC, it does reply:

1 Like

Its only pi.hole thats failing, other queries do get through.
Could this also be Rebind Protection ?