This is desrcibe on PiHole Docker Hub account
- Use the Pi-hole web UI to change the DNS settings Interface listening behavior to “Listen on all interfaces, permit all origins”, if using Docker’s default
bridgenetwork setting. (This can also be achieved by setting the environment variableDNSMASQ_LISTENINGtoall)
Thanks. This is what I’m doing right now. However, I’m just stubborn enough that I want to find a solution to make Allow only local requests to work again. 
Don’t use Docker 
Nope. There must be a way. Unless I misread, I was told that ipvlan can allow container and its host talk. They must be hidden somewhere. 
Checked and hardly find any clue at all. No comments except the word ‘weird’!
After reboot, everything was down. I can’t SSH, but I can ping. I can’t all webUI (portainer, and Nginx Proxy Manager) except Pi-hole, and it’s even weirder that it’s working. 
Anyway, I “killed” it and reinstall everything from scratch. I’m still working on it. Another piece of news is a previous “bug” (Upgrading dietpi: from bullseye to bookworm - #36 by Qlumzy) was replaced by a shorter prompt - “Failed to connect to bus: No such file or directory”. I’m cool, I know it does no harm.
This is expected at the moment.
I have no idea why anyone would directly install a microservice into a heavy LXC, VM, or worse, on bare-metal. I guess some people like wasting resources and giving themselves maintenance nightmares.
Running a pihole container on a macvlan network is totally normal, supported, and widely implemented. Lots of people do it. It’s also smarter to do it this way on a local network service like pihole. You are skipping a network hop and placing the service squarely on the subnet that you intended it to function on, rather than the default bridge docker network (172.x.x.x)
Other benefits to macvlan:
There can be direct communication between docker host and containers. See this page
Your issue is that you aren’t creating an interface and route on the docker host so that it can see the macvlan subnet you are defining.
Anyone who doesn’t fully understand docker networking should watch this video for a better understanding of docker network types - just a primer to scratch the surface.
Anyways, this is how I do it.
My setup:
I will add a 3rd LXC for owncloud infinite scale, which requires direct installation to OS. Therefore, it gets its own dedicated LXC to trash. I’ll give it a mount on the external drive to store all files, DB’s, and configuration files.
Why do it this way?
dietpi@r6s:~$ uptime
16:01:05 up 88 days, 59 min, 1 user, load average: 1.99, 2.14, 2.16
ubuntu@docker:~$ dcinfo
NAMES CONTAINER ID STATE STATUS SIZE
heimdall 22df06462afa running Up 12 hours 51.6MB (virtual 195MB)
sabnzbd ea245edb93da running Up 12 hours 23kB (virtual 191MB)
doublecommander e264143172bb running Up 12 hours 328kB (virtual 1.35GB)
qbittorrent a08e825a2308 running Up 12 hours 21kB (virtual 241MB)
radarr 1519c57dfac9 running Up 12 hours 21.1kB (virtual 219MB)
prowlarr ce1c13702bf2 running Up 12 hours 21.2kB (virtual 201MB)
plex 73792be6e94c running Up 12 hours 3.03MB (virtual 327MB)
pairdrop afed7c55b30d running Up 11 days 22.7kB (virtual 114MB)
unifi-controller 121958dddcc1 running Up 11 days 605kB (virtual 736MB)
sonarr 972479b28986 running Up 12 hours 64MB (virtual 362MB)
pihole cf755d81f8b6 running Up 12 hours (healthy) 48.1MB (virtual 342MB)
Just throwing all that out there to give others some ideas on how you can do things. Back to your issue and how I am running pihole on macvlan.
My router (OpenWRT) is configured like this
How to allow comms between docker host and containers assigned an IP on a macvlan network
Follow the link I posted above for a better understanding. Here is how it is configured in my case;
sudo docker network create -d macvlan -o parent=eth0 --subnet 192.168.1.0/24 --gateway 192.168.1.1 --ip-range 192.168.1.224/27 --aux-address “host=192.168.1.224” frontend
sudo vim /usr/local/bin/macvlan.sh
#!/usr/bin/env bash
sudo ip link add frontend link eth0 type macvlan mode bridge
sudo ip addr add 192.168.1.224/32 dev frontend
sudo ip link set frontend up
ifconfig frontend
sudo ip route add 192.168.1.224/27 dev frontend
chmod +x /usr/local/bin/macvlan.sh
sudo vim /etc/systemd/system/macvlan.service
[Unit]
After=network.target
[Service]
ExecStart=/usr/local/bin/macvlan.sh
[Install]
WantedBy=default.target
sudo systemctl enable macvlan
Here is my docker compose for Pihole:
version: "3"
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
hostname: pihole.lan
environment:
- PUID=1000
- PGID=1000
- TZ=America/New_York
- WEBPASSWORD=urpwdhere
- WEBTHEME=default-dark
- IPv6=false
- FTLCONF_REPLY_ADDR4=192.168.1.254
volumes:
- '/mnt/storage/docker/appdata/pihole/etc-pihole/:/etc/pihole/'
- '/mnt/storage/docker/appdata/pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
#cap_add:
# - NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
restart: unless-stopped
networks:
frontend:
ipv4_address: 192.168.1.254
networks:
frontend:
external: true
name: frontend
That’s all there is to it.
edit: fixed compose
Okay, and now compare your steps with flashing a DietPi image, booting it and clicking through some dialogs to have Pi-hole up 2 minutes later fully functional and with about 10% the RAM and disk usage compared to your solution.
I do not say that there are no use cases for Docker and in that case macvlan, especially when you need to work on badly supported/outdated host operating systems. But given that Pi-hole natively supports Debian via own official installer, the reasons must be good to add the additional complexity and massively increased resources for such otherwise so slim and lightweight applications like Pi-hole and also vaultwarden for a home network.