Bug 1112742 - firewall-cmd --permanent --change-interface=... should report an error
Summary: firewall-cmd --permanent --change-interface=... should report an error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Thomas Woerner
QA Contact: Tomas Dolezal
URL:
Whiteboard:
: 1174909 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-24 15:32 UTC by Ian Pilcher
Modified: 2019-04-16 14:12 UTC (History)
12 users (show)

Fixed In Version: firewalld-0.3.9-8.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 13:23:19 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0520 normal SHIPPED_LIVE firewalld bug fix and enhancement update 2015-03-05 16:33:07 UTC

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

Comment 18 Matthew Sanabria 2017-01-17 04:45:47 UTC
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


Note You need to log in before you can comment on or make changes to this bug.