Stefan Hartmann <stefanh@xxxxxxxxxxxx> wrote:
> I tested with this sequence, with multiple counters and no verdicts and
> nflog:
>
> chain INPUT4 {
> type filter hook input priority 0; policy drop;
> iifname "lo" accept
> ct state established counter packets 403 bytes 26976 accept
> ct state related counter packets 1 bytes 60
> ct helper "ftp-21" counter packets 0 bytes 0
> ct state related ct helper "ftp-21" counter packets 0 bytes 0 accept
> ct state related counter packets 1 bytes 60 log group 10
> ct state related counter packets 1 bytes 60 accept
> ip protocol icmp accept
> tcp dport ssh accept
> tcp dport ftp ip daddr 10.18.16.143 counter packets 1 bytes 60 ct helper
> set "ftp-21" accept
> counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p. died: " group
> 0 drop
> }
>
> And indeed, the RELATED packet going through is the SYN packet from the FTP
> DATA flow.
>
> The ct helper "ftp-21" matches NOT on the RELATED packets, it matches pretty
> sure on the master connection.
> I will try to verificate this.
'ct state related ct helper "ftp"' should work for data connections.
Problem is that 'ct helper' fetches the in-kernel name of the helper
("ftp" in this case) and not the object name defined in the ruleset or
used for assignment.
