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.
Bug 1817205 - firewalld rules broken by nftables service if started later
Summary: firewalld rules broken by nftables service if started later
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: firewalld
Version: 8.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 8.3
Assignee: Eric Garver
QA Contact: Tomas Dolezal
Sagar Dubewar
URL:
Whiteboard:
Depends On:
Blocks: 1807630
TreeView+ depends on / blocked
 
Reported: 2020-03-25 19:24 UTC by Tomas Dolezal
Modified: 2020-11-04 21:36 UTC (History)
9 users (show)

Fixed In Version: firewalld-0.8.2-1.el8
Doc Type: Bug Fix
Doc Text:
.`nftables` and `firewalld` services are now mutually exclusive Previously, it was possible to enable `nftables` and `firewalld` services at the same time. As a consequence, `nftables` was overriding `firewalld` rulesets. With this update, `nftables` and `firewalld` services are now mutually exclusive so that these cannot be enabled at the same time.
Clone Of:
Environment:
Last Closed: 2020-11-04 01:40:13 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1836571 0 unspecified CLOSED firewalld startup failure caused by overlapping ipset entries 2022-06-07 20:47:37 UTC
Red Hat Product Errata RHBA-2020:4461 0 None None None 2020-11-04 01:40:19 UTC

Internal Links: 1694723

Description Tomas Dolezal 2020-03-25 19:24:28 UTC 
Description of problem:
nftables service flushes all rules on it's start, this breaks firewalld.
Coincidentally, if both services are started at the same time, firewalld is ordered after nftables thus it only appends nftables rules and both services do coexist, but that forbids changes to nftables.service state when firewalld is active. Also, this order is not explicitly configured.

Version-Release number of selected component (if applicable):
nftables-0.9.3-11.el8.x86_64
firewalld-0.8.0-4.el8.noarch

How reproducible:
always

Steps to Reproduce:
systemctl restart firewalld
firewall-cmd --state
systemctl restart nftables
firewall-cmd --state
firewall-cmd --add-service ftp
Leads to:
running
running
Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: No such file or directory

internal:0:0-0: Error: Could not process rule: No such file or directory

internal:0:0-0: Error: Could not process rule: No such file or directory

internal:0:0-0: Error: Could not process rule: No such file or directory

internal:0:0-0: Error: Could not process rule: No such file or directory


JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"ct helper": {"family": "inet", "table": "firewalld", "name": "helper-ftp-tcp", "type": "ftp", "protocol": "tcp"}}}, {"add": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_IN_public_allow", "expr": [{"match": {"left": {"payload": {"protocol": "tcp", "field": "dport"}}, "op": "==", "right": 21}}, {"ct helper": "helper-ftp-tcp"}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_IN_public_allow", "expr": [{"match": {"left": {"payload": {"protocol": "tcp", "field": "dport"}}, "op": "==", "right": 21}}, {"match": {"left": {"ct": {"key": "state"}}, "op": "in", "right": {"set": ["new", "untracked"]}}}, {"accept": null}]}}}]}

----------
systemctl restart nftables firewalld
nft list tables
Leads to:
table inet nftables_svc
table ip security
table ip raw
table ip mangle
table ip nat
table ip filter
table ip6 security
table ip6 raw
table ip6 mangle
table ip6 nat
table ip6 filter
table bridge nat
table bridge filter

Expected/suggested fixes:
a firewalld conflict to nftables service is also added, currently:
Conflicts=iptables.service ip6tables.service ebtables.service ipset.service

explicit ordering should be put in place between these services so that one win always

Additional info:
Comment 1 Phil Sutter 2020-03-26 20:16:51 UTC 
I would tend to make firewalld, nftables and iptables services mutually exclusive. None of them should run at the same time. Am I missing some unwanted implications with this approach?
Comment 2 Eric Garver 2020-03-26 21:15:09 UTC 
(In reply to Phil Sutter from comment #1)
> I would tend to make firewalld, nftables and iptables services mutually
> exclusive. None of them should run at the same time.

Agree. firewalld already has Conflicts for iptables service.
Comment 3 Tomas Dolezal 2020-03-26 21:18:09 UTC 
There's issue with conflicting services in that systemd does not inform user about the conflict and silently shuts the other service down. There's even situation when conflicting services can be enabled at the same time but only one of them ends up active after boot. If requested by used, the other service is just brought down without explanation in logs.
With that in mind, we'd have to prefer firewalld to win this situation when both services are requested to start in one transaction. Some mechanism currently does that.
Comment 4 Eric Garver 2020-04-14 11:49:25 UTC 
Upstream:

ecc53ab23be5 ("fix(systemd): Conflict with nftables.service")
Comment 14 RobbieTheK 2020-07-28 18:39:05 UTC 
Still getting this on Fedora 32, firewalld-0.8.3-1.fc32.noarch
firewall-cmd --reload
Error: COMMAND_FAILED: 'python-nftables' failed:
JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"table": {"family": "inet", "name": "firewalld_policy_drop"}}}, {"add": {"chain": {"family": "inet", "table": "firewalld_policy_drop", "name": "filter_input", "type": "filter", "hook": "input", "prio": 9, "policy": "drop"}}}, {"add": {"chain": {"family": "inet", "table": "firewalld_policy_drop", "name": "filter_forward", "type": "filter", "hook": "forward", "prio": 9, "policy": "drop"}}}, {"add": {"chain": {"family": "inet", "table": "firewalld_policy_drop", "name": "filter_output", "type": "filter", "hook": "output", "prio": 9, "policy": "drop"}}}, {"add": {"rule": {"family": "inet", "table": "firewalld_policy_drop", "chain": "filter_input", "expr": [{"match": {"left": {"ct": {"key": "state"}}, "op": "in", "right": {"set": ["established", "related"]}}}, {"accept": null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld_policy_drop", "chain": "filter_forward", "expr": [{"match": {"left": {"ct": {"key": "state"}}, "op": "in", "right": {"set": ["established", "related"]}}}, {"accept": null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld_policy_drop", "chain": "filter_output", "expr": [{"match": {"left": {"ct": {"key": "state"}}, "op": "in", "right": {"set": ["established", "related"]}}}, {"accept": null}]}}}]}
Comment 15 Eric Garver 2020-07-28 19:10:48 UTC 
(In reply to RobbieTheK from comment #14)
> Still getting this on Fedora 32, firewalld-0.8.3-1.fc32.noarch

This report is against RHEL-8.2. Not Fedora. Please file a report against Fedora 32.
Comment 16 Jun Aruga 2020-08-28 12:34:13 UTC 
> This report is against RHEL-8.2. Not Fedora. Please file a report against Fedora 32.

Possibly the following existing ticket is about this issue on Fedora 32.
https://bugzilla.redhat.com/show_bug.cgi?id=1836571
Comment 20 errata-xmlrpc 2020-11-04 01:40:13 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.