Matching metainformation cgroup fails on input, works on output.

Matching metainformation cgroup fails on input, works on output.

[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 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?

-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Matching metainformation cgroup fails on input, works on output.

[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 391638047
bytes 93651768866 accept
                ct state invalid drop
                [...]

-Martin


On Wed, Dec 8, 2021 at 4:39 AM Vladimir Nikishkin <lockywolf@gmail.com> wrote:
>
> 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?
>
> --
> Your sincerely,
> Vladimir Nikishkin (MiEr, lockywolf)
> (Laptop)

Re: Matching metainformation cgroup fails on input, works on output.

[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 0x001000 does not exist. The three outbound
packets are the three ping packets, and they were successfully replied
to.

Martin Gignac <martin.gignac@gmail.com> writes:

> 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 391638047
> bytes 93651768866 accept
>                 ct state invalid drop
>                 [...]
>
> -Martin
>
>
> On Wed, Dec 8, 2021 at 4:39 AM Vladimir Nikishkin <lockywolf@gmail.com> wrote:
>>
>> 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?
>>
>> --
>> Your sincerely,
>> Vladimir Nikishkin (MiEr, lockywolf)
>> (Laptop)


-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Matching metainformation cgroup fails on input, works on output.

[Martin Gignac]

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

On Wed, Dec 8, 2021 at 9:22 AM Vladimir Nikishkin <lockywolf@gmail.com> wrote:
>
> 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.
>
> Martin Gignac <martin.gignac@gmail.com> writes:
>
> > 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 391638047
> > bytes 93651768866 accept
> >                 ct state invalid drop
> >                 [...]
> >
> > -Martin
> >
> >
> > On Wed, Dec 8, 2021 at 4:39 AM Vladimir Nikishkin <lockywolf@gmail.com> wrote:
> >>
> >> 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?
> >>
> >> --
> >> Your sincerely,
> >> Vladimir Nikishkin (MiEr, lockywolf)
> >> (Laptop)
>
>
> --
> Your sincerely,
> Vladimir Nikishkin (MiEr, lockywolf)
> (Laptop)