Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-9316

RFE: firewall-cmd should be able to deal with nft-rules with "burst"

XMLWordPrintable

    • firewalld-0.9.11-8.el8_10
    • None
    • rhel-sst-networking-core
    • ssg_networking
    • 20
    • 5
    • False
    • Yes
    • None
    • Enhancement
    • Hide
      Feature, enhancement (describe the feature or enhancement from the user's point of view): The firewalld rich language feature "limit" now supports a "burst" argument.
      Reason (why has the feature or enhancement been implemented): This allows adding a "brust" to the rate limiter for accept/drop/etc.
      Result (what is the current user experience): Users can now control the burstiness of their rich rules.
      Show
      Feature, enhancement (describe the feature or enhancement from the user's point of view): The firewalld rich language feature "limit" now supports a "burst" argument. Reason (why has the feature or enhancement been implemented): This allows adding a "brust" to the rate limiter for accept/drop/etc. Result (what is the current user experience): Users can now control the burstiness of their rich rules.
    • Proposed
    • None

      Description of problem:
      Via rich rules, one can use for example

      1. firewall-cmd --permanent --zone=XXX --add-rich-rule='rule family="ipv4" source address=192.168.4.0/24 service name=all log prefix="IN_BOUND_XXX " level="info" limit value="2/d" accept'
        Once bz2181406 is implemented, that will create nft like the following command work create:
      2. nft add rule inet firewalld filter_IN_public_log ip saddr 192.168.4.0/24 \
        tcp dport 22 ct state { new, untracked } \
        limit rate 2/day log prefix "IN_BOUND_XXXX " level info

        The issue is that firewall-cmd does not handle the nft "burst" option. Above will assume "burst 5 packets", but to set the limit of 2/day, we would need firewall-cmd to handle burst, so it creates a rule like this:
        # nft add rule inet firewalld filter_IN_public_log ip saddr 192.168.4.0/24 \
        tcp dport 22 ct state { new, untracked }

        \
        limit rate 2/day burst 1 packets log prefix "IN_BOUND_XXXX " level info

      firewall-cmd might instead of the nft utility use a different interface.

      Version-Release number of selected component (if applicable):
      all

      How reproducible:
      always

      Expected outcome:
      firewall-cmd should be extended to create nft rules which allow setting of burst, i.e. "burst 1 packets".

            [RHEL-9316] RFE: firewall-cmd should be able to deal with nft-rules with "burst"

            Errata Tool added a comment -

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            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-2024:5311

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. 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-2024:5311

            Christian Horn added a comment -

            Our partner is biweekly inquiring about the status. Do we know if we get this fix into rhel8? I think 8.10 will be the last chance for this kind of change.

            Christian Horn added a comment - Our partner is biweekly inquiring about the status. Do we know if we get this fix into rhel8? I think 8.10 will be the last chance for this kind of change.

            Marcelo Leitner added a comment -

            Please add Story points sometime soon. Thanks.

            Marcelo Leitner added a comment - Please add Story points sometime soon. Thanks.

            Christian Horn added a comment -

            Thanks!

            Christian Horn added a comment - Thanks!

            Eric Garver added a comment -

            It was set to "In Progress" because it was being worked on upstream. But it's not in progress downstream so I reverted it back to Planning.

            "In Progress" really should mean "being backported to RHEL".

            Eric Garver added a comment - It was set to "In Progress" because it was being worked on upstream. But it's not in progress downstream so I reverted it back to Planning. "In Progress" really should mean "being backported to RHEL".

            Christian Horn added a comment - - edited

            Any details on the status change from "in progress" back to "planning"?

            Christian Horn added a comment - - edited Any details on the status change from "in progress" back to "planning"?

            Thomas Haller added a comment -

            WIP: https://github.com/firewalld/firewalld/pull/1262

            Thomas Haller added a comment - WIP: https://github.com/firewalld/firewalld/pull/1262

            RHEL Jira bot added a comment -

            This issue has been marked unblocked.

            RHEL Jira bot added a comment - This issue has been marked unblocked.

            RHEL Jira bot added a comment -

            IMPORTANT NOTE - This is issue was marked BLOCKED. DO NOT MERGE CODE CHANGES related to this ticket until the blocking reasons are resolved.

            RHEL Jira bot added a comment - IMPORTANT NOTE - This is issue was marked BLOCKED. DO NOT MERGE CODE CHANGES related to this ticket until the blocking reasons are resolved.

            Christian Horn added a comment -

            Can we get an opinion on how likely it is to get this implemented at some point? When we opened the RFE, it sounded likely.. but now this has been forever, and our partner is asking for status updates frequently. If this is not going to happen, then announcing that freely would be better.

            Christian Horn added a comment - Can we get an opinion on how likely it is to get this implemented at some point? When we opened the RFE, it sounded likely.. but now this has been forever, and our partner is asking for status updates frequently. If this is not going to happen, then announcing that freely would be better.

              egarver Eric Garver
              rhn-support-chorn Christian Horn
              Thomas Haller Thomas Haller
              Tomas Dolezal Tomas Dolezal
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: