Bug 1374001

Summary: masquerade rules are not always created the same
Product: Red Hat Enterprise Linux 7 Reporter: Tomas Dolezal <todoleza>
Component: firewalldAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: high Docs Contact:
Priority: medium    
Version: 7.3CC: sauchter, todoleza
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: firewalld-0.4.4.3-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 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:
Attachments:
Description Flags
generated rulesets none

Description Tomas Dolezal 2016-09-07 15:51:00 UTC
Description of problem:
enabling masquerading using --add-masquerade and --add-rich-rule 'rule masquerade' leads to different results in both ipv4 and ipv6 netfilter rules.

Version-Release number of selected component (if applicable):
firewalld-0.4.3.2-6.el7.noarch

How reproducible:
always

Steps to Reproduce:
exclusively configure either or:
--add-masquerade
--add-rich-rule 'rule masquerade'

Actual results:
add-masquerade:
==ipv4:
-A POST_public_allow ! -o lo -j MASQUERADE
-A FWDO_public_allow -j ACCEPT
==ipv6:
!nothing

richrule:
==ipv4:
-A POST_public_allow ! -o lo -j MASQUERADE
-A FWDO_public_allow -m conntrack --ctstate NEW -j ACCEPT
==ipv6:
-A POST_public_allow ! -o lo -j MASQUERADE
-A FWDO_public_allow -m conntrack --ctstate NEW -j ACCEPT

Expected results:
both config variants enable masquerading the same way. especially ipv6 rules are either always added or never.

Additional info:

Comment 1 Tomas Dolezal 2016-09-07 15:53:42 UTC
Created attachment 1198775 [details]
generated rulesets

normalized ruleset outputs for ipv4/ipv6 * all 3 variants basic of masquerading

Comment 6 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