Bug 1421222

Summary: order of INPUT_ZONES_SOURCE rules is not deterministic
Product: Red Hat Enterprise Linux 7 Reporter: Tomas Dolezal <todoleza>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: medium Docs Contact:
Priority: high    
Version: 7.3CC: ajohn, dazo, todoleza, zpytela
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1734765 (view as bug list) Environment:
Last Closed: 2017-08-01 16:22:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1420851, 1734765, 1737491    

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:

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:

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-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.

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.

https://access.redhat.com/errata/RHBA-2017:1934