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.
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.
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.
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.
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.
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?