Bug 2016864 - Masquerade fails to work on F35
Summary: Masquerade fails to work on F35
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Eric Garver
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2020974 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-25 01:02 UTC by Peter Hutterer
Modified: 2022-05-02 13:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-26 22:59:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
firewall-cmd --list-all-zones (3.08 KB, text/plain)
2021-10-25 21:41 UTC, Peter Hutterer
no flags Details
firewall-cmd --list-all-policies (479 bytes, text/plain)
2021-10-25 21:41 UTC, Peter Hutterer
no flags Details

Description Peter Hutterer 2021-10-25 01:02:51 UTC
Apologies first, this is just as likely a misconfiguration or something else but I don't know where to start.

Starting with F35, masquerading + forward no longer seems to work here. I have one host that is connected via OpenVPN to a 10.0.0.0/8 network, it's local IP is 192.168.1.240. The setup I've used for for years is:

$ cat /etc/sysctl.d/99-ip4_forward.conf
net.ipv4.ip_forward = 1

Then enabling the Masquerading checkbox in the firewall configuration for whatever default zone.


On the other hosts in the network, I run 
$ route add -net 10.0.0.0/8 gw 192.168.1.240

And that used to be enough to get those boxes to temporarily have access to the VPN resources (these are all test boxes, I don't need anything more permanent). All boxes use wired connections.

This seems to no longer work with F35, packets are filtered when I ping anything on the 10.0.0.0 network.

I'm *pretty* sure this worked with F34 on the same box but I'm not 100% certain. It certainly works with another box still on F34.

The Masquerade checkbox has an effect in the nftables rulesets:

f35 $ sudo nft list ruleset
        ...
	chain nat_POST_FedoraWorkstation_allow {
		meta nfproto ipv4 oifname != "lo" masquerade
	}

though that entry differs from the F34 one:

f34 $ sudo nft list ruleset
        ...
	chain nat_POST_FedoraWorkstation_allow {
		oifname != "lo" masquerade
	}


/proc/sys/net/ipv4/ip_forward is 1.

So, the question here is: what has changed and how do I debug this? Thanks.

Comment 1 Eric Garver 2021-10-25 17:18:54 UTC
F35 saw a major version bump for firewalld.
See this F35 Change: https://www.fedoraproject.org/wiki/Changes/firewalld-1.0.0#Detailed_Description

Can your share your zone config? The required changes depend on how your interfaces/sources are assigned to zones.

  # firewall-cmd --list-all-zones
  # firewall-cmd --list-all-policies

Comment 3 Peter Hutterer 2021-10-25 21:41:59 UTC
Created attachment 1837016 [details]
firewall-cmd --list-all-policies

Comment 4 Peter Hutterer 2021-10-25 21:46:02 UTC
After looking at those files, I suspect the "forward: no" in the FedoraWorkstation zone may be the issue. And indeed, if I switch the zone to "trusted" (after enabling masquerading) it works fine. But at least in the firewall UI I can't figure out where the toggle is for enabling forwarding - any idea what is enabling that?

Comment 5 Eric Garver 2021-10-26 12:43:43 UTC
(In reply to Peter Hutterer from comment #4)
> After looking at those files, I suspect the "forward: no" in the
> FedoraWorkstation zone may be the issue. And indeed, if I switch the zone to
> "trusted" (after enabling masquerading) it works fine. But at least in the
> firewall UI I can't figure out where the toggle is for enabling forwarding -
> any idea what is enabling that?

It's exposed in the CLI as `--add-forward`. There is currently no config knob in the GUI (firewall-config).

`forward` defaults to `yes` in v1.0.0+. Prior to that it defaulted to `no`. Since your configuration was carried over from a old firewalld it retained the setting of `no`.

If your scenario was fixed by setting `--add-forward`, then I'm guessing you were unknowingly relying on this bug's behavior: https://github.com/firewalld/firewalld/issues/177. This was fixed by upstream commit: https://github.com/firewalld/firewalld/commit/f2896e43c3a548a299f87675a01e1a421b8897b8

As such, I don't think there is a bug here. You need to fix your configuration by setting `--add-forward` in the relevant zone (i.e. FedoraWorkstation). I'll wait on your reply before closing this as NOTABUG.

[1]: https://firewalld.org/2020/01/allowzonedrifting

Comment 6 Peter Hutterer 2021-10-26 22:59:19 UTC
Confirming that firewall-cmd --add-forward fixes the issue here, and forward: yes now shows up in the FedoraWorkstation zone. Thanks heaps!

Comment 7 Eric Garver 2021-11-08 14:17:23 UTC
*** Bug 2020974 has been marked as a duplicate of this bug. ***

Comment 8 Hubert Kario 2022-04-30 09:10:46 UTC
Actually, just setting forward on the internal zone is not sufficient, there's also a need to create a policy that allows the forwarding between zones:

// create new policy
firewall-cmd --permanent --new-policy int_to_ext_fwd
firewall-cmd --permanent --policy int_to_ext_fwd --add-ingress-zone internal
firewall-cmd --permanent --policy int_to_ext_fwd --add-egress-zone external
firewall-cmd --permanent --policy int_to_ext_fwd --set-priority 100
firewall-cmd --permanent --policy int_to_ext_fwd --set-target ACCEPT

// Enable masquerade on external (this should already be the case if the setup worked on F34); 'forward' does not need to be set
firewall-cmd --permanent --zone=external --add-masquerade

// Enable forward on internal (this is a new setting)
firewall-cmd --permanent --zone=internal --add-forward

// restart firewalld
systemctl restart firewalld.service

Comment 9 Eric Garver 2022-05-02 13:52:34 UTC
(In reply to Hubert Kario from comment #8)
> Actually, just setting forward on the internal zone is not sufficient,
> there's also a need to create a policy that allows the forwarding between
> zones:

Correct.

If the two interfaces are in THE SAME ZONE (intra-zone forwarding), then --add-forward is sufficient.

If the two interface are in DIFFERENT zones, then you need an explicit policy to allow the inter-zone forwarding.


Note You need to log in before you can comment on or make changes to this bug.