nftables wiki - User contributions [en]

Main Page

2024-10-12T13:47:11Z

Admin: very confusing presentation, remove it

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= [[News]] =

= Introduction =
* [[What is nftables?]]
* [[How to obtain help/support]]

= Reference =
* [https://www.netfilter.org/projects/nftables/manpage.html man nft - netfilter website]
* [https://www.mankier.com/8/nft man nft - mankier.com]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[Netfilter hooks]] and nftables integration with existing Netfilter components
* [[nftables families|Understanding nftables families]]
* [[Data_types|Data types]]
* [[Connection_Tracking_System|Connection tracking system (conntrack)]], used for stateful firewalling and NAT
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Further_documentation|Additional documentation]]

= Installing nftables =
* [[nftables from distributions|Using nftables from distributions]]
* [[Building and installing nftables from sources]]

= Upgrading from xtables to nftables =
* [[Legacy xtables tools]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]

= Basic operation =
* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Ruleset debug/VM code analysis]]
* [[Output text modifiers]]

= Expressions: Matching packets =
* [[Matching packet metainformation]]
* [[Matching packet headers]]
* [[Matching connection tracking stateful metainformation]]
* [[Matching routing information]]
* [[Rate limiting matchings]]

= Statements: Acting on packet matches =
* [[Accepting and dropping packets]]
* [[Rejecting traffic]]
* [[Jumping to chain]]
* [[Counters]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Setting packet connection tracking metainformation]]
* [[Mangling packet headers]] (including stateless NAT)
* [[Duplicating packets]]
* [[Load balancing]]
* [[Queueing to userspace]]

= Advanced data structures for performance packet classification =
* [[Intervals]]
* [[Concatenations]]
* [[Math operations]]
* [[Stateful objects]]
** [[Counters]]
** [[Quotas]]
** [[Limits]]
** [[Connlimits]] (''ct count'')
* Other objects
** [[Conntrack helpers]] (''ct helper'', Layer 7 ALG)
** [[Ct_timeout|Conntrack timeout policies]] (''ct timeout'')
** [[Ct_expectation|Conntrack expectations]] (''ct expectation'')
** [[Synproxy]]
** [[Secmark|Secmarks]]
* Generic set infrastructure
** [[Sets]]
** [[Element timeouts]]
** [[Updating sets from the packet path]]
** [[Maps]]
** [[Verdict_Maps_(vmaps) | Verdict maps]]
** [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1)
* [[Flowtables]] (the fastpath network stack bypass)

= Examples =
* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Simple ruleset for a home router]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter mini-workshop (2017)]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop (2018)]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop (2019)]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter mini-Workshop (2020)]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]
* Article [https://ral-arturo.org/2020/11/22/python-nftables-tutorial.html How to use nftables from python] and git repository [https://github.com/aborrero/python-nftables-tutorial python-nftables-tutorial.git]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:43:24Z

Admin: /* External links */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter mini-workshop (2017)]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop (2018)]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop (2019)]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter mini-Workshop (2020)]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:43:13Z

Admin: /* External links */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop (2017)]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop (2018)]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop (2019)]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter mini-Workshop (2020)]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:42:58Z

Admin: /* External links */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop (2018)]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop (2018)]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop (2019)]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter mini-Workshop (2020)]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:42:23Z

Admin: /* External links */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter Workshop]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:41:49Z

Admin: /* External links */ fix youtube link

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/watch?v=GqGGo4svj7s - Netdev 0x14 - Netfilter Workshop]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:41:25Z

Admin: /* External links */ fix missing ]

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://yewtu.be/watch?v=GqGGo4svj7s - Netdev 0x14 - Netfilter Workshop]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-11-18T12:40:51Z

Admin: place update videos

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop
* Watch [https://yewtu.be/watch?v=GqGGo4svj7s - Netdev 0x14 - Netfilter Workshop]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Ruleset debug/tracing

2020-11-04T01:06:22Z

Admin: /* Enabling nftrace */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' to enable tracing. If you already have a prerouting chain, then make sure your ''trace_chain'' priority comes ''before'' your existing prerouting chain.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -301\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This example assumes you have an existing raw prerouting chain (at priority -300), hence, this is registering a trace chain right before this chain (at priority -301).

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -1\; }
</source>

This registers the ''trace_chain'' before the existing ''input'' chain.

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Performing Network Address Translation (NAT)

2020-10-28T22:23:23Z

Admin: /* Redirect */

The ''nat'' chain type allows you to perform NAT. This chain type comes with special semantics:

* The first packet of a flow is used to look up for a matching rule which sets up the NAT binding for this flow. This also manipulates this first packet accordingly.
* No rule lookup happens for follow up packets in the flow: the NAT engine uses the NAT binding information already set up by the first packet to perform the packet manipulation.

Adding a NAT rule to a filter type chain will result in an error.

= Stateful NAT =

The stateful NAT involves the nf_conntrack kernel engine to match/set packet stateful information and will engage according to the state of connections.
This is the most common way of performing NAT and the approach we recommend you to follow.

Be aware that '''with kernel versions before 4.18, you have to register the prerouting/postrouting chains even if you have no rules there''' since these chain will invoke the NAT engine for the packets coming in the reply direction. The remaining documentation in this article assumes a newer kernel which doesn't require this inconvenience anymore.

== Source NAT ==

If you want to source NAT the traffic that leaves from your local area network to the Internet, you can create a new table ''nat'' with the postrouting chain:

<source lang="bash">
% nft add table nat
% nft 'add chain nat postrouting { type nat hook postrouting priority 100 ; }'
</source>

Then, add the following rule:

<source lang="bash">
% nft add rule nat postrouting ip saddr 192.168.1.0/24 oif eth0 snat 1.2.3.4
</source>

This matches for all traffic from the 192.168.1.0/24 network to the interface ''eth0''. The IPv4 address 1.2.3.4 is used as source for the packets that match this rule.

== Destination NAT ==

You need to add the following table and chain configuration:

<source lang="bash">
% nft add table nat
% nft 'add chain nat prerouting { type nat hook prerouting priority -100; }'
</source>

Then, you can add the following rule:

<source lang="bash">
% nft 'add rule nat prerouting iif eth0 tcp dport { 80, 443 } dnat 192.168.1.120'
</source>

This redirects the incoming traffic for TCP ports 80 and 443 to 192.168.1.120.

== Masquerading ==

NOTE: ''masquerade'' is available starting with Linux Kernel 3.18.

Masquerade is a special case of SNAT, where the source address is automagically set to the address of the output interface. For example:

<source lang="bash">
% nft add rule nat postrouting masquerade
</source>

Note that ''masquerade'' only makes sense from postrouting chain of NAT type.

== Redirect ==

NOTE: ''redirect'' is available starting with Linux Kernel 3.19.

By using redirect, packets will be forwarded to local machine. Is a special case of DNAT where the destination is the current machine.

<source lang="bash">
% nft add rule nat prerouting redirect
</source>

This example redirects 22/tcp traffic to 2222/tcp:

<source lang="bash">
% nft add rule nat prerouting tcp dport 22 redirect to 2222
</source>

This example redirects outgoing 53/tcp traffic to a local proxy listening on port 10053/tcp:

<source lang="bash">
% nft add rule nat output tcp dport 853 redirect to 10053
</source>

Note that: ''redirect'' only makes sense in prerouting and output chains of NAT type.

== NAT flags ==

Since Linux kernel 3.18, you can combine the following flags with your NAT statements:

* random: randomize source port mapping.
* fully-random: full port randomization.
* persistent: gives a client the same source-/destination-address for each connection.

For example:

<source lang="bash">
% nft add rule nat postrouting masquerade random,persistent
% nft add rule nat postrouting ip saddr 192.168.1.0/24 oif eth0 snat 1.2.3.4 fully-random
</source>

