nft named set address types

nft named set address types

[Matt Zagrabelny]

Hello,

I'd like to use the "inet" address family in a named set. I see nft
supports the following address families [AF] (among others):

       ip       IPv4 address family.

       ip6      IPv6 address family.

       inet     Internet (IPv4/IPv6) address
                family.

However, looking at the named sets, I do not see the "inet" AF:

type  string: ipv4_addr, ipv6_addr, ether_addr, inet_proto, inet_service, mark

Are there plans to add "inet_addr" AF to the types of named sets?

I wouldn't mind using the symbolic variables (define variable = expr)
to achieve a combined ipv4, ipv6 set, but from the docs the variable
doesn't appear to be global in scope - unless they are defined at a
top level.

"""
Symbolic variables can be defined using the define statement. Variable
references are
expressions and can be used to initialize other variables. The scope
of a definition is the
current block and all blocks contained within.
"""

Any feedback about combined ipv4 and ipv6 address families in named
sets? or why an inet family does not exist for named sets?

Thanks for the help!

-m

Re: nft named set address types

[Matt Zagrabelny]

Replying to myself...

On Mon, Nov 1, 2021 at 3:46 PM Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
>
> Hello,
>
> I'd like to use the "inet" address family in a named set. I see nft
> supports the following address families [AF] (among others):
>
>        ip       IPv4 address family.
>
>        ip6      IPv6 address family.
>
>        inet     Internet (IPv4/IPv6) address
>                 family.


I'm not sure nftables even would allow an "inet" to be used in a rule such as:

table inet filter {
    chain input {
        inet saddr { 127.0.0.1, ::1 } tcp dport 22 accept
    }
}

Instead, it seems I must do:

table inet filter {
    chain input {
        ip saddr 127.0.0.1 tcp dport 22 accept
        ip6 saddr ::1 tcp dport 22 accept
    }
}

Why does inet not work in the way I am expecting it to?

Thanks for any answers!

-m

Re: nft named set address types

[Pablo Neira Ayuso]

