The host can’t do DNS resolution while the other devices in the lan can! The Pihole is installed as a docker container in it. The container can’t be ping’ed and I believe it’s the reason why the host can do any DNS resolution.
Any advice? Thanks.
Required Information
- DietPi version | 8.19.1
- Distro version | bookworm
- Kernel version | Linux dietpi-rdx0 6.1.11-meson64 #23.02.2 SMP PREEMPT Sat Feb 18 00:07:55 UTC 2023 aarch64 GNU/Linux
- Architecture | arm64
- SBC model | Radxa Zero (aarch64)
- Power supply used | 5V 500mA
- SD card used | SanDisk 32G (Class 10)
Additional Information (if applicable)
- Software title | 134 Docker Compose, 162 Docker, 185 Portainer
- Was the software title installed freshly or updated/migrated? Yes, the entire system was installed recently.
- Can this issue be replicated on a fresh installation of DietPi? Sorry, IDK.
← If you sent a “dietpi-bugreport”, please paste the ID here →
- Bug report ID |
echo $G_HW_UUID
Steps to reproduce
- ping 192.168.14.9/24 (the IP address of the container) is NOT working on host: 192.168.14.16/24
- Vice versa, ping 192.168.14.16/24 is NOT working on host: 192.168.14.9/24.
- The other devices can be pinged or ping them individuallly.
Expected behaviour
They should be able to ping each other.
Actual behaviour
- ping 192.168.14.9/24 (the IP address of the container) is NOT working on host: 192.168.14.16/24. Vice versa, ping 192.168.14.16/24 is NOT working on host: 192.168.14.9/24.
Extra details
NULL
The text of the compose file has gone wild when i pasted it. So, rather wait upon received the text.
Why does your container has an one IP address? Usually Docker container don’t have individual IPs. Did you configured any special network or vlan settings for this container?
The docker containers usually have addresses in some other network, like 172.17.0.0/16.
If you set it up like this, you’d need to configure the exposed ports.
It will be easier to use the host mode for networking which will expose everything the container has.
In any case a docker inspect pihole will show more details.
Probably my comment was misleading. I meant individual IPs with host network and not from Docker own IP range/ network.
There are ways to configure Docker container to akt as network client within host network but this will block direct communication between host and container. (Behaviour of Docker itself)
Sorry, my bad. I should’ve describe all these clearer in the first place.
My host is 192.168.14.16 and I set an IP address to the Pihole container 192.168.14.9 via macvlan. Of course, there’s another subnet 172.16.14.0/24 for the intercommunication between Pihole and Unbound.
Anyway, this is why there’re 2 IP addresses. I bet it is acting as what Joulinar said: block direct communication between host and container. If so, how may I break down the barrier in between?
Thanks.
P.S. FYR, here is the yaml:
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
ports:
- "53:53/tcp"
- "53:53/udp"
- "${EXT_WEB_PORT}:80/tcp"
networks:
macvlan:
ipv4_address: ${PIHOLE_LAN_IP}
bridge:
ipv4_address: ${PIHOLE_BRIDGE_IP}
volumes:
- pihole:/etc/pihole/
- dnsmasq.d:/etc/dnsmasq.d/
environment:
- FTLCONF_LOCAL_IPV4=${PIHOLE_LAN_IP}
- TZ=${TIMEZONE:-UTC}
- WEBPASSWORD=inUK@161
- PIHOLE_DNS_=${UNBOUND_BRIDGE_IP}
- SKIPGRAVITYONBOOT=1
restart: unless-stopped
unbound:
container_name: unbound-rpi
image: mvance/unbound-rpi:latest
networks:
bridge:
ipv4_address: ${UNBOUND_BRIDGE_IP}
volumes:
- unbound:/opt/unbound/etc/unbound/
restart: unless-stopped
networks:
macvlan:
driver: macvlan
driver_opts:
parent: eth0
ipam:
driver: default
config:
- subnet: ${LAN_SUBNET}
gateway: ${LAN_GATEWAY}
bridge:
driver: bridge
ipam:
driver: default
config:
- subnet: ${BRIDGE_SUBNET}
volumes:
pihole:
dnsmasq.d:
unbound:
Using macvlan did not allow communication between host and container. Its a behaviour of this feature. Docker + Portainer: Macvlan support possibly flawed? · Issue #6223 · MichaIng/DietPi · GitHub
- Why running Pihole within a container and not as native application?
- Why using
macvlan as it is not needed?
- Why do you need to communicate between host and container? Host DNS should point to a global upstream DNS and not to Pihole.
Thanks, Joulinar. You’re always here for help. Even more, I learn a lot along the way. Can’t thank you more! Take care 'cos you don’t seem to need any sleep or rest; you are always online, aren’t you?
I want to use this to host a number of containers since Radax Zero is a waste to serve just Pihole. My plan is to having:
- Proxy Manager
- Pihole
- Password Manager hosting for 2 individuals.
Maybe, I’m wrong, but I think assigning the containers to different IP addresses might make all the stuff hosted clearer. When sth goes wrong, it might be easier to know what went wrong. From my understanding, I need to use macvlan to host different external IP addresses for different containers under a single host.
No, I don’t need to communicate between host and container. I was just routing all DNS queries to Pi-hole for the sake of unity - all DNS queries in my network are served by this Pihole container. I’m open for the change if it causes more trouble than benefit in a long run.
There are multiple ways how to reach your goal. But if possible, I would avoid macvlan as it is not needed. All container can be setup in a way to be reachable via host IP, just on different ports. NPM can be used to create individual proxy host to reach each app.
Personally, I’m hosting PiHole + unbound as native apps. This removes complexity to deal with docker container. But I moved PiHole web server to a different port 8080 to avoid conflicts with NPM. Within NPM I created a proxy host to redirect to PiHole web interface.
As well Vaultwarden is available from our end as native app.
2 Likes
Thanks. I will think it over.
Yes, I’m seriously considering hosting Pi-hole + Unbound as native apps since I’d like to get 2 instances running in my lan for the sake of redundancy. There’re a few areas I want to store my modifications, e.g., adding SSL to admin web and adding other addins, and these definitely make the setup very complicating due to multiple of volumes or one big trunk of volume.
One of my goals in customisation is to make the management easier in a long run. I don’t mind setting thing up rather complicated while getting an easier managing the systems.
For password manager, I’m looking to install 2 instances for me and my wife. If this works well, I might need to increase the instances for my kids as well. Of course, not until they ask.
Just my 2 cents.
It’s not an issue to run the applications in docker containers. I sometimes find it very useful when there are dependencies in packages which make it hard to install it directly on a system. You need to know, however, how to run the containers in order for them to run properly. In general you can run them in host networking mode, which exposes the ports on the host system (the dietpi running the docker) and you don’t need to mess with port forwards or routing. Other than that, both options will do what you want. You should use the option which you are most familiar with.
Thanks for your advice. Originally, I chose to use macvlan cos of remembering IP addresses is easier than port number. I’ll put up a test server and see how things go. Still, I want to keep things as sample as possible though I don’t mind to do complicating stuff during setup since it’s just a 1-time job to me.
Vaultwarden should have multiuser support ootb.
Of course you can use macvlan, you just have to accept the disadvantage that there is no direct communication between container and host system.
1 Like
Thanks!
I’ll take some time to try Vaultwarden out. Did hear of it before, but never try it or Bitwarden. I’m using KeePass, but I want to store this online so I can access my passwords in every device.
If it’s not you, I 'd know that there’s a restriction in communication between a container and its host. I need to think and change my plan if neccessary.
You only have a restriction when using the “macvlan” function. Without this setting, communication between container and host should work fine.
2 Likes
After looking for ways to preserve the ip address of Pi-hole (since I want to seperate host and the container with different IP addresses - don’t ask why, I’m just stubborn 
) for a day, I think I have to give way for the time being. Tried to switch to ipvlan, but still didn’t work.
Ended up taking the advice from @Joulinar (using the same IP address as the host), and use Nginx Proxy Manager as a middleman to translate names to access different containers. Now, I’m on a quest looking for free DDNS service offering short domain names. Found a short one in FreeDNS, but IDK how to get it works with NPM since it’s not in NPM DDNS service list.
No worries, I’ve already found myself a backup one, mywire.org from Dynu. Like my username suggests, I kept typing mywife.org. Hahaha…
Last but surely the most important, thanks to @Joulinar and @trendy helping me along the course. I know I’m a stubborn and idiot troublemaker for sure. This week, I will return to do my study on the docker study kit - Introduction to Container as well as finding myself another book(s) from Kindle on Docker Networking. I’m still wondering if there’s any better way to do this. I’m more than happy if you have any good recommendation on books or any other material. Thanks in advance.
Sorry, I don’t have anything to recommend. Most of my knowledge I have from this forum, looking into various issues and learning along the way trying to fix them. 
I’ve learned a few things about docker from work, so let me know if you need more help on that.
Sorry folk. I’m in search for a solution. Currently, the solution hasn’t solved everything, at least not 100% satisfied me. Right now, Pi-hole is Respond only on interface eth0 instead of Allow only local requests since its default network is the bridge network connecting it and unbound.
Moreover, 2 systems were down this morning. IDK why, and I will have to wait until I try some swapping around to see if they can boot up again. I wonder if there’s any way to check why/how they went down. They’re all running on headless mode. No need to help atm, let me look into them later today. Hopefully, there’re some info by then.
P.S. take this as a journal for myself. I’m thinking it out loud.