Possible to use WindowsVM as a NetVM?

[qubesusermarco]

I have a Windows-7-VM assigned as some LinuxVM's netVM. And I get the error below after some timeout when I try to start the appvm:

ERROR: Start failed: internal error: libxenlight failed to create new domain 'appVM_name'. See /var/log/libvirt/libxl/libxl-driver.log for details.

Here's the error message in the log:

2018-11-21 14:31:13.157+0000: libxl: libxl_device.c:1093:device_backend_callback: unable to add device with path /local/domain/38/backend/vif/40/0

2018-11-21 14:31:13.157+0000: libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices

2018-11-21 14:31:23.181+0000: libxl: libxl_device.c:1093:device_backend_callback: unable to remove device with path /local/domain/38/backend/vif/40/0

2018-11-21 14:31:23.181+0000: libxl: libxl.c:1669:devices_destroy_cb: libxl_devices_destroy_failed_for_40

Is it just plain impossible for a WindowsVM to be a NetVM or I'm missing something?

   

[awokd]

'qubesusermarco' via qubes-users wrote on 11/21/18 4:47 PM:

I don't see adding/removing NICs as one of the supported features in
https://www.qubes-os.org/doc/windows-tools/, so my guess is it's not
possible.

[unman]

You need to think laterally to make this work.

Create new qube, make it provide network, but dont attach it to an
upstream netvm.

Attach Windows Vm to the new qube.
Attach your NIC to the Windows VM.
Now the WindowsVM has two network devices.

Attach your clients to the new qube as netvm.

On the new qube, change firewall rules to allow traffic between the
vif+ interfaces, and remove the restrictions in iptables raw table.

With some jiggerypokery on the intermediate (new) qube, to handle
routing and DNS you dont need to change anything on the client qubes.

I've posted in more detail on this before - if you need more help just
ask, but this should point you where to go.

unman

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/21/18 5:47 PM, 'qubesusermarco' via qubes-users wrote:
> I have a Windows-7-VM assigned as some LinuxVM's netVM.

I just wonder why would you do this?
That would be big, bad, outdated and absolutely not designed for such
task...

> Is it just plain impossible for a WindowsVM to be a NetVM or I'm
> missing something?

I would not say impossible, but not working out of the box for sure.
In practice: it would need a lot of development to make it work.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlv4PlgACgkQVjGlenYH
FQ2jbA//VX1ou/KfC5ARgGRvTQ2VXt2lGK6bo8hWcwsafH+M314EvmOa1vUCQ0ue
THoRTb5/0IbuPD0Cn6n3Fn9GpodBdaM2sMkyXvQDX9OHfbyHc+XtpMUZ4fnobulE
LHzBFSFoPBivWJZ9GcAgqSulWCGVJ5kryYd2TXFEPhjW5HIY5efjphviTh0FUvw1
f/qP7lt0Us3MxL5g542PrpXSH8p0PVOVQTeJscFzYXUw3GdXxsP3bB1AP/a63n8M
F76l0o+vg56sH8hgitMRqg0GUtJ1x2Em6KrnsGdfYzQxhlbur1QsAR44X6e56Bpu
rIyHOFls3GvPmMy2G44rOxaBlwc5YqIFO9eRQYNo9daVmOlX9dBbWWzRsf+SOY/W
RxFXao87kB72sbSz2NlLWTPmA8KikrgCvAO/V/OVf6hdatYHhzT6ko4bkRM9uh7A
tj+6b5cK9olfjRzVrQ2e7KBMaOH8UPm17Lxo0aPP+OLrtuywJvUZP9K/hHCS2Y6P
2ikeNXpKjIkojNZSY/AXHdP25HIj3hu35RTXXvxwhbjAVFy7NPnHZO7ikgpF2uHE
xT+kc8H3g6gjKJIrArOc3Qt5sUJhV+JDeam3AhvJO/FNB22OQgHuxGL54WaVkq0D
3B3GtBAGRVf6QudMVNT6AbYh+sM06+1TVUPIXJ+7h2vvVENKGi8=
=PYnE
-----END PGP SIGNATURE-----

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/23/18 11:52 AM, Zrubi wrote:
> I just wonder why would you do this?

I suppose a Windows-only proprietary VPN client ... am I right?

