NetworkManager and firewalld - Zone is lost on network restart

Hello,

I have a firewalld config with two interfaces, each assigned to its own zone. One is internal, one is external. This has worked fine for about 6 months, but after the latest patch cycle we have an issue. I have read a couple recent threads/bugs on related topics:

• https://bugzilla.redhat.com/show_bug.cgi?id=1112742
• https://access.redhat.com/discussions/1455033

Here is the issue - replicated with test-cases. First, here is my expected config (before the patch cycle):

# firewall-cmd --get-active-zones
my_external_zone
  interfaces: em1
my_internal_zone
  interfaces: p1p1

Here is the issue. After the last patch cycle and reboot I have the following:

# firewall-cmd --get-active-zones
my_external_zone
  interfaces: em1
drop
  interfaces: p1p1

In other words, interface p1p1 lost it's zone (which was configured via nmcli and present in the network-scripts/ifcfg-p1p1 file)

Here is the test case I just ran, which makes me think there is a bug, or perhaps that I am doing something obvious wrong and not seeing my error:

First, I removed the p1p1 interface from the default drop zone:

# firewall-cmd --permanent --zone=drop --remove-interface=p1p1
The interface is under control of NetworkManager and already bound to the default zone
The interface is under control of NetworkManager, setting zone to default.
success

Then, I added the p1p1 interface to the desired zone:

# firewall-cmd --permanent --zone=my_internal_zone --add-interface=p1p1
The interface is under control of NetworkManager, setting zone to 'my_internal_zone'.
success
# firewall-cmd --reload
# firewall-cmd --get-active-zones
my_external_zone
  interfaces: em1
my_internal_zone
  interfaces: p1p1

Then, I verified by checking the network-scripts/ifcfg-p1p1 file:

# cat /etc/sysconfig/network-scripts/ifcfg-p1p1
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=p1p1
DEVICE=p1p1
ONBOOT=yes
IPADDR=192.168.1.1
PREFIX=24
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
ZONE=my_internal_zone

Looks good! I thought the problem was solved at this point. Nope - I restarted networking and checked again:

# systemctl restart network
# firewall-cmd --get-active-zones
my_external_zone
  interfaces: em1
drop
  interfaces: p1p1
# cat /etc/sysconfig/network-scripts/ifcfg-p1p1
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=p1p1
DEVICE=p1p1
ONBOOT=yes
IPADDR=192.168.1.1
PREFIX=24
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

The interface has lost its zone. I reproduced the same results with a full reboot. Then, I tried the same test using nmcli as opposed to firewall-cmd:

# nmcli connection modify p1p1 connection.zone my_internal_zone
# cat /etc/sysconfig/network-scripts/ifcfg-p1p1
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=p1p1
DEVICE=p1p1
ONBOOT=yes
IPADDR=192.168.1.1
PREFIX=24
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
ZONE=my_internal_zone

So far so good. Then, I restarted network services and checked again:

# cat /etc/sysconfig/network-scripts/ifcfg-p1p1
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=p1p1
DEVICE=p1p1
ONBOOT=yes
IPADDR=192.168.1.1
PREFIX=24
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

So, again, the interface has lost its zone after it was set via nmcli and added to the network-scripts/ifcfg-p1p1 file.

Does anyone see anything obvious I am doing wrong here? If not, this seems like a pretty significant bug that was introduced in a recent patch. The last thing in the world any of us want is for all these MANY different and inter-operating configuration commands to affect things like our network configuration, which very seldom changes and in most cases (on the server at least) really needs to stay stable and static.

Thanks for any advise you can offer - especially those of you from RedHat monitoring these discussion threads.