Bug 869625 - Firewall prevents libvirt guests from accessing host TCP ports
Firewall prevents libvirt guests from accessing host TCP ports
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-24 08:41 EDT by Stef Walter
Modified: 2014-02-05 07:42 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:42:01 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)
log during time trying ssh (188.32 KB, application/x-gzip)
2012-12-17 12:58 EST, Gene Czarcinski
no flags Details

  None (edit)
Description Stef Walter 2012-10-24 08:41:20 EDT
Description of problem:

Running a fedora guest vm running via virt-manager. The 'trusted' firewall prevents connecting from guest VMs to TCP ports on the HOST. Results in an ICMP host prohibited, and shows up as an unreachable in the guest.

This is a tcpdump of the guest trying to access port 80, on the host. The guest IP is 192.168.12.176 and the host IP is 192.168.12.1 (on virbr0) and 192.168.11.10 (on p6p1).

The command line executed is "curl http://stef.thewalter.lan"

IP 192.168.12.176.39629 > 192.168.12.1.domain: 53408+ A? stef.thewalter.lan. (36)
IP 192.168.12.1.domain > 192.168.12.176.39629: 53408 1/0/0 A 192.168.11.10 (52)
IP 192.168.12.176.39629 > 192.168.12.1.domain: 37080+ AAAA? stef.thewalter.lan. (36)
IP 192.168.12.1.domain > 192.168.12.176.39629: 37080 0/0/0 (36)
IP 192.168.12.176.51471 > 192.168.11.10.http: Flags [S], seq 3965764830, win 14600, options [mss 1460,sackOK,TS val 858002 ecr 0,nop,wscale 7], length 0
IP 192.168.11.10 > 192.168.12.176: ICMP host 192.168.11.10 unreachable - admin prohibited, length 68
ARP, Request who-has 192.168.12.176 tell 192.168.12.1, length 28
ARP, Reply 192.168.12.176 is-at 52:54:00:93:8f:74, length 28

This is the firewall state:

[root@stef-rawhide tmp]# iptables-save
# Generated by iptables-save v1.4.14 on Wed Oct 24 14:36:42 2012
*nat
:PREROUTING ACCEPT [248:19243]
:INPUT ACCEPT [484:65219]
:OUTPUT ACCEPT [61554:4226544]
:POSTROUTING ACCEPT [15784:1025236]
:OUTPUT_direct - [0:0]
:POSTROUTING_ZONES - [0:0]
:POSTROUTING_direct - [0:0]
:POST_ZONE_external - [0:0]
:POST_ZONE_external_allow - [0:0]
:POST_ZONE_external_deny - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_direct - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES
-A OUTPUT -j OUTPUT_direct
-A POSTROUTING -s 192.168.12.0/24 ! -d 192.168.12.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.12.0/24 ! -d 192.168.12.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.12.0/24 ! -d 192.168.12.0/24 -j MASQUERADE
-A POSTROUTING -j POSTROUTING_direct
-A POSTROUTING -j POSTROUTING_ZONES
-A POSTROUTING_ZONES -o p6p1 -j ACCEPT
-A POST_ZONE_external -j POST_ZONE_external_deny
-A POST_ZONE_external -j POST_ZONE_external_allow
-A POST_ZONE_external_allow -j MASQUERADE
-A PREROUTING_ZONES -i p6p1 -j ACCEPT
COMMIT
# Completed on Wed Oct 24 14:36:42 2012
# Generated by iptables-save v1.4.14 on Wed Oct 24 14:36:42 2012
*mangle
:PREROUTING ACCEPT [196911:58959704]
:INPUT ACCEPT [14657200:21162477349]
:FORWARD ACCEPT [108381:101074582]
:OUTPUT ACCEPT [8676599:593266766]
:POSTROUTING ACCEPT [8785026:694347024]
:FORWARD_direct - [0:0]
:INPUT_direct - [0:0]
:OUTPUT_direct - [0:0]
:POSTROUTING_direct - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_direct - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES
-A INPUT -j INPUT_direct
-A FORWARD -j FORWARD_direct
-A OUTPUT -j OUTPUT_direct
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -j POSTROUTING_direct
-A PREROUTING_ZONES -i p6p1 -j ACCEPT
COMMIT
# Completed on Wed Oct 24 14:36:42 2012
# Generated by iptables-save v1.4.14 on Wed Oct 24 14:36:42 2012
*filter
:INPUT ACCEPT [12:770]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [12:770]
:FORWARD_ZONES - [0:0]
:FORWARD_direct - [0:0]
:FWDO_ZONE_external - [0:0]
:FWDO_ZONE_external_allow - [0:0]
:FWDO_ZONE_external_deny - [0:0]
:INPUT_ZONES - [0:0]
:INPUT_direct - [0:0]
:IN_ZONE_dmz - [0:0]
:IN_ZONE_dmz_allow - [0:0]
:IN_ZONE_dmz_deny - [0:0]
:IN_ZONE_external - [0:0]
:IN_ZONE_external_allow - [0:0]
:IN_ZONE_external_deny - [0:0]
:IN_ZONE_home - [0:0]
:IN_ZONE_home_allow - [0:0]
:IN_ZONE_home_deny - [0:0]
:IN_ZONE_internal - [0:0]
:IN_ZONE_internal_allow - [0:0]
:IN_ZONE_internal_deny - [0:0]
:IN_ZONE_public - [0:0]
:IN_ZONE_public_allow - [0:0]
:IN_ZONE_public_deny - [0:0]
:IN_ZONE_work - [0:0]
:IN_ZONE_work_allow - [0:0]
:IN_ZONE_work_deny - [0:0]
:OUTPUT_direct - [0:0]
COMMIT
# Completed on Wed Oct 24 14:36:42 2012

