|Summary:||firewall-cmd --permanent --change-interface=... should report an error|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Ian Pilcher <ipilcher>|
|Component:||firewalld||Assignee:||Thomas Woerner <twoerner>|
|Status:||CLOSED ERRATA||QA Contact:||Tomas Dolezal <todoleza>|
|Version:||7.0||CC:||ctubbsii, jpopelka, jscotka, Klaus.Arndt, matthew, pasik, peljasz, pierre-yves.goubet, riehecky, swadeley, tiangolo, todoleza|
|Fixed In Version:||firewalld-0.3.9-8.el7||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-03-05 13:23:19 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Ian Pilcher 2014-06-24 15:32:57 UTC
firewalld-0.3.9-7.el7.noarch on RHEL 7.0. Attempting to permanently associate eth0 with the "internal" zone: [root@localhost ~]# firewall-cmd --permanent --zone=internal --change-interface=eth0 success firewall-cmd is reporting "success" even though this command actually does absolutely nothing. (One has to add a ZONE=internal line to ifcfg-eth0.) The man page for firewall-cmd also lists a non-functional [--permanent] option for --add-interface and --remove-interface.
Comment 2 Jiri Popelka 2014-06-25 09:02:02 UTC
(In reply to Ian Pilcher from comment #0) > [root@localhost ~]# firewall-cmd --permanent --zone=internal > --change-interface=eth0 > > firewall-cmd is reporting "success" even though this command actually does > absolutely nothing. (One has to add a ZONE=internal line to ifcfg-eth0.) It adds <interface name="eth0"/> into /etc/firewalld/internal.xml This can be used for interfaces which are not NetworkManager-managed, i.e. don't have ifcfg-* file.
Comment 3 Thomas Woerner 2014-06-25 15:34:17 UTC
This is needed for all interfaces, that are not handled by NM or the network service. For tun devices for example.
Comment 4 Ian Pilcher 2014-06-25 16:22:10 UTC
(In reply to Jiri Popelka from comment #2) > > It adds <interface name="eth0"/> into /etc/firewalld/internal.xml > > This can be used for interfaces which are not NetworkManager-managed, i.e. > don't have ifcfg-* file. Aah. I did not know that. So it works, but it's overridden/ignored by NetworkManager and the network service. On the surface, that seems like an undesirable behavior. Are there reasons for it that I'm not seeing, or is it a technical limitation?
Comment 5 Jiri Popelka 2014-06-26 07:07:57 UTC
Well, it's been really meant only as a fallback mechanism for interfaces that can't be managed via NM. Which zone a network connection (interface) belongs to is a property of that connection and as such NM is the one who should have the last word here, because unlike firewalld NM has all the necessary information about the connection/interface. I should probably put some note into firewalld.zone(5)/firewall-cmd(1) about this.
Comment 7 Jiri Popelka 2014-08-05 15:37:19 UTC
(In reply to Jiri Popelka from comment #5) > I should probably put some note into firewalld.zone(5)/firewall-cmd(1) about > this. https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=8cb698c6bfde00c0104502b9beaeb594f58fb6e7
Comment 10 Klaus Arndt 2015-01-28 15:04:33 UTC
Hello, we saw here a similar issue if we execute : > sudo systemctl restart firewalld.service One of our interfaces fall back in the deafult zone... Afer a Reboot everything is fine again.... Regards Klaus
Comment 12 errata-xmlrpc 2015-03-05 13:23:19 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://rhn.redhat.com/errata/RHBA-2015-0520.html
Comment 13 Jiri Popelka 2015-04-02 12:10:04 UTC
*** Bug 1174909 has been marked as a duplicate of this bug. ***
Comment 15 Christopher Tubbs 2015-12-12 00:00:32 UTC
I ran into this today. It's very confusing, because my ifcfg-eth0 file does not specify `ZONE=...` at all. The zone change worked when I tested doing a `firewall-cmd --complete-reload`, but was reset to the system's default zone upon reboot (or `systemctl restart firewalld.service`). Perhaps this command should not report "success", and instead issue a warning, perhaps based on the interface (like, if it has an ifcfg script). At the very *least*, the behavior of a complete reload and a service restart should be consistent. I think this issue should be reopened. The issue still affects: firewalld-0.3.9-11.el7.noarch
Comment 16 Tomas Dolezal 2016-08-01 13:39:42 UTC
Hello, in next release the zone-interface mapping is done via NetworkManager if running, or in adequate ifcfg-* file in /etc/sysconfig/network-scripts/. In case that NM is not running, the information is written into such existing file. Else, internal informatin is kept in zone config file in /etc/firewalld/zones/.
Comment 17 Sebastián Ramírez 2017-01-13 17:16:33 UTC
I think I came across the same or a similar issue. The problem seemed to be that FirewallD is misbehaving while communicating with NetworkManager, specially during boot time. FirewallD reads configurations from 3 places: * Files in: /etc/sysconfig/network-scripts/ifcfg-* * Files in: /etc/firewalld/zones/*.xml * Messages from NetworkManager via D-Bus And FirewallD writes those ifcfg files if NetworkManager is running, but otherwise it writes the other zone *.xml files. And at boot time, it seems like FirewallD is being unable to communicate with NetworkManager (maybe by that time NetworkManager has not yet published the D-Bus messages). My current workaround ends up in having *.xml files AND ifcfg files for the same configuration. I reported the full issue with all the details and a workaround in the FirewallD repo: https://github.com/t-woerner/firewalld/issues/195