Conntrack translation to nft

One more translation for the conntrack expression.

extensions: libxt_conntrack: Add translation to nft

This patch raises an issue with the inverted list of bitwise values. The syntax parser of nft returns an error when an inverted list of conntrack states are passed to nft.

 $ nft add rule ip filter INPUT ct state != new,related counter accept
 <cmdline>:1:41-41: Error: syntax error, unexpected comma, expecting end of file or newline or semicolon
 add rule ip filter INPUT ct state != new,related counter accept
                                         ^

After several days working of this issue I sent a patch to make it work, but it seems that the byte code regenerated is not correct.

 nft --debug=netlink add rule ip filter INPUT ct state != new,related,established,untracked counter accept
 ip filter INPUT
   [ ct load state => reg 1 ]
   [ cmp neq reg 1 0x0000004e ]
   [ counter pkts 0 bytes 0 ]
   [ immediate reg 0 accept ]

It should be something like:

 nft --debug=netlink add rule ip filter INPUT ct state new,related,established,untracked
 ip filter INPUT
   [ ct load state => reg 1 ]
   [ bitwise reg 1 = (reg=1 & 0x0000004e ) ^ 0x00000000 ]
   [ cmp eq reg 1 0x00000000 ]

I’ll be working further on this issue. To be continued…

 

 

Translation phase passed

The iptables to nftables translation patches released until now are the following:

extensions: libxt_ipcomp: Add translation to nft

extensions: libip6t_hbh: Add translation to nft

extensions: libxt_multiport: Add translation to nft

extensions: libxt_dscp: Add translation to nft

extensions: libip6t_frag: Add translation to nft

extensions: libxt_cgroup: Add translation to nft

And some other documentation fixes in the nftables package:

doc: fix compression parameter index

doc: fix old parameters and update datatypes

doc: Update datatypes

 

Sets and ranges of numbers in nftables

One of the things that I learned during my work translating the iptables multiport match to the native port handling interface of nft is that the port range syntax and sets are different.

So, for example, a port range approach in iptables could be:

$ sudo iptables-translate -t filter -A INPUT -p tcp -m multiport --dports 80:88 -j ACCEPT

the translation to nft is:

nft add rule ip filter INPUT ip protocol tcp tcp dport 80-88 counter accept

Or

nft add rule ip filter INPUT ip protocol tcp tcp dport { 80-88} counter accept

But, by design, they mean a very different thing. The first nft approach shows a simple port range but the second one created a set with one element which is a port range in it.

In reality, both works but the first one would fit better for just one port range structure.