I have a clone of sys-firewall for setting up a local lab for some tests, I need to make the qubes communicate so I set up ip tables correctly: everything works fine
however if I put commands in /rw/config/rc.local OR /rw/config/qubes-firewall-user-script and reboot, they are gone!
template is a disposable vm, which I cannot change to a non diposable one, tried everything!
You could follow these instructions in the Template (disp) that is the basis of sys-firewall, to make files /rw/config/rc.local and /rw/config/qubes-firewall-user-script persistent:
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.
I assume that you use default config,
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.
start sys-firewall-lab.
@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.
You can create in with “Create new qube” GUI tool. Just set the “Provides network access to other qubes” option in Advanced tab in addition to the basic options.
The qubes documentation states (Firewall | Qubes OS):
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
sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]
@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.
what you mean by extra machine? its just another appvm and dispvm, you mention creating lab thing, so you can keep the default sys-firewall for other use, and this sys-firewall-lab for your lab.
if you want a persistence sys-firewall for your lab, you create new appvm from debian-11 template, and tick provide network for other qubes.
I do not find such implication.
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.
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?
I ended up here being just as confused as OP because the Qubes Firewall Docs mention
you should write the above iptables rules into firewallVM’s
qubes-firewall-user-scriptscript
which makes little sense if that file is nuked on reboot.
This is incredibly helpful and worked for me - I suggest to make this explanation a bit more verbose and add it to the Firewall Docs