Bug 997688 - firewalld not respecting zones bound to interfaces
firewalld not respecting zones bound to interfaces
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-15 22:42 EDT by Nicholas Nachefski
Modified: 2014-05-12 07:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-12 06:30:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/firewalld/zones/internal.xml config file (543 bytes, text/plain)
2014-05-07 22:24 EDT, Ken Sugawara
no flags Details
/etc/firewalld/zones/public.xml config file (54 bytes, text/plain)
2014-05-07 22:24 EDT, Ken Sugawara
no flags Details
output of firewall-cmd --list-all-zones command (1.28 KB, text/plain)
2014-05-07 22:25 EDT, Ken Sugawara
no flags Details
output of iptables-save command (9.57 KB, text/plain)
2014-05-07 22:25 EDT, Ken Sugawara
no flags Details

  None (edit)
Description Nicholas Nachefski 2013-08-15 22:42:39 EDT
Updated my F19 box on Monday and rebooted.  Ever since, the zone on my external interface is effectively at the 'default' zone despite it clearly being set to 'external'.

external (active)
  interfaces: p5p1
  sources: 
  services: openvpn
  ports: 
  masquerade: yes
  forward-ports: 
  icmp-blocks: 
  rich rules: 


This looks proper, however, when i nmap my box from a remote source... my ass is showing.

PORT     STATE  SERVICE
21/tcp   closed ftp
22/tcp   open   ssh
53/tcp   open   domain
80/tcp   open   http
88/tcp   open   kerberos-sec
389/tcp  open   ldap
443/tcp  open   https
636/tcp  open   ldapssl
2049/tcp closed nfs
3128/tcp closed squid-http
5900/tcp closed vnc
5901/tcp closed vnc-1
5902/tcp closed vnc-2
5903/tcp closed vnc-3

All of those ports are enabled for the default 'dmz' profile.  It's not respecting the configured zone for that port and using the default.  obviously, this is a problem...
Comment 1 Nicholas Nachefski 2013-08-16 12:12:24 EDT
on that last commend i meant 'interface' instead of 'port'.  Also, i forgot to paste the version of the installed firewalld package.

firewalld-0.3.4-1.fc19.noarch
Comment 2 Ken Sugawara 2014-05-07 01:34:06 EDT
Let me add a me-too here. I've been seeing the same thing on Fedora 20 as well.

I'm surprised noone else's filed this, not to mention this BUG has been left unassigned for such a long time.

kernel-3.14.2-200.fc20.x86_64
firewalld-0.3.9.3-1.fc20.noarch
Comment 3 Jiri Popelka 2014-05-07 08:48:19 EDT
The problem described by Nicholas looks like a regression I introduced in
firewalld-0.3.4 and which should have been fixed [1] in firewalld-0.3.9.3.

Ken, I need to see more information, like output of:
# firewall-cmd --list-all-zones
# iptables-save


[1] https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=b2b5b88c56feffe09ddacf5ed348bc587f84160c
Comment 4 Nicholas Nachefski 2014-05-07 12:15:58 EDT
Jiri,

