Trouble with number of clients when running under Docker

Please follow the below template, it will help us to help you!

Expected Behaviour:

One client per device on the 'extended' network.

Actual Behaviour:

Only 3 clients - the modem, "Docker" and my laptop (with pi-hole manually set as the DNS server).

I know very similar questions have been asked before, but my setup is different to those, and those solutions didn't help. I have a Windows box running Ubuntu under VirtualBox, and pi-hole is running in a Docker container therein. My home network is 192.168.0., but within Docker the containers are 172.30.33. or 172.17.0.*. I want all of the devices to be listed in pi-hole because some are doing 400,000 DNS lookups a day to sites that don't exist, and I want to track them down.

The relevant IP addresses I have are:

  • 192.168.0.1 - Netgear D6200 modem with 192.168.0.66 set up as DNS server
  • 192.168.0.66 - VirtualBox machine
  • 172.17.0.1 - Docker bridged network
  • 172.17.0.3 - pi-hole

The initial setup was to have pi-hole as the sole DNS server on the modem. Everything works fine, except most of the traffic in pi-hole appears to come from the modem rather than the source device.

I have tried this following which seemed to only make matters worse:

  1. Disabling DHCP on the modem and enabling on pi-hole (after setting up over 30 static DHCP leases!). I rebooted the modem and pi-hole, but then the only wifi device that could connect was my laptop that had pi-hole entered as the DNS server. All the other devices (eg. Google Home) could no longer connect to wifi, even after turning off and on. It seemed bizarre that they could no longer connect to wifi.

  2. Thinking they must really want the DHCP/DNS server to be 192.168.0.1, I changed the modem to be 192.168.0.254. I left pi-hole as 192.168.0.66 and doing DHCP and DNS. No change - wired devices were fine, but wifi devices couldn't connect unless they specifically had 192.168.0.66 as the DNS server. Most of the wifi devices don't let me set the DNS server, so this is not an option.

  3. I went back to DHCP enabled on the modem and disabled on pi-hole and set up a /etc/hosts file as suggested here. No joy.

Debug Token:

lt0kewh5ab

Are you sure the devices couldn't connect unless they had the right DNS server set, or were they connected to the network but couldn't resolve domains?

It's a bit hard to tell because they're mainly IoT things like Google Home and they said they're trying to connect to wifi. Actually my iPhone wouldn't even show the wifi SSID (which is not hidden). Most devices appeared in the "Attached Devices" page of the wifi modem/router, but without an IP address. I'm no network engineer, but to me that sounds like they made it to wifi but couldn't find a DHCP server to obtain an IP address. But then again, if the modem is not the DHCP server, I guess it may not be able to associate IP and Mac addresses. I will try some more experiments tonight.

Ok, so I'm still struggling with the modem's DHCP off and pi-hole's DHCP on. There are two main areas that are perhaps insurmountable.

Firstly, it is not possible to turn off Netgear's DNS proxy. Therefore, some devices continue to show up in pi-hole as being from the modem. I guess this might just be a matter of waiting for their leases to expire.

The second issue is more problematic. I have pi-hole running in a Docker container, which is running on an Ubuntu virtual server under VirtualBox on a Windows PC. If I restart the virtual server, it gets to a point where it says "a start job is waiting for network to be connected". After a couple of minutes it moves on, but without network connectivity. Entering systemctl show -p WantedBy network-online.target shows this start job is docker. If the modem is the DHCP server, it eventually gets connectivity and all is well. If the modem is not the DHCP server but pi-hole is, it never gets connectivity and therefore the virtual server never gets an IP address. If I re-enable the modem's DHCP server, the virtual server gets it's IP address and everything starts working. Except of course pi-hole sees all DNS traffic as coming from the modem.

I tried using a static IP in Ubuntu from instructions here, but couldn't get that to work. Their example uses 'eth0' as the adapter. I tried this first, and then tried the adapter I saw in ifconfig, which was 'enp0s3'.

So here's my bold claim - it's not possible for pi-hole to act as the DHCP server when running under Docker on a VM. And then I found this - DHCP not working in bridged mode · Issue #320 · pi-hole/docker-pi-hole · GitHub - it seems to support this theory.

Here is another newer issue where I'm investigating the DHCP problem: DHCP won't function /w host or bridge mode. · Issue #331 · pi-hole/docker-pi-hole · GitHub

I'll try to get to the bottom of this tonight.

1 Like

Update: To get the bridged / port forward mode of docker to work you have to setup a DHCP Relay in your router pointed to the IP of your docker server with the bridged/port forward of 67 Docker Pi-hole container.

Using a DHCP relay is typical setup for DHCP servers which reside on different subnets than the one they're serving, in our case the docker internal subnet used by default docker networking. This isn't documented currently so we'll have to update the README.

The --net=host mode should work without any router level DHCP Relay since it is on the same subnet.

1 Like

Thanks. An update to the documentation would be very helpful.

I don't believe I can set up a DHCP Relay on my router - some Googling suggests it's not very common on consumer routers.

Which probably leaves --net=host as the main option. This makes a lot of sense because it removes the separate docker subnet. However, it might introduce port conflicts to be dealt with.

You may be able to use dhcrelay on your docker host to help bridge the broadcast signal from inside the docker bridged network to your main network:

dhcrelay(8) - Linux man page or maybe dhcp-helper

dhcrelay -i <interface_towards_clients> <ipaddress_of_DHCP_server> (from serverfault)

I have not tried this but it sounds promising to me.

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