Pihole and Nginx-proxy-manager

Project help
1

@klutchell, we’re trying to use both nginx proxy manager and pihole on the same project. But you used network_mode: host for both, which causes conflict.

We tried removing the host option and adding the ports for each service. But nginx-proxy-manager doesnt connect to the db and pihole has a conflict on port 53. Any tips?

2

Hi,

I think you may need to tinker a little bit in the sources.

In nginx-proxy-manager is a configuration file proxy/config.json that defines a mysql host as 127.0.0.1.
This works when running in network_mode: host because it can see the port exposed by the db service on the host OS.
If you’re dropping the network_mode: host, the loopback device no longer refers to the HostOS.
Without network_mode: host, the proxy service should be running on the same network as the db service.
Changing the mysql host entry to db so it will use the container directly, rather than the loopback device, should work then.
Strictly speaking, you shouldn’t even need the exposed port on the db service in this scenario (but it causes no harm).

I don’t have a solution for port 53 (DNS) (yet) as I’ve never worked with pihole before.

1 Like
3

Thanks for the suggestion @tjvv, I wasn’t aware that nginx-proxy-manager hardcoded the database address so that’s good to know!

Pi-hole still requires the host network since exposing port 53:53 via docker-compose will result in attempting to bind to 53 on all interfaces, but this will conflict with the hostOS dnsmasq service. You will see logs similar to this if you try binding port 53:53 for any service (not just Pi-hole).

Nov 11 14:04:14 pihole balenad[14560]: time="2021-11-11T14:04:14.904055785Z" level=error msg="Handler for POST /containers/79192fc3d6fbc53853a91052471a281ebb4b1a1e34e9dcdb906378c83c3bcedf/start returned error: driver failed programming external connectivity on endpoint pihole_4230096_1977002 (fa4dfa73f8c17e9afa72955647b3aac36fc7d7e2d71d1cdc6b319d0bc0f62875): Error starting userland proxy: listen tcp 0.0.0.0:53: bind: address already in use"
Nov 11 14:04:14 pihole f1867163f3fd[14560]: [error]   Scheduling another update attempt in 256000ms due to failure:  Error: Failed to apply state transition steps. (HTTP code 500) server error - driver failed programming external connectivity on endpoint pihole_4230096_1977002 (fa4dfa73f8c17e9afa72955647b3aac36fc7d7e2d71d1cdc6b319d0bc0f62875): Error starting userland proxy: listen tcp 0.0.0.0:53: bind: address already in use  Steps:["start"]

A workaround for single device deployments is to hardcode the desired external interface in docker-compose, but this obviously isn’t scalable unless you have the same static IP for every device in the fleet.

services:
  # https://hub.docker.com/r/pihole/pihole
  pihole:
    build: pihole
    privileged: true
    volumes:
      - "pihole_config:/etc/pihole"
      - "dnsmasq_config:/etc/dnsmasq.d"
    dns:
      - "127.0.0.1"
      - "1.1.1.1"
    # network_mode: host
    ports:
      - "192.168.1.100:53:53/tcp"
      - "192.168.1.100:53:53/udp"
    labels:
      io.balena.features.dbus: "1"

Assuming your eth0 IP address is 192.168.1.100, this configuration avoids conflicts and allows bridge networking.

1 Like
5

If you keep Pi-hole in host networking mode and set the WEB_PORT environment variable to something other than 80 you should be able to avoid conflicts. Let us know if this works!

1 Like
7

Thank you very much @TJvV and @klutchell, yall are awesome :tada:

Changing proxy/config.json to db instead of 127.0.0.1 did the trick for nginx-proxy-manager. And setting the WEB_PORT for a different port enabled us to use host networking mode.

We’re almost there. But for some reason pihole is now conflicting with balena-engine’s dnsmasq. Inside the device, if I stop dnsmasq with systemctl stop dnsmasq everything works.

So only challenge left is: why is pihole suddenly conflicting with the engine’s dnsmasq?

8

Hey @luandro, I’m working on a better solution to this but for now make sure that you have the INTERFACE=eth0 and DNSMASQ_LISTENING=single environment variables for the Pi-hole service and it should avoid conflicts.

We are specifically setting the Pi-hole dnsmasq instance to bind-interfaces which should avoid it binding to all and instead bind to the provided interface only.

1 Like
9

@klutchell I owe you a beer :beers: That did the trick, thank you very much!

10

Glad to hear it worked out! Let me know next time you’re in Canada and we’ll talk!

Cheers, Kyle

1 Like
12

Hey @klutchell I’ve shifting from Pi-Hole to using AdGuard Home, which I’ve seen you have also worked on.

I’m experiencing a similar problem to what I was having with Pi-Hole around conflict on port 53:

adguard [fatal] couldn't start forwarding DNS server: starting listeners: listening to tcp socket: listen tcp 0.0.0.0:53: bind: address already in use

Having AdGuard as host doesn’t seem to be solving the problem, any suggestions?

This is the repository I’m working from:

13

Hey @luandro , you should be able to run in host networking mode but as part of the initial setup you need to only bind to port 53 on a specific interface, like eth0 or wlan0, to avoid conflicting with ports on the resin VPN interface.

Check out the initial setup, step 3, on my README.

If you try to bind ports in the format 53:53 it will fail as one of the interfaces has that port in use, and if you use host networking and use the default option of “all interfaces” you will have the same issue.

3 Likes