I use GNOME Boxes on a laptop. The guest machines get the Internet connection automatically with default settings whenever the laptop moves between networks (Ethernet, Wi-Fi in different locations, or a cellular phone as a USB modem).

The guest machines are not bridged with the host and are not visible on the host's LAN implying that the MAC addresses of the guests are overwritten before passing the frames to the host's LAN.

By default QEMU will create a SLiRP user network backend and an appropriate virtual network device for the guest…

User Networking is implemented using "slirp", which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT'd network.

QEMU's final, and most bizarre, networking option is also its default option. What this does is connect a "usermode network stack" to a vlan. This network stack is a standalone implementation of the ip, tcp, udp, dhcp and tftp (etc.) protocols. It can handle frames from the vlan by e.g. responding to dhcp requests with a valid address, responding to tftp requests with a file from the host filesystem or by creating udp/tcp sockets over which packet data can be forwarded.

Note that this network stack is running within the qemu process itself. So, for example there is no separate dhcp or tftp process handling those requests. Also, the stack is effectively acting as a proxy by unpacking application data from udp/tcp packets and forwarding them over a socket connecting the qemu process and the destination process.

Note, in the above context, "vlan" stands for "emulated" LAN, it doesn't mean IEEE 802.1Q VLAN ID.

By default, the guest has IP address on network. The gateway is The DNS server is The guest can access the host by connecting on gateway IP.

enter image description here

At a particular Wi-Fi network, all guest machines lose Internet access. I found another question about lack of Internet in the guest under QEMU, which discovered that DNS may not work out-of-the-box under certain setup. So, I checked mine. I can access websites by their IP from the guest. Also, if I configure an IPv4 connection manually, resolving gets restored if I add another known resolver, such as, as a backup in addition to the default

According to the local administrator, this Wi-Fi network has VLAN tagging enabled to separate local computers from visitors' computers. Apparently, if VLAN were an issue, it would cause complete loss of Internet access, not just resolving.

Another particularity of that network is that the first DNS resolver is configured to refuse most request. The second resolver is provided, but, apparently, not used by QEMU.

The issue persists across devices. I tried on two completely different laptops with Intel wireless. The issue is found in Debian "Buster" at least since 10.4, "Bullseye" and "Sid".

  • You'll have to explain first how you managed to bridge over Wifi your VMs in the working case. That's usually something difficult to achieve and requiring specific settings on the AP as well as all the (Wifi) clients. If they are routed rather than bridged, then no extra MAC will exist.
    – A.B
    Oct 12, 2020 at 7:28
  • To know what's the setting (bridged or routed), usually the IP address helps: if it's in the same LAN as the host, it's bridged, if it's a different LAN (eg and especially with libvirt) it's routed. There are probably exceptions too.
    – A.B
    Oct 12, 2020 at 7:46
  • 2
    Be careful, you link an article from 2007. "VLAN" just means an emulated LAN, it doesn't mean IEEE 802.1Q VLAN ID, as told there: wiki.qemu.org/Documentation/Networking#The_legacy_-net_option "The obsolete -net syntax automatically created an emulated hub with ID 0 (used to be called a "VLAN" in older versions of QEMU, for virtual LAN)". Even (and especially) with SLiRP if the system is in the end routing, there's no way an other MAC address than the host's MAC address appears. You should investigate with several concurrent tcpdump to see what's happening everywhere. Can't help more.
    – A.B
    Oct 14, 2020 at 20:47
  • I suspect that maybe the laptop (the host) is the one which has the issue, thus the guests inherit this issue. In such case there's nothing involving QEMU anymore.
    – A.B
    Oct 14, 2020 at 20:57

1 Answer 1


In the default "user mode" networking, QEMU uses only the first DNS nameserver from the host machine. So, if that nameserver doesn't resolve properly, QEMU will not fallback to any other nameservers which may be configured as secondary at the host. It results in the apparent loss of Internet connection by the guests while the host can still use its fallback nameservers "hiding" the problem.

It is a known QEMU behavior, which is not expected to be fixed in QEMU. Here is a quote from a Debian Bug report log #625689 from 2011:

No the limitation isn't documented (yet), and it will be difficult to fix too, or maybe not worth a trouble really. Two reasons. First of all, user-mode networking is not suitable for anything serious, you really want tap networking with bridges, which is about 100 times faster and actually works (e.g. ICMP). Second, the implementation is rather simplistic - for DNS it merely forwards (like a NAT box) packets from guest to a nameserver from host /resolv.conf - only one nameserver, because you can't NAT to TWO destinations at once. So in order to fix that, qemu has to become application-level proxy for DNS, instead of a simplande NAT "device".

It is easy to reproduce the issue by adding some garbage as the first nameserver to /etc/resolv.conf at the host. The guest stops resolving immediately.

For a Debian guest machine, to restore networking, it was enough to add another known resolver, such as, to /etc/resolv.conf. Such change of configuration does not survive rebooting the guest.

  • 1
    I struggled for an hour before finding your post... Thanks a lot, it explains the problem quite in depth indeed.
    – perror
    Jan 26, 2021 at 10:56
  • Thank you so much for telling me QEMU uses only the first entry in /etc/resolv.conf. I've just spent a couple of hours struggling to undertand why my guests network suddenly stopped working while everything was OK on the host. Turns out that the first nameserver was down. Nov 29, 2022 at 13:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .