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:
NetworkManager service restart is required after installation of FirewallD, in order to get the currently active zone.
Version-Release number of selected component (if applicable):
100%
How reproducible:
firewalld-0.4.3.2-8.1.el7_3.2
Steps to Reproduce:
1. Install RHEL
2. Configure network interfaces using legacy network scripts
3. Install FirewallD and start the service
4. run firewall-cmd --get-active-zone
Actual results:
It returns nothing
Expected results:
It should return a currently active zone, in my case it should be:
public
interfaces: eth0 eth1
Additional info:
In order to fix the situation one needs to restart the NetWorkManager service following the installation of the Firewalld.
I tried to use the most updated version of the NetworkManager, kernel etc. and still getting the same result.
Interestingly enough it seems to work just fine on CentOS 7.3.
One can use Lago to easily build a reproducible working env., I used rhv-suite-4.1 and manually added latest RHEL 7.3 repo to test with the latest available packages.
Tested with:
NetworkManager-1.4.0-17.el7_3.x86_64 and NetworkManager-1.4.0-12.el7_3.x86_64
3.10.0-514.16.1.el7.x86_64 and 3.10.0-514.el7.x86_64
There are these messages in the /var/log/messages before the NetworkManager service is restarted after the FirewallD installation:
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus-daemon: dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus-daemon: dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine dbus[695]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")
Mar 28 11:10:05 lago-rhv-suite-4-1-engine NetworkManager[715]: <warn> [1490713805.6565] firewall: [0x7f4b8368dcd0,change:"eth0"]: complete: request failed (Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -"))
Mar 28 11:10:05 lago-rhv-suite-4-1-engine NetworkManager[715]: <warn> [1490713805.6568] firewall: [0x7f4b83643890,change:"eth1"]: complete: request failed (Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -"))
The firewalld service is not started automatically after installation of the firewalld package. Because of this I do not understand why firewalld should restart NetworkManager in the firewalld installation process.
Restarting NetworkManager might result in a connection loss, therefore this is something that should not be done in my opinion.
Maybe the NetworkManager team could reveal why the access to the firewalld D-Bus interface is an issue here as the error is happening in NetworkManager.
(In reply to Thomas Woerner from comment #3)
> The firewalld service is not started automatically after installation of the
> firewalld package. Because of this I do not understand why firewalld should
> restart NetworkManager in the firewalld installation process.
>
> Restarting NetworkManager might result in a connection loss, therefore this
> is something that should not be done in my opinion.
>
> Maybe the NetworkManager team could reveal why the access to the firewalld
> D-Bus interface is an issue here as the error is happening in NetworkManager.
Hi Thomas,
The end result is that FirewallD (firewall-cmd) doesn't properly return information, and I'm not entirely sure for the reason. It would be nice if you could debug it from your side, to get more information, including more details where the request fails exactly, and so, if after that you're 100% certain that the issue is not in the FirewallD, but in the NetworkManager code, it would be easier for them to pinpoint the issue, and hopefully also get a faster resolution.
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/RHSA-2017:2299