fw4: ubus-provided SNAT rules with proto icmp and a port range are silently dropped (breaks MAP-T/MAP-E ICMP)

Describe the bug

map.sh publishes, via ubus, one SNAT rule per port set per protocol (icmp, tcp, udp) — package/network/ipv6/map/files/map.sh:

for portset in $(eval "echo \$RULE_${k}_PORTSETS"); do
  for proto in icmp tcp udp; do
    json_add_object ""
      json_add_string type nat
      json_add_string target SNAT
      json_add_string family inet
      json_add_string proto "$proto"
      json_add_boolean connlimit_ports 1
      json_add_string snat_ip $(eval "echo \$RULE_${k}_IPV4ADDR")
      json_add_string snat_port "$portset"
    json_close_object
  done
done

fw4 renders the tcp and udp rules but omits every icmp one, with no warning and no error.

ubus call network.interface.wanmap status lists all three:

{ "type":"nat", "target":"SNAT", "family":"inet", "proto":"icmp",
  "connlimit_ports":true, "snat_ip":"203.0.113.91", "snat_port":"16384-24575" },
{ "type":"nat", ..., "proto":"tcp",  ... },
{ "type":"nat", ..., "proto":"udp",  ... }

nft list chain inet fw4 srcnat contains only two of them. With multiple port sets the pattern is unmistakable: rule indices 1, 2, 4, 5, 7, 8 … are present and every index divisible by 3 (the icmp ones) is missing.

nftables does support source NAT of the ICMP query identifier through the port field. The following is accepted by the kernel and restores working ICMP:

nft insert rule inet fw4 srcnat meta nfproto ipv4 meta l4proto icmp \
    oifname "map-wanmap" counter snat ip to  203.0.113.91 : 16384-24575

OpenWrt version

r33051-f5dae5ece4

OpenWrt release

25.12.5

OpenWrt target/subtarget

x86/64

Device

Lenovo ThinkCentre M720q (10T8S0D200)

Image kind

Official downloaded image

Steps to reproduce

1. Bring up a MAP-T (or MAP-E) interface with the map package, attached to a firewall zone.
2. Compare ubus call network.interface.<mapiface> status with nft list chain inet fw4 srcnat.

Actual behaviour

The icmp SNAT rules are discarded silently. IPv4 ICMP leaves the router with its original private source address, the nat46 device cannot translate it, and the kernel logs [nat46] Could not translate v4->v6 in a tight loop. ping from the LAN never works — which is usually the first thing anyone tries when debugging such a setup, and it sends people chasing the wrong problem.

Expected behaviour

Render the rule (the expression is valid nftables), or report explicitly that it was rejected. Silently discarding a rule provided over ubus is the worst of both.

Additional info

Workaround: a config include script re-inserting the rule after every firewall reload. Related to the MAP-T investigation in issue #____ (odhcp6c).

Diffconfig

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.