Bug 1809225 - FlushAllOnReload=no does not prevent ipset flushing on reload
Summary: FlushAllOnReload=no does not prevent ipset flushing on reload
Keywords:
Status: CLOSED ERRATA
Alias: None
Deadline: 2020-09-28
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: firewalld
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: Eric Garver
QA Contact: Jiri Peska
Sagar Dubewar
URL:
Whiteboard:
Depends On:
Blocks: 1807630
TreeView+ depends on / blocked
 
Reported: 2020-03-02 15:52 UTC by Tomas Dolezal
Modified: 2020-11-04 01:40 UTC (History)
5 users (show)

Fixed In Version: firewalld-0.8.2-1.el8
Doc Type: Bug Fix
Doc Text:
.`firewalld` now restores `ipset` entries after reloading Previously, `firewalld` did not retain runtime `ipset` entries after reloading. Consequently, users had to manually add the missing entries again. With this update, `firewalld` has been modified to restore `ipset` entries after reloading.
Clone Of:
Environment:
Last Closed: 2020-11-04 01:39:57 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4461 0 None None None 2020-11-04 01:40:21 UTC

Description Tomas Dolezal 2020-03-02 15:52:05 UTC
Description of problem:
firewalld maintained ipsets are flushed independently of FlushAllOnReload setting in firewalld.conf(5). Although ipset is not explicitly named, it falls into the 'All' part of the config name.

Version-Release number of selected component (if applicable):
firewalld-0.8.0-3.el8.noarch

How reproducible:
always

Steps to Reproduce:
sed -n '/FlushAllOnReload/,/^$/ p' /etc/firewalld/firewalld.conf 
# FlushAllOnReload
# Flush all runtime rules on a reload. In previous releases some runtime
# configuration was retained during a reload, namely; interface to zone
# assignment, and direct rules. This was confusing to users. To get the old
# behavior set this to "no".
# Default: yes
FlushAllOnReload=no

firewall-cmd --permanent --new-ipset foo --type hash:ip
firewall-cmd --permanent --ipset foo --add-entry 20.30.40.50
firewall-cmd --reload
ipset add foo 20.20.20.20
firewall-cmd --reload

Actual results:
entry 20.20.20.20 is missing after reload.

Expected results:
suggestion: all newly added items are retained, the permanent-config stored ones are readded

Additional info:

Comment 1 Eric Garver 2020-03-02 19:52:16 UTC
Tomas, I don't think we can guarantee we won't flush ipset entries added out-of-band of firewalld. We don't do that for iptables direct rules.

What we can does is make sure rules added at runtime (firewall-cmd --ipset foobar --add-entry 1.2.3.4) are still present after a reload.

Comment 2 Tomas Dolezal 2020-03-03 17:11:26 UTC
Agreed, the option should behave the same to ipsets as it does to direct rules. If out-of-band added items get dropped on reload, ipset should have them removed as well. This applies to the non-standard 'no' value of this flush option to keep user-added items via firewalld interface.

Comment 3 Eric Garver 2020-03-03 17:35:01 UTC
Upstream:

81d784f8c856 ("test: ipset: verify clean up on exit/reload")
f5ed30ce7175 ("fix: ipset: destroy runtime sets on reload/stop")

Comment 21 errata-xmlrpc 2020-11-04 01:39:57 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 (firewalld bug fix and enhancement update), 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-2020:4461


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