cloned Whonix TemplateVM connects / upgrades through sys-whonix even if NetVM is set to a different Whonix-Gateway ProxyVM

Qubes-Whonix
1

if we clone whonix-ws/gw 14 template and we change the connection of appvm from sys-whonix to xxx-gw-appvm. the template will always open sys-whonix even if change the “Networking” to anther gw-appvm name.

this is i think a problem of salt? but anyway its not good to connect all templates to one point by force. as sometimes u like to modify the appvm-gw to be with vpn or with i2p or …etc. this is cant be achieved atm.

2

Hi nurmagoz

  • Qubes-R4.0 templates are non-network connected by default. (NetVM should be set to None!)
  • For TemplateVM updates (apt-get, … ) Qubes updates proxy (RPC/qrexec based) is used instead.

There are a few things to be aware of:

  • Salt sets sys-whonix as updateVM for Qubes-Whonix TemplateVM

  • If sys-whonix is updateVM (default) and both

    1. Networking is enabled for a Whonix templateVM
    2. A different whonix-gw based AppVM is used as netvm for that TemplateVM.

Networking issues ( i.e. not able to connect) will likely take place. RPC/qrexec will fight with netvm to update the template.

There are a few suport requests on Whonix forums and Qubes issues where this was the problem. And I might have had a little experience with this when I first started using Qube-r4 .

Also, you can edit /etc/qubes-rpc/policy/qubes.UpdatesProxy to allow specific Templates to update over other (netvm) AppVMs.

1 Like
3

Right.

It’s a usability issue. Fix suggested here:

1 Like