(In reply to lejeczek from comment #0) 
> Is that really the intention with firewalld-1.0.0-2.el9.noarch

Yes. See bug 2020974 comment 1.

Solution: `firewalld-cmd --permanent --zone <zone> --add-forward`

Nope. The zone (and most by default I think) have forwarding already:

-> $ firewall-cmd --zone=external --list-all
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: virgincable
  sources: 
  services: http https ipsec rsyncd ssh
  ports: 9001/tcp 22067/tcp 22070/tcp 8443/tcp
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
	port=18080:proto=tcp:toport=18080:toaddr=10.3.1.10
  source-ports: 
  icmp-blocks: 
  rich rules:

unless I add other(s) iface(s) via/from which I want communicate to the outside word (virgincable iface) to that zone, there is no traffic passing through:
...
From 10.3.1.100 icmp_seq=238 Packet filtered
...

I tried some rules for that zone, one basic such as here:

	rule priority="-32768" family="ipv4" source address="10.3.1.0/24" masquerade

But none of those worked and.. naturally I'd be nice(desired & expected) to not have to tamper with nft directly for such a basic concept as "gateway"

regards, L.

You need to explicitly allow the forwarding between zones. It sounds like your were relying on the "fall through" behavior mentioned the commit [1] - see the paragraph that starts with "Secondly". The commit changes the behavior of the "default" --set-target. As the commit notes, this "fall through" behavior was unexpected. Packets should not implicitly flow between zones. That's a violation of the zone concept.

The solution is to explicitly allow forwarding between the zones. This can be done in two ways:

  1. use the `trusted` zone on the LAN side
    - trusted uses --set-target=ACCEPT, so the forwarded traffic is allowed
    - this is what podman, libvirt, etc use.

  2. use a policy to allow the forwarded traffic

    # firewall-cmd --permanent --new-policy masqueradePolicy
    # firewall-cmd --permanent --policy masqueradePolicy --add-ingress-zone public
    # firewall-cmd --permanent --policy masqueradePolicy --add-egress-zone external
    # firewall-cmd --permanent --policy masqueradePolicy --add-masquerade

---

[1]: https://github.com/firewalld/firewalld/commit/f2896e43c3a548a299f87675a01e1a421b8897b8

Additionally, the upstream blog about v1.0.0 may be useful to skim.

  https://firewalld.org/2021/06/the-upcoming-1-0-0

Guys, put it every place an admin might go first to look for what-is-new, be it change-logs, blogs, official manuals, etc.
I see many admins if not all! the admins, will stumble over it day-0, as all this time - Centos for certain - between-zone communication just worked (still does with CentOS 8 Stream's firewalld) without lifting a finger.

many thanks, L

(In reply to lejeczek from comment #5)
> Guys, put it every place an admin might go first to look for what-is-new, be
> it change-logs, blogs, official manuals, etc.

I linked the commit and the blog already. It's also in the upstream release notes.

I'm flagging this bug for a RHEL-9.0 release note.