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

[Florian Westphal <fw@strlen.de>]

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.

> 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.