Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
rules for matching and classifying sources can get into rules out of order, this may impact later packet flow in tables if the sources happen to overlap. The overlapping was first overcome by alphanumerical naming of sources to get the order right. with IndividualCalls this stopped working.
copypaste from github:
@brownjtb commented on 10 Nov 2016
I make use of several custom source zones and in RHEL 7.2 (firewalld version 0.3.9), I was able to control the order within "INPUT_ZONES_SOURCE" by ensuring that my zones were named numerically... for example:
chain INPUT_ZONES_SOURCES
target source destination
IN_00_it 192.168.2.10 0.0.0.0/0
IN_10_wrk 192.168.2.0/24 0.0.0.0/0
IN_20_vpn 192.168.3.0/22 0.0.0.0
However, since firewalld was upgraded (0.4.3.2) in RHEL 7.3 this no longer appears to the case. I have tried renaming my zones and even changed the order that they are created, but I can not seem to configure in a way that will guarantee that my rules will be processed in a specific order. For example, the above may now look like the following:
chain INPUT_ZONES_SOURCES
target source destination
IN_10_wrk 192.168.2.0/24 0.0.0.0/0
IN_00_it 192.168.2.10 0.0.0.0/0
IN_20_vpn 192.168.3.0/22 0.0.0.0
There appears to be a fundamental change in how zones are created and added to the "iptables" rules. For example, if a packet satisfies the "IN_10_wrk" rules in the second example above, it will not reach the "IN_00_it" rule. Is there a command-line flag or argument that allows the functionality to revert back where the the zones are created and listed in numerical order (such as in RHEL 7.2, firewalld 0.3.9)?
I believe I have seen comments in other messages that suggest zones should not overlap. However, I do not believe that this is a restriction imposed within IPtables. With numerical/alphabetical naming, I can control the behavior of my rules, but this no longer appears to be possible with the latest RHEL upgrade.
Is there a way to force the ordering of zones as was the case in earlier versions? I know that I can remove "firewalld" and manually configure "iptables" or roll-back to version 0.3.9, but before I decide on either of those two options, I thought I would check to see if restricting zone order is possible now in version 0.4.3.2? Is this something that may be possible in future releases?
Version-Release number of selected component (if applicable):
How reproducible:
always
Steps to Reproduce:
see sources examples above
Actual results:
Expected results:
alphanum ordered sources in netfilter rules
Additional info:
Tested applying commit 2f42e7cbea1d0e1b05e91827f8b695a6e1e107f6 + 7bbe82ef4ce391af68dfb5299d1c2b1f944b77be on an Scientific Linux 7.3 install with firewalld-0.4.3.2-8.1.el7_3.2.noarch.
These two patches resolved the sort order to how it was in SL 7.2.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2017:1934