Description of problem: Multiple reports of F35 updates breaking NAT/masquerading, with an apparent workaround. Version-Release number of selected component (if applicable): 1.0.1-2.fc35 How reproducible: Always Steps to Reproduce: 1. An up-to-date F34, dual-homed system to a public WAN and a local LAN, configured to masquerade/NAT traffic. 2. Update F34 to F35 Actual results: traceroute, outbound connections, pings, are blocked and do not get NATed out. Expected results: No change in behavior. Additional info: firewall-config shows that masquerading should be enabled. Toggling the masquerading checkbox on/off has no effect. Multiple reports here: https://forums.fedoraforum.org/showthread.php?327324-IP-Masquerade-NAT-not-working-in-Fedora-35 Workaround is to manually execute firewall-cmd --add-forward --zone=<appropriate zone> I verified that this worked for me. I executed nft list ruleset Both before and after the fix, and diffed the results as follows: chain filter_FWD_public_allow { + oifname "enp6s0" accept + oifname "enp5s0" accept } (referencing my network interfaces) I cannot locate any difference in what firewall-config is showing me, this option is apparently needed to support masquerading, but either is not supported in firewall-config, or the update fails to enable it, and firewall-config is unaware of it.
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.