Bug 1576426

This issue is consistent with upstream.

Note that I don't consider this as a bug per se, the only deficit is that nft tool doesn't catch the situation when adding the set itself. My point is that concatenated types are probably not quite useful in interval sets. I didn't test this, but from my understanding of how intervals work, I'd say that an element:

| 10.0.0.1 . 22 - 10.0.0.1 - 25

Would match on address 10.0.0.1 and any port in range 22 - 25, just as one would expect. Though an element:

| 10.0.0.1 . 22 - 10.0.0.2 . 22

Would match on address 10.0.0.1 and any port in range 22 - 65535 as well as address 10.0.0.2 and any port in range 0 - 22.

Patch adding a proper error message submitted upstream:

https://marc.info/?l=netfilter-devel&m=152828412409274&w=2

Upstream accepted:

commit 9a3d80172a61e89c2862bcf41cb58313c236b308 (origin/master, origin/HEAD)
Author: Phil Sutter <phil>
Date:   Wed Jun 6 13:21:49 2018 +0200

    evaluate: explicitly deny concatenated types in interval sets
    
    Previously, this triggered a program abort:
    
    | # nft add table ip t
    | # nft add set ip t my_set '{ type ipv4_addr . inet_service ; flags interval ; }'
    | # nft add element ip t my_set '{10.0.0.1 . tcp }'
    | BUG: invalid range expression type concat
    | nft: expression.c:1085: range_expr_value_low: Assertion `0' failed.
    
    With this patch in place, the 'add set' command above gives an error
    message:
    
    | # nft add set ip t my_set3 '{ type ipv4_addr . inet_service ; flags interval ; }'
    | Error: concatenated types not supported in interval sets
    | add set ip t my_set3 { type ipv4_addr . inet_service ; flags interval ; }
    |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    Signed-off-by: Phil Sutter <phil>
    Signed-off-by: Florian Westphal <fw>

(In reply to Phil Sutter from comment #3)
> Note that I don't consider this as a bug per se, the only deficit is that
> nft tool doesn't catch the situation when adding the set itself. My point is
> that concatenated types are probably not quite useful in interval sets. I
> didn't test this, but from my understanding of how intervals work, I'd say

I was attempting to find an equivalent to ipset's hash:net,port. Is there an alternative method?

Hi Eric,

(In reply to Eric Garver from comment #5)
> (In reply to Phil Sutter from comment #3)
> > Note that I don't consider this as a bug per se, the only deficit is that
> > nft tool doesn't catch the situation when adding the set itself. My point is
> > that concatenated types are probably not quite useful in interval sets. I
> > didn't test this, but from my understanding of how intervals work, I'd say
> 
> I was attempting to find an equivalent to ipset's hash:net,port. Is there an
> alternative method?

As discussed at NFWS, nftables' support for prefixes in sets is not optimal to begin with. A clean solution also requires kernel support, so I consider this ticket resolved with the explicit error message mentioned above. Support for prefixes in concatenated data types is probably something for RHEL8, anyway.

Regarding alternatives:

A "simple" one would be to have the prefix in a verdict map where each entry points to a custom chain which then contains a rule matching the port. Ugly, but may do the trick.

Another one would be to convert the prefix into a list of IP addresses and insert them combined with given port into a set of type 'ipv4_addr . inet_service'. Obviously this works with small subnets only.

(In reply to Phil Sutter from comment #7)
> Hi Eric,
> 
> (In reply to Eric Garver from comment #5)
> > (In reply to Phil Sutter from comment #3)
> > > Note that I don't consider this as a bug per se, the only deficit is that
> > > nft tool doesn't catch the situation when adding the set itself. My point is
> > > that concatenated types are probably not quite useful in interval sets. I
> > > didn't test this, but from my understanding of how intervals work, I'd say
> > 
> > I was attempting to find an equivalent to ipset's hash:net,port. Is there an
> > alternative method?
> 
> As discussed at NFWS, nftables' support for prefixes in sets is not optimal
> to begin with. A clean solution also requires kernel support, so I consider
> this ticket resolved with the explicit error message mentioned above.
> Support for prefixes in concatenated data types is probably something for
> RHEL8, anyway.
> 
> Regarding alternatives:
> 
> A "simple" one would be to have the prefix in a verdict map where each entry
> points to a custom chain which then contains a rule matching the port. Ugly,
> but may do the trick.

Thanks. I think it's okay to just wait on native support as you mention above.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3154