ID: 509PHID: PHID-TASK-bnqk6xb7z3slm7pi4eqnAuthor: HulaHoopStatus at Migration Time: openPriority at Migration Time: Normal
nftables is the biggest change in the linux firewalling system in more than a decade.
It promises simplified rulesets, unification of IPv4/IPv6 rules and superior performance to iptables. It also allows backward compatibility with iptables rules. There may be benefits to switching but also reasons for not: if it ain’t broke don’t fix it. Nonetheless its some food for thought.
Supported in recent kernels 3.13+ and packaged in Debian for Jessie and up.
http://wiki.nftables.org/wiki-nftables/index.php/Main_Page http://netfilter.org/projects/nftables/
Or Berkeley Packet Filter (BPF)?
IPv6 is coming in Tor:
TODO:
2016-07-20 12:47:50 UTC
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 TransparentProxy · Wiki · Legacy / Trac · GitLab 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 .)
2017-01-30 11:06:16 UTC
2018-06-20 13:03:45 UTC
2018-12-03 17:02:28 UTC
2019-10-17 17:29:16 UTC
2019-10-21 05:33:06 UTC
NonaSuomy:
Added requested NFTables example from duclicsic #netfilter freenode.
2019-12-11 01:10:33 UTC
2019-12-11 02:35:31 UTC
2021-08-09 17:22:53 UTC
Any updates on this?
! In T509#9147, @Patrick wrote:
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.
2021-08-09 19:13:31 UTC
! In T509#20232, @ak88 wrote:
None.
! In T509#9147, @Patrick wrote:
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:
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.
2023-05-09 10:23:50 UTC
2023-05-09 10:34:56 UTC
Dev/Firewall Refactoring - Kicksecure
ls -la /usr/sbin/iptabels
/usr/sbin/iptables → /etc/alternatives/iptables
ls -la /etc/alternatives/iptables
/etc/alternatives/iptables → /usr/sbin/iptables-nft
In other words, iptabels is already symlinked to iptabels-nft anyhow. Therefore Whonix is already using iptabels-nft.
2023-05-15 17:23:08 UTC
2023-05-15 18:21:27 UTC
2023-05-16 10:32:09 UTC
2023-11-26 06:28:40 UTC
This has been implemented.
committed 01:33PM - 28 May 24 UTC
https://forums.whonix.org/t/consider-nftables-berkeley-packet-filter-bpf-as-a-re… placement-for-iptables/18896
committed 06:32PM - 28 May 24 UTC
@Patrick can you change the tag from status_open_issue_todo to status_closed_issue_implemented ?
This is now in the testers repository.
IPv6 support has now a separate, dedicated ticket: add IPv6 support
committed 05:31PM - 01 Jun 24 UTC
https://forums.whonix.org/t/consider-nftables-berkeley-packet-filter-bpf-as-a-re… placement-for-iptables/18896
This is now in the testers repository.
committed 05:02PM - 02 Jun 24 UTC
- localize loop variables
- refactoring
This is now in the testers repository.
This is now in the stable-proposed-updates repository.