Matching metainformation cgroup fails on input, works on output.
Hello, everyone.
I have a weird problem!
This is my nft code:
``` nft add counter filter test-icmp-output nft add counter filter test-icmp-input nft add rule filter OUTPUT meta cgroup != 0x001000 ip daddr 8.8.8.8 ip protocol icmp counter name test-icmp-output nft add rule filter INPUT meta cgroup != 0x001000 ip saddr 8.8.8.8 ip protocol icmp counter name test-icmp-input ```
Pinging 8.8.8.8 works. The packets are visible on tcpdump too. The cgroup id 0x001000 does not exist, so every packet should match.
Still, the output counter counts the expected number of packets, the second stays 0.
What am I doing wrong?
Signature · 3 lines
Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
What is the complete output of 'nft list ruleset'?
Is it possible you have an earlier INPUT rule that matches and allows packets that match connection-tracking "established" state, such as:
chain INPUT {
type filter hook input priority filter; policy drop;
ct state established,related counter packets 391638047bytes 93651768866 accept
ct state invalid drop
[...]
-Martin
Quoted 26 lines · Vladimir Nikishkin
Hello, everyone.
I have a weird problem!
This is my nft code:
``` nft add counter filter test-icmp-output nft add counter filter test-icmp-input nft add rule filter OUTPUT meta cgroup != 0x001000 ip daddr 8.8.8.8 ip protocol icmp counter name test-icmp-output nft add rule filter INPUT meta cgroup != 0x001000 ip saddr 8.8.8.8 ip protocol icmp counter name test-icmp-input ```Pinging 8.8.8.8 works. The packets are visible on tcpdump too. The cgroup id
0x001000does not exist, so every packet should match.Still, the output counter counts the expected number of packets, the second stays 0.
What am I doing wrong?
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
I have just tested it (again) by flushing the old ruleset and using the following ruleset:
```
table ip filter {
counter test-icmp-output {
packets 3 bytes 252
}
counter test-icmp-input {
packets 0 bytes 0
}
chain INPUT {
type filter hook input priority filter; policy accept;
meta cgroup != 4096 ip saddr 8.8.8.8 ip protocol icmp counter name "test-icmp-input"
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
meta cgroup != 4096 ip daddr 8.8.8.8 ip protocol icmp counter name "test-icmp-output"
}
}
```As previously, the cgroup 0x001000 does not exist. The three outbound packets are the three ping packets, and they were successfully replied to.
Quoted 42 lines · Martin Gignac
What is the complete output of 'nft list ruleset'?
Is it possible you have an earlier INPUT rule that matches and allows packets that match connection-tracking "established" state, such as:
chain INPUT { type filter hook input priority filter; policy drop; ct state established,related counter packets 391638047bytes 93651768866 accept
ct state invalid drop
[...]-Martin
Quoted 26 lines · Vladimir Nikishkin
Hello, everyone.
I have a weird problem!
This is my nft code:
``` nft add counter filter test-icmp-output nft add counter filter test-icmp-input nft add rule filter OUTPUT meta cgroup != 0x001000 ip daddr 8.8.8.8 ip protocol icmp counter name test-icmp-output nft add rule filter INPUT meta cgroup != 0x001000 ip saddr 8.8.8.8 ip protocol icmp counter name test-icmp-input ```Pinging 8.8.8.8 works. The packets are visible on tcpdump too. The cgroup id
0x001000does not exist, so every packet should match.Still, the output counter counts the expected number of packets, the second stays 0.
What am I doing wrong?
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
Signature · 3 lines
Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
I tried the same setup as you, and indeed I get the same result (i.e. no counter increase on INPUT). nftrace also shows that the packet doesn't match the INPUT rule.
This is just a stab in the dark, but isn't it possible that the INPUT rule doesn't match because nftables has no way to filter random INCOMING packets on cgroups? I mean, how would nftables know which cgroup any incoming packet would be associated with?
-Martin
Quoted 80 lines · Vladimir Nikishkin
I have just tested it (again) by flushing the old ruleset and using the following ruleset:
``` table ip filter { counter test-icmp-output { packets 3 bytes 252 } counter test-icmp-input { packets 0 bytes 0 } chain INPUT { type filter hook input priority filter; policy accept; meta cgroup != 4096 ip saddr 8.8.8.8 ip protocol icmp counter name "test-icmp-input" } chain OUTPUT { type filter hook output priority filter; policy accept; meta cgroup != 4096 ip daddr 8.8.8.8 ip protocol icmp counter name "test-icmp-output" } } ```As previously, the cgroup
0x001000does not exist. The three outbound packets are the three ping packets, and they were successfully replied to.Quoted 8 lines · Martin Gignac
What is the complete output of 'nft list ruleset'?
Is it possible you have an earlier INPUT rule that matches and allows packets that match connection-tracking "established" state, such as:
chain INPUT { type filter hook input priority filter; policy drop; ct state established,related counter packets 391638047Quoted 34 lines
bytes 93651768866 accept
ct state invalid drop
[...]-Martin
Quoted 26 lines · Vladimir Nikishkin
Hello, everyone.
I have a weird problem!
This is my nft code:
``` nft add counter filter test-icmp-output nft add counter filter test-icmp-input nft add rule filter OUTPUT meta cgroup != 0x001000 ip daddr 8.8.8.8 ip protocol icmp counter name test-icmp-output nft add rule filter INPUT meta cgroup != 0x001000 ip saddr 8.8.8.8 ip protocol icmp counter name test-icmp-input ```Pinging 8.8.8.8 works. The packets are visible on tcpdump too. The cgroup id
0x001000does not exist, so every packet should match.Still, the output counter counts the expected number of packets, the second stays 0.
What am I doing wrong?
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)