Bug 2020974

Affects: Users that upgraded from F34 (firewalld v0.9.z) to F35 (firewalld v1.0.z) and have previously modified <zone> from the stock configuration.
Solution: `firewalld-cmd --permanent --zone <zone> --add-forward`

New/stock configurations are not affected.

---

Firewalld had a major version bump in f35 which includes breaking changes.
See this Change: https://fedoraproject.org/wiki/Changes/firewalld-1.0.0#Upgrade.2Fcompatibility_impact

Changes of note in regards to this BZ:

  1. Intra-zone forwarding by default
  2. Default target is now similar to reject

#1 is the solution to this bug and new default behavior for zones.
#2 is what caused this BZ report: https://github.com/firewalld/firewalld/commit/f2896e43c3a548a299f87675a01e1a421b8897b8

The rules you note in the description were removed as part of this commit: 

  https://github.com/firewalld/firewalld/commit/c58c6d54c9c09c8da616837f703a7684075a0959

  fix(masquerade): remove conntrack rule in forward chain

  The masquerade feature also implicitly adds a rule to accept all
  forwarded traffic egressing the relevant zone. As of f2896e4 
  ("fix(zone): target: default is now similar to reject") we're
  disallowing implicit forwarding between zones. So now these rules have
  no effect because the decision to accept/reject/drop is made _before_
  these rules are even hit. Let's just get rid of them.

*** This bug has been marked as a duplicate of bug 2016864 ***

(In reply to Eric Garver from comment #1)

>   forwarded traffic egressing the relevant zone. As of f2896e4 
>   ("fix(zone): target: default is now similar to reject") we're
>   disallowing implicit forwarding between zones. So now these rules have
>   no effect because the decision to accept/reject/drop is made _before_
>   these rules are even hit. Let's just get rid of them.

Please excuse my confusion.  Can an explicit forward be created between zones, or does this mean that there is currently no way to forward between zones?

Should this example from CentOS 8 work in this new version? (It is not working for me)

[root@dlp ~]# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o ens8 -j MASQUERADE
[root@dlp ~]# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens2 -o ens8 -j ACCEPT
[root@dlp ~]# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens8 -o ens2 -m state --state RELATED,ESTABLISHED -j ACCEPT

(In reply to John from comment #3)
> (In reply to Eric Garver from comment #1)
> 
> >   forwarded traffic egressing the relevant zone. As of f2896e4 
> >   ("fix(zone): target: default is now similar to reject") we're
> >   disallowing implicit forwarding between zones. So now these rules have
> >   no effect because the decision to accept/reject/drop is made _before_
> >   these rules are even hit. Let's just get rid of them.
> 
> Please excuse my confusion.  Can an explicit forward be created between
> zones

Yes. With policies.
https://firewalld.org/2020/09/policy-objects-introduction

> or does this mean that there is currently no way to forward between
> zones?

No. By default firewalld blocks traffic forwarded between zones.
You have to explicitly allow it - just like most things (e.g. services).

> Should this example from CentOS 8 work in this new version? (It is not
> working for me)
> 
> [root@dlp ~]# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o
> ens8 -j MASQUERADE
> [root@dlp ~]# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens2
> -o ens8 -j ACCEPT
> [root@dlp ~]# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens8
> -o ens2 -m state --state RELATED,ESTABLISHED -j ACCEPT

Not by default. Due to Netfilter (kernel) hook execution order it only works if the FirewallBackend=iptables. It's also unnecessary. Modern firewalld (v0.9.0+) has native support.

Use the native intra-zone forwarding (--add-forward) as indicated in comment 1.

https://firewalld.org/2020/04/intra-zone-forwarding

The policy information is what I was lacking; it's working now.  Thank you for writing up this information!  It's very helpful.