When you use the “firewall” tab in a qube settings, the rules are done in the netvm of the qube, so it could be sys-firewall without requiring a clone, or I am missing something? 
2 Likes
Ah, maybe I’m missing something! 
But I don’t have time to check now.
Edit: and cannot check till Friday. You are probably right though. Will follow up next Friday on this topic.
2 Likes
Using the protonvpn-app method has been quite inconvenient of late. Once again Solene you have bailed me out with solid vpn advice. Your method here worked flawlessly and is a big improvement. Many thanks!
4 Likes
All right, I’m back…
@Solene: you write in the first post of this thread that the “Optional Hardening” is done by adding iptables (or nft, for 4.2) rules in sys-vpn. My point was that those rules can be undone in sys-vpn, if the qube is compromised, hence the use of a dedicated sys-fw-post-vpn to mitigate.
However, if you use qvm-firewall commands in dom0 to achieve this hardening, it is possible to use the stock sys-firewall between sys-vpn and sys-net. The hardening done this way cannot be undone from sys-vpn itself.
Hope this clears up the need (or not) of a dedicated sys-fw-post-vpn!
Oops, hit a glitch Solene and don’t know how to correct it. I successfully made a working Proton vpn vm using your method from the start through the nmcli connect line. It works, but is quite slow, because I chose a double Secure server option for my wireguard. I then followed the exact same process to make another Proton wireguard vm, using a single server. But I’m getting error messages each time I enter the nmcli command line. It’s not happy with the .conf name I enter and thinks it’s not a valid interface name. So far I’ve tried four separate times with four new vms. Each time I get the same result. Have used single servers from various US and Canadian Proton servers. Have also tried system reboots, using the “accept any” option in firewall rules, etc in case it was just a general networking problem (guessing at this point.) I did note your initial comment that if it doesn’t work at the nmcli line, there might be something wrong with the .conf file, but I would have expected to get a workable file after downloading four of them. Any suggestions please?
that’s just the firewall rules on the vpn NetVM, this is exactly what adding rules in the vpn qube firewall tab is doing. It modify the rules on the qube providing network to the vpn qube, it can’t be undone from the vpn qube itself. 
1 Like
Got it thanks Solene. On a chance I bypassed the downloading of the config file, copying to other app vm, moving to /home and instead just downloaded another single server wireguard .conf file from Proton directly into my Proton vpn vm, then moved it to /home. It worked first time. Maybe I just had four bad config files before or maybe the new way allowed the process to work. Don’t know, that’s “out of my pay grade” of knowledge. But the new server is fast and working great. Thanks again.
2 Likes
It’s confirmed! Fedora-39 supports importing wireguard profiles directly form the GUI (since it’s shipping the version 1.34.0, so we won’t need to use the command line for anything).
Added an important detail on the guide… Without this when setting this qube as the default it leads to recursion. sys-vpn setting itself as the net qube, which obviously will not work.
ah, this is an issue that should be reported
The recursion actually does not happen. Qubes simply fails to set it as the net vm of itself.
1 Like
Yeah I glanced over at my Qubes Manager and saw they were all set to default (sys-firewall) also.
Never had an issue with anything related to it.
Did you apply the last “hardening” on 4.2? I’m just asking because there are some iptables rules in the guide and on 4.2 there is only nft. I noticed there is iptables-translate but did not test it yet.
Nope - I didn’t see that. Will take a look. Thanks
I added a snippet to solve MTU problems with wg tunnels. I just got an issue loading www.duckduckgo.com (and only this server) when using the VPN. A solution was to reduce the MTU of eth0 in the qubes using the VPN, but a better alternative is to add a firewall rule to force the MTU to be smaller. (I found the fix as part of my job at ivpn)
1 Like
I’m having some issues connecting to protonvpn’s wireguard servers. Their configuration file provides a private key value of ***** and my fedora template is giving me the error “Key is not of the correct length or format” when I try to connect to it. They do provide a public key.
I don’t know enough about this to know for sure if this is a protonvpn issue or something else.
I don’t understand why you’re talking about the template. The template is just here to install wireguard (if it is not install) then, It’s all happening in the sys-vpn.
You have the public key directly in the config file and DON’T touch it.
Like @solene say, in sys-vpn, just open a terminal where you have your vpn.conf file, then run the command:
nmcli connection import type wireguard file vpn.conf
It’s just what you have to do 
It is not just a protonvpn issue, i do the same thing with riseup vpn. All is allright…
Is it at all possible to accomplish this with Fedora 38 minimal 32 bit? I have very limited resources (only 16 GB ram) so every MB counts.
I don’t think 32 bits templates are provided. I have a laptop with 8 GB of memory and I can definitely have a working VPN setup though 
If wireguard is used, it will not be possible to connect to tor, is there any way to use wireguard in conjunction with tor?