[Bug 1173] New: Documentation/error messages around NAT statements in "inet" tables incorrect

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1173

            Bug ID: 1173
           Summary: Documentation/error messages around NAT statements in
                    "inet" tables incorrect
           Product: nftables
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: netfilter at allycomm.com

Observed behavior:
==================

No matter what the documentation says, it appears that NAT statements can't be
in an "inet" table.  The error messages are unhelpful in deducing this.


Expected behavior:
==================

* NAT statements could be present in inet tables as it is already limited to
IPv4/IPv6 packets, at least as I understand it.

<http://www.netfilter.org/projects/nftables/manpage.html>
"inet
     Internet (IPv4/IPv6) address family."

ibid., under "NAT STATEMENTS" 
"The nat statements are only valid from nat chain types."
(with no statement there that a nat chain can't be in an inet table)

ibid., under "TABLES"
"The inet address family is a dummy family which is used to create hybrid
IPv4/IPv6 tables."

ibid., under "CHAINS"
(No indication that NAT chains cannot be contained within inet tables)

<https://wiki.nftables.org/wiki-nftables/index.php/Why_nftables%3F>
"Simplified dual stack IPv4/IPv6 administration, through the new inet family
that allows you to register base chains that see both IPv4 and IPv6 traffic."


* Error messages point to the likely cause of the problem, as well as how to
resolve it (at least *where* in the file the problem occurred)


Desired outcomes:
=================

* Critical -- update documentation; user shouldn't have to "guess" as to the
problem
* Major -- provide "insightful" error messages
* Enhancement -- allow NAT statements in inet tables




To replicate:
=============


Parses and loads with "table ip"
================================

#!/usr/sbin/nft -f

flush ruleset

table ip global {

    chain nat_in {
        type nat hook prerouting priority -100
    continue
    }

    chain nat_out {
        type nat hook postrouting priority -100
    continue
    }

}


Fails with "table inet"
=======================

#!/usr/sbin/nft -f

flush ruleset

table inet global {

    chain nat_in {
        type nat hook prerouting priority -100
    continue
    }

    chain nat_out {
        type nat hook postrouting priority -100
    continue
    }

}


The error messages here are different, but equally useless

$ sudo nft -f nftables.conf
nftables.conf:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or directory
flush ruleset
^^^^^^^^^^^^^^


When NAT statements occur in a non-trivial rule set, the error messages are
unhelpful as well:

Adding simple NAT statements results in "meaningless" reference in error
message:

    In file included from nftables.conf:114:5-45:
    ./blackhole_check_internal.nft:6:54-57: Error: NAT is only supported for
IPv4/IPv6
    nal_allowed_net {
                                                         ^^^^

That's a non-sequetor, nowhere near any NAT-related statement.

The NAT-related statements are in an "inet" table.

The NAT-related statements are all "protected" with "ip version 4" now,
and the problem still persists.


(See further <http://www.spinics.net/lists/netfilter/msg57562.html>)

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170822/7517aaa5/attachment.html>