Bug 2035894 - Doc(man): firewalld: make it clear policies and zones only overlap for INPUT packets
Summary: Doc(man): firewalld: make it clear policies and zones only overlap for INPUT ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: firewalld
Version: CentOS Stream
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Eric Garver
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-12-28 11:28 UTC by lejeczek
Modified: 2023-06-28 07:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-28 07:28:18 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-106637 0 None None None 2021-12-28 11:29:41 UTC

Description lejeczek 2021-12-28 11:28:28 UTC
Description of problem:

Hi.
I've been trying number of polices but desired, expected end result is not achieved

Both or any single of below policies in use(with 'masquerade' while 'masquerade' remove from 'external' zone and with different priorities and targets):

-> $ firewall-cmd --info-policy=toInternet
toInternet (active)
  priority: -1
  target: CONTINUE
  ingress-zones: internal
  egress-zones: external
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

-> $ firewall-cmd --info-policy=fromInternet
fromInternet (active)
  priority: -1
  target: CONTINUE
  ingress-zones: external
  egress-zones: internal
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

for zones:
-> $ firewall-cmd --zone=external --list-all
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: virgincable
  sources: 
  services: http ....
  ports: 
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

-> $ firewall-cmd --list-all 
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: nm-bridge1031
  sources: 
  services: cockpit ....
  ports: 51850/udp
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

will not let traffic pass from 'internal' to/via 'external'.
'internal' is LAN whereas 'external' hosts the GATEWAY

also, symbolic zones:

-> $ firewall-cmd --permanent --policy=toInternet --add-ingress-zone ANY
Error: INVALID_ZONE: 'ingress_zones' may only contain one of: many regular zones, ANY, or HOST


many thanks, L.

Version-Release number of selected component (if applicable):

firewalld-1.0.0-2.el9.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Eric Garver 2022-01-03 14:03:51 UTC
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

Comment 2 lejeczek 2022-01-05 10:49:51 UTC
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.

Comment 3 Eric Garver 2022-01-05 13:31:17 UTC
(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).

Comment 4 lejeczek 2022-01-05 17:33:07 UTC
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.

Comment 5 Eric Garver 2022-01-05 21:35:20 UTC
(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?

Comment 6 lejeczek 2022-01-06 12:30:46 UTC
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.

Comment 7 lejeczek 2022-01-06 12:32:16 UTC
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

Comment 8 Eric Garver 2022-01-06 13:41:21 UTC
(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.

Comment 9 Eric Garver 2022-01-06 14:33:08 UTC
(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?

Comment 11 RHEL Program Management 2023-06-28 07:28:18 UTC
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.


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