/Sven
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlv4RJgACgkQ2m4We49U
H7adyxAAgHx2uhe3fed67C8gMH9DOqFfMjsCNPip/8cyn4xZDbDYbywEG+MT4nBQ
9Rt1MOSDzGfYKr7EMgWMvo8KSZpLMK8BN6blLqzFqrG5b3GMnKUrTqXW0akFFrBz
Bp4+1cMuPSEQfSBZ0bCsi1Fn1jvXIOVytF1XT2tms/dOGIr+VU5bs8aWfTbypEET
s0M3ci+PZIWRKP7ZVPAGdZ1aOncxEwpAKT5cURWCwhvuciNe9gLVvZ11UjGbEPxX
mpPLhdyCYyKjPNZXbwPamtymNwZKHQIY7SMZ57KszeTtOP1fpd2tJpo9KqMg+3bR
E57WYwlYTaU+YQZPgRzA4WTVGs9CMRaP651XImLR1YqEBSoMhfePSeXU9y337J64
0HnTW8KK5qVP9YcDyPfDOML76EvOyHBvT/DbX5tiY/5uyIel2mIpKOkdDmdSy+24
Xmfn6G7wISo+PhuoF9xiQy7kYnxukN0QLtyXD1zuqNqEvXLA8c/QbVC7us7xlEbt
5ZvgAiDc+tFWbxwzFgh7Z2AT7iHW2xpxi4uNXEUAA8KcNKlQtlJZ2NNdK2o0zFAV
aneoTJtKqQDpJsme3zZGkEg+6WVmgxr8xG4hbY/rJi+yY0L7b1dSIei02LJVg3Mf
Gcn2riftKozg6oexgwvz4H5/gnttYn6wLE/LyN6f7+UfrCVWV6Q=
=cbLZ
-----END PGP SIGNATURE-----

[unman]

On Fri, Nov 23, 2018 at 06:52:32PM +0100, Zrubi wrote:
> > Is it just plain impossible for a WindowsVM to be a NetVM or I'm
> > missing something?
>
> I would not say impossible, but not working out of the box for sure.
> In practice: it would need a lot of development to make it work.
>

As I've said, it doesnt need any development work. Just a minor bit of
configuration and any HVM can act as a netVM.

[qubesus...@gmail.com]

On Friday, November 23, 2018 at 1:19:13 PM UTC-5, Sven Semmler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 11/23/18 11:52 AM, Zrubi wrote:
> > I just wonder why would you do this?
>
> I suppose a Windows-only proprietary VPN client ... am I right?
>
> /Sven

Correct, good guess.

[qubesus...@gmail.com]

On Thursday, November 22, 2018 at 7:35:38 PM UTC-5, unman wrote:
> Attach Windows Vm to the new qube.
> Attach your NIC to the Windows VM.
> Now the WindowsVM has two network devices.

Wow, I never thought that NIC can be attached to VM not on topmost, thanks for the tip!
But, as I was setting up the network you described, the same weird weird problem happened again which I've been dealing with for 2 days and still have no clue...

That is, it seems that a qube couldn't UNDERSTAND the packets coming through its vif+ interface with source ip address not of the qube directly connected to its vif+. By "understand" I mean the packet can be seen by tcpdump and wireshark on the corresponding vif, but never reaches the application, as if dropped by kernel.

In your networking:

i <---- i can't deliver packets generated from outside to C
/ \
/ \
C W <---> outside

i,W,C can ping each other OK
W pings outside: OK
i/C pings outside: ICMP reply seen by tcpdump on i's right side vif, but ping failed.

Same thing happens in this situation:

a
|
|
b
|
|
c

c/b pings a: OK
a pings c: reply seen by tcpdump, but ping fails

Iptables are all empty and rp_filter is 0, so it kinda narrows it down to kernel and XEN. But I don't see any packet-dropping in statistics.
This strange behavior strikes me as some kinds of security mechanism. Do you have the same problem?

[unman]

You havent looked at my other posts, I think.
Have you checked the raw table? By default a netvm restricts traffic on
a vif to the allocated IP: you need to remove that restriction.

I made some notes on using an openBSD HVM as a netvm -
https://github.com/unman/notes/blob/master/openBSD_as_netvm
You should be able to adapt them to your own case.

unman

[qubesus...@gmail.com]

> You havent looked at my other posts, I think.
> Have you checked the raw table? By default a netvm restricts traffic on
> a vif to the allocated IP: you need to remove that restriction.
>
> I made some notes on using an openBSD HVM as a netvm -
> https://github.com/unman/notes/blob/master/openBSD_as_netvm
> You should be able to adapt them to your own case.
>
> unman

Oh my! Looked into every other table except for the raw one... What a shame!
Anyways, upon removal of that sneaky one helluva rule, everything works like a charm now.
Thanks a million, sir!