Routed network ACL: match protocol-number rules with ip protocol, not ip nexthdr - #14352

Description

On a network in routed mode, a network ACL rule that uses a protocol number (e.g. 47 for GRE) is never applied on the VR.

Fixes #14351

Why it breaks

In routed mode the VR renders IPv4 ACL rules as nftables, in CsAcl.AclDevice.__process_routing_ip4(). A protocol-number rule was rendered as ip nexthdr 47. nexthdr is an IPv6 header field, so nft rejects it in an ip rule:

Error: syntax error, unexpected string
add rule ip ip4_acl eth3_ingress_policy ip saddr 1.2.3.4/32 ip nexthdr 47 accept
                                                            ^^^^^^^

The rules are added one nft add rule at a time, and the failure is only logged: /var/log/cloud.log records that the command exited with status 1, while nft's error message goes to stderr. So the rule is silently missing from ip4_acl while the rest of the list loads:

• an allow rule for that protocol never matches;
• a deny rule for it is lost, and the traffic falls through to whatever later rule matches it.

This was introduced with routed mode in #9470 (4.20).

How it is fixed

The IPv4 match now uses the IPv4 field, ip protocol <n>. The IPv6 path in __process_ip6() is not touched by this change.

How to reproduce the old behaviour

1. Create a VPC in routed mode with an IPv4 tier. Network ACLs only exist on VPC tiers; a routed isolated network uses routing firewall rules instead and is not affected.
2. Add an ACL rule to the tier's ACL list: protocol number 47, CIDR 1.2.3.4/32, action Allow. Add a TCP 22 rule from the same CIDR for contrast.
3. On the VR, run nft list chain ip ip4_acl ethX_ingress_policy.

Before (the GRE rule is missing; /var/log/cloud.log has Command 'nft add rule ... ip nexthdr 47 accept' returned non-zero exit status 1):

ip saddr 1.2.3.4 tcp dport 22 accept
counter packets 0 bytes 0 drop

After:

ip saddr 1.2.3.4 ip protocol gre accept
ip saddr 1.2.3.4 tcp dport 22 accept
counter packets 0 bytes 0 drop

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

How Has This Been Tested?

• New systemvm/test/TestCsAclRouting.py checks the rendered IPv4 rule in both directions (ip saddr ingress, ip daddr egress), and that the IPv4 match does not reach the IPv6 rule. It fails on the current 4.22 code and passes with this change. (Nothing in .github/workflows runs systemvm/test, so it runs via systemvm/test/runtests.sh.)
• The before/after chains above are real output. They come from feeding the rules AclDevice generates through the unmodified CsNetfilters.apply_nft_ipv4_rules() into real nft (1.0.9) in a network namespace. ip protocol 47 was also checked on nft 1.0.6, the version in the Debian 12 systemvm template.
• pycodestyle and pylint (as in runtests.sh) report nothing new.

How did you try to break this feature and the system with this change?

• Only type == "protocol" rules go through this line. tcp, udp, icmp and all rules render exactly as before.
• This is independent of VPC ACL: apply every CIDR of a multi-CIDR rule, in order #14350, which touches the CIDR handling a few lines below. The two apply cleanly in either order.