Yes, one day, nftables may be a good idea. Also, one day, IPv6 support may not be avoided if it is so widespread that Whonix would stand out without having IPv6 support.

Whonix is still "essentially based on the https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy wiki page".

ipv6 / nftables is not something I am looking forward to. At the moment Whonix is well leak tested. There are leaks as obscure as the following one:
FIN ACK / RST ACK - Leak Test

And I wouldn't know who would have the skills and time to create an nftables based Whonix firewall that works at first as good as our current one.

So I propose to avoid nftables / IPv6 as long as sanely possible.

EDIT:
I would like to finish other work in preparation. Namely, packaging corridor and enabling testers to easily set up it as leak testing gateway in front of Whonix-Gateway. (corridor is now ready.)

Please note that Qubes 4.0 will use nftables (if available):
https://github.com/QubesOS/qubes-issues/issues/974#issuecomment-251825457

But it shouldn't be a problem to use iptables at the same time - thanks to compatibility layer. Using nftables in Qubes will allow to enable qubes-firewall in Whonix Gateway without breaking firewall installed by Whonix - at least in theory.

nftables transition info:

http://ral-arturo.org/2018/06/16/nfws2018.html

https://researchut.com/post/migrating-firewall-to-nftables/

Starting with Bullseye nftables will be the default:

https://ral-arturo.org/2019/10/14/debian-netfilter.html

NonaSuomy:

Added requested NFTables example from duclicsic #netfilter freenode.

• https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy?action=diff&version=130&old_version=129
• https://trac.torproject.org/projects/tor/ticket/21397#comment:7

Or skip nftables and use Berkeley Packet Filter (BPF)?

https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/

It looks like bpfilter is in rather early stages, and it's few years until we'll see it in Debian.

Any updates on this?

In T509#9147, @Patrick wrote:

And I wouldn't know who would have the skills and time to create an nftables based Whonix firewall that works at first as good as our current one.

I've actually been working with nftables and IPv6 quite a bit lately. Maybe I could offer some insight?

Nftables is essentially just an alternative syntax to iptables. It uses the same core engine (netfilter) under the hood, and has the same symantics as iptables. There are even automated tools for converting between the two.

For example, here's what the current Whonix Workstation firewall would look like (on my machine at least) in nftables:

table ip filter {
	chain INPUT {
		type filter hook input priority 0; policy drop;
		ct state invalid counter packets 0 bytes 0 drop
		ct state invalid counter packets 0 bytes 0 drop
		tcp flags & (fin | syn | rst | psh | ack | urg) == fin | syn | rst | ack counter packets 0 bytes 0 drop
		tcp flags & (fin | syn) == fin | syn counter packets 0 bytes 0 drop
		tcp flags & (syn | rst) == syn | rst counter packets 0 bytes 0 drop
		ip frag-off & 8191 != 0 counter packets 0 bytes 0 drop
		tcp flags & (fin | syn | rst | psh | ack | urg) == fin | syn | rst | psh | ack | urg counter packets 0 bytes 0 drop
		tcp flags & (fin | syn | rst | psh | ack | urg) == 0x0 counter packets 0 bytes 0 drop
		iifname "lo" counter packets 0 bytes 0 accept
		ct state established counter packets 0 bytes 0 accept
		ip protocol tcp counter packets 0 bytes 0 reject with tcp reset
		counter packets 0 bytes 0 reject
	}

	chain FORWARD {
		type filter hook forward priority 0; policy drop;
		counter packets 0 bytes 0 drop
	}

	chain OUTPUT {
		type filter hook output priority 0; policy drop;
		ct state invalid counter packets 0 bytes 0 reject with icmp type admin-prohibited
		ct state invalid counter packets 0 bytes 0 reject with icmp type admin-prohibited
		tcp flags & (fin | syn | rst | psh | ack | urg) == fin | syn | rst | ack counter packets 0 bytes 0 reject with icmp type admin-prohibited
		tcp flags & (fin | syn) == fin | syn counter packets 0 bytes 0 reject with icmp type admin-prohibited
		tcp flags & (syn | rst) == syn | rst counter packets 0 bytes 0 reject with icmp type admin-prohibited
		ip frag-off & 8191 != 0 counter packets 0 bytes 0 reject with icmp type admin-prohibited
		tcp flags & (fin | syn | rst | psh | ack | urg) == fin | syn | rst | psh | ack | urg counter packets 0 bytes 0 reject with icmp type admin-prohibited
		tcp flags & (fin | syn | rst | psh | ack | urg) == 0x0 counter packets 0 bytes 0 reject with icmp type admin-prohibited
		oifname "lo" counter packets 0 bytes 0 accept
		ip daddr 10.137.0.8 udp dport domain counter packets 0 bytes 0 accept
		ip daddr 10.152.152.10 udp dport domain counter packets 0 bytes 0 accept
		ip daddr 10.139.1.1 udp dport domain counter packets 0 bytes 0 accept
		ip daddr 10.139.1.2 udp dport domain counter packets 0 bytes 0 accept
		ip protocol != tcp counter packets 0 bytes 0 reject
		counter packets 0 bytes 0 accept
		counter packets 0 bytes 0 reject
	}
}

