Paraphraser
commented
1 year ago Well, that's not what I see. For example:
To be honest, I can't understand how Pi-hole would ever actually see 172.X.0.1 in incoming query packets.
I'm assuming that 172.X.0.1 implies the default gateway on the internal bridged network.
Please see if you can spot a hole (no pun intended) in my reasoning. Make these assumptions:
- Pi-hole is running in a non-host-mode Docker container on a Raspberry Pi.
- Docker assigns 172.16.0.4/16 to the Pi-hole container.
- The Raspberry Pi's IP address is 192.168.0.60/24.
- A client has the IP address 192.168.0.100/24.
When the client issues a DNS query, the source IP is 192.168.0.100 and the destination IP is 192.168.0.60.
When the packet arrives at the Pi, iptables rules set up by Docker rewrite (de-NAT) the destination address to be 172.16.0.4, then the packet is routed to Pi-hole.
The source IP isn't changed so Pi-hole can see 192.168.0.100 and can log that against the query.
The reply to the query will have a source IP of 172.16.0.4 and a destination IP of 192.168.0.100.
The packet routes out of the internal bridged network to the Pi where iptables rules rewrite (NAT) the source IP address to be 192.168.0.60, and the packet is then forwarded back to the client.
It's fairly easy to verify this:
$ docker exec -it pihole bash
# apt update
# apt install -y tcpdump
# tcpdump -n port 53I have yet to spot the IP address of the default gateway on the internal bridged network (ie 172.16.0.1). All incoming queries originating from devices on my home network have source IP addresses matching 192.168.132.x.
Outside container-space, you can also use tcpdump to confirm that addresses from the internal bridged network aren't getting out onto your home network:
$ sudo tcpdump -n port 53I see plenty of queries and replies, both answered directly by Pi-hole, or being relayed to BIND9 or 8.8.8.8 etc, but no sign of 172.16.x.x.
It's possible that the reason I see all my local clients is because of how I have Pi-hole configured so here's my service definition:
pihole:
container_name: pihole
image: pihole/pihole:latest
restart: unless-stopped
environment:
- TZ=${TZ:-Etc/UTC}
- WEBPASSWORD=
- INTERFACE=eth0
- PIHOLE_DNS_=8.8.8.8;8.8.4.4
- REV_SERVER=true
- REV_SERVER_DOMAIN=my.domain.com
- REV_SERVER_TARGET=192.168.132.55
- REV_SERVER_CIDR=192.168.132.0/24
- FTLCONF_MAXDBDAYS=2
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp"
- "8089:80/tcp"
volumes:
- ./volumes/pihole/etc-pihole:/etc/pihole
- ./volumes/pihole/etc-dnsmasq.d:/etc/dnsmasq.d
dns:
- 127.0.0.1
- 1.1.1.1
cap_add:
- NET_ADMINThe way I use Pi-hole is like this. DHCP divvies-up clients into two buckets:
- devices that need ad-blocking services, which are sent to Pi-hole; and
- everything else, which are sent to my local BIND9 instance (192.168.132.55).
BIND9 is authoritative for my.domain.com. and 132.168.192.in-addr.arpa.
When a client directs a query to Pi-hole, there are three possible outcomes:
- the query is blocked (ie matches an ad-list); or
- the query is in a local domain (forward or reverse), in which case it will be relayed to the local BIND9 instance; otherwise
- the query will be relayed to 8.8.8.8 and friends.
Because BIND9 can answer reverse queries, Pi-hole can translate local IP addresses to local domain names, which then show up in the GUI (the example above).
From the Discourse post:
where X seems to change after a reboot
The "problem" of Docker allocating the subnet dynamically when it creates the default network can be "solved" like this:
networks:
default:
driver: bridge
ipam:
driver: default
config:
- subnet: 172.30.0.0/22Fairly obviously you can pick any subnet you like and prefix length you like. Some people would rather let Docker make the choice (which is why I put "problem" in quotes) but I prefer predictability.
marcelstoer
Since Pi-hole runs in a Docker container on the default Docker network, it identifies all clients in its logs as 172.X.0.1.
This is discussed in a number of places e.g. https://discourse.pi-hole.net/t/pi-hole-in-docker-on-macos-has-only-one-client/55875