On 2021/03/07 10:12, Stefan Hartmann wrote:
Hi,
I want to carefully open the related-flow and noticed that I cannot
concatenate the two ct expressions:
ct state related ct helper "HELPER" ... accept
Simple example with ftp-helper:
...
chain INPUT4 { vom VPN-Peer,
type filter hook input priority 0; policy drop;
ct state established counter accept
# would be nice to match on state related AND applied helper
ct state related ct helper "ftp-21" tcp dport {1024-65535} counter
accept
Hi Stefan,
I guess the problem is that input tcp packets with dport {1024-65535}
that are matched by "ftp-21" ct helper are by definition related packets
(to the original connection to tcp/21), so the explicit "ct state
related" match in your INPUT4 chain rule is redundant. You didn't show
your "ftp-21" ct helper (stateful object) definition, I suppose it is
something like those at:
https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation
Then you'd have something like (warning, untested):
table my_table {
ct helper ftp-21 {
type "ftp" protocol tcp;
}
chain ct_helper_assign {
type filter hook prerouting priority filter;
ct state new tcp dport 21 ct helper set "ftp-21"
}
chain INPUT4 {
type filter hook input priority filter; policy drop;
...
ct helper "ftp-21" tcp dport {1024-65535} counter accept
...
}
...
}
In the above ruleset "ftp-21 related" packets are accepted in a 2-step
process:
1) In the prerouting hook such packets receive "ftp-21 related" status
when the "ftp-21" "ftp" helper recognizes them as matching expectations
it created based on recent packets to tcp/21;
2) In the input hook such packets are matched (with additional tcp dport
restriction), counted, and accepted by the rule in your INPUT4 chain.
This explicit 2-step process differs from the way ct helpers worked
using iptables, for example:
https://home.regit.org/netfilter-en/secure-use-of-helpers/
Best Wishes,
Frank
