If you manually configure your network settings to use static addresses instead of DHCP then they will stay permanently.
There are images of where and how to change them in my link:
Also there is a link to the guide where it is described how to do this:
In case you switch from sys-firewall to sys-whonix, you’ll need a static IP network configuration, DHCP won’t work for sys-whonix. Sometimes this may also happen if you keep using sys-firewall. In both cases, proceed as follows:
Check the IP address allocated to the qube - either from GUI Manager, or via qvm-ls -n WindowsNew from a dom0 terminal (E.g. 10.137.0.x with gateway 10.138.y.z).
In the Windows qube, open the Network manager and change the IPv4 configuration of the network interfacefrom “Automatic” to “Manual”.
Enter the Address: 10.137.0.x in our example.
Enter the Netmask: 255.255.255.0
Enter the Gateway: 10.138.y.z in our example.
Enter DNS: 10.139.1.1,10.139.1.2 (the Virtual DNS addresses used by Qubes.
You’ll have to do this in the network part of the Windows Control Panel, by setting the IPv4 properties of your network adapter. If you use a combination of TemplateVM and AppVM, this has to be done in the template in order to stay permanently.
Is it right, that I have to set the firewall as network vm to update the template, or will the update work as with any other linux templates without a network connection?
In that case I would have to change the network settings in the template each time I would do an update.
My first idea was to create an update script in the app vm and start this automatically after booting with admin rights. I was looking for the right place to put the script and the best way to autostart …
I am afraid that you will have to connect a Windows TemplateVM temporarily to use a network VM.
The designated update VM (sys-net, sys-firewall, or sys-whonix, as configured via the global prefs (qubes-refs updatevm) works for Linux VMs as a network proxy to download the updates, but Windows VMs ignore this setting and simply state they could not search for updates - the cause is an unknown error 8024402C; Windows is helpful as ever in this respect.
Ok, in that case my idea would be better, if we can find out, how to do it.
Should be something similar as rc.local in linux app vms.
I’ve found the following solution to set the correct IP address and DNS:
Lookup the name of your network interface in the network part of the system controls. For the ease of use give it a senseful name. Here I use “Xen PV Interface”. You need to know it for the next commands.
Open cmd.exe as administrator.
Give the following 3 commands:
C:> netsh interface ipv4 set address “Xen PV Ethernet” static address=10.137.0.xxx mask=0.0.0.0 gateway=10.137.0.ggg
C:> netsh interface ip set dns “Xen PV Ethernet” static 10.139.1.1
C:> netsh interface ip add dns “Xen PV Ethernet” 10.139.1.2
Here “xxx” is the IP of the windows app vm, “ggg” is the address of the connected firewall as gateway. If I’m right the two DNS servers are preconfigured by Qubes OS, so they are always the same.
As those 3 commands do the work, they need to be put into a short batch script for example “set-static-IP-config.bat”. We’ll save it on drive Q:, so it won’t get lost with the next shutdown.
At least we will need the right way to start this script. - Again I will need your ideas. My knowledge stops here.
That solution works as long as the active user is in the administrators group.
As I’m using this machine only for gaming, that’s no problem for now.
In security related app vms this will be a problem.
Dr. Google helps: Some little changes and it works for all users!
Create a directory “Qubes” on drive Q: in both virtual machines (template and app vm) and put copies of the above created batchfile in these directories.
Change “xxx” in both files to fit the IP of its corresponding vm.
Test both VMs: After running the script, template and app vm should be able to reach the internet.
Now we can use regedit to create an entry in the templates registry:
Go to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run].
(This part of the registry is stored on C:, so it will be the same in the app vm.)
Create a new key, give it a senseful name and link its value to the batchfile.
After doing this, my exported entry looks as follows:
The entries at this point of the registry are started with system rights. Therefore you should secure the batch files on Q:, that normal users can’t change what happens here!
Sorry: The solution before had some fault: The registry entry would start the batchfile for all users, but not with system or admin rights, what is needed to change network settings. My test, why I thought it would work was faulty, as the test user got the admin rights elevated out of another group.
After talking to a friend with some more experience with Windows, here his ideas put into a working solution:
The easiest way to start a program with system rights instead of those of the actual user is to start that program as a service. There are some free tools for this task available for download. I took nssm, as it is easily installed in the template vm with chocolatey.
Do the following as administrator in the template vm. The nssm gui seems to make some trouble when running as a normal user, even with admin rights and the next tasks need administrative rights anyway.
Install nssm:
C:> choco install nssm
Show some help to nssm:
C:> nssm
Install the service “set-vm-IP-to-Xen-PV-Ethernet”
C:> nssm install set-vm-IP-to-Xen-PV-Ethernet
You will get a GUI where you can choose our batch file on drive Q: in the field “Details” / “Application” / “Path”. Thereafter go to the “Exit actions” tab and choose “No action” for “Restart”.
Click “Install” and you are ready. Shutdown the template and run the app vm.
When the service is started during startup, it uses the batch file on drive Q: of the started VM with the IP of this VM and that’s what we need.
