<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:phil@nwl.cc" title="Phil Sutter <phil@nwl.cc>"> <span class="fn">Phil Sutter</span></a>
</span> changed
<a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - issue with DNAT port range"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1501">bug 1501</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>phil@nwl.cc
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - issue with DNAT port range"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1501#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - issue with DNAT port range"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1501">bug 1501</a>
from <span class="vcard"><a class="email" href="mailto:phil@nwl.cc" title="Phil Sutter <phil@nwl.cc>"> <span class="fn">Phil Sutter</span></a>
</span></b>
<pre>Hi,
(In reply to marco.drummer from <a href="show_bug.cgi?id=1501#c5">comment #5</a>)
<span class="quote">> Thank you for the work.
>
> I just want to confirm that
>
> iptables -t nat -A PREROUTING -p tcp -m tcp --dport 5500:5600 -j DNAT
> --to-destination 10.212.0.1:21500-21600/5500
>
> works in so far, that is does result in a shifted port redirect, regardless
> of whether the oputput of nft list ruleset is correct in displaying
> "10.212.0.1:21500-21600;5500" or not
> (just for the benefit of anyone finding this via google etc.)
>
> This is Ubuntu Server 22.04 with iptables 1.0.2-1ubuntu3
>
> Now the question is, is this considered a bug that would be feasible to be
> backported into the lts kernel and iptables version that ubuntu uses? (Of
> course in the end the ubuntu maintainers may also have to decide this)
> Essentially this is a bug, that breaks the transition from iptables to
> nftables, that will otherwise remain unfixed for over a year in LTS ubuntu.</span >
If enabled at compile-time, nft used libxtables to translate iptables
extensions into native nftables syntax. There were several issues with this:
- Some extensions' xlate callbacks did not return an error code if translation
was not possible or supported, so nft would print incomplete or incorrect
translations in that case.
- If translation was unavailable, nft appended the unsupported extension's
name to the printed rule following a pound (#) sign. In consequence, a
typical 'nft list ruleset | nft -f -' (a short-cut of the usual save and
restore an nftables service would do) could break the ruleset in various
ways.
Note that both these problems stem from mixed use of iptables-nft and nftables.
This is a bad idea per se, but to avoid problems from doing it by accident a
number of changes were pushed into both iptables and nftables repos:
- Correction of iptables extensions' xlate callbacks (various commits).
- Change of how nft prints unsupported extensions, deliberately preventing a
later restore of the dump from passing (79195a8cc9e9d ("xt: Rewrite
unsupported compat expression dumping") and follow-ups)..
Regarding the shifted port ranges you're relying upon, there's still no support
for it in nftables and hence no translation available.
<span class="quote">> Just to see if I understood this correctly
>
> > Not quite. iptables-nft uses the nft communications infrastructure to
> > communicate with the kernel. It is still using the xtables kernel modules.
> > Basically, there's an nft kernel module (called `nft_compat`) that receives
> > messages from userspace and then hands them off to the appropriate iptables
> > kernel module.
>
> This basically means, that right now 90% of my rules use the nft backend and
> that one particular rule actually uses the old xtables backend? (with all
> performance and compatibility drawbacks that entails) but is still printed
> by nft list ruleset?</span >
What performance and compatibility drawbacks are you talking about in
particular?
<span class="quote">> > because, like the more recent iptables-translation mentioned above, nft no
> > longer produces erroneous output for a rule it cannot parse.
>
> But hold on, wouldn't that lead to a situation where I am unable to see the
> actual rule applied in the kernel??
>
> If nft list rulesets just drops the "base port" part and iptables just
> refuses to print anything since it does not understand nft rules, how would
> I ever see this rule correctly again.</span >
Why would iptables not print anything? Any rule created with iptables-nft will
be listed correctly by iptables-nft(-save).
Cheers, Phil</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>