uif.pl: Add more meta l4proto labels to various nft rules

[sunweaver]

No description provided.

[sunweaver]

@dzatoah Please review. Thanks.

[dzatoah]

For icmp(all), UIF would emit:

meta l4proto icmp icmp

This doesn't look good, if we look at the docs: https://man.archlinux.org/man/nft.8#ICMP_TYPE_TYPE

Likewise, ipv6-icmp(all):
meta l4proto ipv6-icmp ipv6-icmp

The all cases must not emit a trailing icmp or icmpv6 expression.

[dzatoah]

You can use nft --check btw, also I suggest following test cases:

Service expression	Expected nft match
icmp(all)	meta l4proto icmp
negated icmp(all)	meta l4proto != icmp
ipv6-icmp(all)	meta l4proto ipv6-icmp
negated ipv6-icmp(all)	meta l4proto != ipv6-icmp
icmp(echo-request)	meta l4proto icmp icmp type echo-request
negated icmp(echo-request)	meta l4proto != icmp icmp type echo-request
ipv6-icmp(echo-request)	meta l4proto ipv6-icmp icmpv6 type echo-request
negated ipv6-icmp(echo-request)	meta l4proto != ipv6-icmp icmpv6 type echo-request

[sunweaver]

@dzatoah Please revisit! Thanks!

[dzatoah]

The negated ICMP cases still generate invalid or contradictory nft expressions:

• Negated icmp(all) produces meta l4proto ! icmp; nft comparison syntax requires meta l4proto != icmp.
• Negated icmp(echo-request) produces meta l4proto ! icmp icmp type echo-request. For the existing UIF semantics, this should keep the protocol match positive and negate the type instead: meta l4proto icmp icmp type != echo-request.
• The same applies to ipv6-icmp(all) and typed ipv6-icmp(...) expressions.

Could you move the negation to the relevant comparison: meta l4proto != ... for all, and icmp type != ... / icmpv6 type != ... for typed ICMP rules?

[dzatoah]

  icmp4.run1.nft:54:27-38: Error: negation can only be used with singleton bitmask values
  add rule ip filter INPUT  meta l4proto ! icmp counter accept
                            ^^^^^^^^^^^^   ~~~~
  icmp4.run1.nft:55:27-38: Error: negation can only be used with singleton bitmask values
  add rule ip filter INPUT  meta l4proto ! icmp icmp type echo-request counter accept
                            ^^^^^^^^^^^^   ~~~~

  icmp6.run1.nft:54:28-39: Error: negation can only be used with singleton bitmask values
  add rule ip6 filter INPUT  meta l4proto ! ipv6-icmp counter accept
                             ^^^^^^^^^^^^   ~~~~~~~~~
  icmp6.run1.nft:55:28-39: Error: negation can only be used with singleton bitmask values
  add rule ip6 filter INPUT  meta l4proto ! ipv6-icmp icmpv6 type echo-request counter accept

uif-evidence-pr5.txt

[sunweaver]

@dzatoah please revisit

[dzatoah]

Positive and negated ICMP rules now generate the same predicate because $icmp_not is set to != in both branches.

For example, positive icmp(all) generates:

meta l4proto != icmp

That is valid nft syntax, but it matches non-ICMP traffic instead of ICMP. The IPv6 case has the same problem.

Typed negation still applies != to the protocol instead of the type:

meta l4proto != icmp icmp type echo-request

This should be meta l4proto icmp icmp type != echo-request, with the equivalent change for ICMPv6.

Also, negated TCP/UDP ranges still fail nft --check. For example:

meta l4proto tcp ! tcp sport 1000-1002 ! tcp dport 2000-2002

nft reports syntax error, unexpected !. The negation needs to be part of each comparison, for example tcp sport != 1000-1002 and tcp dport != 2000-2002.

uif-evidence-pr5-2275d87.txt

[sunweaver]

It turned out that not just icmp negations have been broken so far, but all negations when using nft. This PR requires #14 to be merged to become fully functional.

[dzatoah]

Retested current PR 5 (a2fdd343) together with PR 14 (afb46636) on current master, using Debian trixie and nftables 1.1.3.

The commits apply cleanly, but generated IPv4 and IPv6 rules both fail nft --check. TCP/UDP range negation places != before the protocol expression, single-port negation is omitted, and typed ICMP negates the protocol instead of the type. Positive and negated igmp() output also remains malformed.

Full environment, generated expressions, and nft errors are recorded here:
#14 (comment)

PRs 5 and 14 are not functionally ready in their current combined form.