In "Primary IP addresses" of "System Information (System Settings)" I can see:
IPv4 192.168.0.10 @ eth0
But this is eth0 interface (connected to Router iface) and not it's the correct (br0), but I've set the correct interface in var "INTERFACE: br0" of my Compose, and I can check it's defined in "pihole.toml" config file:
A br interface would be a bridge interface, but you have your docker compose (and thus docker) running with host mode networking.
You need to pick one or the other, host mode would directly attach to eth0 and use that interface. DHCP is a broadcast technology, it does not cross interfaces without an external application reflecting the broadcast packets.
Thank you Dan,
Yes, it's a bridge, but it's a Physical bridge created by me with some Phisical ethernet connectors from my Hardware. It's not a Docker bridge, and documentation related to Docker bridges, not apply.
I don't want cross interfaces, I want use only one interface (br0), not others, but Pihole is consider eth0 too, but I defined br0 as the correct interface in Pihole config, but without success.
I can see from the debug log that there are queries coming in from clients on 192.168.5.0/24
Mar 25 20:48:05 dnsmasq[51]: query[A] 0.debian.pool.ntp.org from 192.168.5.15
You also have queries coming in from 127.0.0.1, they look like they have an internal domain so I won't quote them here. They are getting NXDOMAIN responses so it doesn't look like there is an authoritative DNS server for that internal domain.
Using network: host will put the docker container on the host network stack but I'm not clear what you want to run. Can you explain with detail what you would like to have running when everything is up and configured? What interface should be responding to DNS queries, what interface should be the DHCP server, what other DHCP daemons are running on the network segments?
Edit: And if you can share the /etc/network/interfaces config file for how you constructed the bridge?
I tell "not working" because my network clients are not received IPs when I configure Pihole as DHCP Server (when I up another container with KEADHCP, no problem).
I configure pihole as "network_mode=host" and the network host interfaces are the following:
~# ip ad | grep "inet "
inet 127.0.0.1/8 scope host lo
inet 192.168.0.10/24 brd 192.168.0.255 scope global eth0
inet 192.168.5.10/24 brd 192.168.5.255 scope global br0
inet 172.20.0.1/24 brd 172.20.0.255 scope global midockerbr
inet 172.20.1.1/24 brd 172.20.1.255 scope global midockerbrpriv
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
The "eth0" interface is connected to Internet router (it has an DHCP server, but I've probed to disable, without success), I want to exclude this from Pihole DHCP activity.
The "br0" interface is my Bridge with some ethernet connectors integrated in my hardware, where my network clients are connected. This is the interface where Pihole DHCP must operate. This is the bridge config:
auto eth1
iface eth1 inet manual
auto eth2
iface eth2 inet manual
auto eth3
iface eth3 inet manual
...
auto br0
iface br0 inet static
bridge_ports eth1 eth2 eth3 ...
address 192.168.5.10
netmask 255.255.255.0
The "172.X.X.X" are docker interfaces, not apply.
Pihole looks consider "eth0" interface only, but I set "br0" interface.
Queries that you see in DEBUG Log from 192.168.5.15 client, is the only lease I can see. I suppose because I have defined this host as static lease. I don't know, another clients are not having activity.
to misc.dnsmasq_lines under Settings | All settings » Miscellaneous. All settings is available in Expert mode only.
Your DHCP issue is likely related to Docker rather than Pi-hole.
If your network's DHCP broadcasts are correctly arriving at br0, but not received by your Pi-hole container's DHCP server, they are likely intercepted by Docker.
Docker is using bridge networking for its internal networks in order to provide container isolation, employing bridge network filtering rules.
A quick search indicates that could be mitigated by adding an iptables rule to your Docker host, but be cautious to pick a solution, as messing with Docker's iptables ruleset is finicky.