iptables →nftables

[DemiMarie]

The problem you're addressing (if any)
QubesOS uses the legacy xtables stack via iptables

Describe the solution you'd like
QubesOS should use the modern nf_tables kernel subsystem exclusively

Where is the value to a user, and who might that user be?
This is likely to be of greatest value to advanced users, but could also improve firewall throughput for those with very fast connections.

Describe alternatives you've considered
QubesOS could switch to BPF-based firewalling, but that is more complicated.

Additional context
Debian 10 uses iptables-nft by default, which implements iptables on top of nf_tables. Furthermore, nf_tables has features like vmaps and sets, which can provide a performance improvement.

Relevant documentation you've consulted
https://wiki.nftables.org/wiki-nftables

Related, non-duplicate issues
#4991

[icequbes1]

On R4.0 with a Fedora 32 and Debian 10 template, the following is observed:

• Debian 10's iptables package is nf_tables backend (iptables-nft)
• Fedora 32's iptables package is the legacy backend (iptables-legacy)

This results in an inconsistent state between the two templates, especially when dealing with the Qubes Firewall.

Most notably, on Fedora, iptables rules and nftables rulesets appear "separate". While both iptables and nftables can coexist, it can increase user confusion/understanding of the system configuration.

On Debian, iptables-nft replicates the proper nftables rulesets, such that nft list rulesets shows rules created using /usr/sbin/iptables.

This divergence (Fedora 32 vs Debian Qubes templates) can potentially be resolved if qubes-core-agent-networking in Fedora 32 (4.0.58-1) instead depends on iptables-nft as opposed to iptables in the rpm spec file.

However, that update may cause users to have to update any user-specific firewall commands in their Fedora 32 AppVMs. While it is unlikely users would convert from iptables to nftables, it would be beneficial if there was less divergence among the two templates.

Edit: Add link to: https://docs.fedoraproject.org/en-US/fedora/f32/release-notes/sysadmin/Networking/

[pefu]

I've a question about the following sentence:

However, that update may cause users to have to update any user-specific firewall commands in their Fedora 32 AppVMs

In https://github.com/QubesOS/qubes-doc/blob/master/user/security-in-qubes/firewall.md section "Enabling networking between two qubes" are examples how to create a qubes-firewall-user-script. Could you please elaborate whether and how such scripts would be effected?

[Nurmagoz]

quebs-core-agent-networking depend on iptables, And debian discourage the usage of iptables:

Should I build a firewall using a nftables?

Yes. Building new firewalls on top of iptables is discouraged.

Should I replace an iptables firewall with a nftables one?

Yes, nftables is the replacement for iptables. There are some tools in place to ease in this task.

Please read: https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables 

quebs-core-agent-networking depends: (without this package, no internet in appvm/standalonvm)

user@host:~$ sudo apt show qubes-core-agent-networking 
Package: qubes-core-agent-networking
Version: 4.1.31-1+deb11u1
Priority: extra
Section: admin
Source: qubes-core-agent
Maintainer: unman <[email protected]>
Installed-Size: 112 kB
Depends: qubes-core-agent (= 4.1.31-1+deb11u1), tinyproxy, iptables, net-tools, ethtool, conntrack, socat, iproute2, python3:any
Suggests: nftables
Breaks: qubes-core-agent (<< 4.0.0-1)
Replaces: qubes-core-agent (<< 4.0.0-1)
Homepage: https://www.qubes-os.org
Download-Size: 41.5 kB
APT-Manual-Installed: yes
APT-Sources: tor+https://deb.qubes-os.org/r4.1/vm bullseye/main amd64 Packages
Description: Networking support for Qubes VM
 This package provides:
  * basic network functionality (setting IP address, DNS, default gateway)
  * proxy service used by TemplateVMs to download updates
  * qubes-firewall service (FirewallVM)
 .
 Note: if you want to use NetworkManager (you do want it in NetVM), install
 also qubes-core-agent-network-manager.

[unman]

The Debian iptables is in fact iptables (nf_tables) - not legacy iptables. You can confirm by running iptables -V It's an interface to nftables, and is referenced and linked from the very page you quoted.

[Nurmagoz]

The Debian iptables is in fact iptables (nf_tables)

There is no debian iptables, iptables is fully not in debian anymore. (i mean in official release)

What you mean is iptables when installed it will not be the legacy version but nf_tables or also called iptables-nft, This is just for backward compatibility plus some advantages of nftables.

Redhat Devs:

The newer iptables-nft command provides a bridge to the nftables kernel API and infrastructure.

As I noted earlier, the nftables utility improves the kernel API. The iptables-nft command allows iptables users to take advantage of the improvements. The iptables-nft command uses the newer nftables kernel API but reuses the legacy packet-matching code.

^ This behavior as well is not recommended, Better to just use the pure nftables.

According to Debian:

• Should I replace an iptables firewall with a nftables one?

YES

• Should I mix nftables and iptables/ebtables/arptables rulesets?

NO

• I knew the iptables syntax. Is there a new syntax in nftables?

Yes, but the nftables one is better :-)

Help in migrating to nftables: https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

[unman]

I cant see this (or your last comment) adds anything to the issue.

[marmarek]

Implementation hint: see ip*tables* files in https://github.com/QubesOS/qubes-core-agent-linux/blob/master/network/

[andrewdavidwong]

Reopening due to apparent regression reported in #8346.

[marmarek]

Fixed in QubesOS/qubes-core-agent-linux#440