On 2021/03/09 11:13, Stefan Hartmann wrote:
On 08.03.21 22:05, Florian Westphal wrote:
'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
Thank you, this is the necessary hint!
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"'?
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?
https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers
currently says:
"You have to attach your conntrack helper from the prerouting chain."
Thanks,
Frank
For the sake of completeness, here my nftables ftp-helper test ruleset:
Active ruleset: ================.
table ip FILTER4 {
ct helper ftp-21 {
type "ftp" protocol tcp
l3proto ip
}
chain PREROUTING-EARLY4 {
type filter hook prerouting priority -300; policy accept;
}
chain PREROUTING-MANGLE4 {
type filter hook prerouting priority -150; policy accept;
}
chain PREROUTING-NAT4 {
type nat hook prerouting priority -100; policy accept;
}
chain PREROUTING-FILTER4 {
type filter hook prerouting priority 0; policy accept;
}
chain FORWARD4 {
type filter hook forward priority 0; policy drop;
counter packets 0 bytes 0 log prefix "NFT: FILTER4/FORWARD4: p.
died: " group 0 drop
}
chain INPUT4 {
type filter hook input priority 0; policy drop;
iifname "lo" accept
ct state established counter packets 317 bytes 20876 accept
ct state related ct helper "ftp" tcp dport { 1024-65535 } ip
saddr 10.18.0.0/19 counter packets 3 bytes 180 accept
ct state related ct helper "ftp" counter packets 0 bytes 0 log
prefix "NFT: FILTER4/INPUT4: p. died :" group 0 drop
ct state related counter packets 0 bytes 0 accept
ip protocol icmp accept
tcp dport ssh accept
tcp dport ftp ip daddr 10.18.16.143 counter packets 2 bytes 120
ct helper set "ftp-21" accept
counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p.
died: " group 0 drop
}
chain OUTPUT-MANGLE4 {
type route hook output priority -150; policy accept;
}
chain OUTPUT4 {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ct state established counter packets 250 bytes 1073349 accept
ct state related ct helper "ftp" tcp sport ftp-data ip daddr
10.18.0.0/19 counter packets 3 bytes 180 accept
ct state related ct helper "ftp" counter packets 0 bytes 0 log
prefix "NFT: FILTER4/OUTPUT4: p. died :" group 0 drop
ct state related counter packets 0 bytes 0 accept
ip protocol icmp accept
udp dport { domain, ntp } ip daddr 10.18.0.0/19 accept
tcp dport { domain, 3128 } ip daddr 10.18.0.0/19 accept
counter packets 0 bytes 0 log prefix "NFT: FILTER4/OUTPUT4: p.
died :" group 0 drop
}
chain POSTROUTING-MANGLE4 {
type filter hook postrouting priority -150; policy accept;
}
chain POSTROUTING-NAT4 {
type nat hook postrouting priority 100; policy accept;
}
}
[info] End of ruleset: ================.
