I wanted to get a head start on setting up a honeypot project, since it seemed like a simple enough build to begin with. Before doing that, I decided to switch VM managers from VMware to Virt-Manager. From what I had read, Virt-Manager is generally more lightweight and better suited for Linux hosts, so making the switch seemed worth it.
After following Abstract Programmer’s guide to get it up and running, I entered all the commands and rebooted the homelab. Once it came back up, I went to download a fresh Kali Linux ISO, but my browser suddenly refused to connect to anything.
That was strange, because this had never been an issue before. I also did not expect Virt-Manager to interfere with anything DNS-related. My first thought was Pi-hole, since that was the main service on my homelab using port 53.
For some background, my homelab acts as a Tailscale exit node, meaning Tailscale traffic routes through the homelab first and then out to the internet. To add another layer of security, I have Tailscale DNS traffic going through Pi-hole and Unbound so malicious or unwanted DNS requests can be filtered before they leave the network.
Since Pi-hole seemed like the obvious suspect, I started with the usual troubleshooting steps:
- Restarted the device and check again
- Made sure that the container was actually up and running
- Attempted to connect to the service locally
The container appeared healthy, but DNS still was not working. So what was the issue? The actual issue turned out to be libvirt, one of the packages used by Virt-Manager. Libvirt sets up a default virtual network and uses a service called ‘dnsmasq’ to provide DNS and DHCP for that network. That service was already using port 53, but only on libvirt’s virtual bridge IP.
The real conflict came from Docker. My Pi-hole container was configured to publish port 53 on every host interface. In other words, Docker was trying to bind Pi-hole to all IPs on the machine, including the virtual bridge IP that dnsmasq was already using. Because of that overlap, Pi-hole could not bind correctly.
The fix was simple once I understood what was happening. I updated the ports section of my Pi-hole Docker Compose file so that Pi-hole only binds to my homelab’s LAN IP and Tailscale IP. That let Pi-hole keep working exactly as intended for both LAN and Tailscale traffic, while leaving libvirt’s virtual bridge IP alone.
This was one of those classic homelab hiccups that turns into a learning experience. It was frustrating in the moment, but it also helped me better understand how port binding, Docker networking, and libvirt interact on the same host. I’ll keep posting updates here as I continue building out the lab.