Firewalld config updated in 9.5

After taking an update for firewalld, the config file is being replaced with a new one (Nov 4) with “new” config variables that the the updated firewalld doesn’t like. Oddly if I use the firewalld.conf from 9.4 against the updated firewalld it doesn’t have these Errors/Warnings.
I happened to check the github project for firewalld and see these config variables recently updated. Possible that the firewalld in the 9.5 repo and the config are out of sync regarding these new features?

firewalld-1.3.4-7.el9.noarch

Errors in /var/log/messages

firewalld[942]: ERROR: Invalid option: 'ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP'
firewalld[942]: ERROR: Invalid option: 'NftablesTableOwner=yes'
firewalld[942]: WARNING: IPv6_rpfilter 'strict' is not valid, using default value True
firewalld[942]: ERROR: Invalid option: 'ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP'
firewalld[942]: ERROR: Invalid option: 'NftablesTableOwner=yes'
firewalld[942]: WARNING: IPv6_rpfilter 'strict' is not valid, using default value True

Previous firewalld.conf vs new firewalld.conf

old

# IPv6_rpfilter
# Performs a reverse path filter test on a packet for IPv6. If a reply to the
# packet would be sent via the same interface that the packet arrived on, the
# packet will match and be accepted, otherwise dropped.
# The rp_filter for IPv4 is controlled using sysctl.
# Note: This feature has a performance impact. See man page FIREWALLD.CONF(5)
# for details.
# Default: yes
IPv6_rpfilter=yes

New (Nov 4)

# IPv6_rpfilter
# Performs reverse path filtering (RPF) on IPv6 packets as per RFC 3704.
# Possible values:
#   - strict: Performs "strict" filtering as per RFC 3704. This check
#             verifies that the in ingress interface is the same interface
#             that would be used to send a packet reply to the source. That
#             is, ingress == egress.
#   - loose: Performs "loose" filtering as per RFC 3704. This check only
#            verifies that there is a route back to the source through any
#            interface; even if it's not the same one on which the packet
#            arrived.
#   - strict-forward: This is almost identical to "strict", but does not perform
#                     RPF for packets targeted to the host (INPUT).
#   - loose-forward: This is almost identical to "loose", but does not perform
#                    RPF for packets targeted to the host (INPUT).
#   - no: RPF is completely disabled.
#
# The rp_filter for IPv4 is controlled using sysctl.
# Note: This feature has a performance impact. See man page FIREWALLD.CONF(5)
# for details.
# Default: strict
IPv6_rpfilter=strict

Old
Reload Policy did not exist

New (Nov 4)

# ReloadPolicy
# Policy during reload. By default all traffic except for established
# connections is dropped while the rules are updated. Set to "DROP", "REJECT"
# or "ACCEPT". Alternatively, specify it per table, like
# "OUTPUT:ACCEPT,INPUT:DROP,FORWARD:REJECT".
# Default: ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP
ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP

Old
NfttablesTableOwner did not exist

New (Nov 4)

# NftablesTableOwner
# If set to yes, the generated nftables rule set will be owned exclusively by
# firewalld. This prevents other entities from mistakenly (or maliciously)
# modifying firewalld's rule set. If you intentionally modify firewalld's
# rules, then you will have to set this to "no".
# Defaults to "yes".
NftablesTableOwner=yes

First, could you use code tags on the post as the markdown here uses hashtag …

Second, I do have firewalld-1.3.4-7.el9 of AlmaLinux 9 and its (unmodified) config file has:

# grep "^[^#]" /etc/firewalld/firewalld.conf 
DefaultZone=public
CleanupOnExit=yes
CleanupModulesOnExit=no
Lockdown=no
IPv6_rpfilter=strict
IndividualCalls=no
LogDenied=off
FirewallBackend=nftables
FlushAllOnReload=yes
ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP
RFC3964_IPv4=yes
NftablesTableOwner=yes

Does not produce any such error messages.


The /etc/firewalld/firewalld.conf ought to be in the package firewalld with the rest of the service and thus them getting “out of sync” sounds like a remarkable feat.

Is it possible that the update of the package did somehow fail and that your service still uses the old version?

rpm -V firewalld

no issues with firewalld install according to rpm -V firewalld.
I’ve duplicated this behavior on 7 servers now so far with this issue.
As a test I made a commented out change to firewalld.conf “before” updating it, and as predicted it did not modify the original config file, but produced an .rpmnew with the “new” entries, and no errors in /var/log/messages.

I see as of Feb 4 there is a 1.3.4-9.el9_5.noarch, but has the same issues trying to use new config variables.

1.3.4-7.el9 (Nov 4)
-rwxr-xr-x 1 root root 9989 Nov  4 20:53 /usr/sbin/firewalld
72da338d2bbea7c3cf509c90a146ab81  /usr/sbin/firewalld
1.3.4-9.el9_5 (Feb 4)
-rwxr-xr-x 1 root root 9989 Feb  4 03:33 /usr/sbin/firewalld
72da338d2bbea7c3cf509c90a146ab81  /usr/sbin/firewalld

