Windows HVM cannot reach beyond gateway

User Support General
,
1

I have created a new windows 10 HVM using qvm-create-windows-qube. The installation of QWT intially failed telling me to enable testsigning. I did that. Canceled te qvm-create-windows-qube run and installed the tools manually.

So far most tings seem to be working. I’m running with

gui = “” and gui-emulated=1

Coyping files from other qubes also works.
The only problem I have currently is with networking. I can ping the gateway set in te network preferneces but ping anting else like 8.8.8.8 results in a “Destination net unreachable” from the gateway. All other (debian-based) qubes have no issues with networking.

How can I narrow this down?

1 Like
2

deleted

1 Like
3

This looks like DNS is not working for the Windows qube or that it is not routed to the external network. There are several locations where a wrong configuration might rest:

  • The properties of the qube might point to the wrong IP addresses. So check, via qvm-prefs or the Qube Manager, if the gateway of the Windows qube has the IP address of sys-net, sys-firewall or sys-whonix. The DNS entry for that qube should be 10.139.1.1and 10.139.1.2. It might be better to change the second of these values to that of your router.

  • In the VM, have a look at the properties of its network interface, which will probably be something like Ethernet1. They should match those set in Qubes for the VM.

4

Hi GWeck,

Thank you for your help. Here is the subset of qvm-prefs:

$ qvm-prefs reporting-vm | grep -P '(gateway|dns|net)'
dns                   D  10.139.1.1 10.139.1.2
gateway               D  
gateway6              D  
netvm                 -  sys-net1
provides_network      D  False
visible_gateway       D  10.137.0.29
visible_gateway6      D  
visible_netmask       D  255.255.255.255

And the windows ip configuration:

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek RTL8139C+ Fast Ethernet NIC #2
   Physical Address. . . . . . . . . : 00-16-3E-5E-6C-00
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::719d:5c63:8209:671e%3(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.137.0.33(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Lease Obtained. . . . . . . . . . : Monday, February 2, 2026 1:44:07 PM
   Lease Expires . . . . . . . . . . : Thursday, February 12, 2026 1:44:07 PM
   Default Gateway . . . . . . . . . : 10.137.0.29
   DHCP Server . . . . . . . . . . . : 10.137.0.29
   DHCPv6 IAID . . . . . . . . . . . : 117446206
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-31-0D-89-D8-00-16-3E-5E-6C-00
   DNS Servers . . . . . . . . . . . : 10.139.1.1
                                       10.139.1.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

The netvm name deserves some explation: I restored it from a backp so it is not named sys-net (yet). I went with sys-net instead of sys-firewall in this case because I wanted to exlcude sys-firewall as a problem-source.

From what it looks like I cannot ping the DNS server, but that is also the case in my other VMs which have working DNS so its probably not the issue here.


C:\Users\user>ping 10.139.1.1

Pinging 10.139.1.1 with 32 bytes of data:
Reply from 10.137.0.29: Destination net unreachable.
Reply from 10.137.0.29: Destination net unreachable.
Reply from 10.137.0.29: Destination net unreachable.
Reply from 10.137.0.29: Destination net unreachable.

Ping statistics for 10.139.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Users\user>

C:\Users\user>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 10.137.0.29: Destination net unreachable.
Reply from 10.137.0.29: Destination net unreachable.
Reply from 10.137.0.29: Destination net unreachable.

That failing ping for 8.8.8.8 doesn’t seem normal though.

@GWeck I read something about QWT availability in Qubes 4.2 vs 4.3. What is the Version of QWT that I should use on QWT 4.3?

Currently I’m seeing:

~$ rpm -q qubes-windows-tools
qubes-windows-tools-4.2.2-1.fc41.noarch

Is that the new one based on the newly build (and thus secure) drivers?