Main differences with iptables: Difference between revisions
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: | ||
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 | * '''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 [[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. | ||
* ''' | * '''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 | * '''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]]. | ||
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.