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.
Hmm. Established connections only seem to continue if I run `firewall-cmd --add --service=ssh` immediately after starting firewalld.
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 ?
Created attachment 585020 [details]
Created attachment 585021 [details]
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.
(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:
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.
(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.
I forgot to add that the workaround to this problem is to run
'firewall-cmd --add --interface=<iface>'
after you restart the firewalld service.
*** Bug 812020 has been marked as a duplicate of this bug. ***
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
systemctl stop firewalld.service
, i still can not connect with ssh.
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:
and i got:
i tried again,
and i got:
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.
(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:
iptables-save | grep IN_ZONE_public_allow
also attach /var/log/firewalld
"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
Closing as not a bug due to comment 12.
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.
*** Bug 876390 has been marked as a duplicate of this bug. ***
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).
should fix the original problem.
(In reply to comment #17)
> Upstream commit
> should fix the original problem.
Cool, thanks. It appears to. :)