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
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
> 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
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....
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.
*** 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:
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:
* Files in:
* 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