Issues Getting Clean Setup; Pihole in Docker on Arch Host

iamstevedavis · May 28, 2022, 5:56am

The issue I am facing:
Hello,

I am setting up Pihole using docker. I am having a myriad of issues where the pihole is not blocking anything and decided to try and debug. It looks like for some reason I have a lot of port issues in my debug logs and I suspect this is probably the root of my issues. I followed the guide here: GitHub - pi-hole/docker-pi-hole: Pi-hole in a docker container because it applies to Arch as well. It has not seemed to really help much and I am still seeing all these ports blocked, where pihole is reporting issues.

Debug Logs:
[✓] Your debug token is: https://tricorder.pi-hole.net/GfAISmxJ/

Details about my system:
I am running pihole in docker on Arch. I am not sure what I can say about it - it is a vanilla install straight from the arch website. Let me know if there is any additional info I can provide here about the host system.

Here is a docker ps with pihole running:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
97b5e38851a4 pihole/pihole:latest "/s6-init" 48 minutes ago Up 8 minutes (healthy) 0.0.0.0:53->53/tcp, 0.0.0.0:53->53/udp, :::53->53/tcp, :::53->53/udp, 67/udp, 0.0.0.0:9999->80/tcp, :::9999->80/tcp pihole

Here is my compose file:

  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: kiwi.hole
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      # If port 53 is in use - https://github.com/pi-hole/docker-pi-hole#installing-on-ubuntu
      - "53:53/tcp"
      - "53:53/udp"
      # - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "9999:80/tcp"
    environment:
      TZ: "America/Toronto"
      WEBPASSWORD: ''
      VIRTUAL_HOST: 'kiwi.hole'
      DNS_BOGUS_PRIV: 'true'
      DNS_FQDN_REQUIRED: 'true'
      REV_SERVER: 'true'
      REV_SERVER_DOMAIN: 'local'
      REV_SERVER_TARGET: '192.168.1.1'
      REV_SERVER_CIDR: '192.168.1.0/24'
    labels:
        # Not recommended, I know
        com.centurylinklabs.watchtower.enable: "true"
    # Volumes store your data between container upgrades
    volumes:
      - "/mnt/usb/v/pihole/etc/etc-pihole:/etc/pihole"
      - "/mnt/usb/v/pihole/etc/etc-dnsmasq.d:/etc/dnsmasq.d"
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities

Permissions on the mounted volume are 777 and pihole created the folders there as root root. I got help with that here and it is now an ext4 formatted drive.

Here is the startup from pihole docker

