Red Hat Bugzilla – Bug 1112742
firewall-cmd --permanent --change-interface=... should report an error
Last modified: 2017-01-16 23:45:47 EST
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.
(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.
This is needed for all interfaces, that are not handled by NM or the network service. For tun devices for example.
(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?
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.
(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
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
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
*** Bug 1174909 has been marked as a duplicate of this bug. ***
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
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/.
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
I confirmed this behavior on CentOS 7.2.1511 and CentOS 7.3.1611. Also commented my workaround in the aforementioned URL: https://github.com/t-woerner/firewalld/issues/195