netfilter buglog - Jul 2023 - [Bug 1501] issue with DNAT port range

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at nwl.cc

--- Comment #7 from Phil Sutter <phil at nwl.cc> ---
Hi,

(In reply to marco.drummer from comment #5)
> 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.
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.
> 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?
What performance and compatibility drawbacks are you talking about in
particular?
> > 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.
Why would iptables not print anything? Any rule created with iptables-nft will
be listed correctly by iptables-nft(-save).

Cheers, Phil

-- 
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/20230726/76dbbed2/attachment.html>