Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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:
Direct rules rely on legacy iptables tools even if nftables backend is newly used by default.
This introduces implicit and non-intuitive behaviour of subjecting network traffic to both iptables (direct rules) and nftables (main firewalld rules), hence ACCEPT target in direct rules is not definitive and firewalld ruleset must be adjusted.
This request is to put this information suitably (wording, references) into man pages of firewall-cmd(1) and firewalld.direct(5). Recommended resolution for nftables use should be included.
Version-Release number of selected component (if applicable):
firewalld-0.6.3-7.el8.noarch
Actual results:
firewall-cmd(1)
Direct Options
The direct options give a more direct access to the firewall. These options require user to know basic
iptables concepts, i.e. table (filter/mangle/nat/...), chain (INPUT/OUTPUT/FORWARD/...), commands
(-A/-D/-I/...), parameters (-p/-s/-d/-j/...) and targets (ACCEPT/DROP/REJECT/...).
Direct options should be used only as a last resort when it's not possible to use for example
--add-service=service or --add-rich-rule='rule'.
The first argument of each option has to be ipv4 or ipv6 or eb. With ipv4 it will be for IPv4 (iptables(8)),
with ipv6 for IPv6 (ip6tables(8)) and with eb for ethernet bridges (ebtables(8)).
firewalld.direct(5):
DESCRIPTION
Direct configuration gives a more direct access to the firewall. It requires user to know basic
ip(6)tables/ebtables concepts, i.e. table (filter/mangle/nat/...), chain (INPUT/OUTPUT/FORWARD/...),
commands (-A/-D/-I/...), parameters (-p/-s/-d/-j/...) and targets (ACCEPT/DROP/REJECT/...). Direct
configuration should be used only as a last resort when it's not possible to use firewalld.zone(5). See also
Direct Options in firewall-cmd(1).
A firewalld direct configuration file contains informations about permanent direct chains, rules and
passthrough ...
Expected results:
specifics of and directions for direct rules usage with nftables backend
Additional info:
Comment 3Erinn Looney-Triggs
2019-12-09 22:52:29 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, 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/RHEA-2020:1836
Description of problem: Direct rules rely on legacy iptables tools even if nftables backend is newly used by default. This introduces implicit and non-intuitive behaviour of subjecting network traffic to both iptables (direct rules) and nftables (main firewalld rules), hence ACCEPT target in direct rules is not definitive and firewalld ruleset must be adjusted. This request is to put this information suitably (wording, references) into man pages of firewall-cmd(1) and firewalld.direct(5). Recommended resolution for nftables use should be included. Version-Release number of selected component (if applicable): firewalld-0.6.3-7.el8.noarch Actual results: firewall-cmd(1) Direct Options The direct options give a more direct access to the firewall. These options require user to know basic iptables concepts, i.e. table (filter/mangle/nat/...), chain (INPUT/OUTPUT/FORWARD/...), commands (-A/-D/-I/...), parameters (-p/-s/-d/-j/...) and targets (ACCEPT/DROP/REJECT/...). Direct options should be used only as a last resort when it's not possible to use for example --add-service=service or --add-rich-rule='rule'. The first argument of each option has to be ipv4 or ipv6 or eb. With ipv4 it will be for IPv4 (iptables(8)), with ipv6 for IPv6 (ip6tables(8)) and with eb for ethernet bridges (ebtables(8)). firewalld.direct(5): DESCRIPTION Direct configuration gives a more direct access to the firewall. It requires user to know basic ip(6)tables/ebtables concepts, i.e. table (filter/mangle/nat/...), chain (INPUT/OUTPUT/FORWARD/...), commands (-A/-D/-I/...), parameters (-p/-s/-d/-j/...) and targets (ACCEPT/DROP/REJECT/...). Direct configuration should be used only as a last resort when it's not possible to use firewalld.zone(5). See also Direct Options in firewall-cmd(1). A firewalld direct configuration file contains informations about permanent direct chains, rules and passthrough ... Expected results: specifics of and directions for direct rules usage with nftables backend Additional info: