Fwd: Re: How to port "-m multiport ! --sports 80,443" to nftables?

[Florian Westphal <fw@xxxxxxxxx>]

Hi.

I proposed following change a while back but got no replies,
I realized only now that I forgot to CC nf-devel.

So, re-posting this.

Context is this:

> add rule ip raw-set peerblock ip daddr @some_set tcp dport vmap { 80:accept, 443:accept } counter drop
> 
> Which in mind would be: allow 80 and 443, and block the rest. 
> But that actually doesn't work, I mean it doesn't block the rest.
> 
> Also, does "counter" work with vmap because I see "0" all the time?

Right, it doesn't work because in case no result is found 'lookup
expression' sets 'break' in the verdict register.

Pablo/others, I would propose following change, which i think is
backwards compatible:

+++ b/net/netfilter/nft_lookup.c
@@ -37,15 +37,19 @@ void nft_lookup_eval(const struct nft_expr *expr,
 
        found = set->ops->lookup(nft_net(pkt), set, &regs->data[priv->sreg],
                                 &ext) ^ priv->invert;
-       if (!found) {
-               regs->verdict.code = NFT_BREAK;
-               return;
-       }
 
-       if (set->flags & NFT_SET_MAP)
+       if (set->flags & NFT_SET_MAP) {
+               if (!found) {
+                       if (priv->dreg != NFT_REG_VERDICT)
+                               regs->verdict.code = NFT_BREAK;
+                       return;
+               }
+
                nft_data_copy(&regs->data[priv->dreg],
                              nft_set_ext_data(ext), set->dlen);
-
+       } else if (!found) {
+               regs->verdict.code = NFT_BREAK;
+       }
 }

This makes following rule work:
tcp dport vmap { 80:accept, 443:accept } counter drop

(if 80/443, we leave via nft_data_copy, so evaluation of ruleset
 terminates with verdict, if no result, we do not set NFT_BREAK
 anymore, so we continue to evaluate remaining expressions (counter, drop).

With jumps to user defined chains this scheme should work as well,
as we would continue after the rule if we had a match.

If the set doesn't contain verdicts (but e.g. nfmarks), then priv->dreg
can't be NFT_REG_VERDICT.

If you agree, I will make a formal submission.