RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0520 0 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.