Bug 2026176

Summary: FirewallD is Extremely Slow when Importing CIDR Lists under Fedora 35
Product: [Fedora] Fedora Reporter: niohiani <notinsideofhereiamnotinside>
Component: firewalldAssignee: Eric Garver <egarver>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 36CC: egarver, psutter
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: firewalld-1.2.2-1.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-12-15 02:16:31 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
cidr-format list (IPv4)
none
Latest CIDR list (IPv4) for testing none

Description niohiani 2021-11-24 01:06:55 UTC
Created attachment 1843257 [details]
cidr-format list (IPv4)

A few days after upgrading from f34 to f35, I went to add an updated set of IPs to the drop zone using firewalld (1.0.1). This is something I have done on a weekly basis for some time now, because I often run a streaming audio server (Icecast) that can be accessed from outside my LAN, and a comprehensive set of IPs in the drop zone has significantly reduced what used to be incessant attempts at compromising my device.

I was surprised to see CPU usage spike to 25% upon importing my largest CIDR list (11057 entries, 72640 subnets, IPv4) from the file chooser, and the task did not complete for about 17 minutes, with CPU usage remaining around the aforementioned level for the duration. The task completed without error, though the time and resource-usage was highly concerning.

For reference, under Fedora 34 w/firewalld 0.9.4, the same task would never take more than ten seconds. The situation was similarly quick under Fedora 33 w/firewalld 0.8.6. This is all with lists of roughly the same size.

I am uncertain about the root of this problem, and could find nothing in the logs which gives me a clue.

I have attached the CIDR list I used in this operation. Hopefully this is reproducible and can be resolved. This seems potentially related to the following bug under RHEL 8: https://bugzilla.redhat.com/show_bug.cgi?id=2016822

P.S. I did some tests with smaller lists. As expected, the processing time increased significantly with the amount of subnets.

Comment 1 niohiani 2022-11-10 20:44:36 UTC
This is still an issue under Fedora 36 and 37.

Comment 2 Eric Garver 2022-11-10 21:05:54 UTC
The fix is in the below firewalld releases. How do you feel about rebasing firewalld to v1.2.1 (same as f37 and f38) ? It's a big version bump for an old release.

$ git tag --contains 36c170db265265e838a089858be4b20dbbd582eb
v1.1.0
v1.1.1
v1.1.2
v1.1.3
v1.2.0
v1.2.1

Comment 3 niohiani 2022-11-10 21:15:55 UTC
Obviously not many others have noticed the issue, so thank you for the response. I was unaware of there being a fix, and that's great news. It would of course be awesome to see it backported to f36, as I usually keep my main PC one release behind the latest Fedora for 2 or 3 months while kinks and edge-cases are worked out, and I imagine that some other users take similar approaches to release upgrades.

Comment 4 Eric Garver 2022-11-10 21:22:28 UTC
> It would of course be awesome to see it backported to f36

Do you mean a backport of specific patches.. or a rebase to v1.2.1?

The latter is actually less time consuming for your friendly maintainer. ;)

Comment 5 niohiani 2022-11-10 21:28:50 UTC
Ah, then of course the latter. I'm but a lone user with a relatively obscure issue, and only maintain one - much less complicated - package myself. I can offer you my heartfelt appreciation for any time you spend on a rebase.

Comment 6 Eric Garver 2022-11-10 21:33:19 UTC
(In reply to niohiani from comment #5)
> Ah, then of course the latter. I'm but a lone user with a relatively obscure
> issue, and only maintain one - much less complicated - package myself. I can
> offer you my heartfelt appreciation for any time you spend on a rebase.

I'll do the rebase.

It may rot in bodhi (testing), but at least you'll have a build for yourself.

Comment 7 niohiani 2022-11-10 21:34:25 UTC
Many, many thanks, and godspeed!

Comment 8 Fedora Update System 2022-11-11 12:42:01 UTC
FEDORA-2022-2305f92d83 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83

Comment 9 Eric Garver 2022-11-11 12:43:28 UTC
(In reply to Fedora Update System from comment #8)
> FEDORA-2022-2305f92d83 has been submitted as an update to Fedora 36.
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83

It should hit testing soon. I set the karma threshold to 5 (up from 3) since it's a rebase in an old release.

Comment 10 niohiani 2022-11-11 19:17:00 UTC
Stellar! Saves me a lot of time when importing new lists. Mark this as closed whenever you see fit.

Comment 11 Fedora Update System 2022-11-13 02:39:01 UTC
FEDORA-2022-2305f92d83 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2305f92d83`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 niohiani 2022-11-13 21:54:31 UTC
Created attachment 1924078 [details]
Latest CIDR list (IPv4) for testing

Comment 13 niohiani 2022-11-13 21:59:41 UTC
Alright, so I'm using the new build, and while there are no noticeable regressions, this bug appears to be unresolved. I have attached the latest CIDR list I'm working with, and made sure to clear all of the previous entries before importing the new list under IPSets. It took about 15 minutes for the import to complete. Would love to assist in getting to the bottom of this.

Comment 14 Eric Garver 2022-11-14 15:44:44 UTC
Can you show the exact commands you're using?


--->8---

# dnf info firewalld
Installed Packages
Name         : firewalld
Version      : 1.2.1
Release      : 1.fc37
[..]

# firewall-cmd --permanent --new-ipset foobar hash:net

# time firewall-cmd --permanent --ipset foobar --add-entries-from-file=big_set
success

real    0m0.253s
user    0m0.151s
sys     0m0.020s

[root@vm-local-fedora tmp]# wc -l big_set
10611 big_set

Comment 15 niohiani 2022-11-14 16:44:55 UTC
Pretty weird. Importing via the GUI (firewall-config) is still extremely slow, but doing so via the command line appears to have been fixed, and only takes seconds. Didn't think to try adding via firewall-cmd since I filed this bug, as I usually only use firewall-cmd for backing up previous IPSet entries, and tend toward the GUI for other operations. Will be avoiding firewall-config for now.

Comment 16 Fedora Update System 2022-11-23 02:19:22 UTC
FEDORA-2022-2305f92d83 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-2305f92d83`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2305f92d83

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Fedora Update System 2022-11-30 02:32:17 UTC
FEDORA-2022-6499e05ba6 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6499e05ba6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6499e05ba6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2022-12-15 02:16:31 UTC
FEDORA-2022-6499e05ba6 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.