Yes.
It won’t support multiple VPNs. If you need to use different VPNs for different qubes connected to ProxyVM then you’ll have to make additional routing as I’ve described in my first reply.
Or, if I am not mistaken, the alternative is what I had planned to try next: Set up ProxyVM as a VPN gateway using NetworkManager.
I’m not sure about NetworkManager as well. I didn’t look into how it can route different interface using different VPNs but you’ll most probably need to specify the qubes virtual interfaces vif* that should use specific VPN configs but there’s a problem with this:
Because these virtual interfaces are not tied to specific qubes persistently. So you’ll need to somehow make the runtime configuration to first determine which interface belongs to which qube and then configure this interface to use specific VPN config.
An ‘easy’ way to do this with Qubes-vpn-support is to keep the various configs in a subdir /rw/config/vpn/my-confs and then have a small script that lets you choose one of the configs.
#!/usr/bin/env sh
selected=$(zenity --file-selection --filename /rw/config/vpn/my-confs/)
cp "$selected" /rw/config/vpn/vpn-client.conf
systemctl restart qubes-vpn-handler
That’s about it, really. Its only the .conf files that go in the my-confs subdir; any other conf-realted files like .pem, .crt etc stay in the parent dir.
If using qubes-tunnel instead, you would only have to change a couple paths + service name…
#!/usr/bin/env sh
selected=$(zenity --file-selection --filename /rw/config/qtunnel/my-confs/)
cp "$selected" /rw/config/qtunnel/qtunnel.conf
systemctl restart qubes-tunnel
You could also put this in a loop with a read at the end so you have to press Return before getting the next file prompt. Or you could call it from a systray tool that run scripts.
Network Manager:
There are good reasons why you probably shouldn’t use NM for VPNs unless the VPN provider has NM-specific instructions. In short, the NM openvpn plugin was designed incorrectly and cannot handle every combination of config options that VPN providers like to use. Its been that way for a loooong time.
I thought I understood the issue you were explaining: Even if everything works with NM, it would still only select one config for all the AppVMs at a time, whereas I wanted different configs running in the ProxyVM simultaneously.
So where does the script run? Can it choose different configs per AppVM simultaneously?
The misunderstanding that there is NO Appvm ↔ VPN config association at all.
If you run multiple VPN, that will be ‘available’ for all the connected AppVMs.
So by design - and by default - the VPN do not know about your AppVMs at all.
That’s can be confusing and ‘dangerous’ for the beginners, but very practical for the one that needs such setup.
And again: NM allows you to run multiple VPNs at the same time.
I’m using this ‘feature’ daily.
OK. So now I have setup up a ProxyVM running NetworkManager with two VPN connecttions.
Then I tried using this to provide the network for an AppVM. Testing the connection showed that the AppVM is using the first VPN connection from NM. So how to do I make the AppVM use the other VPN?
I am guessing that the next step involves qvm-firewall but can I please confirm?
well, the VPN - in general - connecting you with another host or network.
However It can provide you a default route too, which means every connection goes trough that tunnel.
It boot pushing you default route - that’s usually means you do not need more than one VPN at the same time 
Multiple VPNs are only meaningful if you not expecting them to push a default route.
Even tho this simpified sentence not always true, as your client can decide if it accept that route or not, moreover it can also override it.
so in general the (Layer 3) VPN just creates a tunnel, and then it’s all about routing. As you see VPN providers trying to ‘help you’ create the corrent routing… but all depends on your goals.
If you can describe why do you think you need multiple VPN at the same time, I might be able to help you clarify…
I don’t really know what “boot pushing you default route” means? I am using two different configs from the same VPN provider. They have many locations (maybe 50 ~ 100).
But certainly I do need to restrict each VM to use only one of the VPN configs of my choosing. Location spoofing is just one reason.
So unless I can achieve that functionality with this setup it will not be my solution.
You cannot use the same sys-vpn vm to provide different vpn routes to two different qubes. So you have two options:
- Connect both qubes to the same
sys-vpn: they will have the same vpn route; - Create a secondary
sys-vpn-2with a different config file, then connect qube 1 tosys-vpn-1and qube 2 tosys-vpn-2.
1 Like
That answers my question then. The 1st approach does not do what is needed.
The obvious setback of the 2nd approach is that multiple ProxyVMs consume RAM. I’m finding Qubes difficult to use as it is on a 16GB system: VMs frequently become unresponsive as memory gets used up.
I will post the details of my 3rd solution separately. It uses the VPN provider’s app in each AppVM, but this is not straightforward.
so it seems you don’t really need multiple VPNs on a single proxyVM, but you need more RAM 
Consider using a minimal template with the following packages installed, my sys-vpn runs on 300Mb of ram:
Actually, that is not even a solution either. I have a used system with a 16GB max. But yeah, a new computer would help.
This is really not an ideal solution. I would want at least 3, and ideally more VPNs.
I didn’t try your “recipe” but it seems odd that you would need to install network-manager-openvpn for example. I’m guessing you installed extra to make sure it worked.
I just wanted to direct you to your real probem…
I have run Qubes with 16G RAM for a loong time, without issues and with multiple proxyVMs
So, you should search for RAM optimising tips, I’m sure there where a lot of discusion about that.
(maybe before these forums, so search on the mailing list…)
1 Like
I will have a look.
My impression is that web browsers are the main culprit for memory consumption.