Bug 1378610 - Public interface sometimes loses it's zone and applying new firewalld rules fails
Summary: Public interface sometimes loses it's zone and applying new firewalld rules f...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 25
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-22 23:09 UTC by David Hill
Modified: 2016-10-03 22:18 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-03 22:18:07 UTC
Type: Bug


Attachments (Terms of Use)

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.


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