firewall-config reports the firewall is in 'trusted' mode.

Version-Release number of selected component (if applicable):

Name        : firewalld
Arch        : noarch
Version     : 0.2.9
Release     : 1.fc18
Size        : 1.1 M

This is an updated Fedora 18 as of yesterday.
Comment 1 Thomas Woerner 2012-10-24 09:10:27 EDT
Which libvirt version are you using?
Comment 2 Thomas Woerner 2012-10-24 09:12:33 EDT
BTW: There is no trusted mode in the firewall. The p6p1 interface is trusted.
Comment 3 Stef Walter 2012-10-24 09:57:07 EDT
Name        : libvirt
Arch        : x86_64
Version     : 0.10.2
Release     : 3.fc18

(In reply to comment #2)
> BTW: There is no trusted mode in the firewall. The p6p1 interface is trusted.

Well firewall-config makes it look like 'trusted' is a global thing with wording like: 'Default Zone: trusted', and 'Change Default Zone'.
Comment 4 Thomas Woerner 2012-10-24 10:19:52 EDT
There is one limitation in libvirt: firewalld has to be active before libvirt gets started. Otherweise libvirt will not use firewalld.

Your firewall configuration is not complete, there are no filter rules for libvirt.
Comment 5 Matthew Miller 2012-11-09 09:35:11 EST
(In reply to comment #4)
> There is one limitation in libvirt: firewalld has to be active before
> libvirt gets started. Otherweise libvirt will not use firewalld.
> 
> Your firewall configuration is not complete, there are no filter rules for
> libvirt.

I'm not clear on whether this is _the_ problem here, or an unrelated issue. As a user or sysadmin, it would be very confusing if firewall configuration was dependent on a race condition between libvirtd and firewalld at boot time. Is that what's going on?

If I *had* started services in the right order, would there be an easy way to configure guest-to-host firewall rules?
Comment 6 Thomas Woerner 2012-11-09 10:47:38 EST
@Stef

If your connection is not configured to be part of another zone, it is part of the default zone and therefore trusted. But libvirt is creating rules for guests and these are not in the default zone.

@Matthew

libvirt is taking care of firewall rules for guests. And at libvirt start it decides if it is using firewalld or not. THis iwas a design decision in libvirt. There has been a proposed patch for libvirt to do this dynamically. But the libvirt team decided to do this only at the start.
Comment 7 Matthew Miller 2012-11-13 11:40:09 EST
(In reply to comment #6)
> libvirt is taking care of firewall rules for guests. And at libvirt start it
> decides if it is using firewalld or not. THis iwas a design decision in
> libvirt. There has been a proposed patch for libvirt to do this dynamically.
> But the libvirt team decided to do this only at the start.

So, just so I'm extra clear:

If firewalld is in use, but libvirtd happens to start before firewalld, the behaviour will be different than if firewalld started first?
Comment 8 Thomas Woerner 2012-11-15 08:55:55 EST
@Matthew: Yes.
Comment 9 Matthew Miller 2012-11-15 10:45:36 EST
Ah, but we do have "Before=libvirtd.service" in the systemd startup script, so that shouldn't happen in the normal case. However, if firewalld happens to not be running, weird things might occur. Sounds like another argument for bug #876683. :)
Comment 10 Gene Czarcinski 2012-12-17 06:54:51 EST
F18-TC2+updates, libvirt-1.0.1

F17+availeable-updates, libvirt-1.0.1

Each system is a virtualization host.  On each is a F18-TC2+updates guest.

I am getting very different behavior on the two systems.  On the F17 system, the guest can ssh and scp to the host as well as other systems.  On the F18 system, the guest canNOT ssh or scp to the host of any other systems.

I cannot find any documentation that says this is working correctly.  Therefore, bug!
Comment 11 Thomas Woerner 2012-12-17 10:19:19 EST
Are there libvirt errors in the /var/log/messages file?
Comment 12 Gene Czarcinski 2012-12-17 12:58:29 EST
Created attachment 665018 [details]
log during time trying ssh

Sorry no.  I did a fresh boot and then a boot of a freshly installed F18 guest.

I am attaching the log but there is not much there.

For "ssh -4 hawk.lcl" I got "port 22 No route to host

and for "ssh -6 hawk.lcl" I got port 22 Permission denied.

More or less identical guest on F17 host works.

I did find some selinux problems with qemu-kvm but after updating the policy, it still did not work (I did not expect this to have an effect).
Comment 13 Gene Czarcinski 2012-12-17 13:23:29 EST
Some of the comments I have seen concerning the "ssh problem" say that restarting firewalld sometimes fixed things ... so I gave it a try.

Now that generated a large number of error messages from libvirtd ... do you wnat to see them?
Comment 14 Jiri Popelka 2012-12-17 13:43:21 EST
(In reply to comment #13)
> Now that generated a large number of error messages from libvirtd ... do you
> wnat to see them?

Probably bug #884346 ?
Comment 15 Adam Williamson 2012-12-18 13:37:55 EST
It's a bit hard to know what Gene's talking about, but I can say this. I just switched from iptables to firewalld on my F18 system. Then I restarted libvirt. Now I cannot do 'ssh 192.168.122.1' on either an F17 or F18 guest with default configuration: they both give 'No route to host'. This works fine when the host is using iptables (it lets the guest connect to the host). This is with the default libvirt networking config, straightforward NAT.

This is with all current updates-testing F18 stuff on the host.
Comment 16 Adam Williamson 2012-12-18 13:44:52 EST
Oh, I do see the errors from 884346 around the time I restarted libvirtd.service .
Comment 17 Adam Williamson 2012-12-18 13:57:14 EST
I think we should keep this bug for the case where firewalld is started after libvirtd, and use https://bugzilla.redhat.com/show_bug.cgi?id=888288 for the problem Gene is reporting and I think I've reproduced. Otherwise things will get confused.
Comment 18 Fedora End Of Life 2013-12-21 04:11:22 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2014-02-05 07:42:04 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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