Attaching to pihole
pihole  | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
pihole  | [s6-init] ensuring user provided files have correct perms...exited 0.
pihole  | [fix-attrs.d] applying ownership & permissions fixes...
pihole  | [fix-attrs.d] 01-resolver-resolv: applying... 
pihole  | [fix-attrs.d] 01-resolver-resolv: exited 0.
pihole  | [fix-attrs.d] done.
pihole  | [cont-init.d] executing container initialization scripts...
pihole  | [cont-init.d] 05-changer-uid-gid.sh: executing... 
pihole  | [cont-init.d] 05-changer-uid-gid.sh: exited 0.
pihole  | [cont-init.d] 20-start.sh: executing... 
pihole  |  ::: Starting docker specific checks & setup for docker pihole/pihole
pihole  | cap[cap_sys_nice] not permitted
pihole  | 
pihole  |   [i] Installing configs from /etc/.pihole...
pihole  |   [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [✓] Installed /etc/dnsmasq.d/01-pihole.conf
  [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
pihole  | Existing DNS servers detected in setupVars.conf. Leaving them alone
pihole  | ::: Pre existing WEBPASSWORD found
pihole  | DNSMasq binding to default interface: eth0
pihole  | Added ENV to php:
pihole  | 			"TZ" => "America/Toronto",
pihole  | 			"PIHOLE_DOCKER_TAG" => "2022.05",
pihole  | 			"PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
pihole  | 			"ServerIP" => "0.0.0.0",
pihole  | 			"CORS_HOSTS" => "",
pihole  | 			"VIRTUAL_HOST" => "kiwi.hole",
pihole  | Using IPv4 and IPv6
pihole  | ::: setup_blocklists now setting default blocklists up: 
pihole  | ::: TIP: Use a docker volume for /etc/pihole/adlists.list if you want to customize for first boot
pihole  | ::: Blocklists (/etc/pihole/adlists.list) now set to:
pihole  | https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
pihole  | ::: Testing lighttpd config: Syntax OK
pihole  | ::: All config checks passed, cleared for startup ...
pihole  | ::: Enabling Query Logging
pihole  |   [i] Enabling logging...
  [✓] Logging has been enabled!
pihole  |  ::: Docker start setup complete
pihole  |   Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
pihole  |   Pi-hole version is v5.10 (Latest: v5.10)
pihole  |   AdminLTE version is v5.12 (Latest: v5.12)
pihole  |   FTL version is v5.15 (Latest: v5.15)
pihole  |   Container tag is: 2022.05
pihole  | [cont-init.d] 20-start.sh: exited 0.
pihole  | [cont-init.d] done.
pihole  | [services.d] starting services
pihole  | Starting pihole-FTL (no-daemon) as pihole
pihole  | Starting crond
pihole  | Starting lighttpd
pihole  | [services.d] done.

What I have changed since installing Pi-hole:
Not much outside of what is recommended and what I have shared.

I got such great help last time, I really do want to put all the effort I can into fixing this. I have a lot of my stuff moved to docker now and this is one of the last pieces. I am willing to post any info or investigate any links anyone can share!

Thank you all.

Bucking_Horn · May 28, 2022, 7:56am

For Docker (or any other virtualised environment), the debug log may be less informative and conclusive than for a bare metal installation, due to limitations imposed by virtualisation.
Your Ports in use section seems affected here, so it likely isn't accurate, as other diagnostics from the same log confirm your Pi-hole to be operational.

Arch Linux is not officially supported by Pi-hole, and Pi-hole itself does not offer any software on Arch Linux. However, Arch Linux themselves maintain a Pi-hole package, see Pi-hole - ArchWiki.

Anyway, from your docker-compose, it would seem you are using the official Pi-hole Docker image, and the guide you've followed applies to Docker in general, regardless of the OS hosting Docker, unless mentioned otherwise.

It would seem you missed the recommendation to set FTLCONF_REPLY_ADDR4.

I don't know whether that would contribute to your issue, mainly because I'm not sure I understand your issue well enough yet.

Could you provide an example here?

Also, run from a client that you expect to use Pi-hole for DNS, what is the output of:

nslookup pi.hole

nslookup flurry.com

iamstevedavis · May 28, 2022, 12:55pm

Bucking_Horn thank you for taking the time to help me out!

Ah okay. I did not know this. The last few years I have been running pihole on an actual raspberry pi so I think maybe my expectations here are wrong if that is the case.

Ah, yes. Sorry what I said was confusing. My host OS is Arch but my docker image is official as you mentioned. From that guide I specifically wanted to point out the part about systemd-resolved being something I had to do in case it was relevant to anything in my logs.

I will make this update, I did miss that 100% - thanks!

I am sorry, reading through again I realize I was not 100% clear on my issue here. Let me clarify. The last few years I have been running pihole on an actual pi. Pi died so I migrated it to this little thin client I have repurposed for a few menial tasks on my home network. In the time of pihole on pi I experienced block rates of about 20 - 25% - hundreds of thousands of queries and tens to hundreds of thousands of blocks. Since I migrated I have noticed that the block rate is like .5% to 1% and I am seeing ads all over the places on devices that would have previously not had any. I could see that entries in the query list were green for domains that seemed to be one that should be blocked. Maybe I am misunderstanding what I am seeing, or my expectations are off, but in my experience over the last few years with a functional pihole I would generally not see things like this getting through.

This is what I got:

[steve@friday ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.137
[steve@friday ~]$ nslookup pi.hole
Server:		192.168.1.137
Address:	192.168.1.137#53

Name:	pi.hole
Address: 0.0.0.0

[steve@friday ~]$ nslookup flurry.com
Server:		192.168.1.137
Address:	192.168.1.137#53

Name:	flurry.com
Address: 0.0.0.0
Name:	flurry.com
Address: ::

[steve@friday ~]$

I wanted to add that I have reverted my DNS server in my router - it hands our 8.8.8.8 now while I am messing with the pihole but normally I have it setup to hand out JUST the pihole ip 192.168.1.137 which is set as a static ip. I am setting the pihole as dns only for specific clients while I diagnose the issue. Just in case you see something that indicates otherwise, wanted to clear that up.

One point of clarity - my interface settings. I have set that to Permit All Origins which I believe I had read somewhere in the docs (I can't find it now) is required for Docker Pihole. Is that correct?

Bucking_Horn · May 29, 2022, 5:59am

Were those nslookups run from a client or from your Docker machine hosting Pi-hole?

pi.hole should have been answered with an IP, so I guess that was run when FTLCONF_REPLY_ADDR4 was still absent.

flurry.com correctly returned 0.0.0.0, confirming that Pi-hole's blocking is operational, at least for the machine that issued the DNS request.

Blocking percentages can be expected to fluctuate over time.
By themselves, they wouldn't be a reliable indication.

Did the number of DNS requests also drop significantly?

Together, that could suggest that DNS requests may be going elsewhere, by-passing Pi-hole.

The nslookups I asked you to run are also meant to reveal whether a client would send its requests to another DNS server.
Running ipconfig /all on a Windows client and scrutinising the output's DNS server section could also help to verify whether clients are indeed using only Pi-hole's IPs for DNS.

Not related to your observation, but I also noticed you are using .local as your local domain.
You should change that, as .local FQDNs are reserved for usage by the mDNS protocol as implemented e.g. by Apple's Bonjour or Linux' avahi.

iamstevedavis · June 1, 2022, 1:18pm

These were run on my laptop, I added the output from resolv.conf in that reply just to show that it was indeed using the pihole static IP as the dns server. Oddly enough, that was run after I made that change. In my docker-compose.yml I now have:

      FTLCONF_REPLY_ADDR4: '192.168.1.137'

I actually implemented some NAT policies that route any traffic on port 53 directly to the pihole, if the router is the destination, in addition to having the pihole set as my sole DNS provider in my router. The queries have not dropped and are still high.

Wow thank you. I did not know this, today I learned! I will make this change.

I have been messing around a bit and my block rate seems to have jumped up to about 16%. One of the changes I made was to ownership of /mnt/usb where the volume is stored for pihole's container. Does the pihole require write access to that location in order to function? I am wondering if it did not have access to write previously and now it does which has caused it to start functioning correctly...?

Bucking_Horn · June 2, 2022, 10:00am

Did you restart the container for settings to take effect?

Pi-hole's dashboard statistics are exclusively in-memory.

If I read you correctly, DNS requests to public DNS servers could still by-pass Pi-hole.

I don't quite recall if your network had IPv6 connectivity, but still:
Do those NAT rules cover IPv6 as well?

If not, your IPv6-capable clients may be able to by-pass Pi-hole via your router's IPv6 address.
This would also apply if your network were link-local IPv6 only (i.e. only range fe80::/10 addresses for clients, and your router has no public IPv6 connectivity).

By default, most routers would advertise their own IPv6 address as local DNS server, but not all routers would expose respective configuration options.

On a Windows client, a look at the DNS server section of ipconfig /all should reveal whether an IPv6 DNS server address is in use on your network.

system · June 23, 2022, 10:00am

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