On 2021/03/08 14:22, Stefan Hartmann 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.
Thanks for including the output with counters. I'd advise removing the
'ct helper set "ftp-21"' from the last 'accept' rule in your INPUT4
input chain to get simply:
tcp dport ftp ip daddr 10.18.16.143 accept
And adding the ct helper 'ftp-21' definition and a _prerouting_ chain
with your helper rule as in the earlier example I sent, and:
https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation
https://www.mankier.com/8/nft#Stateful_Objects-CT_Helper
I think having the helper rule in _prerouting_ rather than _input_ may
change what you see...
Best Wishes,
Frank
