Nftables v6 address not matched properly in nftable set

Nftables v6 address not matched properly in nftable set

[sontu mazumdar]

Hi Team,

I have nftables to only allow specific v6 traffic, but I see that v6
address is not exactly matched.

nftable version:
nftables v1.0.9 (Old Doc Yak #3)

I have created a custom chain filter and added a rule to match it
against the below set

nft add set inet filter_table set1 "{ type inet_proto . ipv6_addr;
flags interval ; counter; }"
nft add element inet filter_table set1 "{ ipv6-icmp . 10:0:3::10}"
nft add rule inet filter_table ip6_filter meta l4proto . ip6 saddr
@set1 jump accept_actions

I am sending traffic from 10:0:1::10 to 10:0:2::10, though my set
source address is 10:0:3::10 but still the rule element is getting hit
(verified via the counter command).
If I remove the "flags interval" from the set it works, but I need to
keep the "flags interval" because sometimes I want to configure a
range as well.

Couple of examples I tried with modifying the source address in my set:

10:0:1ff::10 (rule doesn't hit)

10:0:ff::10 (rule hit)

10:0:1::11 (doesn't hit)

Based on these tests (comparing with original source 10:0:1::10), it
looks like only the first 40 bits and last 80 bits are matched, the
middle 8 is kind of a wildcard.

Another data point is if the set contains a single ipv6_addr (no other
fields) it works fine.
Below is the sample config
nft add set inet filter_table set1 "{ type ipv6_addr; flags interval ;
counter; }"
nft add element inet filter_table set1 "{ 10:0:3::10 }"
nft add rule inet filter_table ip6_filter ip6 saddr @set1 jump accept_actions

Can someone please help here, I think this behaviour is not expected.

Regards,
Sontu

Re: Nftables v6 address not matched properly in nftable set

[Bradley Hook]

I'd first try using address ranges that are appropriate. It looks like
you are trying to adapt RFC1918 addresses (for IPv4) into IPv6
addresses. For RFC1918 equivalent addresses in IPv6, you probably want
RFC4193 addresses. You can use something like
https://unique-local-ipv6.com/ to generate your own prefix, that way
you are using address space that won't get unusual treatment by the IP
stack itself.

Second, when using intervals, I always specify an explicit mask. In
v6, that means a /128 mask for a single host. I tend to not use
intervals unless they fall on a CIDR boundary. That might not work for
your needs, but it makes the rules easier, and there's so much address
space available in IPv6 that you can usually use CIDR boundaries
without issue.

I don't know that either of these would change the behavior of your
examples, but they might make it easier to identify the problem.

Also, be careful about trying to apply IPv4 logic to IPv6 addresses.
One is in decimal, the other is in hex.

Respectfully,
~Bradley Hook, J.D.
Director, Information Systems
Google Certified Project Manager
Kansas State Schools for the Deaf and the Blind
bhook@kansasdeaf.gov
Mobile: 913-275-9982

-- 
*Kansas State Schools for the Deaf and the Blind Confidentiality Notice**:* 
 
The information contained in this e-mail transmission is confidential and 
legally protected.  It is intended for the sole use of the individual(s) 
entity named in the message header.  If you are not the intended recipient, 
you are hereby notified that any dissemination or copying of this 
information is strictly prohibited.  If you received this message in error, 
please notify the sender of the error and delete this message and any 
attachments.

Re: Nftables v6 address not matched properly in nftable set

[sontu mazumdar]

Thanks Bradley for your response.
I don't think the ipv6 addressing format is the issue here.

I just tried to put a rule on the destination address (I am using
google v6 address "2607:f8b0:400a:804::200e").

Below are the rules I configured in nftable:
nft add set inet filter_table set1 "{ type inet_proto . ipv6_addr;
flags interval ; counter; }"
nft add element inet filter_table set1 "{ tcp . 2607:f8b0:4000:804::200e/128}"
nft add rule inet filter_table ip6_filter meta l4proto . ip6 daddr
@set1 jump accept_actions

        set set1 {
                type inet_proto . ipv6_addr
                flags interval
                counter
                elements = { tcp . 2607:f8b0:4000:804::200e counter
packets 1 bytes 80 }
        }