There's also iptables-nft, which converts iptables commands into nftables commands on the fly. In theory you could instantly convert a whole system just by symlinking it.

Is there something I'm missing here? The only catch I can think of is that nftables doesn't directly support ipset, which is used by corridor. We would have to patch corridor to use either ipset-translate or nftables native sets, or replace the ipset command with a shim. Still, it doesn't sound too difficult either way.

IPv6 is kind of a separate issue, is it not? I'm not sure what it has to do with migrating to nftables, other than that nftables supports unified rulesets for IPv4 and IPv6, and therefore it would be convenient to switch to nftables before adding IPv6 support. Don't get me wrong, I'd very much like to see IPv6 in Whonix at some point in the foreseeable future, whether it's with nftables or ip6tables. FWIW, at the moment Whonix is the main reason I haven't replaced my dual-stack setup with an IPv6+NAT64 setup. Nftables is not a requirement for IPv6 however.

In T509#20232, @ak88 wrote:

Any updates on this?

None.

In T509#9147, @Patrick wrote:

And I wouldn't know who would have the skills and time to create an nftables based Whonix firewall that works at first as good as our current one.

I've actually been working with nftables and IPv6 quite a bit lately. Maybe I could offer some insight?

Yes, please.

There's also iptables-nft, which converts iptables commands into nftables commands on the fly. In theory you could instantly convert a whole system just by symlinking it.

Well, in that case we could just replace calls to iptables to iptables-nft but that seems a bit pointless?

Current implementation:

• https://github.com/Whonix/whonix-firewall
• https://github.com/Whonix/whonix-firewall/blob/master/usr/bin/whonix_firewall
• https://github.com/Whonix/whonix-firewall/blob/master/usr/bin/whonix-gateway-firewall
• https://github.com/Whonix/whonix-firewall/blob/master/usr/bin/whonix-gateway-firewall

Nftables is essentially just an alternative syntax to iptables. It uses the same core engine (netfilter) under the hood, and has the same symantics as iptables. There are even automated tools for converting between the two.

From that perspective we could even stick with iptables for many years to come? No real need to move to nftables?

Advantages of Whonix keeping iptables:

• Years long tested in Whonix.
• More people supposedly know iptables.

Other advantages for/against iptables/nftables that would speak for making such a major change?

The only catch I can think of is that nftables doesn't directly support ipset, which is used by corridor. We would have to patch corridor to use either ipset-translate or nftables native sets, or replace the ipset command with a shim. Still, it doesn't sound too difficult either way.

Could you discuss this please with corridor?

IPv6 is kind of a separate issue, is it not?

Yes.