Provided by: iptables_1.8.4-3ubuntu2.1_amd64 bug

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)