Bug 821938 - firewalld doesn't work after service restart when not using NetworkManager
firewalld doesn't work after service restart when not using NetworkManager
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
: Reopened
: 812020 876390 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-15 15:42 EDT by Andrew McNabb
Modified: 2015-03-10 09:17 EDT (History)
6 users (show)

See Also:
Fixed In Version: firewalld-0.2.12-1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-15 07:13:51 EST
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)
firewall-cmd --list=all (41 bytes, text/plain)
2012-05-16 13:11 EDT, Andrew McNabb
no flags Details
iptables -L (6.12 KB, text/plain)
2012-05-16 13:12 EDT, Andrew McNabb
no flags Details

  None (edit)
Description Andrew McNabb 2012-05-15 15:42:44 EDT
With firewalld-0.2.5-1.fc17.noarch, I ran `firewall-cmd --add --service=ssh` as described on the Fedora firewalld-default feature page. Unfortunately, it continues to block ssh connections. If I do `service firewalld stop`, then ssh connections can proceed. If I do `service firewalld start`, then new ssh connections are again blocked, though established connections continue.
Comment 1 Andrew McNabb 2012-05-15 15:43:40 EDT
Hmm. Established connections only seem to continue if I run `firewall-cmd --add --service=ssh` immediately after starting firewalld.
Comment 2 Jiri Popelka 2012-05-16 07:11:44 EDT
Can you attach output of 'firewall-cmd --list=all' and 'iptables -L' before and after running 'firewall-cmd --add --service=ssh'.

Are you running NetworkManager ?
Comment 3 Andrew McNabb 2012-05-16 13:11:09 EDT
Created attachment 585020 [details]
firewall-cmd --list=all
Comment 4 Andrew McNabb 2012-05-16 13:12:54 EDT
Created attachment 585021 [details]
iptables -L

I have attached the output of `firewall-cmd --list=all` and `iptables -L`. When I then ran `firewall-cmd --add --service=ssh`, it reported, "Error: ALREADY_ENABLED", and incoming ssh connections fail with "ssh: connect to host testvm port 22: No route to host".

This machine is not using NetworkManager.
Comment 5 Jiri Popelka 2012-05-17 07:32:24 EDT
(In reply to comment #3)
> # firewall-cmd --list=all
> zone: public
> services: dhcpv6-client ssh

Which means that there's no network interface in the default ('public') zone.

(In reply to comment #4)
> When I then ran `firewall-cmd --add --service=ssh`, it reported, "Error:
> ALREADY_ENABLED"

Yes, as you can see the 'ssh' service had already been enabled in 'public' zone.
Problem is that your network interface is not in this zone (it's probably not in any zone).

> This machine is not using NetworkManager.

This is the cause ! Firewalld relies on NM.
The zone is actually a property of the connection (interface),
stored in /etc/sysconfig/network-scripts/ifcfg-<iface> as ZONE=<zone> (default if missing). It's the NM who manipulates this property and tells firewalld
what connection (interface) belongs into which zone.
If firewalld is (re)started NM (re)informs it again about this, because
firewalld itself doesn't store this information anywhere.

Initscripts (aka network service) also inform (bug #802415) firewalld about the zone when the interface goes up/down but because initscripts are only a one-shot scripts and not a running service, they are unable to reinform firewalld about the zone when firewalld restarts.

At the moment I'm not sure how to clearly solve this.
Probably to disable firewalld if NM is also disabled ?
That would mean that bug #802415 is nonsense because firewalld
is not able to properly work without NM, i.e. with network service.
Comment 6 Andrew McNabb 2012-05-17 11:31:25 EDT
(In reply to comment #5)
> At the moment I'm not sure how to clearly solve this.
> Probably to disable firewalld if NM is also disabled ?
> That would mean that bug #802415 is nonsense because firewalld
> is not able to properly work without NM, i.e. with network service.

Failing with an error sounds much better than silently locking you out of your system. :)

I think most (or all) people who are using initscripts instead of NetworkManager would plan on disabling firewalld anyway. And supporting both in firewalld sounds like a lot of work without much benefit.
Comment 7 Jiri Popelka 2012-05-18 10:57:58 EDT
I forgot to add that the workaround to this problem is to run
'firewall-cmd --add --interface=<iface>'
after you restart the firewalld service.
Comment 8 Jiri Popelka 2012-05-23 12:14:09 EDT
*** Bug 812020 has been marked as a duplicate of this bug. ***
Comment 9 cornel panceac 2012-09-30 02:19:16 EDT
Hello, i see a similar problem in F18 (i can not connect to ssh with firewalld started and iptables stopped, xor firewalld stopped and firewalld started) and i do use NM. attempting the workaround from comment #t, i get: "option --add: not a unique prefix". the command was:

firewall-cmd --add --interface=em1

after 

systemctl stop firewalld.service 

, i still can not connect with ssh.
Comment 10 cornel panceac 2012-09-30 02:49:32 EDT
ok, the should have been "comment #7" :)

i've discovered firewalld-applet was not installed. after installing it, no useful change (only i can no longer login to my account (in gnome), but this is another problem). i've tried:

firewall-cmd --add-interface=em1

and i got:

Error: ZONE_ALREADY_SET

i tried again,

firewall-cmd --add-service=ssh

and i got:

Error: ALREADY_ENABLED

nmap localhost (on server) shows a lot of ports opened (ssh, among them),
nmap <server ip> shows no port is opened. 

this is both with firewalld.service running, or stopped.
Comment 11 Jiri Popelka 2012-10-01 05:31:42 EDT
(In reply to comment #9)
> and i do use NM

cornel, if you use NM then it's different bug. Please fill a separate bug report and attach output of the following commands after you start the machine and after you restart firewalld:

firewall-cmd --list-all
iptables-save | grep IN_ZONE_public_allow

also attach /var/log/firewalld
Comment 12 cornel panceac 2012-10-02 14:28:02 EDT
"unfortunately", the next evening ssh started working (maybe some updates were involved) so probably any logs would be useless. since i've not see it not working since, i'm not opening another bug report. thank you very much
Comment 13 Thomas Woerner 2012-10-04 06:52:22 EDT
Closing as not a bug due to comment 12.
Comment 14 Jiri Popelka 2012-10-04 07:11:27 EDT
Actually the original bug (no active zones after firewalld restart when there's no running NetworkManager) is still not solved and I doubt there's any clean solution. However the work-around is to also restart 'network' service.
Comment 15 Matthew Miller 2012-11-21 08:31:55 EST
*** Bug 876390 has been marked as a duplicate of this bug. ***
Comment 16 Matthew Miller 2012-12-04 20:46:55 EST
I don't think documentation is an adequate fix for this for F18 if firewalld is to be the default, as long as we are still supporting not running NetworkManager (which we have to for the forseeable future, because it too isn't able to be a 100% replacement for the older initscripts).
Comment 17 Jiri Popelka 2013-01-14 08:30:00 EST
Upstream commit
http://git.fedorahosted.org/cgit/firewalld.git/commit/?id=4ec98e390102b5c065f7b2855204e01c08af88c1

should fix the original problem.
Comment 18 Matthew Miller 2013-02-15 08:42:54 EST
(In reply to comment #17)
> Upstream commit
> http://git.fedorahosted.org/cgit/firewalld.git/commit/
> ?id=4ec98e390102b5c065f7b2855204e01c08af88c1
> 
> should fix the original problem.

Cool, thanks. It appears to. :)

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