Fedora 32 Looking At Switching Firewalld From Iptables To Nftables

[q2dg]

I don't get why somebody wants to change iptables or netfilter, by some crap..

Because nftables IS netfiler, ignorant

[starshipeleven]

I don't get why somebody wants to change iptables or netfilter, by some crap..

faster performance

[Weasel]

Thanks for re-jogging my memory, I remember reading that article when it came out. Any news in the subsequent 1½ years since it was written, except that bpfilter was apparently merged for 4.18?

Yeah I'm curious too.

[tildearrow]

Nice.

It is long overdue for nftables to get some wider adoption.

nft add comment inet mytable {
"I will never get used to nftables..."
}

[tildearrow]

faster performance

I thought these were shared? (e.g. adding a rule with iptables and deleting it with nft)

[chilinux]

I don't get why somebody wants to change iptables or netfilter, by some crap..

iptables is part of a suite of utilities that include iptables (for IPv4), arptables, ip6tables and ebtables

Both the syntax and the code used with this suite make strong assumptions about the protocols that will be used. You want to allow/deny IPv4 (Layer 3) for a specific TCP (Layer 4) port, then iptables has the syntax for that. If you want to block LLDP (Layer 2) packets then ebtables has the syntax to do that.

For over 90% of use cases, given the popularity of TCP/IP and UDP/IP, the suite that makes up iptables has worked out alright for now. Some side cases have been kind of address through iptable extension modules. Modern CPUs have kept up alright with 1gbps traffic. Things have been alright and most people's itch have been scratched.

But this suite is now two decades old and some of the assumptions don't scale well for the future.

What if you need a rule that applies only to VXLAN 5,001 (not VLAN but RFC 7348 VXLAN) for GRE tunneled IPv6 packets and block all packets with a source address of FD00::/8? The legacy filter system doesn't have a clean way to add this rule. This gets into concepts that pre-date assumptions about what protocols the filters would be used to act on. So, is it left to the user to write their own xtables kernel extension? Is it realistic that addressing side cases via code written by the user without being vetted by the standard kernel development process still provide an environment that continues to be just as stable and reliable? How will does doing things this way scale up to 10Gbps networking?

The "some crap" that "somebody" wants to change to from the legacy filter system is designed to more cleanly answer these questions. It provides a flexible method to remove all assumptions about the protocols and protocol layers that will be filter out of the kernel. Brand new protocols that don't exist today could be filtered under the new system just be providing a new user-space tool that uses the new filter model. That flexibility greatly changes what additional use cases Linux can be used for in the future.

It might be that the current user-space tools still have limitations but at least the inflexibility that puts limits on the usefulness and performance optimization is finally being move out of the kernel in the new model.

[chilinux]

I thought these were shared? (e.g. adding a rule with iptables and deleting it with nft)

If you run: iptables --version

Does it then spit out a line ending with "(legacy)" or ending with "(nf_tables)"?

If it says legacy then it is not shared. If it says nf_tables, then it is.

[tildearrow]

If you run: iptables --version

Does it then spit out a line ending with "(legacy)" or ending with "(nf_tables)"?

If it says legacy then it is not shared. If it says nf_tables, then it is.

Neither.

$ iptables --version
iptables v1.6.0

Will assume it's legacy though...

[chilinux]

Neither.

$ iptables --version
iptables v1.6.0

Will assume it's legacy though...

I don't think version 1.6.0 had any provisions to use nf_tables so legacy seems about right.

[S.Pam]

Iptables is usling same backend as nftables.

# iptables -version
iptables v1.8.3 (legacy)