Pi-Hole Admin page only accessible through http://ip/admin

Help
1

Expected Behaviour:

I expect to be able to go to http://pi.hole/admin to see the admin page. Currently I can only access it via the IP Address. E.G. http://ip_addr/admin This leads me to believe that I may have an issue with my installation.

Actual Behaviour:

I get an unable to connect error in firefox. Going directly to the IP causes no problems.

Debug Token:

https://tricorder.pi-hole.net/PHoMeNgg/

I am running Pi-hole via docker on Ubuntu Server 22.04LTS. Currently it is the only docker image running.

Router used is the ASUS RT-AX68U. I have followed their FAQ article to add the Pi-hole DNS. That FAQ is here. https://www.asus.com/support/FAQ/1046062/
My firmware is in the > category. I have the Pi-hole DNS setup under WAN and LAN although it was still not working when under LAN only.

I have also followed the netplan settings in the Github docker Readme.

My local device is running Kubuntu 23.04. I have also added the server IP as a DNS there as well.

I know that Pi-hole is working to some extent. I had to add a domain name for the router in order to be able to access it. I.E. router.asus.com that pointed to the router IP.

Here are some commands that I have seen requested in other forum posts to hopefully help as well.

This is ran on a local device NOT running Pi-hole.

>nslookup pi.hole
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   pi.hole
Address: 0.0.0.0

On the Ubuntu Server

>nslookup pi.hole
Server:         ::1
Address:        ::1#53

Name:   pi.hole
Address: 0.0.0.0

Ping from device NOT running Pi-hole

> ping pi.hole
PING pi.hole (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.051 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.064 ms
^C
--- pi.hole ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms
rtt min/avg/max/mdev = 0.045/0.053/0.064/0.007 ms

Thanks for any suggestions.

2

This is typically an indicator that the client is not using Pi-hole for DNS. Only the Pi-hole software will properly resolve the domain name pi.hole to the Pi-hole IP. When you use the IP directly, no domain name resolution is required.

This client is not using Pi-hole for DNS - it is using a DNS on the loopback address on the device.

From a client that you believe should be connected to the Pi-Hole for DNS (in this case, the client in question, if different than the client above), from the command prompt or terminal on that client (and not via ssh or Putty to the Pi), what is the output of

nslookup pi.hole

nslookup flurry.com

3

Thanks for the quick reply!

The nslookup you quoted was from a device in the network that should be using Pi-hole as its domain name server. After re-reading my original post I realize I could have communicated that in a better manner. For posterity I reran that again along with the other command requested. Both of these was ran on a separate device on the network than the one running Pi-hole, but should be using the Pi-hole. SSH wasn't used.

>nslookup pi.hole
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   pi.hole
Address: 0.0.0.0

>nslookup flurry.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   flurry.com
Address: 0.0.0.0
Name:   flurry.com
Address: ::

I do have some indications that I am using Pi-hole for the DNS server which is what lead to my original confusion when I was searching for other topics on the issue related to this. I just ran the test outlined below.

  1. Went to google and gmail accounts successfully.
  2. Went to the domains tab and added a wildcard domain blacklist for google.
  3. After clearing caches and waiting a minute or so I can no longer reach www.google.com or my gmail bookmark.
  4. Removed the google blacklist.
  5. Waited a minute or so and now I can access google and my gmail account.

While trying to access the sites during the blacklist period, Pi-hole shows that these blocked domains were trying to be accessed under queries section. It shows that it blocked them because of the blacklist.

Note: I added the XXX's to the IP address before posting.

2023-06-25 17:51:13 	AAAA	www.google.com	192.168.XX.XXX	Blocked (regex blacklist)	IP (0.0ms)
2023-06-25 17:51:09 	AAAA	mail.google.com	192.168.XX.XXX	Blocked (regex blacklist)	IP (0.0ms)

Pi-hole also shows that I have 9 clients connected which is the same number that my router lists.

I'm also only able to access router.asus.com after adding an A record (I think thats what its called) in Pi-hole.

I hope some of this information is helpful. I'm going to look into why I am using a local domain for my DNS on my client device since that seems weird.

4

This is a known issue with allot of Asus routers with stock firmware:

5

On the same machine you tested before, what is the output of cat /etc/resolv.conf?

6 
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

I guess that explains the nslookup results? I guess the UI in KDE didn't configure my DNS correctly. I'll try to apply it through netplan.

I changed the nameserver to point to the ubuntu server running Pi-hole and got the following.

Server:         192.168.XX.X
Address:        192.168.XX.X#53

Name:   pi.hole
Address: 0.0.0.0

I was still unable to access http://pi.hole/admin

7

Note that I did make the change manually in /etc/resolv.conf and not through netplan.

8

Please post the compose file or docker run command used to start the container (just hide the password, if set).

9

systemd-resolve --status

?

10

Here is the results of my docker-compose.yml

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "80:80/tcp"
      - "443:443"
    environment:
      TZ: 'America/Chicago'
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    restart: unless-stopped
11

Thats a weird search domain I've never seen before.

EDIT: Ow its seems normal if no search/suffix domain is supplied/configured:

pi@ph5b:~ $ man resolv.conf
[..]
       search Search list for host-name lookup.
              By  default,  the search list contains one entry, the local
              domain name.  It is determined from the local hostname  re‐
              turned by gethostname(2); the local domain name is taken to
              be everything after the first '.'.  Finally, if  the  host‐
              name  does not contain a '.', the root domain is assumed as
              the local domain name.
12

Wait...

You don't need to do this for private IP addresses (like 192.168.50.1).

Your debug log shows your Pi-hole is using 192.168.112.2.
It also shows 2 devices making queries to Pi-hole: 192.168.50.104 and 192.168.50.1.

Are you sure the Pi-hole IP is on the same subnet of your other machines?

13

Good point.

My LAN subnet is 50 so 192.168.50. The machine the Pi-hole docker container is running on is at 192.168.50.3.

I thought this would be expected since Pi-hole is running in docker? The docker container would have its own network that I forward ports to. My networking knowledge is still in the early stages though so I could possibly be misunderstanding something.

I also downloaded chrome and tried using that and got the same results. (I wanted to rule out my browser as the root cause)

Thanks again for all the help everyone.

14

Sorry, I missed this reply. I saw your other one but I'm still unpacking it. I'm wondering if the router is the cause now.

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Sun 2023-06-25 11:40:29 CDT; 7h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 485 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18868)
     Memory: 7.0M
        CPU: 2.424s
     CGroup: /system.slice/systemd-resolved.service
             └─485 /lib/systemd/systemd-resolved

