It’s likely that sys-firewall is a static disposable. You could either try making your changes in the disposable template on which sys-firewall is based or making a separate firewall qube that isn’t disposable.
clone fedora-37-dvm / debian-11-dvm, rename it as app-sys-firewall
clone sys-firewall, rename it as sys-firewall-lab
change template sys-firewall-lab from fedora-37-dvm / debian-11-dvm to app-sys-firewall
configure your changes on app-sys-firewall.
@51lieal yes it’s my default installation to have sys-firewall template set to debian-11-dvm. Your workaround will probably work fine, but I have to create an extra machine, I’d just like to change my sys-firewall clone template to a non disposable one, yet this seems impossible.
@adw yes that is the case, the first option you mention is what the other user wrote after you. I’d actually really like to make a new sys-firewall from scratch with a non dvm template but there’s no documentation about it
By the way, I’m just following the qubes official documentation to make the iptables modification persistence so that qubes can talk to eachother, they should probably write something in case the user chose to use dvm as sys-firewall and sys-net templates during Qubes installation.
Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, …) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons. In particular, if you want to ensure proper functioning of the Qubes firewall, you should not tinker with iptables or nftables rules in such qubes.
Instead, you should deploy a network infrastructure such as
@disp6252 so they say to not use a network service qube (like the one for a vpn) as a firewall machine, meaning they are indeed different machines! furthermore there are no official instructions to re-create sys-firewall, suggesting it’s a special machine.
So far 51lieal’s suggestion is the best workaround imho.
We also no longer distinguish between AppVMs, NetVMs and Proxy VMs. Instead, each VM has a property provides_network, which is false by default, except for the VMs which we want to expose networking to other VMs (e.g. because they might have some networking device assigned, such as cellular modem or WiFi device, or because they act as VPNs or proxies of some sort).
You can also check your current sys-firewall Qube Settings and you’ll see that in Advanced tab the “Privides network” is set.
Yes even sys-firewall is an appvm with the provides network feature enabled, but the documentation is quite clear in implying that sys-firewall has had modifications that make it different than a simple appvm (with or without the provides network feature), otherwise they wouldn’t have written what I quoted.
It sucks that qubes always relies on the community to solve all the issues
The qube with provides_network will start being truly firewall VM only when you set some firewall rules to the qubes that are connected to this VM. There are no specific settings for the qube that determine it as firewall qube. They are dynamically configured by Qubes.
I think the best way to understand this is to see that there could be
interaction between any nftables modifications made to support other
services and operation of the qubes-firewall table.
To avoid this, use a dedicated firewall qube - that way you will be
assured that the Qubes firewall will work as intended.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Ok then, I’ll clone debian-11-dvm, set my firewall rules in the /rw/config folder, then create a fresh appvm (disposableVM actually, otherwise I cannot set the dvm template I just cloned) and set the template to this clone I just created, and set the provides network feature. According to unman it’s even better to not use a clone of sys-firewall as it might have specific nftables modifications that I do not want.
LAST QUESTION: if I set through dom0 qvm-firewall command to drop everything on this fresh firewall appvm, meaning the only line is:
[user@dom0 ~]$ qvm-firewall super-firewall list
NO ACTION HOST PROTOCOL PORT(S) etc
0 drop - - -
then no type of traffic will past right? I"m afraid dns, icmp, and perhaps other protocols will pass through. I just want to make sure the lab is 100% network closed no matter what.
Yes. But in this case you’ll need to have this setup: sys-net -> sys-firewall -> super-firewall -> lab-qube
Because if you set super-firewall firewall rules with qvm-firewall then these rules will be applied in its networking qube sys-firewall in this example setup.
If you just want to do this then why not to just set the super-firewall networking to none?