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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
> 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.