== Inet family NAT ==

Since Linux kernel 5.2, there is support for performing stateful NAT in ''inet'' family chains. Syntax and semantics are equivalent to ''ip''/''ip6'' families; the only exception being if IP addresses are specified, a prefix of either ''ip'' or ''ip6'' to clarify the address family is required:

<source lang="bash">
% nft add rule inet nat prerouting dnat ip to 10.0.0.2
% nft add rule inet nat prerouting dnat ip6 to feed::c0fe
</source>

== Incompatibilities ==

You cannot use iptables and nft to perform NAT at the same time before kernel 4.18. So make sure that the ''iptable_nat'' module is unloaded:

<source lang="bash">
% rmmod iptable_nat
</source>

With later kernels, it is possible to use iptables and nftables nat at the same time.
The nat chains are consulted according to their priorities, the first matching rule
that adds a nat mapping (dnat, snat, masquerade) is the one that will be used for the connection.

= Stateless NAT =

This type of NAT just modifies each packet according to your rules without any other state/connection tracking.

This is valid for 1:1 mappings and is faster than stateful NAT. However, it's easy to shoot yourself in the foot.
If your environment doesn't require this approach, better stick to stateful NAT.

You have to disable connection tracking for modified packets.

The example below sets IP/port for each packet (also valid in IPv6):

<source>
% nft add rule ip raw prerouting ip protocol tcp ip daddr set 192.168.1.100 tcp dport set 10 notrack
% nft add rule ip6 raw prerouting ip6 nexthdr tcp ip6 daddr set fe00::1 tcp dport set 10 notrack
</source>

Be sure to check our documentation regarding [[Mangle packet header fields | mangling packets]] and [[setting packet connection tracking metainformation]].

To use this feature you require nftables >=0.7 and linux kernel >= 4.9.

= See also =

* [[Multiple_NATs_using_nftables_maps | Example: multiple NATs using nftables maps]]

Ruleset debug/tracing

2020-10-28T22:16:05Z

Admin: /* Complete example */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' to enable tracing. If you already have a prerouting chain, then make sure your ''trace_chain'' priority comes ''before'' your existing prerouting chain.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -301\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This example assumes you have an existing raw prerouting chain (at priority -300), hence, this is registering a trace chain right before this chain (at priority -301).

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -1\; }
</source>

This registers the ''trace_chain'' before the existing ''input'' chain.

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T22:15:49Z

Admin: /* Complete example */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' to enable tracing. If you already have a prerouting chain, then make sure your ''trace_chain'' priority comes ''before'' your existing prerouting chain.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -301\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This example assumes you have an existing raw prerouting chain (at priority -300), hence, this is registering a trace chain right before this chain (at priority -301).

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -1\; }
</source>

This register the ''trace_chain'' before the existing ''input'' chain.

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T22:14:36Z

Admin: /* Use a chain to enable tracing */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' to enable tracing. If you already have a prerouting chain, then make sure your ''trace_chain'' priority comes ''before'' your existing prerouting chain.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -301\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This example assumes you have an existing raw prerouting chain (at priority -300), hence, this is registering a trace chain right before this chain (at priority -301).

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T22:14:00Z

Admin: /* Use a chain to enable tracing */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' to enable tracing. If you already have a prerouting chain, then make sure your ''trace_chain'' priority comes ''before'' your existing prerouting chain.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -301\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

Assuming you have an existing raw prerouting chain (at priority -300), you can register this trace chain right before this chain (at priority -301).

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T22:13:43Z

Admin: /* Use a chain to enable tracing */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to go is to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' to enable tracing. If you already have a prerouting chain, then make sure your ''trace_chain'' priority comes ''before'' your existing prerouting chain.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -301\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

Assuming you have an existing raw prerouting chain (at priority -300), you can register this trace chain right before this chain (at priority -301).

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:52:09Z

Admin: /* enabling nftrace */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= Enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to go is to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

Note that, if you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:51:34Z

Admin: /* Use a chain to enable tracing */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to go is to enable tracing is to add a chain for this purpose.

Register a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

Note that, if you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:51:10Z

Admin: /* Use a chain to enable tracing */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to go is to enable tracing is to add a chain.

For this purpose, register a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

Note that, if you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:46:48Z

Admin: /* enabling nftrace */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

= Use a chain to enable tracing =

The recommended way to go is to enable tracing on demand to debug your ruleset.

For this purpose, register a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing.

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

Note that, if you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:42:40Z

Admin: /* Complete example */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
</source>

Load this ruleset:

<source lang="bash">
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:41:57Z

Admin: /* Complete example */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
% cat ruleset.nft
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

The trace id uniquely identifies a packet. The trace describes the packet entering the chain initially.

<source lang="bash">
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:aa:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
</source>

Then, the packet travel through the ruleset.

Ruleset debug/tracing

2020-10-28T21:38:16Z

Admin: /* complete example */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= Complete example =

Here is complete example of this debug/tracing mechanism in work.

Assuming you have this ruleset:

<source lang="bash">
% cat ruleset.nft
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:dd:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:dd:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

Tracing two different kind of packets at the same monitor session:

<source lang="bash">
% nft filter input tcp dport 10000 nftrace set 1
% nft filter input icmp type echo-request nftrace set 1
% nft -nn monitor trace
trace id e1f5055f ip filter input packet: iif eth0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 ip saddr 192.168.122.1 ip daddr 192.168.122.83 ip tos 0 ip ttl 64 ip id 32315 ip length 84 icmp type echo-request icmp code 0 icmp id 10087 icmp sequence 1
trace id e1f5055f ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id e1f5055f ip filter input verdict continue
trace id e1f5055f ip filter input
trace id 74e47ad2 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 0 ip ttl 64 ip id 49030 ip length 84 icmp type echo-request icmp code 0 icmp id 10095 icmp sequence 1
trace id 74e47ad2 ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id 74e47ad2 ip filter input verdict continue
trace id 74e47ad2 ip filter input
trace id 3030de23 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 16 ip ttl 64 ip id 59062 ip length 60 tcp sport 55438 tcp dport 10000 tcp flags == syn tcp window 29200
trace id 3030de23 ip filter input rule tcp dport 10000 nftrace set 1 (verdict continue)
trace id 3030de23 ip filter input verdict continue
trace id 3030de23 ip filter input
</source>

Ruleset debug/tracing

2020-10-28T21:37:46Z

Admin: /* complete example */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= complete example =

Here are a couple of complete examples of this debug/tracing mechanism in work. Assuming you have this ruleset:

<source lang="bash">
% cat ruleset.nft
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 2 bytes 292 accept
ct state new tcp dport 22 counter packets 0 bytes 0 accept
}
}
% nft -f ruleset.nft
</source>

Then, add a chain that enables tracing:

<source lang="bash">
% nft add chain ip filter trace_chain { type filter hook prerouting priority -600\; }
</source>

And the rule to enable the tracing:

<source lang="bash">
% nft add rule ip filter trace_chain meta nftrace set 1
</source>

Simple tracing test, by pinging one host:

<source lang="bash">
% ping -c 1 8.8.8.8
</source>

You run on a different terminal:

<source lang="bash">
% nft monitor trace
trace id a95ea7ef ip filter trace_chain packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:dd:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter trace_chain rule meta nftrace set 1 (verdict continue)
trace id a95ea7ef ip filter trace_chain verdict continue
trace id a95ea7ef ip filter trace_chain policy accept
trace id a95ea7ef ip filter input packet: iif "enp0s25" ether saddr 00:0d:b9:4a:49:3d ether daddr 3c:97:0e:39:dd:20 ip saddr 8.8.8.8 ip daddr 192.168.2.118 ip dscp cs0 ip ecn not-ect ip ttl 115 ip id 0 ip length 84 icmp type echo-reply icmp code net-unreachable icmp id 9253 icmp sequence 1 @th,64,96 24106705117628271805883024640
trace id a95ea7ef ip filter input rule ct state established,related counter packets 168 bytes 53513 accept (verdict accept)
</source>

