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

Sun Feb 23 23:47:45 UTC 2025

Sent with Proton Mail secure email.

On Sunday, February 23rd, 2025 at 10:32 PM, user <newtyperacer at proton.me> wrote:

> On Friday, February 21st, 2025 at 5:02 AM, Peter Tirsek peter at tirsek.com wrote:
> 
> > 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.
> 
> 
> Thank you for explaining the output to me. I now have a clearer idea of how my problem works, and why the solution I discovered while playing around works.
> 
> > 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.
> 
> 
> Yes, you have found the new question to which I must find an answer.
> While I understand how to use the software, I do not yet understand dnsmasq's underlying function well enough, or its role in Whonix's design. I do not know the intentions of the developer, either, so I cannot presume anything about the reason for multiple instances. Since I do not know these things, I delayed my response so I could conduct some research.
> 
> First, I revisited dnsmasq's man page, so I could re-read its summary. I also remembered there is a section in the Debian Administrator's Handbook on networking, so I reviewed the material I thought might be relevant in Chapter 10: Networking Infrastructure under the following headings:
> 
> https://www.debian.org/doc/manuals/debian-handbook/index.en.html
> 
> 10.5 Dynamic Routing
> 10.7 Domain Name Server
> 10.8 DHCP
> 
> I also read the overview of the cited DNSSEC Wikipedia page in subsection 10.7. Next, I re-investigated Whonix's documentation, as I know there is a section on its technical design:
> 
> https://www.whonix.org/wiki/Documentation
> https://www.whonix.org/wiki/Dev/Technical_Introduction
> 
> I understand dnsmasq's purpose as the server that facilitates DNS resolution, and little more about the components of DNS. I also understand Whonix's design philosophy of 'security by isolation'. Of note on the technical page to me is the excerpt in section 4, Whonix Framework, subsection 4.1, Design under the Whonix-Workstation heading:
> 
> DNS leaks are eliminated since all DNS requests are sent over the Tor network via the Whonix-Gateway.
> 
> While this refers to traffic from the Whonix-Workstation VM to the broader Internet being funneled through the Whonix-Gateway VM, it did make me think about whether there exists any advantage in having multiple dnsmasq instances to prevent DNS leaks, if having more than one were truly part of its design. I checked a number of other pages with the following headings for anything that might suggest such a possibility:
> 
> Design Documentation https://www.whonix.org/wiki/Design
> Stream Isolation https://whonix.org/wiki/Stream_Isolation
> Dev/DHCP https://www.whonix.org/wiki/Dev/DHCP
> Dev/KVM https://www.whonix.org/wiki/Dev/KVM
> Dev/Whonix Virtualization Platform https://www.whonix.org/wiki/Dev/Virtualization_Platform
> Dev/Whonix Networking Implementation Documentation https://www.whonix.org/wiki/Dev/Project_Networking
> 
> The pages on networking seem to refer only to networking between the Whonix-Workstation VM and the Whonix-Gateway VM, rather than between the Whonix-Gateway VM and the host. I also checked Kicksecure's documentation as Whonix is based on Kicksecure, and it is my host OS:
> 
> https://www.kicksecure.com/wiki/Documentation
> https://www.kicksecure.com/wiki/Dev
> 
> For the general documentation, I read the pages with the following headings:
> 
> Network Obstacle https://www.kicksecure.com/wiki/Network_Obstacle
> Virtualization Platform Security https://www.kicksecure.com/wiki/Virtualization_Platform_Security
> Advanced Host Security https://www.kicksecure.com/wiki/Advanced_Host_Security
> DNS Security https://www.kicksecure.com/wiki/DNS_Security
> 
> The Virtualization Platform Security page details Kicksecure's use inside a VM, which is not my use case. Where it discusses VMs at all, it is only the VirtualBox software. There is no mention of DNS, DHCP, KVM, or libvirt. The Advanced Host Security mentions nothing relevant either.
> 
> The DNS Security page also had sub-pages on networking and DNS in general, so I read all three. I think the Networking page deals with actions performed by systemd, and I am unable to recognise a connection with running more than one dnsmasq instance. The DNS and DNS Security pages are similar in the sense that while I learned more about DNS and some of the problems it presents, I am unable to make a liaison between my understanding of the material and my question of "do I really need two dnsmasqs?". If there were any relevant information, however, I think these pages would be the most likely to contain any, if someone else with a stronger understanding of networking, VMs, and security would like to try.
> 
> Unlike the Whonix 'Dev' documentation, the Kicksecure 'Dev' documentation none of the headings there stood out to me as dealing with DNS or networking in particular. I did check the following pages to be certain:
> 
> About Computer (In)Security https://www.kicksecure.com/wiki/Dev/About_Computer_(In)Security
> Privacy Goals and Non-Goals https://www.kicksecure.com/wiki/Privacy
> 
> These cover higher, generic security and privacy concepts, but nothing pertaining to my specific question.
> 
> The documentation cites the Securing Debian Manual as a reference, so I looked at the pages under the following headings:
> 
> https://www.debian.org/doc/manuals/securing-debian-manual/
> 
> 4.18 Securing network access
> 5.7 Securing BIND
> 
> I do not see anything that would suggest an advantage of multiple dnsmasq instances. Perhaps my original idea of DNS leak prevention is incorrect. If it is, I did not see any other material that would suggest some other advantage, either. Since I was unable to find anything conclusive, I recognise the possibility that running two is accidental and that I should pursue the first solution you suggested, which is:
> 
> > 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.
> 
> 
> You also detail a two-instance solution here:
> 
> > 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
> 
> 
> Since you took the time to detail this to me, I wanted to test it anyway, even if it were not the intended design. I went to prepare a second computer to try this. While doing that, I used the specific term 'dnsmasq' as a search term on the Whonix documentation, and only returned the KVM installation instructions. Since I was going to need them anyway, I decided to review them one more time:
> 
> https://whonix.org/wiki/KVM#Debian
> 
> You can find a condensed version of the page with only the terminal commands here:
> 
> https://whonix.org/wiki/KVM/Minimalized_Installation
> 
> After the portion where the user installs KVM and reboots, I notice this:
> 
> virsh -c qemu:///system net-autostart default
> virsh -c qemu:///system net-start default
> 
> which I assume is the system-wide instance that is running on 0.0.0.0 and :: in addition to the one for Whonix-External:
> 
> sudo virsh -c qemu:///system net-autostart Whonix-External
> sudo virsh -c qemu:///system net-start Whonix-External
> 
> Here we have in the very installation instructions the spawning of two dnsmasqs! I drew a few different conclusions from this:
> 
> 1. It is the developer's intention to have two instances running, in which case I should pursue the second option you suggest.
> 
> 2. It is a generic instruction for running virtual machines. I do not know enough about other virtual machine configurations or setups, but perhaps other setups don't define explicit ones like Whonix does here and just rely on running the system-wide one.
> 
> 3. It is an obsolete or incorrect instruction from when dnsmasq in prior versions failed silently, according to a poster in the link provided by the user Buck Horn (https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2055776). Since it failed silently, it wouldn't matter if there were two running; you wouldn't notice the problem. Only now since dnsmasq complains about it did it become a problem because it obstructs the launch of the Whonix-Gateway VM.
> 
> I cannot determine the intention with my research alone. Now that I have exhausted my options, I think I will participate in the Whonix forum thread (https://forums.whonix.org/t/cannot-start-whonix-external-virtual-network/21092) and detail my findings (and present the solutions you described) thanks to the help you have provided. Since I have shifted the question from both my and the original poster's incidental problem to Whonix (why does dnsmasq prevent me from starting the Whonix-Gateway?) to an integral one (what is the role of dnsmasq in Whonix's design and KVM implementation, and does it necessitate only one or multiple instances?) I think the developer may now be able to provide an answer.
> 
> Meanwhile, I will attempt the two-instance solution. I have never done this activity before, so it may take me quite a bit of time. I do not know if any problems or questions I may have will be on-topic for the dnsmasq mailing list, per se, but I think the outcome and whatever response I may receive in the forum should provide a tidier conclusion to the thread.