Bug 812020

Summary:	firewalld blocks incoming ssh traffic even though "ALREADY_ENABLED"
Product:	[Fedora] Fedora	Reporter:	Frank Ch. Eigler <fche>
Component:	firewalld	Assignee:	Thomas Woerner <twoerner>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	jpopelka, mrezanin, twoerner
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-23 16:14:09 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:
Embargoed:

Description Frank Ch. Eigler 2012-04-12 14:39:27 UTC

Description of problem:
I cannot ssh into a VM with a brand new f17-branched installation.

Version-Release number of selected component (if applicable):
firewalld-0.2.4-1.fc17
openssh-5.9p1-22.fc17

How reproducible:
always

Steps to Reproduce:
1. Install f17-branched
2. ssh to host fails
3. suspecting firewall problems, # firewall-cmd --add --service-ssh
4. Error: ALREADY_ENABLED
5. systemctl --all indicates firewalld.service & iptables.service active

Actual results:
no connection

Expected results:
connection

Additional info:
ssh localhost works.
tcpdump indicates the port-22 packets are arriving.
# firewall-cmd --set-default-zone=home  fails with Permission denied.

Comment 1 Frank Ch. Eigler 2012-04-12 14:42:27 UTC

Note that permission denied message is a selinux problem.

Comment 2 Frank Ch. Eigler 2012-04-12 14:46:14 UTC

With selinux disabled, and 
# firewall-cmd --set-default-zone=home
done, and with firewalld restarted, incoming ssh finally is permitted.

The "ALREADY_ENABLED" message rather mislead about the source of the
problem, which was apparently that "public" is the default zone.

Comment 3 Jiri Popelka 2012-04-12 15:54:33 UTC

(In reply to comment #0)
> 5. systemctl --all indicates firewalld.service & iptables.service active

that shouldn't be possible because firewalld.service contains 'Conflicts=iptables.service'.
What does the following command show ?
systemctl list-unit-files | egrep 'iptables|firewalld'

(In reply to comment #1)
> Note that permission denied message is a selinux problem.

I filled bug #812040. Please check that it's the same SELinux warning that you see.

(In reply to comment #2)
> With selinux disabled, and 
> # firewall-cmd --set-default-zone=home
> done, and with firewalld restarted, incoming ssh finally is permitted.
> 
> The "ALREADY_ENABLED" message rather mislead about the source of the
> problem, which was apparently that "public" is the default zone.

It returns ALREADY_ENABLED, because ssh is already allowed in the default ("public") zone. So changing default zone from "public" to "home" actually shouldn't "fix" the problem as I understand it, because ssh is allowed in both.
Does the problem occur again if you change it back to "public" ?

Comment 4 Miroslav Rezanina 2012-05-03 12:14:21 UTC

Problem with sshd is even when iptables are disabled. Until I start them I'm not able to connect to the guest. And when iptables are enabled, I need to restart them to get sshd working.

Comment 5 Jiri Popelka 2012-05-03 12:59:02 UTC

(In reply to comment #4)
> Problem with sshd is even when iptables are disabled. Until I start them I'm
> not able to connect to the guest.

Could you show me output of the following commands in this state (before you start iptables) ?
systemctl --all | egrep 'iptables|firewalld'
firewall-cmd --list=all
iptables -L

> And when iptables are enabled, I need to
> restart them to get sshd working.

That's probably because it conflicts with firewalld. Did you disable firewalld ?

Comment 6 Jiri Popelka 2012-05-17 11:36:26 UTC

I think this is duplicate of bug #821938.

Do you use NetworkManager or network service (initscripts).

Comment 7 Jiri Popelka 2012-05-23 16:14:09 UTC


*** This bug has been marked as a duplicate of bug 821938 ***