Pihole server can't connect to the internet. Other devices on the network are properly connected

Expected Behaviour:

I am using a Jetson Nano running Ubuntu 18.04.6 LTS with a static IP address. The nano is connected to the network using a ethernet cable. I got pihole up and running by using the docker image and instructions from docker-pi-hole. Because I am running on Ubuntu, I ran into the issue of port 53 being already in use by systemd-resolved. I got around that by following the steps mentioned on the Installing on Ubuntu section which asks me to run the following commands:

sudo sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf
sudo sh -c 'rm /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf'
systemctl restart systemd-resolved

As a result of these steps, I am able to start the pihole container.

Actual Behaviour:

Once I start the container, I am able to access the pihole website. Once I change the settings on my router to use the pihole as the DNS, my Nano (running the pihole container) can no longer connect to the internet. Interestingly, pihole seems to be functioning properly, which means I see requests from other devices on the network coming in, being allowed or blocked based on the gravity list. Only the nano itself cannot connect to the internet.

Result of ping 1.1.1.1:

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6149ms

Result of route (router's LAN IP is 192.168.0.1)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    20100  0        0 eth0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-a7381256f38d
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

Contents of /etc/resolv.conf:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must 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 1.1.1.1
nameserver 192.168.0.193
nameserver 192.168.10.254

The 1.1.1.1 nameserver is in there because I changed /etc/systemd/resolved.conf to:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
DNS=1.1.1.1
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
DNSStubListener=no

hoping that having 1.1.1.1 as the nameserver might solve issues. No luck.

If i remove the pihole server as the DNS, the nano is able to connect to the internet again, though of course nothing's using pihole anymore. I've been trying to solve this issue looking at other topics, but no luck as well. Can't seem to figure out what I'm doing differently that leads to issues.

Debug Token:

Can't run pihole -d cause no internet on the pihole server.

This is a networking issue.
pinging an IP address demonstrates that DNS is not involved here.
Your result indicates that the machine it was run on cannot communicate with 1.1.1.1.

Usually, this would suggest that a firewall is interfering (on that device, on your router or a dedicated firewall machine).

If it was a firewall issue wouldn't it persist regardless of whether the pihole is used as the DNS or not?
Currently, if i switch the router settings to not use the pihole as DNS, internet connection is restored in the pihole server.

Your router's DNS configuration has no impact on your ping to 1.1.1.1.
As ping already knows the IP, it wouldn't employ DNS (nor any other hostname resolution method).

Your resolv.conf has three nameserver entries.
Two of them are for a private IPv4 (but note those IPs would be on different /24 subnets).
Your host may try any of them for DNS, perhaps succeeding with one occasionally.

Without a debug log, I can't tell whether those two would be reachable from your host or point to the host itself.

Do they answer to pings?
Do they answer to DNS requests, e.g.

nslookup pi.hole 192.168.0.193

pihole -d can be run regardless of connectivity, it's just the upload that would fail without. The log is stored locally and can be inspected at /var/log/pihole/pihole_debug.log.

And as you state:

Could you please upload a debug log and share just the token?

I understand the problem isn't with the DNS. I have added the debug log here. I also tried to do nslookup from another device in the LAN and I get:

$ nslookup pi.hole 192.168.0.193
Server:  UnKnown
Address:  192.168.0.193

Name:    pi.hole
Address:  0.0.0.0

192.168.0.193 is the host itself. I am able to ping the host (running the pihole docker container) without issues.

Can you please also post your compose file (or docker run command) used to start the container?

This will help us understand if something is missing.

That's only applicable for your ping of 1.1.1.1.

We haven't yet established whether that would also be true for the other two DNS servers that your host is using.

Your debug log shows that your Docker container has no public connectivity, just like its host:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] dobykart.com is 0.0.0.0 on lo (127.0.0.1)
[✓] dobykart.com is 0.0.0.0 on eth0 (172.18.0.2)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

