<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Documentation/error messages around NAT statements in "inet" tables incorrect"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1173">1173</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Documentation/error messages around NAT statements in "inet" tables incorrect
</td>
</tr>
<tr>
<th>Product</th>
<td>nftables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>critical
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>nft
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pablo@netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>netfilter@allycomm.com
</td>
</tr></table>
<p>
<div>
<pre>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.
<<a href="http://www.netfilter.org/projects/nftables/manpage.html">http://www.netfilter.org/projects/nftables/manpage.html</a>>
"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)
<<a href="https://wiki.nftables.org/wiki-nftables/index.php/Why_nftables%3F">https://wiki.nftables.org/wiki-nftables/index.php/Why_nftables%3F</a>>
"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 <<a href="http://www.spinics.net/lists/netfilter/msg57562.html">http://www.spinics.net/lists/netfilter/msg57562.html</a>>)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>