nftables with ipset combined types

nftables with ipset combined types

[Brian Allen Vanderburg II]

I use ipset for my setup to simplify certain iptables rules. I have
rules to allow trusted networks and trusted services using two different
sets.  The services set is a hash:net,port set, and the network set its
a hash:net,iface set.  Is it planned to have sets that can contain
multiple value entries in nftables?  Also, as some of my interfaces are
dynamic, would such sets support interface names instead of indexes? 
Something like { (10.10.1.0/24,"eth0"), (10.20.1.0/24,"tap0") }?  Or if
not, is there a way to use the existing ipset utility with nftables?

# Allow access to all services for traffic to/from certain networks on
specific interfaces
iptables -A INPUT -m set --match-set networks src,src -j ACCEPT
iptables -A OUTPUT -m set --match-set networks dst,dst -j ACCEPT

# Allow access to specific services from certain networks
iptables -A INPUT -m set --match-set services dst,src -j ACCEPT
iptables -A OUTPUT -m set --match-set services src,dst -j ACCEPT

# Perhaps translated to nft as
nft filter input ip saddr + iifname @networks accept
nft filter output ip daddr + oifname @networks accept

nft filter input ip saddr + dport @services accept
nft filter output ip daddr + sport @services accept

I have seem that this might be possible with maps, but one feature of a
set over a map that I like seems to be I'd only have to add the matching
information to the set, while the action such as accept, drop, or jump
is not part of the set but is hard-coded in the added rule.

Brian Vanderburg II

Re: nftables with ipset combined types

[Pablo Neira Ayuso]

On Wed, Jan 29, 2014 at 02:27:50AM -0500, Brian Allen Vanderburg II wrote:
> I use ipset for my setup to simplify certain iptables rules. I have
> rules to allow trusted networks and trusted services using two different
> sets.  The services set is a hash:net,port set, and the network set its
> a hash:net,iface set.  Is it planned to have sets that can contain
> multiple value entries in nftables?

Yes, some bits are missing in the kernel, we'll have support for
multi-dimensional keys in sets at some point.

Re: nftables with ipset combined types

[Patrick Schaaf]

Hi Pablo,

another useful feature of ipset is that the same set is usable in the
filter, nat, and mangle tables.

If I'm not mistaken, sets in nftables are right now scoped within a table,
so I could not reuse them in that fashion.

Am I mistaken? Or, is that another thing on the invisible roadmap? :)

best regards
  Patrick

Re: nftables with ipset combined types

[Arturo Borrero Gonzalez]

On 29 January 2014 12:34, Patrick Schaaf <netdev@bof.de> wrote:
>
> If I'm not mistaken, sets in nftables are right now scoped within a table,
> so I could not reuse them in that fashion.
>

AFAIK, by now this is true.

-- 
Arturo Borrero González
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nftables with ipset combined types

[Pablo Neira Ayuso]

On Wed, Jan 29, 2014 at 12:34:12PM +0100, Patrick Schaaf wrote:
> Hi Pablo,
> 
> another useful feature of ipset is that the same set is usable in the
> filter, nat, and mangle tables.
> 
> If I'm not mistaken, sets in nftables are right now scoped within a table,
> so I could not reuse them in that fashion.

The table <-> set link is currently needed to check for loops if
verdict maps are used. But AFAICS, for sets with no verdict maps using
jump to chain, this limitation could be removed. I'll add this to my
TODO list.

Re: nftables with ipset combined types

[Patrick McHardy]

On 2. Februar 2014 23:57:34 GMT+00:00, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>On Wed, Jan 29, 2014 at 12:34:12PM +0100, Patrick Schaaf wrote:
>> Hi Pablo,
>> 
>> another useful feature of ipset is that the same set is usable in the
>> filter, nat, and mangle tables.
>> 
>> If I'm not mistaken, sets in nftables are right now scoped within a
>table,
>> so I could not reuse them in that fashion.
>
>The table <-> set link is currently needed to check for loops if
>verdict maps are used. But AFAICS, for sets with no verdict maps using
>jump to chain, this limitation could be removed. I'll add this to my
>TODO list.

While this might be useful, I don't think it justifies more than minor code changes since the user can just as well only use a single table.

Regarding TODO lists, I think it would be good to put the bigger items in the nftables TODO list. I'll start by cleaning it up and adding my current items.