That would match your pihole.log excerpts showing Pi-hole to forward requests to its 8.8.8.8 and 8.8.4.4 upstreams, but not containing any upstream replies, e.g.:

   -----tail of pihole.log------
   Mar 19 21:48:31 dnsmasq[229]: query[A] ctldl.windowsupdate.com from 192.168.0.170
   Mar 19 21:48:31 dnsmasq[229]: forwarded ctldl.windowsupdate.com to 8.8.8.8
   Mar 19 21:48:34 dnsmasq[229]: query[A] ns1.pi-hole.net from 172.18.0.1
   Mar 19 21:48:34 dnsmasq[229]: forwarded ns1.pi-hole.net to 8.8.8.8
   Mar 19 21:48:37 dnsmasq[229]: query[A] connectivity-check.ubuntu.com from 192.168.0.193
   Mar 19 21:48:37 dnsmasq[229]: forwarded connectivity-check.ubuntu.com to 8.8.8.8
   Mar 19 21:48:37 dnsmasq[229]: forwarded connectivity-check.ubuntu.com to 8.8.4.4
   Mar 19 21:48:37 dnsmasq[229]: query[AAAA] connectivity-check.ubuntu.com from 192.168.0.193
   Mar 19 21:48:37 dnsmasq[229]: forwarded connectivity-check.ubuntu.com to 8.8.8.8
   Mar 19 21:48:37 dnsmasq[229]: forwarded connectivity-check.ubuntu.com to 8.8.4.4

I'd guess that ping 8.8.8.8 would also fail, and together, that would reinforce my previous assumption that

Since we now know that neither 1.1.1.1 nor your Pi-hole at 192.168.0.193 are able to provide DNS, the remaining working nameserver from your resolv.conf is 192.168.10.254.

I'd be surprised if that IP would not belong to your router.

If I'm guessing right and it is, that could explain your observation, provided that the router settings you are referring to would configure your router's upstream DNS servers (in contrast to configuring the local DNS server your router tells its clients to use).

If you point your router's upstream to Pi-hole, your Pi-hole host would try the following DNS resolution chains:
client -> 1.1.1.1 = unreachable, doesn't work
client -> 192.168.0.193 (Pi-hole) -> 8.8.8.8 = unreachable, doesn't work
client -> 192.168.10.254 (router) -> 192.168.0.193 (Pi-hole) -> 8.8.8.8 = unreachable, doesn't work

Now, if you point your router to a public DNS (e.g. 9.9.9.9), the resolution attempts would be the same, apart from the last line, which would become:
client -> 192.168.10.254 (router) -> 9.9.9.9 = success

To address your issue, you have to allow your Pi-hole host to connect to public DNS servers.

In addition, you could consider to configure your router to distribute Pi-hole as local DNS server via DHCP (often, a LAN/DHCP kind of setting), instead of having your router use Pi-hole as upstream.
This would also allow you to attribute DNS requests to individual client IPs.

However, it would depend on your router whether it exposes such a setting.
Not all router models would do so.
If yours isn't, you could consider to disable your router's DHCP server and enable Pi-hole's. Your Pi-hole host would need a static IP address configured directly on the host in that case.

Noted! from what i understand, things should work if my pihole host is allowed to connect to public DNS servers like 1.1.1.1?
any idea what might be preventing it from doing so? I already updated the firewall rules as suggested in the docs, though i ran the commands on the host, and not inside the docker container.

Yeah if nothing else works i guess i'll have to use the pihole as the DHCP server.

Thanks for helping me debug this :slight_smile: .

Compose file is below:

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"
      - "80:80/tcp"
    environment:
      TZ: 'TIMEZONE_HERE'
      WEBPASSWORD: 'PASSWORD_HERE'
    # 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

Just to check, wouldn't the same logic apply to any other device connected on the network? This would then mean that no device on the LAN would be able to access the internet. But in my case the other devices are able to access interent even when the router's upstream is set to pihole.

We are dealing with your host's DNS servers as defined via /etc/resolv.conf here, so your Docker container isn't involved.

Your router's firewall (or a dedicated firewall gateway) could block those requests, or perhaps divert them according to some custom static route definitons.

Enabling Pi-hole's DHCP server is a last resort measure to achieve that clients talk directly to Pi-hole for DNS.
It won't fix your issue communicating to 1.1.1.1.

Only if your router's DHCP server would distribute the exact same set of DNS server to clients.

We have discussed DNS resolution of your Pi-hole host OS, as defined by its resolv.conf. Pi-hole doesn't touch that file.

On your system, it's contents is managed by systemd-resolved.
Usually, that would pick up DNS servers from your router's DHCP server.

As your other DHCP clients do not ecnounter the same DNS resolutiion issues, that would indicate that they are not using the same set of DNS servers. My guess would be that they just use your router's 192.168.10.254, but you should be able to verify that on a client.

This in turn would suggest that the DNS servers on your machine hosting Pi-hole has been amended, either manually or by some other software.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.