Tracing two different kind of packets at the same monitor session:

<source lang="bash">
% nft filter input tcp dport 10000 nftrace set 1
% nft filter input icmp type echo-request nftrace set 1
% nft -nn monitor trace
trace id e1f5055f ip filter input packet: iif eth0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 ip saddr 192.168.122.1 ip daddr 192.168.122.83 ip tos 0 ip ttl 64 ip id 32315 ip length 84 icmp type echo-request icmp code 0 icmp id 10087 icmp sequence 1
trace id e1f5055f ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id e1f5055f ip filter input verdict continue
trace id e1f5055f ip filter input
trace id 74e47ad2 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 0 ip ttl 64 ip id 49030 ip length 84 icmp type echo-request icmp code 0 icmp id 10095 icmp sequence 1
trace id 74e47ad2 ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id 74e47ad2 ip filter input verdict continue
trace id 74e47ad2 ip filter input
trace id 3030de23 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 16 ip ttl 64 ip id 59062 ip length 60 tcp sport 55438 tcp dport 10000 tcp flags == syn tcp window 29200
trace id 3030de23 ip filter input rule tcp dport 10000 nftrace set 1 (verdict continue)
trace id 3030de23 ip filter input verdict continue
trace id 3030de23 ip filter input
</source>

Ruleset debug/tracing

2020-10-28T21:27:24Z

Admin: /* enabling nftrace */ refine

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have a prerouting chain, then make sure the ''trace_chain'' priority comes ''before'' your existing prerouting chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= complete example =

Here are a couple of complete examples of this debug/tracing mechanism in work.

Simple tracing test:

<source lang="bash">
% nft add rule inet filter input iif lo counter nftrace set 1 accept
% nft monitor trace
trace id 530fa6dd inet filter input packet: iif lo
trace id 530fa6dd inet filter input rule iif lo accept (verdict accept)
trace id 87a375ea inet filter input packet: iif lo
trace id 87a375ea inet filter input rule iif lo accept (verdict accept)
</source>

Tracing two different kind of packets at the same monitor session:

<source lang="bash">
% nft filter input tcp dport 10000 nftrace set 1
% nft filter input icmp type echo-request nftrace set 1
% nft -nn monitor trace
trace id e1f5055f ip filter input packet: iif eth0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 ip saddr 192.168.122.1 ip daddr 192.168.122.83 ip tos 0 ip ttl 64 ip id 32315 ip length 84 icmp type echo-request icmp code 0 icmp id 10087 icmp sequence 1
trace id e1f5055f ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id e1f5055f ip filter input verdict continue
trace id e1f5055f ip filter input
trace id 74e47ad2 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 0 ip ttl 64 ip id 49030 ip length 84 icmp type echo-request icmp code 0 icmp id 10095 icmp sequence 1
trace id 74e47ad2 ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id 74e47ad2 ip filter input verdict continue
trace id 74e47ad2 ip filter input
trace id 3030de23 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 16 ip ttl 64 ip id 59062 ip length 60 tcp sport 55438 tcp dport 10000 tcp flags == syn tcp window 29200
trace id 3030de23 ip filter input rule tcp dport 10000 nftrace set 1 (verdict continue)
trace id 3030de23 ip filter input verdict continue
trace id 3030de23 ip filter input
</source>

Ruleset debug/tracing

2020-10-28T21:26:32Z

Admin: /* enabling nftrace */

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have more prerouting chains, then select a chain priority that comes ''before'' your existing prerouting chains.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= complete example =

Here are a couple of complete examples of this debug/tracing mechanism in work.

Simple tracing test:

<source lang="bash">
% nft add rule inet filter input iif lo counter nftrace set 1 accept
% nft monitor trace
trace id 530fa6dd inet filter input packet: iif lo
trace id 530fa6dd inet filter input rule iif lo accept (verdict accept)
trace id 87a375ea inet filter input packet: iif lo
trace id 87a375ea inet filter input rule iif lo accept (verdict accept)
</source>

Tracing two different kind of packets at the same monitor session:

<source lang="bash">
% nft filter input tcp dport 10000 nftrace set 1
% nft filter input icmp type echo-request nftrace set 1
% nft -nn monitor trace
trace id e1f5055f ip filter input packet: iif eth0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 ip saddr 192.168.122.1 ip daddr 192.168.122.83 ip tos 0 ip ttl 64 ip id 32315 ip length 84 icmp type echo-request icmp code 0 icmp id 10087 icmp sequence 1
trace id e1f5055f ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id e1f5055f ip filter input verdict continue
trace id e1f5055f ip filter input
trace id 74e47ad2 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 0 ip ttl 64 ip id 49030 ip length 84 icmp type echo-request icmp code 0 icmp id 10095 icmp sequence 1
trace id 74e47ad2 ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id 74e47ad2 ip filter input verdict continue
trace id 74e47ad2 ip filter input
trace id 3030de23 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 16 ip ttl 64 ip id 59062 ip length 60 tcp sport 55438 tcp dport 10000 tcp flags == syn tcp window 29200
trace id 3030de23 ip filter input rule tcp dport 10000 nftrace set 1 (verdict continue)
trace id 3030de23 ip filter input verdict continue
trace id 3030de23 ip filter input
</source>

Ruleset debug/tracing

2020-10-28T21:25:43Z

Admin: /* enabling nftrace */ extend tracing info

Since nftables v0.6 and linux kernel 4.6, ruleset debug/tracing is supported.

This is an equivalent of the old iptables method -J TRACE, but with some great improvements.

The steps to enable debug/tracing is the following:
* give support in your ruleset for it (set nftrace in any of your rules)
* monitor the trace events from the nft tool

= enabling nftrace =

To enable nftrace in a packet, use a rule with this statement:
<source lang="bash">
meta nftrace set 1
</source>

After all, nftrace is part of the [[Setting packet metainformation|metainformation]] of a packet.

Of course, you may only enable nftrace for a given matching packet.
In the example below, we only enable nftrace for tcp packets using the loopback interface:

<source lang="bash">
iif lo ip protocol tcp meta nftrace set 1
</source>

Adjusting nftrace to only your subset of desired packets is key to properly debug the ruleset, otherwise you may get a lot of debug/tracing information which may be overwhelming.

The following example shows how to enable tracing for your existing ruleset:

<source lang="bash">
% nft add chain filter trace_chain { type filter hook prerouting priority -600\; }
% nft add rule filter trace_chain meta nftrace set 1
</source>

This is registering a ''trace_chain'' chain at priority -600 which contains a rule to enable tracing. If you already have more prerouting chains, then select a chain priority that comes before your existing chain.

Once you are done with rule tracing, you can just delete this chain to disable it:

<source lang="bash">
% nft delete chain filter trace_chain
</source>

= monitoring tracing events =

In nftables, getting the debug/tracing events is a bit different from the iptables world.
Now, we have an event-based monitor for the kernel to notify the nft tool.

The basic syntax is:

<source lang="bash">
% nft monitor trace
</source>

Each trace event is assigned an 'id' for you to easily follow different packets in the same trace session.

= complete example =

Here are a couple of complete examples of this debug/tracing mechanism in work.

Simple tracing test:

<source lang="bash">
% nft add rule inet filter input iif lo counter nftrace set 1 accept
% nft monitor trace
trace id 530fa6dd inet filter input packet: iif lo
trace id 530fa6dd inet filter input rule iif lo accept (verdict accept)
trace id 87a375ea inet filter input packet: iif lo
trace id 87a375ea inet filter input rule iif lo accept (verdict accept)
</source>

