Using sets for protocols ?

Using sets for protocols ?

[J Doe]

Hi,

I am currently experimenting with nftables syntax and was wondering if there was a way to specify that a rule applies to *BOTH* TCP and UDP.

For instance, allowing DNS resolution:

add rule filter input tcp sport domain ct state established,related accept
add rule filter output tcp dport domain ct state new,established,related accept
add rule filter input udp sport domain ct state established,related accept
add rule filter output udp dport domain ct state new,established,related accept 

...requires four rules the way I have written it.

Is there a way to decrease this by specifying the rules apply to both TCP and UDP ?

I tried using a set:

add rule filter input { tcp, udp } sport domain ct state established,related accept
add rule filter output { tcp, udp } dport domain ct state new,established,related accept

...but the nft parser rejects this syntax.

I also tried leaving the protocol out to see if it would default to both:

add rule filter input sport domain ct state established,related accept
add rule filter output dport domain ct state new,established,related accept

...but the nft parser rejects this syntax as well.

Is there another way of writing this ?

Thanks,

- J

Re: Using sets for protocols ?

[Eric Leblond]

Hi,

On Tue, 2017-08-08 at 17:15 -0400, J Doe wrote:
> Hi,
> 
> I am currently experimenting with nftables syntax and was wondering
> if there was a way to specify that a rule applies to *BOTH* TCP and
> UDP.
> 
> For instance, allowing DNS resolution:
> 
> add rule filter input tcp sport domain ct state established,related
> accept
> add rule filter output tcp dport domain ct state
> new,established,related accept
> add rule filter input udp sport domain ct state established,related
> accept
> add rule filter output udp dport domain ct state
> new,established,related accept 
> 
> ...requires four rules the way I have written it.

Well, there is a series of mistakes here. First, usual way to write the
rules is to have one rule for established packets (that can also
include related)

  add rule filter input ct state established accept
  add rule filter output ct state established accept

This rule will take care of all replies and other packets. The only
thing you have to do after that is to accept packet that open a
exchange.

As you want to allow dns resolution, you need to open dns trafic:

  add rule filter output ct state new udp dport domain accept

Client don't use TCP often but you will indeed need a extra rule if
ever ou want to:

   add rule filter output ct state new tcp dport domain accept

> Is there a way to decrease this by specifying the rules apply to both
> TCP and UDP ?
> 
> I tried using a set:
> 
> add rule filter input { tcp, udp } sport domain ct state
> established,related accept
> add rule filter output { tcp, udp } dport domain ct state
> new,established,related accept
> 
> ...but the nft parser rejects this syntax.

Yes, it won't work because the expression 'tcp dport domain' is
translated as 'check tcp + at tcp offset get port and check it against
53'


++
-- 
Eric Leblond <eric@regit.org>
Blog: https://home.regit.org/

Re: Using sets for protocols ?

[J Doe]

Hi Eric and Noel,

> On Aug 8, 2017, at 8:11 PM, Eric Leblond <eric@regit.org> wrote:
> 
> Well, there is a series of mistakes here. First, usual way to write the
> rules is to have one rule for established packets (that can also
> include related)
> 
>  add rule filter input ct state established accept
>  add rule filter output ct state established accept
> 
> This rule will take care of all replies and other packets. The only
> thing you have to do after that is to accept packet that open a
> exchange.
> 
> As you want to allow dns resolution, you need to open dns trafic:
> 
>  add rule filter output ct state new udp dport domain accept
> 
> Client don't use TCP often but you will indeed need a extra rule if
> ever ou want to:
> 
>   add rule filter output ct state new tcp dport domain accept

Ok, thanks for the correction regarding style.

Out of curiosity - was the original syntax I specified logically incorrect (in the sense that there would be errors in my firewall ruleset), as well as being poor style ?

I want to follow the convention, I'm just wondering if the way I am forming rules can lead to errors as well.

Thanks,

- J