Qubes OS 4.2 nftables / nft firewall guide

I agree. If you know nftables use nftables. If your lost, and don’t know the nftables equivilant to -A, it can be way faster to find it out by doing:
iptables-translate -A INPUT -s 1.1.1.1/24 -j ACCEPT
and getting:
nft add rule ip filter INPUT ip saddr 1.1.1.0/24 counter accept

rather then trying to look it up in a man page, or doing a google search on it, cause you already know exactly what the one side means.

1 Like

Agreed. Thanks for opening this topic, @Solene.

Btw, do you know why R4.2 used to work but the new update that made VPNs dysfunctional was viewed as an improvement? Were there leaks or security flaws? Online auditors and cli status showed my VPN configuration to be working with the values it was designed to. Is there something hidden in this iptables complexity you could elucidate?

And does anyone know what these “start” IPs refer to in the output highlighted here? What are -t -nat --flush PR-QBS all about? No simple path for Rise Up now, is there?

As a matter of fact, don’t forget that in R4.2, selinux is enabled by default, adding some more security but at the same time, making even a simple script startup from /rw/ more complex.

in R4.2, selinux is enabled by default

Is there any more detailed info (documentation) about it?

Whatever Mullvad VPN has done is compatible with the new configuration. If someone could figure out all that they did to make their GUI and integrations with Qubes other VPNs might be easier to make work.

So each VPN offering “framework” has a lot of specifics that need to be tailored to ip/nf tables now that whatever that was automating and streamlining the particulars it has been removed?

That means that if I want to make a remailer qube, yggdrasil, veilid, nym, freenet, etc I should definitely start by mastering iptables, right? Ambitious goal. But such a proposed muti-networking-modality computer would be an attractive acquisition…

They have been using nftables in their Linux application for quite some time, so it works on Qubes 4.2.

You need to learn the syntax of nftables and how it works. iptables is considered deprecated and is already replaced by nftables under the hood in some distributions.

iptables is considered deprecated and is already replaced by nftables under the hood in some distributions.

My information may be somewhat outdated but some months ago I have read that Android uses only iptables and most non-x86 architectures don’t support nftables at all. Of course, nftables is better and the way forward. Just sharing.

Of course!
4.2.0 Resease Notes
And, linked in the Release Notes:
SELinux support in Fedora qubes
(scroll towards the end, the thread starts in 2018)
On Feb 26 2023, marmarek (chapeau!) confirms that selinux is enabled by default in Fedora-based templates: Build Fedora templates with SELinux enabled from the start #7988

2 Likes

Ok. Read up on nftables. Still dont know how to, for starters, take an installation guide specific to Debian stable or bookworm and add something with nftables to make it work like it did before when R4.2 has iptables. nftables just organizes iptables more and corrects a few other security issues.

If you have trouble with nftables, you can still use iptables-translate to get any iptables rule into nftables syntax. The only thing to keep in mind is that Qubes has created its own table called “qubes”, so if you are using nft, you will need to refer to it in your command.
You have some examples in this PR:

I don’t know how it is in 4.2, but in 4.1, whenever I add an IPv6 address to the allow list, it does not show up in nft list ruleset. I wonder if this is a bug.

Can anyone using 4.2 check this?

What’s your nft command?

IPv6 is disabled by default, you need to enable it explicitly:

What’s your nft command?

Listed above.
I add the IPv6 address through the firewall tab in the qube settings UI.

I’ve tested this for R4.2 and it works with IPv6-enabled qubes.

IPv6 is disabled by default

I didn’t know that. Thanks.

I still don’t know why (I’m still checking the source code), but everything that is applied to sys-firewall from the GUI/CLI is set to its NetVM in the qubes-firewall table (sys-net in my case).

This is how the firewall works, when you edit a rule for a qube, it’s applied in its netvm so if the qube is compromised the firewall rules can’t be altered.

1 Like

I understand this, but if someone applies rules to sys-firewall, it goes to sys-net, which is more likely to be compromised. So the better way to apply rules, in the case of a VPN setup for example, is to set them on the VPN qube itself and not on sys-firewall I guess?

These Qubes firewall rules can only be applied from dom0.