Bug 2035894

The policies you have (toInternet, fromInternet) are not doing anything. They do not contain any rules. CONTINUE allows rules is subsequent policies to be considered. CONTINUE does not ACCEPT traffic.

To allow traffic to pass from external to internal you can change the --set-target of a policy to accept all traffic.
e.g.

  # firewall-cmd --permanent --policy toInternet --set-target=ACCEPT

Alternatively, you can allow only a subset of traffic:

  # firewall-cmd --permanent --policy toInternet --add-service=https

Link which I was given somewhere - https://firewalld.org/2020/09/policy-objects-introduction - says:
"..The default is CONTINUE which means packets will be subject to rules in following policies and zones.."
Which I understand simply as 'pass the traffic & give control over it to a zone(s), ingress/egress (in my case  external/internal)

So it's only to other 'policies' that 'CONTINUE' gives away the traffic and 'zones' play no role here at all?

thanks, L.

(In reply to lejeczek from comment #2)
> Link which I was given somewhere -
> https://firewalld.org/2020/09/policy-objects-introduction - says:
> "..The default is CONTINUE which means packets will be subject to rules in
> following policies and zones.."
> Which I understand simply as 'pass the traffic & give control over it to a
> zone(s), ingress/egress (in my case  external/internal)
> 
> So it's only to other 'policies' that 'CONTINUE' gives away the traffic and
> 'zones' play no role here at all?

Correct. Your example is FORWARDed traffic. Zones only filter INPUT traffic (with a couple historical caveats, e.g. masquerade).

I then encourage everybody to make it very clear in man pages and elsewhere.
What I quoted is perhaps even misleading, well, misled me - "..be subject to rules in following policies and _zones_ .. so it's loud & clear for 'regular' admins when ZONEs are not part of the POLICIES equation. 

thanks, L.

(In reply to lejeczek from comment #4)
> I then encourage everybody to make it very clear in man pages and elsewhere.
> What I quoted is perhaps even misleading, well, misled me - "..be subject to
> rules in following policies and _zones_"

This is true for INPUT which is where zones and policies overlap.
Zones can not filter FORWARD nor OUTPUT traffic.

Rules in either of these may filter the same INPUT traffic:

  - policyA with ingress-zones=public, and egress-zones=HOST
  - public zone


With that knowledge, do you have a suggested improvement to the text?

Just - in man pages which are already very good - make it clear, make that clear distinction between: when policies "do go to/via" zones, and when it is not the case - ideally! using examples.

When I read mans/docs on CONTINUE I thought that: a simple policy 'toInternet' should pass then delegate(nothing more) to 'external' zone which then does the "whole" lot - I thought great, makes sense, simple & clean - in zones, as all this time, 'management' takes place and POLICIES only allow 'interaction' between zones. 

side note. I cannot remember now exact steps but it seems like definition of a POLICY - if ingress/egress & masquarade is/will be used - should be with very specific order.

Apologies, if that is separate & should be a separate BZ, here:

-> $ firewall-cmd --new-policy=testing --permanent
-> $ firewall-cmd --reload
-> $ firewall-cmd --policy=testing --add-ingress-zone=direct
-> $ firewall-cmd --policy=testing --add-egress-zone=external
-> $ firewall-cmd --policy=testing --add-masquerade
Error: INVALID_ZONE: 'masquerade' cannot be used in a policy if an ingress zone has assigned interfaces

VS
-> $ firewall-cmd --new-policy=testing --permanent
-> $ firewall-cmd --reload
-> $ firewall-cmd --policy=testing --add-masquerade
-> $ firewall-cmd --policy=testing --add-egress-zone=external
-> $ firewall-cmd --policy=testing --add-ingress-zone=direct
-> $ firewall-cmd --runtime
-> $ firewall-cmd --reload
success

thanks, L

(In reply to lejeczek from comment #7)
> Apologies, if that is separate & should be a separate BZ, here:

Separate.

> -> $ firewall-cmd --new-policy=testing --permanent
> -> $ firewall-cmd --reload
> -> $ firewall-cmd --policy=testing --add-ingress-zone=direct
> -> $ firewall-cmd --policy=testing --add-egress-zone=external
> -> $ firewall-cmd --policy=testing --add-masquerade
> Error: INVALID_ZONE: 'masquerade' cannot be used in a policy if an ingress
> zone has assigned interfaces
> 
> VS
> -> $ firewall-cmd --new-policy=testing --permanent
> -> $ firewall-cmd --reload
> -> $ firewall-cmd --policy=testing --add-masquerade
> -> $ firewall-cmd --policy=testing --add-egress-zone=external
> -> $ firewall-cmd --policy=testing --add-ingress-zone=direct
> -> $ firewall-cmd --runtime
> -> $ firewall-cmd --reload
> success

Config checks are an area that I'm working on. This is an example where current checks are insufficient.
The error is valid (for the reasons stated in the error message). The latter scenario should be caught, but obviously is not.

You can file a separate issue for this.

(In reply to lejeczek from comment #6)
> Just - in man pages which are already very good - make it clear, make that
> clear distinction between: when policies "do go to/via" zones, and when it
> is not the case - ideally! using examples.
> 
> When I read mans/docs on CONTINUE I thought that: a simple policy
> 'toInternet' should pass then delegate(nothing more) to 'external' zone
> which then does the "whole" lot - I thought great, makes sense, simple &
> clean - in zones, as all this time, 'management' takes place and POLICIES
> only allow 'interaction' between zones.

So additions to FIREWALLD.POLICIES(5) ? Maybe in the "Similarity to Zones" section?

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.