The rules could be bypassed in some cases so it’s better to have the killswitch inside the qube as well.
For example, sys-whonix is not supporting the Qubes firewall so the firewall rules are ignored if you set sys-whonix as net qube for sys-vpn.
this is why it is recommended to have a sys-firewall as a netvm of their vpn, between the “real” netvm and the vpn qube 
BTW is the default “sys-firewall” anything special?
Do I understand correctly that it is enough to just configure the vpn-qube and then clone the default sys-firwall to sys-firwall-after-vpn, and that would be enough?
No.
Yes.
What do you mean by “app friendly”? Is it that I cannot script things inside the sys-vpn qube because the firewall rules are outside the scope of that qube with qvm-firewall?
So if I understand you correctly, hardening is nice for sys-vpn setups where I need to do more than just route traffic inside the qube, but if I just care about a VPN connection, qvm-firewall is even better and hardening is then useless/necessary?
Please confirm. Thanks.
That is very interesting. I did not know that, where is it documented?
This might be interesting here as well: QubesOS Firewall Management + Any Problem with sys-usb, sys-firewall, sys-net Being Disposable?
Can you please check and comment on this?
rules done at level qvm-firewall can’t be read/modified by the qube itself
“after vpn” is misleading, ideally it should be between the vpn and its netvm, “after” depends how you see the flow 
1 Like
I am not sure how sys-firewall works. Thanks for the insight. Does sys-firewall use the qvm-firewall rules? How does that work? I had a similar question that you might want to expand your knowledge on. I would really appreciate it. Thank you very much.
Please check: QubesOS Firewall Management + Any Problem with sys-usb, sys-firewall, sys-net Being Disposable?
basically, we call it “sys-firewall”, but it’s just a disposable qube that is a netvm and does nothing more. It just exists, receive firewall rules for the qubes using it as a netvm, and that’s all.
Thanks again, so this means that qvm-firewall is sort of a mega killswitch, because even if the sys-vpn qube is compromised, the firewall rules would still exist, right?
Where do the firewall rules that sys-firewall process come from? Is it that qvm-firewall keeps a config and loads it into sys-firewall at startup?
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Qubes/Firewall#Qubes_VM_Manager_Firewall_Tab_Settings
Clearnet link:
Qubes/Firewall - Whonix
1 Like
it’s in the qube metadata, accessible from dom0
1 Like
So each qube has a metadata file with its rules, and sys-firewall loads that and processes it? What if sys-firewall is disposable? Will the firewall rules still work because sys-firewall does not actually store the rule information, but always loads it from the connected qubes?
Why?
There is a quite significant inconvenience with the NM applet. If you use a VPN provider that has hundreds of servers, you may want to just import all of their WG configs (because why not). However, in such case the NM applet’s VPN Connections list becomes extremely long, with seemingly no way to search for a given config by name, or even instantly scroll to the bottom, or by a screen (like End and PgDn keys usually work). Even worse, there seems to be no way to activate a connection by opening the applet’s proper window (by clicking Edit Connections). Is there any workaround to this?
The only thing I can think of is using some nmcli and fzf wrapper in a terminal emulator window instead of using the NM applet. Then you can search for configs nicely. However, this kinda defeats the purpose of using GUI tools on a specifically desktop OS…
Your use-case is a niche case (i.e., very different from the normal/expected OS usage). In which case, as you say, some kind of wrapper may be needed.
Probably the easiest thing is to have a script randomly choose a VPN from the list for you, a variation of the “random VPN at startup” concept outlined in this thread. You could run that via a toolbar icon or desktop shortcut. But of course this does not solve the “browse/search for a specific server” problem.
It could be easy to make a menu entry to run a terminal running the script with fzf + nmcli
How so? It’s normal for provider-specific VPN apps to list all of their servers, and for a user to search for and switch to a server of a specific country from that list (for example to circumvent an aggressive geoblock). NM allows for provider-agnostic way of providing a GUI of sorts to raw WG configs, for potentially the same result.
To follow up on my own post here after some testing, I have two new things to report:
- The described nft rule in
/rw/config/qubes-firewall-user-scriptdoes not work automatically in my case. I made the script executable, but it still does not load when the VM starts. I confirmed this by runningnft list table ip qubes. The custom-forward chain is empty. Only by running the script manually does the custom forward chain show the rule.
I am by no means a QubesOS or nftables expert. I may have misconfigured my system or run the checks incorrectly. Please help. My qube is based on Fedora 40 Minimal.
- After manually adding the nft rule, DuckDuckGo (and others) still won’t load properly. The
ip link show eth0command still shows an MTU of 1500. Again, I may have checked the wrong thing.
A second assumption: because I have a second VPN on my router, the nft rule is not reducing the MTU to a working size. I would appreciate some clarification on the nft rule. I am new to nftables.
In contrast, my personal fix is automatically picked up by VM strat and works fine.
cat >> /rw/config/rc.local <<-'EOF'
ip link set dev eth0 mtu 1280
EOF