View source for Main differences with iptables

The main differences between ''nftables'' and ''iptables'' from the user point of view are:

* The '''syntax'''. The ''iptables'' command line tool uses a getopt_long()-based parser where keys are always preceded by double minus, eg. ''--key'' or one single minus, eg. ''-p tcp''. In that regard, ''nftables'' uses nicer, more intuitive and more compact syntax which is inspired by ''tcpdump''. 

* '''Tables and chains are fully configurable'''. In ''nftables'', tables are container of chains with no specific semantics. Note that ''iptables'' comes with tables with a predefined number of base chains, you get them in an all or nothing fashion. Thus, all chains are registered even if you only need one of them. We got reports in the past that unused base chains are harming performance, even if you add no rules at all. With this new approach, you can just register the chains that you need depending on your setup. Moreover, you can also model your pipeline using the chain priorities in the way you need and select any name for your tables and chains.

* '''No distinction between matches and targets anymore'''. In ''nftables'', the ''expressions'' are the basic building block of rule, thus, a rule is basically a composite of expressions that is linearly evaluated from left to right: if the first expression matches, then the next expression is evaluated and so on until we reach the last expression that is part of the rule. An expression can match some specific payload field, packet/flow metadata and any action.

* '''You can specify several actions in one single rule'''. In ''iptables'' you can only specify one single target. This has been a longstanding limitation that users resolve by jumping to custom chains at the cost of making the rule-set structure slightly more complex.

* '''No built-in counter per chain and rules'''. In ''nftables'', these are optional so you can enable counters on demand.

* '''Better support for dynamic ruleset updates'''. In ''nftables'', if you add a new rule, the remaining existing ones are left untouched since the ruleset is represented in a linked-list contrary to the monolithic blob representation in which the maintainance of the internal state information is complicated when performing ruleset updates.

* '''Simplified dual stack IPv4/IPv6 administration''', through the new ''inet'' family which allows you to register base chains that see both IPv4 and IPv6 traffic. Thus, you don't need to rely on scripts to duplicate your ruleset anymore.

* '''Generic [[sets|set]] and [[maps|map]] infrastructure'''. This new infrastructure integrates tightly into the nftables core and it allows advanced configurations such as [[dictionaries]], [[maps]] and [[intervals]] to achieve performance-oriented packet classification. The most important thing is that you can use ''any'' supported selector to classify traffic.

* '''Support for [[concatenations]]'''. Since Linux kernel 4.1, you can concatenate several keys and combine them with [[dictionaries]] and [[maps]]. The idea is to build a tuple whose values are hashed to obtain the action to be performed nearly O(1).

* '''New supported protocols without kernel upgrades'''. Kernel upgrades can be a timeconsuming and daunting task. Specifically if you have to maintain more than one single firewall in your network. Distributors usually include a bit older Linux kernel versions for stability reasons. With the new nftables virtual machine approach, you will most likely not need such upgrade to support a new protocol. A relatively simple ''nft'' userspace software update should be enough to support new protocols.