Tracing two different kind of packets at the same monitor session:

<source lang="bash">
% nft filter input tcp dport 10000 nftrace set 1
% nft filter input icmp type echo-request nftrace set 1
% nft -nn monitor trace
trace id e1f5055f ip filter input packet: iif eth0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 ip saddr 192.168.122.1 ip daddr 192.168.122.83 ip tos 0 ip ttl 64 ip id 32315 ip length 84 icmp type echo-request icmp code 0 icmp id 10087 icmp sequence 1
trace id e1f5055f ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id e1f5055f ip filter input verdict continue
trace id e1f5055f ip filter input
trace id 74e47ad2 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 0 ip ttl 64 ip id 49030 ip length 84 icmp type echo-request icmp code 0 icmp id 10095 icmp sequence 1
trace id 74e47ad2 ip filter input rule icmp type echo-request nftrace set 1 (verdict continue)
trace id 74e47ad2 ip filter input verdict continue
trace id 74e47ad2 ip filter input
trace id 3030de23 ip filter input packet: iif vlan0 ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 1 vlan id 1000 ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 16 ip ttl 64 ip id 59062 ip length 60 tcp sport 55438 tcp dport 10000 tcp flags == syn tcp window 29200
trace id 3030de23 ip filter input rule tcp dport 10000 nftrace set 1 (verdict continue)
trace id 3030de23 ip filter input verdict continue
trace id 3030de23 ip filter input
</source>

Main Page

2020-10-28T21:13:19Z

Admin: /* Possible actions on packets */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-10-28T21:11:45Z

