Bug 1378610

Summary: Public interface sometimes loses it's zone and applying new firewalld rules fails
Product: [Fedora] Fedora Reporter: David Hill <dhill>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 25CC: dcbw, dhill, erik-fedora, fgiudici, klember, lkundrak, psimerda, thaller
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-03 22:18:07 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:

Description David Hill 2016-09-22 23:09:57 UTC
Description of problem:

Public interface sometimes loses it's zone and applying new firewalld rules fails ...  A simple ifdown/ifup on that interface seems to bring it back.


[root@zappa ~]# firewall-cmd --zone=external --list-all
external
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: ssh
  ports: 67/udp 143/udp 143/tcp
  protocols: 
  masquerade: yes
  forward-ports: port=2235:proto=tcp:toport=:toaddr=192.168.1.22
	port=2236:proto=tcp:toport=:toaddr=192.168.1.22
	port=22:proto=tcp:toport=22:toaddr=192.168.1.22
	port=2235:proto=tcp:toport=2235:toaddr=192.168.1.22
  sourceports: 
  icmp-blocks: 
  rich rules: 
	
[root@zappa ~]# firewall-cmd --get-zone-of-interface eno1
no zone
[root@zappa ~]# cd /etc/sysconfig/network-scripts/
[root@zappa network-scripts]# ls
allo.sh     ifcfg-eno1.static  ifcfg-lo  ifdown-bnep  ifdown-ippp  ifdown-isdn  ifdown-ppp     ifdown-sit     ifup          ifup-bnep  ifup-ippp  ifup-isdn  ifup-plusb  ifup-ppp     ifup-sit     ifup-wireless     network-functions
ifcfg-eno1  ifcfg-eno2         ifdown    ifdown-eth   ifdown-ipv6  ifdown-post  ifdown-routes  ifdown-tunnel  ifup-aliases  ifup-eth   ifup-ipv6  ifup-plip  ifup-post   ifup-routes  ifup-tunnel  init.ipv6-global  network-functions-ipv6
[root@zappa network-scripts]# vim ficfg-eno1
[root@zappa network-scripts]# vim ifcfg-eno1
[root@zappa network-scripts]# ifdown eno1 && ifup eno1
Device 'eno1' successfully disconnected.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
[root@zappa network-scripts]# ifconfig eno1
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 74.57.34.90  netmask 255.255.255.0  broadcast 74.57.34.255
        inet6 fe80::862b:2bff:fe13:f291  prefixlen 64  scopeid 0x20<link>
        ether 84:2b:2b:13:f2:91  txqueuelen 1000  (Ethernet)
        RX packets 26494741  bytes 22502149292 (20.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25743668  bytes 16725615342 (15.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@zappa network-scripts]# firewall-cmd --get-zone-of-interface eno1
external
[root@zappa network-scripts]# iptables -nL | grep 2235
[root@zappa network-scripts]# iptables -nL -t nat | grep 2235
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            mark match 0x67 to:192.168.1.22:2235


Version-Release number of selected component (if applicable):


How reproducible:
Random


Steps to Reproduce:
1. Try adding new rules
2. 
3.

Actual results:
Doesn't apply until ifdown/ifup is done on external interface

Expected results:
Should remain whatever happens.

Additional info:
This is Fedora 25.

Comment 1 Thomas Haller 2016-09-23 06:04:14 UTC
you mean, at the beginning you'd expect the interface to be in zone "external"?

Please show the content of ifcfg-eno1, and if possible also a logfile of NetworkManager with debug-logging enabled, showing how the zone setting is lost. See https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf?id=c90ec2d8c8a12b44c908bf7f80b23059c29f68fa

Comment 3 David Hill 2016-10-03 22:18:07 UTC
I'm closing this case as I'm fairly new with firewall-cmd and this issue didn't re-occur .  I'll blame it on me probably forgetting to add --permanent when attaching the device to the external zone even though it is in the configuration file.