When I do curl requests on the destination IP it is working (curl -6
-vvv https://[2607:f8b0:400a:804::200e]/ -k)
Although I put a strict 2607:f8b0:4000:804::200e/128 check, the 3rd
hextet 4000 is not matched against destination 400a, but surprisingly
it is matching the rule.

When I change the rule, removing the inet_proto option from the rule,
the traffic to 2607:f8b0:400a:804::200e is not passed, it is doing an
exact match in this case.

nft add set inet filter_table set1 "{ type ipv6_addr; flags interval ;
counter; }"
nft add element inet filter_table set1 "{ 2607:f8b0:4000:804::200e/128}"
nft add rule inet filter_table ip6_filter ip6 daddr @set1 jump accept_actions

Hence I feel somewhere the logic in nftable/netfilter is incorrect and
it looks like a bug.

Regards,
Sontu

On Thu, Apr 3, 2025 at 10:59 PM Bradley Hook <bhook@kansasdeaf.gov> wrote:
>
> I'd first try using address ranges that are appropriate. It looks like
> you are trying to adapt RFC1918 addresses (for IPv4) into IPv6
> addresses. For RFC1918 equivalent addresses in IPv6, you probably want
> RFC4193 addresses. You can use something like
> https://unique-local-ipv6.com/ to generate your own prefix, that way
> you are using address space that won't get unusual treatment by the IP
> stack itself.
>
> Second, when using intervals, I always specify an explicit mask. In
> v6, that means a /128 mask for a single host. I tend to not use
> intervals unless they fall on a CIDR boundary. That might not work for
> your needs, but it makes the rules easier, and there's so much address
> space available in IPv6 that you can usually use CIDR boundaries
> without issue.
>
> I don't know that either of these would change the behavior of your
> examples, but they might make it easier to identify the problem.
>
> Also, be careful about trying to apply IPv4 logic to IPv6 addresses.
> One is in decimal, the other is in hex.
>
> Respectfully,
> ~Bradley Hook, J.D.
> Director, Information Systems
> Google Certified Project Manager
> Kansas State Schools for the Deaf and the Blind
> bhook@kansasdeaf.gov
> Mobile: 913-275-9982
>
> --
> *Kansas State Schools for the Deaf and the Blind Confidentiality Notice**:*
>
> The information contained in this e-mail transmission is confidential and
> legally protected.  It is intended for the sole use of the individual(s)
> entity named in the message header.  If you are not the intended recipient,
> you are hereby notified that any dissemination or copying of this
> information is strictly prohibited.  If you received this message in error,
> please notify the sender of the error and delete this message and any
> attachments.

Re: Nftables v6 address not matched properly in nftable set

[Florian Westphal]

sontu mazumdar <sontu21@gmail.com> wrote:
> Hence I feel somewhere the logic in nftable/netfilter is incorrect and
> it looks like a bug.

This set type had many bugs, you need to tell us the kernel version you
are testing with.

Re: Nftables v6 address not matched properly in nftable set

[Florian Westphal]

Florian Westphal <fw@strlen.de> wrote:
> sontu mazumdar <sontu21@gmail.com> wrote:
> > Hence I feel somewhere the logic in nftable/netfilter is incorrect and
> > it looks like a bug.
> 
> This set type had many bugs, you need to tell us the kernel version you
> are testing with.

Looks like its a bug in the avx2 implementation, I'll send a patch
shortly and will place you on CC.  Thanks for reporting.

Re: Nftables v6 address not matched properly in nftable set

[sontu mazumdar]

Thanks Florian.

On Fri, Apr 4, 2025 at 8:52 AM Florian Westphal <fw@strlen.de> wrote:
>
> Florian Westphal <fw@strlen.de> wrote:
> > sontu mazumdar <sontu21@gmail.com> wrote:
> > > Hence I feel somewhere the logic in nftable/netfilter is incorrect and
> > > it looks like a bug.
> >
> > This set type had many bugs, you need to tell us the kernel version you
> > are testing with.
>
> Looks like its a bug in the avx2 implementation, I'll send a patch
> shortly and will place you on CC.  Thanks for reporting.