Main differences with iptables: Difference between revisions

From nftables wiki
Jump to navigation Jump to search
(another dictionary -> vmap)
m (linked nft update page)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
The main differences between ''nftables'' and ''iptables'' from the user point of view are:
Some key 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''.  
* '''nftables uses a new 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 contrast, nftables uses a compact syntax 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.
* '''Tables and chains are fully configurable.''' ''iptables'' has multiple pre-defined tables and base chains, all of which are registered even if you only need one of them. There have been reports of even unused base chains harming performance. With nftables there are no pre-defined tables or chains. Each table is explicitly defined, and contains only the objects (chains, sets, maps, flowtables and stateful objects) that you explicitly add to it. Now you register only the base chains that you need. You choose table and chain names and netfilter hook priorities that efficiently implement your specific packet processing pipeline.


* '''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.
* '''A single nftables rule can take multiple actions.''' Instead of the matches and single target action used in iptables, an nftables rule consists of zero or more expressions followed by one or more statements. Each expression tests whether a packet matches a specific payload field or packet/flow metadata. Multiple expressions are linearly evaluated from left to right: if the first expression matches, then the next expression is evaluated and so on. If we reach the final expression, then the packet matches all of the expressions in the rule, and the rule's statements are executed. Each statement takes an action, such as setting the netfilter mark, counting the packet, logging the packet, or rendering a verdict such as accepting or dropping the packet or jumping to another chain. As with expressions, multiple statements are linearly evaluated from left to right: a single rule can take multiple actions by using multiple statements. Do note that a verdict statement by its nature ends the rule.


* '''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 rule.''' In nftables counters are optional, you can enable them as needed.


* '''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 contrast to the monolithic blob used by iptables, nftables rulesets are represented internally in a linked list. Now adding or deleting a rule leaves the rest of the ruleset untouched, simplifying maintenance of internal state information.


* '''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.''' The nftables ''inet'' family allows you to register base chains that see both IPv4 and IPv6 traffic. It is no longer necessary to rely on scripts to duplicate your ruleset.


* '''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.
* '''New generic [[sets|set]] infrastructure'''. This infrastructure integrates tightly into the nftables core and allows advanced configurations such as [[maps]], [[Verdict_Maps_(vmaps) | verdict maps]] and [[intervals]] to achieve performance-oriented packet classification. The most important thing is that you can use ''any'' supported selector to classify traffic.


* '''Generic [[sets|set]] and [[maps|map]] infrastructure'''. This new infrastructure integrates tightly into the nftables core and it allows advanced configurations such as [[maps]], [[Verdict_Maps_(vmaps) | verdict 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 [[maps]] and [[Verdict_Maps_(vmaps) | verdict maps]]. The idea is to build a tuple whose values are hashed to obtain the action to be performed nearly O(1).


* '''Support for [[concatenations]]'''. Since Linux kernel 4.1, you can concatenate several keys and combine them with [[maps]] and [[Verdict_Maps_(vmaps) | verdict maps]]. The idea is to build a tuple whose values are hashed to obtain the action to be performed nearly O(1).
* '''Support new protocols without a kernel upgrade'''. Kernel upgrades can be a time-consuming and daunting task, especially if you have to maintain more than a single firewall in your network. Distribution kernels usually lag the newest release. With the new nftables virtual machine approach, supporting a new protocol will often not require a new kernel, just a relatively simple [[List_of_updates_in_the_nft_command_line_tool|''nft'' userspace software update]].
 
* '''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.

Latest revision as of 11:51, 18 February 2021

Some key differences between nftables and iptables from the user point of view are:

  • nftables uses a new 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 contrast, nftables uses a compact syntax inspired by tcpdump.
  • Tables and chains are fully configurable. iptables has multiple pre-defined tables and base chains, all of which are registered even if you only need one of them. There have been reports of even unused base chains harming performance. With nftables there are no pre-defined tables or chains. Each table is explicitly defined, and contains only the objects (chains, sets, maps, flowtables and stateful objects) that you explicitly add to it. Now you register only the base chains that you need. You choose table and chain names and netfilter hook priorities that efficiently implement your specific packet processing pipeline.
  • A single nftables rule can take multiple actions. Instead of the matches and single target action used in iptables, an nftables rule consists of zero or more expressions followed by one or more statements. Each expression tests whether a packet matches a specific payload field or packet/flow metadata. Multiple expressions are linearly evaluated from left to right: if the first expression matches, then the next expression is evaluated and so on. If we reach the final expression, then the packet matches all of the expressions in the rule, and the rule's statements are executed. Each statement takes an action, such as setting the netfilter mark, counting the packet, logging the packet, or rendering a verdict such as accepting or dropping the packet or jumping to another chain. As with expressions, multiple statements are linearly evaluated from left to right: a single rule can take multiple actions by using multiple statements. Do note that a verdict statement by its nature ends the rule.
  • No built-in counter per chain and rule. In nftables counters are optional, you can enable them as needed.
  • Better support for dynamic ruleset updates. In contrast to the monolithic blob used by iptables, nftables rulesets are represented internally in a linked list. Now adding or deleting a rule leaves the rest of the ruleset untouched, simplifying maintenance of internal state information.
  • Simplified dual stack IPv4/IPv6 administration. The nftables inet family allows you to register base chains that see both IPv4 and IPv6 traffic. It is no longer necessary to rely on scripts to duplicate your ruleset.
  • New generic set infrastructure. This infrastructure integrates tightly into the nftables core and allows advanced configurations such as maps, verdict 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 maps and verdict maps. The idea is to build a tuple whose values are hashed to obtain the action to be performed nearly O(1).
  • Support new protocols without a kernel upgrade. Kernel upgrades can be a time-consuming and daunting task, especially if you have to maintain more than a single firewall in your network. Distribution kernels usually lag the newest release. With the new nftables virtual machine approach, supporting a new protocol will often not require a new kernel, just a relatively simple nft userspace software update.