Bug 1817205
| Summary: | firewalld rules broken by nftables service if started later | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Tomas Dolezal <todoleza> |
| Component: | firewalld | Assignee: | Eric Garver <egarver> |
| Status: | CLOSED ERRATA | QA Contact: | Tomas Dolezal <todoleza> |
| Severity: | high | Docs Contact: | Sagar Dubewar <sdubewar> |
| Priority: | high | ||
| Version: | 8.2 | CC: | egarver, jaruga, jmaxwell, lmanasko, pasik, psutter, qe-baseos-daemons, rkudyba, todoleza |
| Target Milestone: | rc | ||
| Target Release: | 8.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 01:40:13 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1807630 | ||
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? (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. 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. Upstream:
ecc53ab23be5 ("fix(systemd): Conflict with nftables.service")
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}]}}}]}
(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. > 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 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 |
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: