[Dnsmasq-discuss] dnsmasq: failed to create listening socket for 10.0.2.2: Address already in use

[Peter Tirsek]

On Tue, 18 Feb 2025, user via Dnsmasq-discuss wrote:

> Netid   State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port   Process
> udp     UNCONN   0        0                0.0.0.0:53            0.0.0.0:*       users:(("dnsmasq",pid=932,fd=4))
> udp     UNCONN   0        0                   [::]:53               [::]:*       users:(("dnsmasq",pid=932,fd=6))
> tcp     LISTEN   0        32               0.0.0.0:53            0.0.0.0:*       users:(("dnsmasq",pid=932,fd=5))
> tcp     LISTEN   0        32                  [::]:53               [::]:*       users:(("dnsmasq",pid=932,fd=7))

So here you're showing that there's already a system-wide dnsmasq 
process running, listening on tcp and udp port 53.

> sudo service dnsmasq stop
> virsh -c qemu:///system net-start Whonix-External
> and I was able to launch the Whonix-Gateway VM.

... and stopping it allows another to start. That sounds entirely 
reasonable and is expected behavior. Unless the server software is 
designed to share with others, two things normally can't bind to the 
same port at the same time, so this works as designed.

It sounds like you need to decide what you your desired outcome is. If 
it's acceptable that the system-wide service isn't running at all and 
that dnsmasq only runs when you start the Whonix-External network, then 
disable the system-wide service permanently, and your setup will run 
like what you just tried manually.


If you instead need both services to run at the same time, you'll have 
to make sure they don't step on each other's toes. Exactly how to do 
that depends on your specific network configuration. From the error 
messages you shared earlier, it sounds like the virtual network 
instance tries to bind to a specific interface address, whereas the 
sytem-wide one binds to the catch-all addresses of 0.0.0.0 and ::.

First, think about why you have multiple instances of dnsmasq. That's 
not really a typical use case. Perhaps the correct solution is to 
configure your libvirt to not spawn a second dnsmasq instance and 
instead rely on the main one without changing anything in the dnsmasq 
configuration.


If you do need two instances, perhaps you can change the system-wide 
service (typically configured in /etc/dnsmasq.conf) to only bind to the 
necessary interfaces using the `interface=...` setting and listing only 
`lo` and/or your physical network device (depending on what you need), 
or by using the `listen-address=...` setting and listing the IP 
addresses of the relevant interfaces. You may also need need 
`bind-interfaces` or `bind-dynamic` as well; then restart the main 
dnsmasq service again. You can also try telling dnsmasq which 
interfaces to stay away from with `except-interface=virbr1` in the 
config instead, depending on what's easier.

If that works, the ss -tulpn command should no longer show dnsmasq 
listening on the addresses 0.0.0.0 and ::, but on 127.0.0.1 (if you 
enable interface "lo") and whatever IP address your main network 
interface has, if you listed that one on the interface line. After 
that, the other instance should be able to bind to the 10.0.2.2 address 
that your virtual network uses, as long as it doesn't also try to bind 
to the other interfaces. If it still fails, then maybe you also need to 
adjust the /var/lib/libvirt/dnsmasq/Whonix-External.conf file as 
needed. That one is probably maintained by libvirt, so any adjustments 
needed there will likely have to be made in the libvirt configuration 
instead somewhere.

-- 
Peter Tirsek