Qemu Windows 10 Guest No Internet Access on Arch Linux

If you’re struggling with no internet access on Windows 10 under QEMU on Arch Linux this post might have an answer…

qemu windows no internet arch featured image

Spoiler: It's SystemD again...

About 3 min reading time

I’ve just about lost all my hair trying to get this working. It worked a couple of nights ago, but something must have changed because it stopped working after I installed on another machine. The problem is, if you follow all the internet guides for how to get Windows 10 see the Internet on a QEMU VM on Arch Linux with a NAT virtual NIC (around the time of Dec2021-Jan2022) – you’ll struggle.

By the way, QEMU documentation says that user mode networking using NAT ‘just works’. It doesn’t in my case. Though to be fair, as it turns out it’s not QEMU’s fault…. It’s fscking SystemD messing us up. I hate SystemD, it has its fingers in everything, and it just simply shouldn’t.

Here’s How I Did It

This is a short post – primarily to remind me how to do it if I need to again. But hopefully it helps you.

You’ve by now probably found the other posts which say to;

sudo pacman -S qemu virt-manager virt-viewer dnsmasq vde2 bridge-utils openbsd-netcat ebtables

And having done that, everything looks like it should work.

sudo iptables -L

shows various reasonable looking VIRTD rules. Windows sees the NIC device. Virt-manager shows the device is active and starts on boot. Multiple reboots make no difference. A stiff drink doesn’t help either.

But no matter what you do, Windows stubbornly refuses to obtain an IP address. You can see dnsmasq running for the NATted network. No IP address still.

So here’s what I ended up doing.

(Actually as I write this I realise this /may/ be a weird interaction between Arch with Cinnamon DE, since that is something I changed recently!)

systemctl stop systemd-resolved.service
systemctl disable systemd-resolved.service
pacman -Rns systemd-resolvconf

For the record, I utterly despise systemd-resolved – I run a Zerotier network and a local DNS server for locally resolving addresses when I’m inside my network. I also have internet resolvable addresses with port forwarding set up on the router when I’m outside.

When running systemd-resolved, my internal IP addresses ALWAYS use the OUTSIDE address for web connections. I’ve checked the DNS settings and it’s using the internal server. I’ve turned off FallbackDNS just in case it’s using that. nslookup returns the internal network address (192.168.xx.xx) but web browsing always connects to the external address. Except the external address has some restrictions which means I can’t actually administer my own stuff.

So it’s removed. Using normal name resolution ‘just works’. No idea how system-resolved knows about my external address unless it’s ignoring my configuration and asking root nameservers itself?

Also remove systemd-networkd

Now, this might be because I’m using Arch with Cinnamon, it actually did all seem to ‘just work’ when I was on Gnome… By the way though, Cinnamon on Arch is (this problem aside) perfect!

I think Cinnamon is using NetworkManager to configure the network, and that’s conflicting with systemd-networkd. I only stumbled upon this because the Arch wiki mentioned ensuring that systemd-resolv.conf is setup correctly if you’re using it.

Anyway – if your Windows guest cannot see the Internet in a QEMU VM using the default NAT interface, removing systemd-resolved and systemd-networkd might solve your problem.

But only do this if you’re happy to reinstall it all again if it doesn’t work 😉

It worked for me – but you might hose everything to do with your networking if it doesn’t work for you!


    There are currently no comments - why not be the first!?

Have Your Say:

Affiliate Disclosure

This site is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites. We may also participate in other Affiliate programs. For further information please see our Affiliate Disclosure