NAME

       xtables-nft — iptables using nftables kernel api

DESCRIPTION

       xtables-nft  are  versions  of  iptables  that  use the nftables API.  This is a set of tools to help the
       system administrator migrate the ruleset from iptables(8), ip6tables(8), arptables(8), and ebtables(8) to
       nftables(8).

       The xtables-nft set is composed of several commands:

       • iptables-nft

       • iptables-nft-save

       • iptables-nft-restore

       • ip6tables-nft

       • ip6tables-nft-save

       • ip6tables-nft-restore

       • arptables-nft

       • ebtables-nft

         These tools use the libxtables framework extensions and hook to the nf_tables  kernel  subsystem  using
         the nft_compat module.

USAGE

       The  xtables-nft  tools allow you to manage the nf_tables backend using the native syntax of iptables(8),
       ip6tables(8), arptables(8), and ebtables(8).

       You should use the xtables-nft tools exactly the same way as you would  use  the  corresponding  original
       tools.

       Adding  a  rule  will result in that rule being added to the nf_tables kernel subsystem instead.  Listing
       the ruleset will use the nf_tables backend as well.

       When these tools were designed, the main idea was to replace each legacy binary with  a  symlink  to  the
       xtables-nft program, for example:

            /sbin/iptables -> /usr/sbin/iptables-nft-multi
            /sbin/ip6tables -> /usr/sbin/ip6tables-nft-multi
            /sbin/arptables -> /usr/sbin/arptables-nft-multi
            /sbin/ebtables -> /usr/sbin/ebtables-nft-multi

       The  iptables  version  string will indicate whether the legacy API (get/setsockopt) or the new nf_tables
       api is used:
            iptables -V
            iptables v1.7 (nf_tables)

DIFFERENCES TO LEGACY IPTABLES

       Because the xtables-nft tools use the nf_tables kernel API,  rule  additions  and  deletions  are  always
       atomic.   Unlike  iptables-legacy, iptables-nft -A ..  will NOT need to retrieve the current ruleset from
       the kernel, change it, and re-load the altered ruleset.  Instead, iptables-nft will tell  the  kernel  to
       add one rule.  For this reason, the iptables-legacy --wait option is a no-op in iptables-nft.

       Use of the xtables-nft tools allow monitoring ruleset changes using the xtables-monitor(8) command.

       When  using  -j  TRACE  to  debug  packet  traversal  to  the  ruleset,  note  that  you will need to use
       xtables-monitor(8) in --trace mode to obtain monitoring trace events.

EXAMPLES

       One basic example is creating the skeleton ruleset in nf_tables from the xtables-nft tools,  in  a  fresh
       machine:

            root@machine:~# iptables-nft -L
            [...]
            root@machine:~# ip6tables-nft -L
            [...]
            root@machine:~# arptables-nft -L
            [...]
            root@machine:~# ebtables-nft -L
            [...]
            root@machine:~# nft list ruleset
            table ip filter {
                 chain INPUT {
                      type filter hook input priority 0; policy accept;
                 }

                 chain FORWARD {
                      type filter hook forward priority 0; policy accept;
                 }

                 chain OUTPUT {
                      type filter hook output priority 0; policy accept;
                 }
            }
            table ip6 filter {
                 chain INPUT {
                      type filter hook input priority 0; policy accept;
                 }

                 chain FORWARD {
                      type filter hook forward priority 0; policy accept;
                 }

                 chain OUTPUT {
                      type filter hook output priority 0; policy accept;
                 }
            }
            table bridge filter {
                 chain INPUT {
                      type filter hook input priority -200; policy accept;
                 }

                 chain FORWARD {
                      type filter hook forward priority -200; policy accept;
                 }

                 chain OUTPUT {
                      type filter hook output priority -200; policy accept;
                 }
            }
            table arp filter {
                 chain INPUT {
                      type filter hook input priority 0; policy accept;
                 }

                 chain FORWARD {
                      type filter hook forward priority 0; policy accept;
                 }

                 chain OUTPUT {
                      type filter hook output priority 0; policy accept;
                 }
            }

       (please  note  that  in  fresh  machines, listing the ruleset for the first time results in all tables an
       chain being created).

       To migrate your complete filter ruleset, in the case of iptables(8), you would use:

            root@machine:~# iptables-legacy-save > myruleset # reads from x_tables
            root@machine:~# iptables-nft-restore myruleset   # writes to nf_tables
       or
            root@machine:~# iptables-legacy-save | iptables-translate-restore | less

       to see how rules would look like in the nft nft(8) syntax.

LIMITATIONS

       You should use Linux kernel >= 4.17.

       The CLUSTERIP target is not supported.

       To get up-to-date information about this, please head to http://wiki.nftables.org/.

SEE ALSO

       nft(8), xtables-translate(8), xtables-monitor(8)

AUTHORS

       The nftables framework is written by the Netfilter project (https://www.netfilter.org).

       This manual page was written by Arturo Borrero Gonzalez <arturo@debian.org> for the Debian  project,  but
       may be used by others.

       This documentation is free/libre under the terms of the GPLv2+.

                                                    June 2018                                     XTABLES-NFT(8)