I can confirm that this is fixed in the current version (firewalld-0.3.9.3).
Comment 5 Ken Sugawara 2014-05-07 22:24:05 EDT
Created attachment 893502 [details]
/etc/firewalld/zones/internal.xml config file
Comment 6 Ken Sugawara 2014-05-07 22:24:37 EDT
Created attachment 893503 [details]
/etc/firewalld/zones/public.xml config file
Comment 7 Ken Sugawara 2014-05-07 22:25:10 EDT
Created attachment 893504 [details]
output of firewall-cmd --list-all-zones command
Comment 8 Ken Sugawara 2014-05-07 22:25:40 EDT
Created attachment 893505 [details]
output of iptables-save command
Comment 9 Ken Sugawara 2014-05-07 22:30:05 EDT
(In reply to Jiri Popelka from comment #3)
> Ken, I need to see more information, like output of:
> # firewall-cmd --list-all-zones
> # iptables-save

Jiri,

Please see my attachments.

Note that, although internal.xml has the following two lines,
firewall-cmd --list-all-zones lists these interfaces in the
public zone:

  <interface name="p4p1"/>
  <interface name="br0"/>

I can work around this issue by changing the default zone to
internal instead of public.

Thanks,

Ken
Comment 10 Jiri Popelka 2014-05-09 12:56:40 EDT
Are the "p4p1" and "br0" interfaces NetworkManager (NM) managed, i.e. can you see them in 'nmcli connection show' ?
If yes then NM has the last word in which zone the interface belongs and it overrules the <interface name="abc"> in <zone>.xml.
In that case you set the zone in NM GUI in General tab or add [1]
ZONE='internal' into /etc/sysconfig/network-scripts/ifcfg-p4p1

The <interface> tag was AFAIR added so one can specify zone also for non-NM managed interfaces.

BTW: I've just realized that [2] doesn't work anymore, I need to ask somebody how to do it now.


[1] http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sec-Add_Interface_to_a_Zone-edit-config.html
[2] http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sec-View_the_firewall_settings_using_NM_CLI.html
Comment 11 Ken Sugawara 2014-05-12 01:41:55 EDT
(In reply to Jiri Popelka from comment #10)
> Are the "p4p1" and "br0" interfaces NetworkManager (NM) managed, i.e. can
> you see them in 'nmcli connection show' ?

Yup:
$ nmcli connection show
NAME  UUID                                  TYPE            TIMESTAMP-REAL           
br0   d2d68553-f97e-7549-7a26-b34a26f29318  bridge          Mon May 12 14:30:13 2014 
p4p1  b41d65ff-0296-461a-8017-b4911ce51010  802-3-ethernet  Mon May 12 14:30:13 2014 


> If yes then NM has the last word in which zone the interface belongs and it
> overrules the <interface name="abc"> in <zone>.xml.

Hm, but I don't think it makes much sense since if I change DefaultZone (/etc/firewalld/firewalld.conf) to "internal", it makes the interfaces belong to the "internal" zone. If NetworkManager was the one changing zones of these interfaces, it won't make any difference, don't you think?

> In that case you set the zone in NM GUI in General tab or add [1]
> ZONE='internal' into /etc/sysconfig/network-scripts/ifcfg-p4p1

Will try. Right now, neither of ifcfg-{p4p1,br0} has ZONE= line.

> The <interface> tag was AFAIR added so one can specify zone also for non-NM
> managed interfaces.

Thanks. I will remember this.

Ken
Comment 12 Ken Sugawara 2014-05-12 02:01:58 EDT
(In reply to Ken Sugawara from comment #11)
> > In that case you set the zone in NM GUI in General tab or add [1]
> > ZONE='internal' into /etc/sysconfig/network-scripts/ifcfg-p4p1
> 
> Will try. Right now, neither of ifcfg-{p4p1,br0} has ZONE= line.

I added ZONE=internal to ifcfg-* files, reverted firewalld.conf's 
DefaultZone back to public, and rebooted. The p4p1 and br0 interfaces 
are in the "internal" zone now.

> > The <interface> tag was AFAIR added so one can specify zone also for non-NM
> > managed interfaces.
> 
> Thanks. I will remember this.

I guess this was the crux of the biscuit in the end...

Thanks,

Ken
Comment 13 Jiri Popelka 2014-05-12 06:30:57 EDT
Thanks, I'm closing this ticket as the original Nicholas' problem has been fixed in 0.3.9.3 and yours is notabug.
Comment 14 Jiri Popelka 2014-05-12 07:37:36 EDT
(In reply to Jiri Popelka from comment #10)
> BTW: I've just realized that [2] doesn't work anymore, I need to ask
> somebody how to do it now.
> 
> [2]
> http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sec-
> View_the_firewall_settings_using_NM_CLI.html

'nmcli -f all con status' is now 'nmcli -f all con show active'

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