Bug 1421222 - order of INPUT_ZONES_SOURCE rules is not deterministic
Summary: order of INPUT_ZONES_SOURCE rules is not deterministic
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Thomas Woerner
QA Contact: Tomas Dolezal
: 1421278 (view as bug list)
Depends On:
Blocks: 1420851 1734765 1737491
TreeView+ depends on / blocked
Reported: 2017-02-10 16:05 UTC by Tomas Dolezal
Modified: 2020-12-14 08:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1734765 (view as bug list)
Last Closed: 2017-08-01 16:22:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github t-woerner firewalld issues 166 0 None None None 2020-09-08 12:42:52 UTC
Red Hat Knowledge Base (Solution) 3039881 0 None None None 2017-05-19 16:01:43 UTC
Red Hat Product Errata RHBA-2017:1934 0 normal SHIPPED_LIVE firewalld bug fix and enhancement update 2017-08-01 17:55:15 UTC

Description Tomas Dolezal 2017-02-10 16:05:39 UTC
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:

target source destination

However, since firewalld was upgraded ( 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:

target source destination

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 Is this something that may be possible in future releases?

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

How reproducible:

Steps to Reproduce:
see sources examples above

Actual results:

Expected results:
alphanum ordered sources in netfilter rules

Additional info:

Comment 4 Thomas Woerner 2017-03-27 16:08:45 UTC
*** Bug 1421278 has been marked as a duplicate of this bug. ***

Comment 7 Thomas Woerner 2017-04-05 08:52:52 UTC
Note: The upstream fix https://github.com/t-woerner/firewalld/commit/2f42e7cbea1d0e1b05e91827f8b695a6e1e107f6 is needed to have a working solution for firewalld version 0.4.3.

This patch is part of all firewalld 0.4.4 versions.

Comment 8 David Sommerseth 2017-04-20 15:54:07 UTC
Tested applying commit 2f42e7cbea1d0e1b05e91827f8b695a6e1e107f6 + 7bbe82ef4ce391af68dfb5299d1c2b1f944b77be on an Scientific Linux 7.3 install with firewalld-

These two patches resolved the sort order to how it was in SL 7.2.

Comment 10 errata-xmlrpc 2017-08-01 16:22:56 UTC
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.


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