Bug 1112742
| 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> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | ctubbsii, jpopelka, jscotka, Klaus.Arndt, matthew, pasik, peljasz, pierre-yves.goubet, riehecky, swadeley, tiangolo, todoleza |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | firewalld-0.3.9-8.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 13:23:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ian Pilcher
2014-06-24 15:32:57 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. 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 |