Bug 812020 - firewalld blocks incoming ssh traffic even though "ALREADY_ENABLED"
firewalld blocks incoming ssh traffic even though "ALREADY_ENABLED"
Status: CLOSED DUPLICATE of bug 821938
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-12 10:39 EDT by Frank Ch. Eigler
Modified: 2012-05-23 12:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-23 12:14:09 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)

  None (edit)
Description Frank Ch. Eigler 2012-04-12 10:39:27 EDT
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 10:42:27 EDT
Note that permission denied message is a selinux problem.
Comment 2 Frank Ch. Eigler 2012-04-12 10:46:14 EDT
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 11:54:33 EDT
(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 08:14:21 EDT
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 08:59:02 EDT
(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 07:36:26 EDT
I think this is duplicate of bug #821938.

Do you use NetworkManager or network service (initscripts).
Comment 7 Jiri Popelka 2012-05-23 12:14:09 EDT

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

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