On Tue, Nov 02, 2021 at 02:39:33PM -0500, Matt Zagrabelny wrote:
> Replying to myself...
> 
> On Mon, Nov 1, 2021 at 3:46 PM Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> >
> > Hello,
> >
> > I'd like to use the "inet" address family in a named set. I see nft
> > supports the following address families [AF] (among others):
> >
> >        ip       IPv4 address family.
> >
> >        ip6      IPv6 address family.
> >
> >        inet     Internet (IPv4/IPv6) address
> >                 family.
> 
> 
> I'm not sure nftables even would allow an "inet" to be used in a rule such as:
> 
> table inet filter {
>     chain input {
>         inet saddr { 127.0.0.1, ::1 } tcp dport 22 accept
>     }
> }
> 
> Instead, it seems I must do:
> 
> table inet filter {
>     chain input {

there is no chain definition here, this chain sees no traffic.

          type filter hook input priority filter; policy drop;

is missing.

>         ip saddr 127.0.0.1 tcp dport 22 accept
>         ip6 saddr ::1 tcp dport 22 accept

Better split your ruleset in a tree using verdict maps:

table inet filter {
    chain input_ip4 {
        ip saddr 127.0.0.1 accept
    }

    chain input_ip6 {
        ip6 saddr ::1 accept
    }

    chain input {
        type filter hook input priority filter; policy drop;
        ct state vmap { established : accept, related : accept, invalid : drop }
        # implicit match on 'ct state new,untracked'
        tcp dport 22 meta protocol vmap { ip : jump input_ip4, ip6 : jump input_ip6 }
    }
}

Re: nft named set address types

[Matt Zagrabelny]

Hey Pablo!

On Tue, Nov 2, 2021 at 3:23 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> On Tue, Nov 02, 2021 at 02:39:33PM -0500, Matt Zagrabelny wrote:
> > Replying to myself...
> >
> > On Mon, Nov 1, 2021 at 3:46 PM Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> > >
> > > Hello,
> > >
> > > I'd like to use the "inet" address family in a named set. I see nft
> > > supports the following address families [AF] (among others):
> > >
> > >        ip       IPv4 address family.
> > >
> > >        ip6      IPv6 address family.
> > >
> > >        inet     Internet (IPv4/IPv6) address
> > >                 family.
> >
> >
> > I'm not sure nftables even would allow an "inet" to be used in a rule such as:
> >
> > table inet filter {
> >     chain input {
> >         inet saddr { 127.0.0.1, ::1 } tcp dport 22 accept
> >     }
> > }
> >
> > Instead, it seems I must do:
> >
> > table inet filter {
> >     chain input {
>
> there is no chain definition here, this chain sees no traffic.

I've got it defined in a different include file:

table inet filter {
    chain input {
        type filter hook input \
        priority 0;
        policy drop;
    }
    chain forward {
        type filter hook forward \
        priority 0;
        policy drop;
    }
    chain output {
        type filter hook output \
        priority 0;
        policy accept;
    }
}


>
>           type filter hook input priority filter; policy drop;
>
> is missing.
>
> >         ip saddr 127.0.0.1 tcp dport 22 accept
> >         ip6 saddr ::1 tcp dport 22 accept
>
> Better split your ruleset in a tree using verdict maps:
>
> table inet filter {
>     chain input_ip4 {
>         ip saddr 127.0.0.1 accept
>     }
>
>     chain input_ip6 {
>         ip6 saddr ::1 accept
>     }
>
>     chain input {
>         type filter hook input priority filter; policy drop;
>         ct state vmap { established : accept, related : accept, invalid : drop }
>         # implicit match on 'ct state new,untracked'
>         tcp dport 22 meta protocol vmap { ip : jump input_ip4, ip6 : jump input_ip6 }
>     }
> }

That's cool about the verdict maps. I'll have to read up on those.

Though, I still feel like I should be able to say:

chain input {
    inet saddr {127.0.0.1, ::1} accept
}

Anyhow. It seems that is currently an impossibility.

Thanks for the reply and the info about verdict maps.

I appreciate it!

-m

Re: nft named set address types

[Matt Zagrabelny]

Hello Pablo and others,

I'm attempting to have a similar ICMP{4,6} ruleset as I have for TCP -
thanks Pablo for the vmap hint.

On Tue, Nov 2, 2021 at 3:23 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> Better split your ruleset in a tree using verdict maps:
>
> table inet filter {
>     chain input_ip4 {
>         ip saddr 127.0.0.1 accept
>     }
>
>     chain input_ip6 {
>         ip6 saddr ::1 accept
>     }
>
>     chain input {
>         type filter hook input priority filter; policy drop;
>         ct state vmap { established : accept, related : accept, invalid : drop }
>         # implicit match on 'ct state new,untracked'
>         tcp dport 22 meta protocol vmap { ip : jump input_ip4, ip6 : jump input_ip6 }
>     }
> }

I see there is an icmpx for reject packets. Is there something
equivalent for destination packets?

I've tried:

table inet filter {
    chain icmp_ipv4 {
        ip  saddr $icmp_networks_ipv4 accept
    }

    chain icmp_ipv6 {
        ip6 saddr $icmp_networks_ipv6 accept
    }

    chain input {
        meta protocol {icmp, icmpv6} vmap {
            icmp: jump icmp_ipv4,
            icmpv6: jump icmp_ipv6,
        }
    }
}

Nov 15 11:39:05 watchtower nft[3709857]: In file included from
/etc/nftables.conf.d/100-include.nft:5:1-48:
Nov 15 11:39:05 watchtower nft[3709857]:                  from
/etc/nftables.conf:3:1-37:
Nov 15 11:39:05 watchtower nft[3709857]:
/etc/nftables.conf.d/600-host.d/100-icmp.nft:11:38-41: Error: syntax
error, unexpected vmap, expecting newline or semicolon
Nov 15 11:39:05 watchtower nft[3709857]:         meta protocol {icmp,
icmpv6} vmap {

Is there no vmap for icmp?

Thanks for any help or hints!

-m

Re: nft named set address types

[Eugene Crosser]

[-- Attachment #1.1: Type: text/plain, Size: 865 bytes --]

On 15/11/2021 18:40, Matt Zagrabelny wrote:

> I've tried:
> 
> table inet filter {
>     chain icmp_ipv4 {
>         ip  saddr $icmp_networks_ipv4 accept
>     }
> 
>     chain icmp_ipv6 {
>         ip6 saddr $icmp_networks_ipv6 accept
>     }
> 
>     chain input {
>         meta protocol {icmp, icmpv6} vmap {
>             icmp: jump icmp_ipv4,
>             icmpv6: jump icmp_ipv6,
>         }
>     }
> }

This is simply incorrect syntax. You need it like this, I believe:

    <value> `vmap` {map with verdicts}

e.g.

table inet testfilter {

    chain icmp_ipv4 {

        accept

    }



    chain icmp_ipv6 {

        accept

    }

    chain input {

        meta protocol vmap {

            icmp: jump icmp_ipv4,

            icmpv6: jump icmp_ipv6,

        }

    }

}

Regards,

Eugene

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: nft named set address types

[Kerin Millar]

On Mon, 15 Nov 2021 11:40:43 -0600
Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:

> I see there is an icmpx for reject packets. Is there something
> equivalent for destination packets?
> 
> I've tried:
> 
> table inet filter {
>     chain icmp_ipv4 {
>         ip  saddr $icmp_networks_ipv4 accept
>     }
> 
>     chain icmp_ipv6 {
>         ip6 saddr $icmp_networks_ipv6 accept
>     }
> 
>     chain input {
>         meta protocol {icmp, icmpv6} vmap {
>             icmp: jump icmp_ipv4,
>             icmpv6: jump icmp_ipv6,
>         }
>     }
> }

This is definitely nonsensical syntax. Try "meta protocol vmap" instead.

-- 
Kerin Millar

Re: nft named set address types

[Pablo Neira Ayuso]

On Mon, Nov 15, 2021 at 11:40:43AM -0600, Matt Zagrabelny wrote:
> Hello Pablo and others,
> 
> I'm attempting to have a similar ICMP{4,6} ruleset as I have for TCP -
> thanks Pablo for the vmap hint.
> 
> On Tue, Nov 2, 2021 at 3:23 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 
> > Better split your ruleset in a tree using verdict maps:
> >
> > table inet filter {
> >     chain input_ip4 {
> >         ip saddr 127.0.0.1 accept
> >     }
> >
> >     chain input_ip6 {
> >         ip6 saddr ::1 accept
> >     }
> >
> >     chain input {
> >         type filter hook input priority filter; policy drop;
> >         ct state vmap { established : accept, related : accept, invalid : drop }
> >         # implicit match on 'ct state new,untracked'
> >         tcp dport 22 meta protocol vmap { ip : jump input_ip4, ip6 : jump input_ip6 }
> >     }
> > }
> 
> I see there is an icmpx for reject packets. Is there something
> equivalent for destination packets?
> 
> I've tried:
> 
> table inet filter {
>     chain icmp_ipv4 {
>         ip  saddr $icmp_networks_ipv4 accept
>     }
> 
>     chain icmp_ipv6 {
>         ip6 saddr $icmp_networks_ipv6 accept
>     }
> 
>     chain input {
>         meta protocol {icmp, icmpv6} vmap {
>             icmp: jump icmp_ipv4,
>             icmpv6: jump icmp_ipv6,
>         }
>     }
> }
> 
> Nov 15 11:39:05 watchtower nft[3709857]: In file included from
> /etc/nftables.conf.d/100-include.nft:5:1-48:
> Nov 15 11:39:05 watchtower nft[3709857]:                  from
> /etc/nftables.conf:3:1-37:
> Nov 15 11:39:05 watchtower nft[3709857]:
> /etc/nftables.conf.d/600-host.d/100-icmp.nft:11:38-41: Error: syntax
> error, unexpected vmap, expecting newline or semicolon
> Nov 15 11:39:05 watchtower nft[3709857]:         meta protocol {icmp,
> icmpv6} vmap {
> 
> Is there no vmap for icmp?

instead of:

         meta protocol {icmp, icmpv6} vmap {
             icmp: jump icmp_ipv4,
             icmpv6: jump icmp_ipv6,
         }

this should be:

         meta protocol vmap {
             icmp: jump icmp_ipv4,
             icmpv6: jump icmp_ipv6,
         }

Re: nft named set address types

[Pablo Neira Ayuso]

On Mon, Nov 15, 2021 at 08:47:10PM +0100, Pablo Neira Ayuso wrote:
> On Mon, Nov 15, 2021 at 11:40:43AM -0600, Matt Zagrabelny wrote:
[...]
> > Is there no vmap for icmp?
> 
> instead of:
> 
>          meta protocol {icmp, icmpv6} vmap {
>              icmp: jump icmp_ipv4,
>              icmpv6: jump icmp_ipv6,
>          }
> 
> this should be:
> 
>          meta protocol vmap {
>              icmp: jump icmp_ipv4,
>              icmpv6: jump icmp_ipv6,
>          }

Wrong selector actually:

# nft describe meta protocol
meta expression, datatype ether_type (Ethernet protocol) (basetype integer), 16 bits

pre-defined symbolic constants (in hexadecimal):
        ip                              0x0800
        arp                             0x0806
        ip6                             0x86dd
        8021q                           0x8100
        8021ad                          0x88a8
        vlan                            0x8100

you should used meta l4proto instead

# nft describe meta l4proto
meta expression, datatype inet_proto (Internet protocol) (basetype integer), 8 bits
        ip                              0
        icmp                            1
        igmp                            2
        ggp                             3
        ipencap                         4
        st                              5
        tcp                             6
        ...

Therefore:

          meta l4proto vmap {
              icmp: jump icmp_ipv4,
              icmpv6: jump icmp_ipv6,
          }

Careful with this idiom, because it might not do what you want.

If you do not previously classify traffic at layer 3, then depending
on your ruleset, this might allow for packet crafting such as
IPv4/ICMPv6 and IPv6/ICMPv4.

Re: nft named set address types

[Matt Zagrabelny]

Hey Pablo and others...

On Mon, Nov 15, 2021 at 8:22 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> On Mon, Nov 15, 2021 at 08:47:10PM +0100, Pablo Neira Ayuso wrote:
> > On Mon, Nov 15, 2021 at 11:40:43AM -0600, Matt Zagrabelny wrote:
> [...]
> > > Is there no vmap for icmp?
> >
> > instead of:
> >
> >          meta protocol {icmp, icmpv6} vmap {
> >              icmp: jump icmp_ipv4,
> >              icmpv6: jump icmp_ipv6,
> >          }
> >
> > this should be:
> >
> >          meta protocol vmap {
> >              icmp: jump icmp_ipv4,
> >              icmpv6: jump icmp_ipv6,
> >          }
>
> Wrong selector actually:


Ha. Yup. I'm just discovering this as you sent your email. I was going
to reply with a few questions. So your reply was well timed.


> # nft describe meta protocol
> meta expression, datatype ether_type (Ethernet protocol) (basetype integer), 16 bits
>
> pre-defined symbolic constants (in hexadecimal):
>         ip                              0x0800
>         arp                             0x0806
>         ip6                             0x86dd
>         8021q                           0x8100
>         8021ad                          0x88a8
>         vlan                            0x8100
>
> you should used meta l4proto instead
>
> # nft describe meta l4proto
> meta expression, datatype inet_proto (Internet protocol) (basetype integer), 8 bits
>         ip                              0
>         icmp                            1
>         igmp                            2
>         ggp                             3
>         ipencap                         4
>         st                              5
>         tcp                             6
>         ...
>
> Therefore:
>
>           meta l4proto vmap {
>               icmp: jump icmp_ipv4,
>               icmpv6: jump icmp_ipv6,
>           }

Agreed. This is working better than the previous vmap.

I search for "nftables icmp" on the interwebs and found these rules:

        meta nfproto ipv4 icmp type { echo-request } counter accept
        meta nfproto ipv6 icmpv6 type echo-request counter accept

Not sure how they compare to the above "meta l4proto..." commands.


> Careful with this idiom, because it might not do what you want.

Alright... Currently it looks like it is doing what I want.

>
> If you do not previously classify traffic at layer 3,

How do you classify traffic at layer 3? Is that a manual configuration?

then depending
> on your ruleset, this might allow for packet crafting such as
> IPv4/ICMPv6 and IPv6/ICMPv4.

Hmmm... Are there any (potential) security problems with cross
version/protocol packets?

Thanks for the help and the words of caution.

Cheers,

-m

Re: nft named set address types

[Pablo Neira Ayuso]

On Mon, Nov 15, 2021 at 08:55:19PM -0600, Matt Zagrabelny wrote:
> Hey Pablo and others...
> 
> On Mon, Nov 15, 2021 at 8:22 PM Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >
> > On Mon, Nov 15, 2021 at 08:47:10PM +0100, Pablo Neira Ayuso wrote:
> > > On Mon, Nov 15, 2021 at 11:40:43AM -0600, Matt Zagrabelny wrote:
> > [...]
> > > > Is there no vmap for icmp?
> > >
> > > instead of:
> > >
> > >          meta protocol {icmp, icmpv6} vmap {
> > >              icmp: jump icmp_ipv4,
> > >              icmpv6: jump icmp_ipv6,
> > >          }
> > >
> > > this should be:
> > >
> > >          meta protocol vmap {
> > >              icmp: jump icmp_ipv4,
> > >              icmpv6: jump icmp_ipv6,
> > >          }
> >
> > Wrong selector actually:
> 
> 
> Ha. Yup. I'm just discovering this as you sent your email. I was going
> to reply with a few questions. So your reply was well timed.
> 
> 
> > # nft describe meta protocol
> > meta expression, datatype ether_type (Ethernet protocol) (basetype integer), 16 bits
> >
> > pre-defined symbolic constants (in hexadecimal):
> >         ip                              0x0800
> >         arp                             0x0806
> >         ip6                             0x86dd
> >         8021q                           0x8100
> >         8021ad                          0x88a8
> >         vlan                            0x8100
> >
> > you should used meta l4proto instead
> >
> > # nft describe meta l4proto
> > meta expression, datatype inet_proto (Internet protocol) (basetype integer), 8 bits
> >         ip                              0
> >         icmp                            1
> >         igmp                            2
> >         ggp                             3
> >         ipencap                         4
> >         st                              5
> >         tcp                             6
> >         ...
> >
> > Therefore:
> >
> >           meta l4proto vmap {
> >               icmp: jump icmp_ipv4,
> >               icmpv6: jump icmp_ipv6,
> >           }
> 
> Agreed. This is working better than the previous vmap.
> 
> I search for "nftables icmp" on the interwebs and found these rules:
> 
>         meta nfproto ipv4 icmp type { echo-request } counter accept
>         meta nfproto ipv6 icmpv6 type echo-request counter accept

The following is just fine:

        icmp type echo-request counter accept
        icmpv6 type echo-request counter accept

but the problem is that you will end up with an IPv4 rule and an IPv6
rule, that's why I suggest you to split the IP-dependent part into
chains, ie.

        meta protocol vmap { ip : jump ipv4_input, ip6 : ipv6_input }

Please, have a look at the nft manpage and wiki.

Re: nft named set address types

[Florian Westphal]

Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
> I'd like to use the "inet" address family in a named set. I see nft
> supports the following address families [AF] (among others):
> 
>        ip       IPv4 address family.
> 
>        ip6      IPv6 address family.
> 
>        inet     Internet (IPv4/IPv6) address
>                 family.
> 
> However, looking at the named sets, I do not see the "inet" AF:
> 
> type  string: ipv4_addr, ipv6_addr, ether_addr, inet_proto, inet_service, mark
> 
> Are there plans to add "inet_addr" AF to the types of named sets?

No.

> Any feedback about combined ipv4 and ipv6 address families in named
> sets? or why an inet family does not exist for named sets?

There is no ip family either, only data types, and all must have a fixed
length.

nft describe ip saddr