| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend 8b043938e77b ("evaluate: disallow ct original {s,d}ddr from
maps") to cover concatenations too.
Error: specify either ip or ip6 for address matching
add rule x y meta mark set ct original saddr . meta mark map { 1.1.1.1 . 20 : 30 }
^^^^^^^^^^^^^^^^^
The old syntax for ct original saddr without either ip or ip6 results
in unknown key size, which breaks the listing. The old syntax is only
allowed in simple rules for backward compatibility.
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1489
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
| |
test.nft:6:55-71: Error: specify either ip or ip6 for address matching
add rule ip mangle manout ct direction reply mark set ct original daddr map { $ext1_ip : 0x11, $ext2_ip : 0x12 }
^^^^^^^^^^^^^^^^^
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1489
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a prefix expression's length is on a byte-boundary, it is sufficient
to just reduce the length passed to "cmp" expression. No need for
explicit bitwise modification of data on LHS. The relevant code is
already there, used for string prefix matches. There is one exception
though, namely zero-length prefixes: Kernel doesn't accept zero-length
"cmp" expressions, so keep them in the old code-path for now.
This patch depends upon the previous one to correctly parse odd-sized
payload matches but has to extend support for non-payload LHS as well.
In practice, this is needed for "ct" expressions as they allow matching
against IP address prefixes, too.
Signed-off-by: Phil Sutter <phil@nwl.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These keys are available since kernel >= 4.17.
You can still use NFT_CT_{SRC,DST}, however, you need to specify 'meta
protocol' in first place to provide layer 3 context.
Note that NFT_CT_{SRC,DST} are broken with set, maps and concatenations.
This patch is implicitly fixing these cases.
If your kernel is < 4.17, you can still use address matching via
explicit meta nfproto:
meta nfproto ipv4 ct original saddr 1.2.3.4
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
| |
use 'ip saddr', 'ip6 saddr', etc.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Acctually, ct l3proto and ct protocol are unrelated to direction, so
it's unnecessary that we must specify dir if we want to use them.
Now add support that we can match ct l3proto/protocol without direction:
# nft add rule filter input ct l3proto ipv4
# nft add rule filter output ct protocol 17
Note: existing syntax is still preserved, so "ct reply l3proto ipv6"
is still fine.
Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
old: ct saddr original 1.2.3.4
new: ct original saddr 1.2.3.4
The advantage is that this allows to add ct keys where direction is optional
without creating ambiguities in the parser.
So we can have
ct packets gt 42
ct original packets gt 42
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Cannot check e.g. saddr for 192.168.0.1 for 'any' protocol, nft
needs to expect arguments of a specific address type.
So e.g. when using 'inet' we need to add a rule that makes the expected
family explicit, e.g. 'meta nfproto ipv4'.
Signed-off-by: Florian Westphal <fw@strlen.de>
|