The service does use the old “modified” config file and is naturally fine with it. (Not sure whether the “proper new” service would say anything about “missing new config” that the old file lacks.)

The /usr/sbin/firewalld is a Python script. It has actually identical size and md5sum in AlmaLinux 9, so it is probably identical to what is in RHEL 9 too. The main point is though that the relevant changes are most likely in some another file.

On AlmaLinux 9:

# dnf install firewalld
Dependencies resolved.
================================================================================
 Package                  Arch       Version            Repository         Size
================================================================================
Installing:
 firewalld                noarch     1.3.4-7.el9        baseos        452 k
Installing dependencies:
 firewalld-filesystem     noarch     1.3.4-7.el9        baseos        8.6 k
 ipset                    x86_64     7.11-8.el9         baseos         42 k
 ipset-libs               x86_64     7.11-8.el9         baseos         69 k
 python3-firewall         noarch     1.3.4-7.el9        baseos        355 k
 python3-nftables         x86_64     1:1.0.9-3.el9      baseos         20 k
Installing weak dependencies:
 libcap-ng-python3        x86_64     0.8.2-7.el9        appstream      29 k

Transaction Summary
================================================================================
Install  7 Packages

You could check all those, and also look at rpm -q --changelog firewalld

I’m starting to believe that possibly during the rpm install the config is getting updated and reloading firewalld without firewalld actually being updated?

Here is the sequence of events

Feb  5 07:23:21 server firewalld[942]: ERROR: Invalid option: 'ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP'
Feb  5 07:23:21 server firewalld[942]: ERROR: Invalid option: 'NftablesTableOwner=yes'
Feb  5 07:23:21 server firewalld[942]: WARNING: IPv6_rpfilter 'strict' is not valid, using default value True
Feb  5 07:23:42 server firewalld[942]: ERROR: Invalid option: 'ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP'
Feb  5 07:23:42 server firewalld[942]: ERROR: Invalid option: 'NftablesTableOwner=yes'
Feb  5 07:23:42 server firewalld[942]: WARNING: IPv6_rpfilter 'strict' is not valid, using default value True
Feb  5 07:23:42 server firewalld[942]: ERROR: Invalid option: 'ReloadPolicy=INPUT:DROP,FORWARD:DROP,OUTPUT:DROP'
Feb  5 07:23:42 server firewalld[942]: ERROR: Invalid option: 'NftablesTableOwner=yes'
Feb  5 07:23:42 server firewalld[942]: WARNING: IPv6_rpfilter 'strict' is not valid, using default value True
Feb  5 07:25:45 server systemd[1]: Stopping firewalld - dynamic firewall daemon...
Feb  5 07:25:45 server systemd[1]: firewalld.service: Deactivated successfully.
Feb  5 07:25:45 server systemd[1]: Stopped firewalld - dynamic firewall daemon.
Feb  5 07:25:45 server systemd[1]: firewalld.service: Consumed 1.345s CPU time.
Feb  5 07:25:45 server systemd[1]: Starting firewalld - dynamic firewall daemon...
Feb  5 07:25:46 server systemd[1]: Started firewalld - dynamic firewall daemon.

dnf log

2025-02-05T07:21:32-0600 DEBUG ---> Package firewalld-filesystem.noarch 1.3.4-1.el9 will be upgraded
2025-02-05T07:21:32-0600 DEBUG ---> Package firewalld-filesystem.noarch 1.3.4-7.el9 will be an upgrade
2025-02-05T07:21:32-0600 DEBUG ---> Package firewalld.noarch 1.3.4-1.el9 will be upgraded
2025-02-05T07:21:32-0600 DEBUG ---> Package firewalld.noarch 1.3.4-7.el9 will be an upgrade
 firewalld                                        noarch                      1.3.4-7.el9                                      baseos                         453 k
 firewalld-filesystem                             noarch                      1.3.4-7.el9                                      baseos                         8.7 k
2025-02-05T07:26:08-0600 DEBUG Upgraded: firewalld-1.3.4-7.el9.noarch
2025-02-05T07:26:08-0600 DEBUG Upgraded: firewalld-filesystem-1.3.4-7.el9.noarch
2025-02-05T07:26:08-0600 DDEBUG /var/cache/dnf/baseos-522ed8e2b2f761ff/packages/firewalld-1.3.4-7.el9.noarch.rpm removed
2025-02-05T07:26:08-0600 DDEBUG /var/cache/dnf/baseos-522ed8e2b2f761ff/packages/firewalld-filesystem-1.3.4-7.el9.noarch.rpm removed

After you said didn’t see the issue I restarted firewalld on a few servers and it didn’t re-reproduce the error. I should have thought of that before.

is mentioned within the files of python3-firewall

Package update essentially installs files of new version, removes files of old version, and for services usually restarts the service.

The last step ought to be by the scripts in the package. See rpm -q --scripts firewalld
Looks like it delegates the service restart to systemd (to occur when?).

thank you for your time! I’ll concentrate on the the new config variables to merge and not worry about the weirdness of the install.