Admin: /* Possible actions on packets */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]
* [[Tracing rule evaluation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Setting packet connection tracking metainformation

2020-10-20T10:41:11Z

Admin: /* helpers */

You can set some bits of the packet conntrack metainformation, apart of [[Matching connection tracking stateful metainformation | matching on it]].

== notrack ==

You can use the '''notrack''' support to explicitly skip connection tracking for matching packets.

The example below skips traffic for 80/tcp and 443/tcp:

<source lang="bash">
nft add rule ip raw prerouting tcp dport { 80, 443 } notrack
</source>

Please, note that you should use notrack before the kernel connection tracking is triggered.
Use a chain with priority -300. Example:

<source lang="bash">
nft add table raw
nft add chain raw prerouting { type filter hook prerouting priority -300 \; }
nft add rule raw prerouting tcp dport 80 notrack
</source>

Support for this was added in linux kernel 4.9 and in nftables v0.7.

== helpers ==

You can assign each packet a conntrack helper.

Instantiate a helper, using a named object:

<source>
table filter {
ct helper sip-5060 {
type "sip" protocol udp;
}

ct helper tftp-69 {
type "tftp" protocol udp;
}

ct helper ftp-standard {
type "ftp" protocol tcp;
}

chain c {
type filter hook prerouting priority 0;
}
}
</source>

Your chain priority must be > -200, because conntrack registers at this priority.
Otherwise, packets will not find any conntrack information (which is required
to attach the helper).

Then, from the rules:

<source>
nft add rule filter c ct state new tcp dport 21 ct helper set "ftp-standard"
nft add rule filter c ct state new udp dport 5060 ct helper set "sip-5060"
nft add rule filter c ct state new udp dport 69 ct helper set "tftp-69"
</source>

You can of course use a dictionary, one single rule to assign many helpers:

<source>
nft add rule filter c ct state new ct helper set ip protocol . th dport map { \
udp . 69 : "tftp-69", \
udp . 5060 : "sip-5060", \
tcp . 21 : "ftp-standard" }
</source>

which sets the helper based in the transport protocol number and the transport destination port.

You need nftables >= 0.8 and the kernel >= 4.12 to use this feature.

In case of a previous version of nftables, you can enable automatic assignment with:

<source>
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
</source>

Also, with the sysctl parameter:

<source>
net.netfilter.nf_conntrack_helper = 1
</source>

Setting packet connection tracking metainformation

2020-10-20T10:40:21Z

Admin: /* helpers */ update

You can set some bits of the packet conntrack metainformation, apart of [[Matching connection tracking stateful metainformation | matching on it]].

== notrack ==

You can use the '''notrack''' support to explicitly skip connection tracking for matching packets.

The example below skips traffic for 80/tcp and 443/tcp:

<source lang="bash">
nft add rule ip raw prerouting tcp dport { 80, 443 } notrack
</source>

Please, note that you should use notrack before the kernel connection tracking is triggered.
Use a chain with priority -300. Example:

<source lang="bash">
nft add table raw
nft add chain raw prerouting { type filter hook prerouting priority -300 \; }
nft add rule raw prerouting tcp dport 80 notrack
</source>

Support for this was added in linux kernel 4.9 and in nftables v0.7.

== helpers ==

You can assign each packet a conntrack helper.

Instantiate a helper, using a named object:

<source>
table filter {
ct helper sip-5060 {
type "sip" protocol udp;
}

ct helper tftp-69 {
type "tftp" protocol udp;
}

ct helper ftp-standard {
type "ftp" protocol tcp;
}

chain c {
type filter hook prerouting priority 0;
}
}
</source>

Your chain priority must be > -200, because conntrack registers at this priority.
Otherwise, packets will not have any conntrack information (which is a requirement
to

Then, from the rules:

<source>
nft add rule filter c ct state new tcp dport 21 ct helper set "ftp-standard"
nft add rule filter c ct state new udp dport 5060 ct helper set "sip-5060"
nft add rule filter c ct state new udp dport 69 ct helper set "tftp-69"
</source>

You can of course use a dictionary, one single rule to assign many helpers:

<source>
nft add rule filter c ct state new ct helper set ip protocol . th dport map { \
udp . 69 : "tftp-69", \
udp . 5060 : "sip-5060", \
tcp . 21 : "ftp-standard" }
</source>

which sets the helper based in the transport protocol number and the transport destination port.

You need nftables >= 0.8 and the kernel >= 4.12 to use this feature.

In case of a previous version of nftables, you can enable automatic assignment with:

<source>
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
</source>

Also, with the sysctl parameter:

<source>
net.netfilter.nf_conntrack_helper = 1
</source>

Setting packet connection tracking metainformation

2020-10-20T10:30:33Z

Admin: /* helpers */ restrict it to ct state new

You can set some bits of the packet conntrack metainformation, apart of [[Matching connection tracking stateful metainformation | matching on it]].

== notrack ==

You can use the '''notrack''' support to explicitly skip connection tracking for matching packets.

The example below skips traffic for 80/tcp and 443/tcp:

<source lang="bash">
nft add rule ip raw prerouting tcp dport { 80, 443 } notrack
</source>

Please, note that you should use notrack before the kernel connection tracking is triggered.
Use a chain with priority -300. Example:

<source lang="bash">
nft add table raw
nft add chain raw prerouting { type filter hook prerouting priority -300 \; }
nft add rule raw prerouting tcp dport 80 notrack
</source>

Support for this was added in linux kernel 4.9 and in nftables v0.7.

== helpers ==

You can assign each packet a conntrack helper.

Instantiate a helper, using a named object:

<source>
table filter {
ct helper sip-5060 {
type "sip" protocol udp;
}

ct helper tftp-69 {
type "tftp" protocol udp;
}

ct helper ftp-standard {
type "ftp" protocol tcp;
}

chain c {
type filter hook prerouting priority 0;
}
}
</source>

Then, from the rules:

<source>
nft add rule filter c ct state new tcp dport 21 ct helper set "ftp-standard"
nft add rule filter c ct state new udp dport 5060 ct helper set "sip-5060"
nft add rule filter c ct state new udp dport 69 ct helper set "tftp-69"
</source>

You can of course use a dictionary, one single rule to assign many helpers:

<source>
nft add rule filter c ct state new ct helper set ip protocol . th dport map { \
udp . 69 : "tftp-69", \
udp . 5060 : "sip-5060", \
tcp . 21 : "ftp-standard" }
</source>

which sets the helper based in the transport protocol number and the transport destination port.

You need nftables >= 0.8 and the kernel >= 4.12 to use this feature.

In case of a previous version of nftables, you can enable automatic assignment with:

<source>
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
</source>

Also, with the sysctl parameter:

<source>
net.netfilter.nf_conntrack_helper = 1
</source>

Setting packet connection tracking metainformation

2020-10-20T10:25:10Z

Admin: /* helpers */ update

You can set some bits of the packet conntrack metainformation, apart of [[Matching connection tracking stateful metainformation | matching on it]].

== notrack ==

You can use the '''notrack''' support to explicitly skip connection tracking for matching packets.

The example below skips traffic for 80/tcp and 443/tcp:

<source lang="bash">
nft add rule ip raw prerouting tcp dport { 80, 443 } notrack
</source>

Please, note that you should use notrack before the kernel connection tracking is triggered.
Use a chain with priority -300. Example:

<source lang="bash">
nft add table raw
nft add chain raw prerouting { type filter hook prerouting priority -300 \; }
nft add rule raw prerouting tcp dport 80 notrack
</source>

Support for this was added in linux kernel 4.9 and in nftables v0.7.

== helpers ==

You can assign each packet a conntrack helper.

Instantiate a helper, using a named object:

<source>
table filter {
ct helper sip-5060 {
type "sip" protocol udp;
}

ct helper tftp-69 {
type "tftp" protocol udp;
}

ct helper ftp-standard {
type "ftp" protocol tcp;
}

chain c {
type filter hook prerouting priority 0;
}
}
</source>

Then, from the rules:

<source>
nft add rule filter c tcp dport 21 ct helper set "ftp-standard"
nft add rule filter c udp dport 5060 ct helper set "sip-5060"
nft add rule filter c udp dport 69 ct helper set "tftp-69"
</source>

You can of course use a dictionary, one single rule to assign many helpers:

<source>
nft add rule filter c ct helper set ip protocol . th dport map { \
udp . 69 : "tftp-69", \
udp . 5060 : "sip-5060", \
tcp . 21 : "ftp-standard" }
</source>

which sets the helper based in the transport protocol number and the transport destination port.

You need nftables >= 0.8 and the kernel >= 4.12 to use this feature.

In case of a previous version of nftables, you can enable automatic assignment with:

<source>
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
</source>

Also, with the sysctl parameter:

<source>
net.netfilter.nf_conntrack_helper = 1
</source>

Main Page

2020-10-20T10:17:00Z

Admin: /* Possible actions on packets */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2020-10-20T10:16:40Z

Admin: /* Possible actions on packets */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]
* [[Output text modifiers]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]
* [[Attaching connection tracking helpers]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Meters

2020-09-28T16:39:19Z

Admin: /* Listing meters */ fix listing of set

== Meters ==

'''Dynamic sets/maps''' or meters are a way to use maps with stateful objects. They used to be known as ''flow tables'' before nft v0.8.1 and Linux kernel 4.3.

Among other things, they provide a native replacement for the ''hashlimit'' match in iptables. However, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

'''Note that the ''meter'' keyword is obsolete, the dynamic set and map syntax is now preferred for consistency.'''

== Using meters ==

The following commands create a table named ''my_filter_table'', a chain named ''my_input_chain'' which hooks incoming traffic and a rule that uses a meter:

<source lang="bash">
% nft add table my_filter_table
% nft add chain my_filter_table my_input_chain {type filter hook input priority 0\;}
% nft add set my_filter_table my_ssh_meter { type ipv4_addr\; flags dynamic \;}
% nft add rule my_filter_table my_input_chain tcp dport 22 ct state new add @my_ssh_meter { ip saddr limit rate 10/second } accept
</source>

In this example we create a rule to match ''new'' TCP ''ssh'' (port 22) connections, which uses a dynamic set named ''my_ssh_meter'' to limit the traffic rate to 10 connections per second for each source IP address. The available time units on limits are: ''second'', ''minute'', ''hour'', ''day'' and ''week''.

You can also use [[concatenations]] to build selectors:

<source lang="bash">
% nft add set my_filter_table my_ssh_meter { type ipv4_addr . inet_service\; flags timeout, dynamic \;}
% nft add rule my_filter_table my_input_chain tcp dport 22 ct state new add @my_ssh_meter { ip saddr . tcp dport timeout 60s limit rate 10/second } accept
</source>

This rule counts incoming connections (packets with state ''new'') based on the tuple ''(IP source address, TCP destination port)'', the counters are dropped after 60 seconds without update.

== Listing meters ==

To list the content matched by the meter use:

<source lang="bash">
% nft list set my_filter_table my_ssh_meter
table ip my_filter_table {
set my_ssh_meter {
type ipv4_addr
size 65535
flags dynamic
elements = { 10.141.10.2 limit rate 10/second }
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, there is a new ''ct count'' selector that allows you to count the number of existing connections. This extension uses the information available in the Connection Tracking System table, therefore, the counting of connection is based on the existing entries in the table.

The following example shows how to do ''connlimit'' from nftables:

table ip my_filter_table {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain my_output_chain {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
}
}

The example above dynamically populates the set ''connlimit'' from the packet path. For the first packet of each connection (ie. packets matching ''ct state new''), this adds an entry into ''connlimit'' set, this entry uses the IPv4 destination address as a key. If the number of connections goes over 20, then packets are dropped.

Since ''connlimit'' is a set, you can perform any operation on it, such as listing and flushing its content.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Simple rule management

2020-09-25T07:56:40Z

Admin: /* Removing all the rules in a chain */

= Appending new rules =

To add new rules, you have to specify the corresponding table and the chain that you want to use, eg.

<source lang="bash">
% nft add rule filter output ip daddr 8.8.8.8 counter
</source>

Where ''filter'' is the table and ''output'' is the chain. The example above adds a rule to match all packets seen by the output chain whose destination is 8.8.8.8, in case of matching it updates the rule counters. Note that counters are optional in ''nftables''.

For those familiar with iptables, the rule appending is equivalent to ''-A'' command in iptables.

= Listing rules =

You can list the rules that are contained by a table with the following command:

<source lang="bash">
% nft list table filter
table ip filter {
chain input {
type filter hook input priority 0;
}

chain output {
type filter hook output priority 0;
ip daddr 8.8.8.8 counter packets 0 bytes 0
tcp dport ssh counter packets 0 bytes 0
}
}
</source>

You can also list rules by chain, for example:

<source lang="bash">
% nft list chain filter ouput
table ip filter {
chain output {
type filter hook output priority 0;
ip daddr 8.8.8.8 counter packets 0 bytes 0
tcp dport ssh counter packets 0 bytes 0
}
}
</source>

There are plenty of [[Output_text_modifiers | output text modifiers]] than can be used when listing your rules, to for example, translate IP addresses to DNS names, TCP protocols, etc.

= Testing your rule =

Let's test this rule with a simple ping to 8.8.8.8:

<source lang="bash">
% ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=64 time=1.31 ms
</source>

Then, if we list the rule-set, we obtain:

<source lang="bash">
% nft -nn list table filter
table ip filter {
chain input {
type filter hook input priority 0;
}

chain output {
type filter hook output priority 0;
ip daddr 8.8.8.8 counter packets 1 bytes 84
tcp dport 22 counter packets 0 bytes 0
}
}
</source>

Note that the counters have been updated.

= Adding a rule at a given position =

If you want to add a rule at a given position, you have to use the handle as reference:

<source lang="bash">
% nft list table filter -n -a
table filter {
chain output {
type filter hook output priority 0;
ip protocol tcp counter packets 82 bytes 9680 # handle 8
ip saddr 127.0.0.1 ip daddr 127.0.0.6 drop # handle 7
}
}
</source>

If you want to add a rule after the rule with handler number 8, you have to type:

<source lang="bash">
% nft add rule filter output position 8 ip daddr 127.0.0.8 drop
</source>

Now, you can check the effect of that command by listing the rule-set:

<source lang="bash">
% nft list table filter -n -a
table filter {
chain output {
type filter hook output priority 0;
ip protocol tcp counter packets 190 bytes 21908 # handle 8
ip daddr 127.0.0.8 drop # handle 10
ip saddr 127.0.0.1 ip daddr 127.0.0.6 drop # handle 7
}
}
</source>

If you want to insert a rule before the rule with handler number 8, you have to type:

<source lang="bash">
% nft insert rule filter output position 8 ip daddr 127.0.0.8 drop
</source>

= Removing rules =

You have to obtain the ''handle'' to delete a rule via the '''-a''' option. The ''handle'' is automagically assigned by the kernel and it uniquely identifies the rule.

<source lang="bash">
% nft list table filter -a
table ip filter {
chain input {
type filter hook input priority 0;
}

chain output {
type filter hook output priority 0;
ip daddr 192.168.1.1 counter packets 1 bytes 84 # handle 5
}
}
</source>

You can delete the rule whose handle is ''5'' with the following command:

<source lang="bash">
% nft delete rule filter output handle 5
</source>

'''Note''': There are plans to support rule deletion by passing:
<source lang="bash">
% nft delete rule filter output ip saddr 192.168.1.1 counter
</source>

but this is '''not''' yet implemented. So you'll have to use the handle to delete rules until that feature is implemented.

= Removing all the rules in a chain =

You can delete '''all the rules''' in a chain with the following command:

<source lang="bash">
% nft flush rule filter output
</source>

You can also delete '''all the rules''' in a table with the following command:

<source lang="bash">
% nft flush table filter
</source>

= Prepending new rules =

To prepend new rules through the ''insert'' command:

<source lang="bash">
% nft insert rule filter output ip daddr 192.168.1.1 counter
</source>

This prepends a rule that will update per-rule packet and bytes counters for traffic addressed to 192.168.1.1.

The equivalent in iptables is:

<source lang="bash">
% iptables -I OUTPUT -t filter -d 192.168.1.1
</source>

Note that iptables always provides per-rule counters.

= Replacing rules =

You can replace any rule via the ''replace'' command by indicating the rule handle. Therefore, first you have to list the ruleset with option ''-a'' to obtain the rule handle.

<source lang="bash">
# nft list ruleset -a
table ip filter {
chain input {
type filter hook input priority 0; policy accept;
ip protocol tcp counter packets 0 bytes 0 # handle 2
}
}
</source>

Then, assuming you want to replace rule with handle number 2, you have to specify this handle number and the new rule that you want to place instead of it:

<source lang="bash">
nft replace rule filter input handle 2 counter
</source>

Then, when listing back the ruleset:

<source lang="bash">
# nft list ruleset -a
table ip filter {
chain input {
counter packets 0 bytes 0
}
}
</source>

You can effective note that the rule has been replaced by a simple rule that counts any packets, instead of counting TCP packets as the previous rule was doing.

List of updates in the nft command line tool

2020-06-24T11:13:34Z

Admin:

This page contains links to the release announcements:

* [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6 release]
* [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5 release] (This release broke '''vmap''' support, this is fixed in 0.9.6)
* [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4 release]
* [https://marc.info/?l=netfilter&m=157532146917292&w=2 nftables 0.9.3 release]

The cover letter usually includes a description of the updates and examples to follow track of the updates in the userspace command line tool.

List of updates in the nft command line tool

2020-06-24T11:12:06Z

Admin:

This page contains links to the release announcements:

* [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6 release]
* [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5 release] (This release broke '''vmap''' support, this is fixed in 0.9.6)
* [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4 release]

The cover letter usually includes a description of the updates and examples to follow track of the updates in the userspace command line tool.

List of updates in the nft command line tool

2020-06-24T11:10:59Z

Admin:

This page contains links to the release announcements:

* [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6 release]
* [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4 release]

The cover letter usually includes a description of the updates and examples to follow track of the updates in the userspace command line tool.

List of updates in the nft command line tool

2020-06-24T11:10:10Z

Admin:

This page contains links to the release announcements:

* [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6 release]
* [https://marc.info/?l=netfilter&m=158583434604821&w=2 nftables 0.9.4 release]

The cover letter usually includes a description of the updates and examples to follow track of the updates in the userspace command line tool.

List of updates in the nft command line tool

2020-06-24T11:10:02Z

Admin:

This page contains links to the release announcements:

* [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6 release]
* [https://marc.info/?l=netfilter&m=158583434604821&w=2 nftables 0.9.5 release]

The cover letter usually includes a description of the updates and examples to follow track of the updates in the userspace command line tool.

List of updates in the nft command line tool

2020-06-24T11:09:12Z

Admin: initial page, link to 0.9.6

This page contains links to the release announcements:

* [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6 release]

The cover letter usually includes a description of the updates and examples to follow track of the updates in the userspace command line tool.

Main Page

2020-06-24T11:06:46Z

Admin: /* Development */

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= Introduction =

* [[What is nftables?]]
* [[Why nftables?]]
* [[Main differences with iptables]]
* [[Netfilter hooks]] and integration with existing Netfilter components.
* [[Adoption]]
* [[Legacy xtables tools]]
* [[How to obtain help/support]]

= Getting started =

* [[Building and installing nftables from sources]]
* Using [[nftables from distributions]]
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[nftables families|Understanding nftables families]]

= Basic operation =

* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]

= Supported selectors for packet matching =

* [[Matching packet header fields]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Rate limiting matchings]]
* [[Routing information]]

= Possible actions on packets =

* [[Accepting and dropping packets]]
* [[Jumping to chain]]
* [[Rejecting traffic]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Queueing to userspace]]
* [[Duplicating packets]]
* [[Mangle packet header fields]]
* [[Mangle TCP options]]
* [[Counters]]
* [[Load balancing]]
* [[Setting packet connection tracking metainformation]]

Note that, unlike ''iptables'', you can perform several actions in one single rule.

= Advanced data structures for performance packet classification =

You will have to redesign your rule-set to benefit from these new nice features:

* [[Sets]]
* [[Dictionaries]]
* [[Intervals]]
* [[Maps]]
* [[Concatenations]]
* [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1 release)
* [[Updating sets from the packet path]]
* [[Element timeouts]]
* [[Math operations]]
* [[Stateful objects]]
* [[Flowtable]] (the fastpath network stack bypass)

If you are already using [[ipset]] in your ''iptables'' rule-set, that transition may be a bit more simple to you.

= Examples =

* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter workshop]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Building and installing nftables from sources

2020-03-26T10:06:54Z

Admin: /* Installing userspace libraries */

nftables requires several userspace libraries, the 'nft' userspace command line utility and the kernel modules.

If you are using a major linux distribution, you may consider using [[nftables from distributions]].

= Installing userspace libraries =

You have to install the following userspace libraries:

* [http://www.netfilter.org/projects/libmnl libmnl ], this library provides the interfaces to communicate kernel and userspace via Netlink. ''It is very likely that your distribution already provides a package for libmnl that you can use''. If you decide to use your distributor package, make sure you install the development package as well.

* [http://www.netfilter.org/projects/libnftnl libnftnl], this library provides the low-level API to transform netlink messages to objects.

You also need ''libgmp'' and ''libreadline'', most distributions already provide packages for these two libraries, so make sure you install the development extensions of this packages to successfully compile ''nftables''.

If you plan to give a test to ''nftables'', we recommend you to use git snapshots for ''libnftnl'' and ''nft''.

== Installing userspace libraries from git ==

To install ''libnftnl'', to can type these magic spells:

<source lang="bash">
$ git clone git://git.netfilter.org/libnftnl
$ cd libnftnl
$ sh autogen.sh
$ ./configure
$ make
$ sudo make install
</source>
If you are working behind proxy than it might possible that you are not able to clone using git protocol so try to clone using "http/https:" instead "git:"
<br > Reasons:- 1) The git protocol, by default, uses the port 9418. It might possible that your traffic is blocked on that port.
<br > 2) Also take help and can relate from the [http://stackoverflow.com/a/28494985 solution]

If you have any compilation problem, please report them to the [https://www.netfilter.org/mailinglists.html netfilter developer mailing list] providing as much detailed information as possible.

== Installing userspace libraries from snapshots ==

You can retrieve daily snapshots of this library from the [ftp://ftp.netfilter.org/pub/libnftnl/snapshot/ Netfilter FTP]. Then, to install it you have to:

<source lang="bash">
$ wget ftp://ftp.netfilter.org/pub/libnftnl/snapshot/libnftnl-20140217.tar.bz2
$ tar xvjf libnftnl-20140217.tar.bz2
$ ./configure
$ make
$ sudo make install
</source>

= Installing userspace nft command line utility =

This is the command line utility that provides a user interface to configure ''nftables''.

== Installing from git ==

Just type these commands:

<source lang="bash">
% git clone git://git.netfilter.org/nftables
% cd nftables
% sh autogen.sh
% ./configure
% make
% make install
</source>

You should check that ''nft'' is installed in your system by typing:

<source lang="bash">
% nft
nft: no command specified
</source>

That means ''nft'' has been correctly installed.

= Installing Linux kernel with nftables support =

Prerequisites: nftables is available in Linux kernels since version 3.13 but this is software under development, so we encourage you to run the latest stable kernel.

== Validating your installation ==

You can validate that your installation is working by checking if you can install the 'nf_tables' kernel module.

<source lang="bash">
% modprobe nf_tables
</source>

Then, you can check that's actually there via ''lsmod'':

<source lang="bash">
# lsmod | grep nf_tables
nf_tables 42349 0
</source>

dmesg should show the following message:

<source lang="bash">
% dmesg
...
[13939.468020] nf_tables: (c) 2007-2009 Patrick McHardy <kaber@trash.net>
</source>

Make sure you also have loaded the family support, eg.

<source lang="bash">
% modprobe nf_tables_ipv4
</source>

The ''lsmod'' command should show something like:

<source lang="bash">
# lsmod | grep nf_tables
nf_tables_ipv4 12869 0
nf_tables 42349 1 nf_tables_ipv4
</source>

Other family modules are ''nf_tables_ipv6'', ''nf_tables_bridge'', ''nf_tables_arp'' and (since Linux kernel >= 3.14) ''nf_tables_inet''.

These modules provide the corresponding [[Configuring_tables|table]] and the filter [[Configuring_chains|chain]] support for the given family.

You could also check which modules are supported by your current kernel. How to to do this, depends on your distro:
* on debian, look in /boot/config-XXX-YYY, where XXX is your kernel package version, and YYY is your arch, e.g. /boot/config-4.2.0-1-amd64
* on Arch, look in /proc/config.gz. As this is compressed, use a command such as zcat or zgrep.

In the debian example below, CONFIG_NFT_REDIR_IPV4 and CONFIG_NFT_REDIR_IPV6 are not set, so you can't use [http://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Redirect redirect] in the ruleset:

<source lang="bash">
% grep CONFIG_NFT_ /boot/config-4.2.0-1-amd64
CONFIG_NFT_EXTHDR=m
CONFIG_NFT_META=m
CONFIG_NFT_CT=m
CONFIG_NFT_RBTREE=m
CONFIG_NFT_HASH=m
CONFIG_NFT_COUNTER=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
CONFIG_NFT_MASQ=m
CONFIG_NFT_REDIR=m
CONFIG_NFT_NAT=m
CONFIG_NFT_QUEUE=m
CONFIG_NFT_REJECT=m
CONFIG_NFT_REJECT_INET=m
CONFIG_NFT_COMPAT=m
CONFIG_NFT_CHAIN_ROUTE_IPV4=m
CONFIG_NFT_REJECT_IPV4=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
CONFIG_NFT_MASQ_IPV4=m
# CONFIG_NFT_REDIR_IPV4 is not set
CONFIG_NFT_CHAIN_ROUTE_IPV6=m
CONFIG_NFT_REJECT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV6=m
CONFIG_NFT_MASQ_IPV6=m
# CONFIG_NFT_REDIR_IPV6 is not set
CONFIG_NFT_BRIDGE_META=m
CONFIG_NFT_BRIDGE_REJECT=m
</source>

== Installing from git ==

This is slower as you will retrieve the Linux kernel git tree for nftables:

<source lang="bash">
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nftables.git
</source>

After retrieving the git tree, you have to follow the same steps that described in the installation from sources.

But you will get the most recent changes for the ''nftables'' kernel code there.

When configuring the kernel, be sure to enable all the nftables modules (choose 'm' or 'y'). This is an example:

<source lang="bash">
$ make oldconfig

Netfilter Xtables support (required for ip_tables) (NETFILTER_XTABLES) [M/y/?] m
Netfilter nf_tables support (NF_TABLES) [N/m] (NEW) m
Netfilter nf_tables payload module (NFT_PAYLOAD) [N/m] (NEW) m
Netfilter nf_tables IPv6 exthdr module (NFT_EXTHDR) [N/m] (NEW) m
Netfilter nf_tables meta module (NFT_META) [N/m] (NEW) m
Netfilter nf_tables conntrack module (NFT_CT) [N/m] (NEW) m
Netfilter nf_tables rbtree set module (NFT_RBTREE) [N/m] (NEW) m
Netfilter nf_tables hash set module (NFT_HASH) [N/m] (NEW) m
Netfilter nf_tables counter module (NFT_COUNTER) [N/m] (NEW) m
Netfilter nf_tables log module (NFT_LOG) [N/m] (NEW) m
Netfilter nf_tables limit module (NFT_LIMIT) [N/m] (NEW) m
Netfilter nf_tables nat module (NFT_NAT) [N/m] (NEW) m
Netfilter x_tables over nf_tables module (NFT_COMPAT) [N/m/?] (NEW) m

IPv4 nf_tables support (NF_TABLES_IPV4) [N/m] (NEW) m
nf_tables IPv4 reject support (NFT_REJECT_IPV4) [N/m] (NEW) m
IPv4 nf_tables route chain support (NFT_CHAIN_ROUTE_IPV4) [N/m] (NEW) m
IPv4 nf_tables nat chain support (NFT_CHAIN_NAT_IPV4) [N/m] (NEW) m

IPv6 nf_tables support (NF_TABLES_IPV6) [M/n] m
IPv6 nf_tables route chain support (NFT_CHAIN_ROUTE_IPV6) [M/n] m
IPv6 nf_tables nat chain support (NFT_CHAIN_NAT_IPV6) [M/n] m

Ethernet Bridge nf_tables support (NF_TABLES_BRIDGE) [N/m/y] (NEW) m
</source>

Jumping to chain

2019-07-23T19:40:47Z

Admin:

Like in ''iptables'', you can structure your rule-set in using a tree of [[Configuring chains|chains]]. To do so, you first need to create the non-base chain via:

<source lang="bash">
% nft add chain ip filter tcp-chain
</source>

The example above creates the ''tcp-chain'' which will be used to add rules to filter tcp traffic, eg.

<source lang="bash">
% nft add rule ip filter input ip protocol tcp jump tcp-chain
</source>

We can just add a simple rule to that ''tcp-chain'' to count packets and bytes:

<source lang="bash">
% nft add rule ip filter tcp-chain counter
</source>

The listing should show something like:

<source lang="bash">
% nft list table filter
table ip filter {
chain input {
type filter hook input priority 0;
ip protocol tcp jump tcp-chain
}

chain tcp-chain {
counter packets 8 bytes 2020
}
}
</source>

The counters should update by generating simple TCP traffic.

'''Note:''' You can only jump to non-base chains.

== jump vs goto ==

Please note the difference between '''jump''' and '''goto'''.

* If you use '''jump''' to get packet processed in another chain, packet will return to the chain of the calling rule after the end.

* However, if you use '''goto''', packets will be processed in another chain but '''they will not return''' to the chain of the calling rule. In this case, the default policy applied to the packet will be the default policy of the original base chain which started processing the packet.

Example of '''jump''':

Packet is: SRC=1.1.1.1 DST=2.2.2.2 TCP SPORT 111 DPORT 222

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority 0; policy accept;
# this is the 1º matching rule
ip saddr 1.1.1.1 ip daddr 2.2.2.2 tcp sport 111 tcp dport 222 jump other-chain
# this is the 3º matching rule
ip saddr 1.1.1.1 ip daddr 2.2.2.2 tcp sport 111 tcp dport 222 accept
}

chain other-chain {
# this is the 2º matching rule
counter packets 8 bytes 2020
}
}
</source>

Example of '''goto''':

Packet is: SRC=1.1.1.1 DST=2.2.2.2 TCP SPORT 111 DPORT 222

<source lang="bash">
table ip filter {
chain input {
type filter hook input priority 0; policy accept;
# this is the 1º matching rule
# default policy 'accept' will be applied after other-chain ends processing
ip saddr 1.1.1.1 ip daddr 2.2.2.2 tcp sport 111 tcp dport 222 goto other-chain
# this rule will never be reached by this packet!
ip saddr 1.1.1.1 ip daddr 2.2.2.2 tcp sport 111 tcp dport 222 accept
}

chain other-chain {
# this is the 2º matching rule
counter packets 8 bytes 2020
}
}
</source>

Note that only jump and goto actions to '''non-base chains''' are allowed.

Jumping to chain

2019-07-23T19:40:24Z

Admin:

Jumping to chain

2019-07-23T19:39:49Z

Admin:

Jumping to chain

2019-07-23T19:39:35Z

Admin:

Meters

2019-07-12T11:22:00Z

Admin: /* Meters */

== Meters ==

This feature used to be known as ''flow tables'' before nft v0.8.1 and Linux kernel 4.3. However, the ''meter'' keyword is obsolete, the dynamic set and map syntax is now preferred for consistency.

Meters are a way to use maps.

Among other things, they provide a native replacement for the ''hashlimit'' match in iptables. However, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

== Using meters ==

The following commands create a table named ''filter'', a chain named ''input'' which hooks incoming traffic and a rule that uses a meter:

<source lang="bash">
% nft add table filter
% nft add chain filter input {type filter hook input priority 0\;}
% nft add map filter ssh-meter { type ipv4_addr : limit; }
% nft add rule filter input tcp dport 22 ct state new update @ssh-meter { ip saddr limit rate 10/second } accept
</source>

In this example we create a rule to match ''new'' ''ssh'' (port 22) connections, which uses a meter named ''ssh-meter'' to limit the traffic rate to 10 packets per second for each source IP address. The available time units on limits are: ''second'', ''minute'', ''hour'', ''day'' and ''week''.

You can also use [[concatenations]] to build selectors:

<source lang="bash">
% nft add rule filter input tcp dport 22 ct state new update @ssh-meter { ip saddr . tcp dport timeout 60s limit rate 10/second } accept
</source>

This rule counts incoming packets based on the tuple ''(input interface index, IP source address, TCP destination port)'', the counters are dropped after 60 seconds without update.

== Listing meters ==

To list the content matched by the meter use:

<source lang="bash">
% nft list map filter ssh-meter
table ip filter {
map ssh-meter {
type iface_index . ipv4_addr . inet_service
flags timeout
elements = { "wlan1" . 64.62.190.36 . 55000 expires 38s : counter packets 2 bytes 220, "wlan1" . 83.98.201.47 . 35460 expires 39s : counter packets 10 bytes 5988, "wlan1" . 172.217.7.142 . 43254 expires 46s : counter packets 1 bytes 98}
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, there is a new ''ct count'' selector that allows you to count the number of existing connections. This extension uses the information available in the Connection Tracking System table, therefore, the counting of connection is based on the existing entries in the table.

The following example shows how to do ''connlimit'' from nftables:

table ip filter {
set connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain y {
type filter hook output priority filter; policy accept;
ct state new add @connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
}
}

The example above dynamically populates the set ''connlimit'' from the packet path. For the first packet of each connection (ie. packets matching ''ct state new''), this adds an entry into ''connlimit'' set, this entry uses the IPv4 destination address as a key. If the number of connection goes over 20, then packets are dropped.

Since ''connlimit'' is a set, you can perform any operation on it, such as listing and flushing its content.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Meters

2019-07-12T11:19:59Z

Admin: /* Listing meters */

== Meters ==

This feature used to be known as ''flow tables'' before nft v0.8.1.

Since Linux Kernel 4.3 and nft v0.8.1 nftables supports this feature.

Meters provide a native replacement for the ''hashlimit'' match in iptables, however, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

== Using meters ==

The following commands create a table named ''filter'', a chain named ''input'' which hooks incoming traffic and a rule that uses a meter:

<source lang="bash">
% nft add table filter
% nft add chain filter input {type filter hook input priority 0\;}
% nft add map filter ssh-meter { type ipv4_addr : limit; }
% nft add rule filter input tcp dport 22 ct state new update @ssh-meter { ip saddr limit rate 10/second } accept
</source>

In this example we create a rule to match ''new'' ''ssh'' (port 22) connections, which uses a meter named ''ssh-meter'' to limit the traffic rate to 10 packets per second for each source IP address. The available time units on limits are: ''second'', ''minute'', ''hour'', ''day'' and ''week''.

You can also use [[concatenations]] to build selectors:

<source lang="bash">
% nft add rule filter input tcp dport 22 ct state new update @ssh-meter { ip saddr . tcp dport timeout 60s limit rate 10/second } accept
</source>

This rule counts incoming packets based on the tuple ''(input interface index, IP source address, TCP destination port)'', the counters are dropped after 60 seconds without update.

== Listing meters ==

To list the content matched by the meter use:

<source lang="bash">
% nft list map filter ssh-meter
table ip filter {
map ssh-meter {
type iface_index . ipv4_addr . inet_service
flags timeout
elements = { "wlan1" . 64.62.190.36 . 55000 expires 38s : counter packets 2 bytes 220, "wlan1" . 83.98.201.47 . 35460 expires 39s : counter packets 10 bytes 5988, "wlan1" . 172.217.7.142 . 43254 expires 46s : counter packets 1 bytes 98}
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, there is a new ''ct count'' selector that allows you to count the number of existing connections. This extension uses the information available in the Connection Tracking System table, therefore, the counting of connection is based on the existing entries in the table.

The following example shows how to do ''connlimit'' from nftables:

table ip filter {
set connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain y {
type filter hook output priority filter; policy accept;
ct state new add @connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
}
}

The example above dynamically populates the set ''connlimit'' from the packet path. For the first packet of each connection (ie. packets matching ''ct state new''), this adds an entry into ''connlimit'' set, this entry uses the IPv4 destination address as a key. If the number of connection goes over 20, then packets are dropped.

Since ''connlimit'' is a set, you can perform any operation on it, such as listing and flushing its content.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.