Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Mar 09, 2021 at 06:24:28PM +0100, Florian Westphal wrote:
> Frank Myhr <fmyhr@fhmtech.com> wrote:
> > > The ct helper "ftp" matches on the RELATED packets.
> > 
> > Stefan, congrats on getting your configuration working. :-)
> > And thank you very much for posting your complete ruleset below.
> > 
> > Florian, I hope you can comment:
> > 
> > 1) I will look at the code, but am surprised that "ct helper" uses the
> > in-kernel name "ftp" rather than that of the stateful object "ftp-21" that
> > the ruleset goes to the trouble of explicitly defining.
> > 
> > a) Is this simply a parsing artifact -- if the helper were called "abcd"
> > would the expression 'ct helper "abcd"' match it?
> > 
> > b) If it is NOT a parsing artifact but by design: why? It would be more
> > intuitive to use the name of the explicitly-named helper object. Another way
> > to ask the same thing: why bother with the explicit helper object at all,
> > rather than just use "ftp" (which implies the ip & tcp protocols in "ftp-21"
> > definition anyway) in both match and statement, like 'ct helper set "ftp"'?
> 
> Its a design fuckup.  When I made the objref patches to attach the
> defined helpers I did not consider that we already had a 'ct helper'
> with existing behaviour.
> 
> The explicit helper objects were done this way to allow defining
> multiple helpers wuth different settings.
> 
> There are helpers that can be tuned by options and users might want to
> use different settings in each.

Just posted a patchset, maybe we can address this inconsistency moving
forward:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-2-pablo@netfilter.org/
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-3-pablo@netfilter.org/

> > 2) Does it make a difference whether 'ct helper set' is done in input (as in
> > below ruleset) or in prerouting? Maybe it has to be in prerouting only in
> > case of forwarded traffic?
> 
> It can be in input if the traffic is not forwarded.

Actually it can be place in forward chain too IIRC.

If the rule is added to prerouting, then the ct helper is attached to
both input and forward traffic.