Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1349903 - FirewallD fails to parse direct rules with a lot of destination addresses
FirewallD fails to parse direct rules with a lot of destination addresses
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld (Show other bugs)
7.2
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Thomas Woerner
Tomas Dolezal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-24 09:30 EDT by Thiago Basilio
Modified: 2016-11-03 17:03 EDT (History)
2 users (show)

See Also:
Fixed In Version: firewalld-0.4.2-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 17:03:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2597 normal SHIPPED_LIVE Moderate: firewalld security, bug fix, and enhancement update 2016-11-03 08:11:47 EDT

  None (edit)
Description Thiago Basilio 2016-06-24 09:30:29 EDT
Description of problem:
On FirewallD you have two options when dealing with DIRECT rules:
... 1) Inserting them temporary using firewall-cmd --direct command;
... 2) Permanently storing them into the XML file (/etc/firewalld/direct.xml);

In RHEL 7.2 the current FirewallD version is 0.3.9.

If the administrator inserts DIRECT rules with lots of destination addresses using method 1, it works and the rule is inserted.
If the method 2 is used, when the administrator reloads FirewallD (firewall-cmd --reload) the rules will not be inserted (decode error, lack of arguments, incomplete arguments).

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

How reproducible:
Create some DIRECT rules using firewall-cmd --permanent --direct <RULE> with lots of destination addresses.

Steps to Reproduce:
1. Clear all DIRECT rules, backup your /etc/firewalld/direct.xml file.

2. Clear /etc/firewalld/direct.xml file, insert the rules for testing.
You can break things using this script:
#!/bin/bash
ADDRS=$(for i in $(seq 1 49); do for j in $(seq 1 255); do echo -n "1.1.$i.$j,"; done; done; echo "1.2.0.0")
CMD="firewall-cmd -q --permanent --direct --add-rule ipv4 mangle PREROUTING"
$CMD 1 -s 1.0.0.0/24 -d $ADDRS -j MARK --set-mark 1 -m comment --comment "MARK ADDRS"

3. Reload the firewall (firewall-cmd --reload) and check its logfile (/var/log/firewalld) for parse/command error(s).

Actual results:
Rules are not inserted on firewall because of decode error(s) and/or missing/incomplete iptables arguments.

Example log:
2016-06-24 10:24:32 WARNING: COMMAND_FAILED: '/sbin/iptables -w2 -t mangle -I PREROUTING_direct 1 26.27,1.1.26.28,1.1.26.29,1.1.26.30,1.1.26.31,1.1.26.32,1.1.26.33,1.1.26.34,1.1.26.35,1.1.26.36,1.1.26.37,1.1.26.38,1.1.26.39,1.1.26.40,1.1.26.41,1.1.26.42,1.1.26.43,1.1.26.44,1.1.26.45,1.1.26.46,1.1.26.47,1.1.26.48,1.1.26.49,1.1.26.50,1.1.26.51,1.1.26.52,1.1.26.53,1.1.26.54,1.1.26.55,1.1.26.56,1.1.26.57,1.1.26.58,1.1.26.59,1.1.26.60,1.1.26.61,1.1.26.62,1.1.26.63,1.1.26.6 <SNIP>

Expected results:
All rules on /etc/firewalld/direct.xml should be parsed and inserted properly on the firewall.

Additional info:
Comment 1 Thomas Woerner 2016-06-24 09:33:48 EDT
Here is the upstream patch: https://github.com/t-woerner/firewalld/commit/3451763190a7d997613ab6eb448271d778999d6c
Comment 7 errata-xmlrpc 2016-11-03 17:03:11 EDT
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://rhn.redhat.com/errata/RHSA-2016-2597.html

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