Windows HVM + sys-whonix networking suddenly broken

User Support
1

Hello, after the most recent whonix gateway update my Windows 10 HVM’s internet suddenly stopped working. To be candid this could be a complete coincidence however the timing of the update with the sudden network unavailability seems suspicious.

I have an existing windows HVM that has the net and iface xen PV drivers manually installed directly (qubes windows tools not installed) that has its NetVM as sys-whonix.

Up until now it has worked perfectly fine, however suddenly after updating whonix-gateway all networking to the HVM is broken, showing “Unidentified network”.

I have since followed the qubes guide to setup a Static IP for a windows HVM to make sure everything was correct, but even with a static ip (correctly using the ip values from Qube Manager, and trying both /24 and /32 subnet prefix length) it still doesn’t work.

I even tried to install a brand new windows HVM following the same guide with a windows 10 enterprise ltsc iso, and the exact same issue occurred. The brand new HVM does not have any xen PV drivers present unlike my existing windows HVM.

Any idea what could have changed?

3 Likes
2

It’s not a complete coincidence, it also happens to me in every windows version (not only 10). I thought might be qubes related, but this is clearly a whonix bug, see below:

sys-whonix → windows HVM (not working after last update, worked fine for years)

sys-whonix → sys-vpn → windows HVM (works fine, go figure)

Has anyone came up with a way to restore networking after last update?

1 Like
3

I forgot to mention. The Windows error code is 10060. Winsock timeout error.

1 Like
4
1 Like
5

Can someone please try sys-whonix on a Windows HVM? This way we know if OP and me are not the only ones affected.

1 Like
6

I’m experiencing this same issue, to a T. Issue happens both with and without PV drivers, even in pre-existing and newly spun up Windows HVMs. Setting up a static IP hasn’t resolved anything either, both with the Qubes-suggested IPs and the ones the Whonix team suggests.

Something I also found is that even when doing sys-whonix → mullvad-vpn → windows, it still doesn’t work, but sys-whonix and even mullvad-vpn both work for any other kind of qube.

If worth anything, I’m using this continuation of the liteqube project to slim down core service qubes, but I’m still using the default sys-whonix qube for Tor networking.

1 Like
7

I have exactly the same problem. But I tried it with VPN and it didn’t help me. If anyone finds a solution, please let me know.

2 Likes
8

At this time, it might be worth checking for bug reports and if none exists, report a bug.

1 Like
9

I am genuinely interested in what would be the goal of using sys-whonix as netVm for a Windows VM?

1 Like
10

Is it going to be fixed on Qubes 4.2 or will need to wait for 4.3? I would open a github issue. Unfortunately, I do not have a github account.

1 Like
11

@unman

12

@unman The situation is as follows:

sys-whonix → windows HVM

1-qubes
1-qubes771×157 6.14 KB

2-windows
2-windows707×417 20.4 KB

3-no_internet
3-no_internet1038×652 13.2 KB

1 Like
13

sys-vpn → Windows HVM
sys-whonix → sys-vpn → Windows HVM

1-qubes
1-qubes696×121 5.38 KB

2-windows
2-windows772×465 23.3 KB

3-internet
3-internet1037×640 46.5 KB

1 Like
14

I’ve raised an issue - #9990

1 Like
15

I have the same problem. Windows HVM does not connect with sys-whonix. This happened after the Gateway update

1 Like
16

Can you check journalctl in sys-whonix for any errors about the time when Windows HVM starts?

1 Like
17

Start Windows HVM minute 31. Shut down minute 40. Only 1 error detected minute 40.

31:06 host root[4756]: /etc/xen/scripts/vif-route-qubes: online type_if=vif XENBUS_PATH=backend/vif/33/0
31:06 host root[4787]: /etc/xen/scripts/vif-route-qubes: Successful vif-route-qubes online for vif33.0.
31:06 host root[4788]: /etc/xen/scripts/vif-route-qubes: Writing backend/vif/33/0/hotplug-status connected to xenstore.
31:06 host kernel: vif vif-33-0 vif33.0: Guest Rx ready
31:08 host root[4806]: /etc/xen/scripts/vif-route-qubes: online type_if=vif XENBUS_PATH=backend/vif/32/0
31:08 host root[4836]: /etc/xen/scripts/vif-route-qubes: Successful vif-route-qubes online for vif32.0.
31:08 host root[4837]: /etc/xen/scripts/vif-route-qubes: Writing backend/vif/32/0/hotplug-status connected to xenstore.
31:08 host root[4847]: /etc/xen/scripts/vif-route-qubes: add type_if=tap XENBUS_PATH=backend/vif/32/0

40:14 host root[5412]: /etc/xen/scripts/vif-route-qubes: offline type_if=vif XENBUS_PATH=backend/vif/33/0
40:14 host root[5419]: /etc/xen/scripts/vif-route-qubes: offline type_if=vif XENBUS_PATH=backend/vif/32/0
40:14 host root[5461]: /etc/xen/scripts/vif-route-qubes: Successful vif-route-qubes offline for vif33.0.
40:14 host root[5462]: /etc/xen/scripts/vif-route-qubes: Writing backend/vif/32/0/hotplug-error /etc/xen/scripts/vif-route-qubes failed; error detected. backend/vif/32/0/hotplug-status error to xenstore.
40:14 host root[5464]: /etc/xen/scripts/vif-route-qubes: /etc/xen/scripts/vif-route-qubes failed; error detected.
40:14 host root[5473]: /etc/xen/scripts/vif-route-qubes: remove type_if=tap XENBUS_PATH=backend/vif/32/0
1 Like
18

Hm, the error on the “offline” action shouldn’t be relevant here, it’s during shutdown anyway. And I don’t see error during “online” action… Maybe there is something more in /var/log/xen/xldevd.log or /var/log/xen/xen-hotplug.log (both in sys-whonix)? But without error in journalctl, probably no…

1 Like
19

There are errors.

/var/log/xen/xldevd.log

libxl: error: libxl_exec.c:117:libxl_report_child_exitstatus: /etc/xen/scripts/vif-route-qubes add [2915] exited with error status 1

/var/log/xen/xen-hotplug.log

Failed to read /qubes-netvm-gateway6
Failed to read /qubes-netvm-gateway6
xenstore-read: couldn't read path /local/domain/0/backend/vif/54/0/type
1 Like
20

Following up. There are no such errors if I do sys-whonix → sys-vpn → Windows HVM

/var/log/xen/xldevd.log

empty file

/var/log/xen/xen-hotplug.log

Failed to read /qubes-netvm-gateway6
1 Like