RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

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:

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.

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.

Upstream:

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

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