Jun 25 11:40:29 shraan systemd-resolved[485]: Using system hostname 'shraan'.
Jun 25 11:40:29 shraan systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 25 11:40:33 shraan systemd-resolved[485]: wlp59s0: Bus client set default route setting: yes
Jun 25 11:40:33 shraan systemd-resolved[485]: wlp59s0: Bus client set DNS server list to: 192.168.50.3
Jun 25 11:40:33 shraan systemd-resolved[485]: wlp59s0: Bus client set search domain list to: XXXX.io
Jun 25 12:14:41 shraan systemd-resolved[485]: wlp59s0: Bus client reset search domain list.
Jun 25 12:24:33 shraan systemd-resolved[485]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.50.3.
Jun 25 12:29:01 shraan systemd-resolved[485]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.50.3.
Jun 25 12:51:37 shraan systemd-resolved[485]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.50.3.
Jun 25 15:23:58 shraan systemd-resolved[485]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 192.168.50.3.

Note: This was ran on a client device that is expecting to use the Pi-hole as the DNS NOT the server running it.

15

I got this from the ASUS documentation. I am undoing it now. I'm still unpacking the rest of this message.

16

Is above 192.168.50.3 IP Pi-hole?

17

Yes that's the IP of the Ubuntu server running Pi-hole.

Edit: Added quote for posterity and readability.

18

Is it actually Pi-hole thats answering?

dig +short @192.168.50.3 chaos txt version.bind

Eg:

pi@ph5b:~ $ dig +short @10.0.0.4 chaos txt version.bind
"dnsmasq-pi-hole-v2.87rc1"
19

I ran that in the terminal and got:

"dnsmasq-pi-hole-v2.89-9461807"
20

When I have ran block test that I mentioned a few posts up I can see my client IP in the Pi-hole logs.