Description of problem: At this point in the F18 process, I do not understand why I need to file this report! The problem is that with firewalld running, my virtual guests a crippled as compared to them running on a Fedora 17 system. I started out with putting F18-beta into some virtual guests running on a F17 host. There were some bumps but things were looking good. I also installed F18-beta on a real hardware test system. Again, there were some bumps. I also installed some packages with better IPv6/DHCPv6 support in the form of dnsmasq-2.65, NetworkManager-git20121130, and libvirt-1.0.1. Then (recently) I decided to do virtualization testing withe the F18-beta system as the host. The F18-beta virtual guest I installed is identical to one I had running on the F17 host. But, when I brought the system up, a lot of stuff did not work. This included a lot of IPv6, and especially ssh -4 and ssh -6. After much effort and no progress, I decided that maybe my "extra" stuff was causing the problem. So I installed F18-TC2-beta again into a different partition as well as installed F18-TC2-beta on the F17 Virtualization host, Brought them up ... the problem is the same on both systems. Then, on my F18 test system, I shutdown all of virtualization, stopped and disabled firewalld, enabled both iptables and ip6tables, and finally rebooted. After the reboot, I started a virtual guest and everything worked as it did when I ran the guest on F17. I know iptables rules a little but i do not understand those rules with firewalld running. I do not know where to look for the problem. Is there a firewalld mode which implements the same protection that is available in F17? I tried a bunch of the zones including internal. I also enabled the libvirt port. Nothing seemed to make a difference. Well, the system is sitting here. I you need me to try something or gather some info, just ask BTW, I have no idea if this is a dup of Bug 869625 or not.
Your report is very vague, but it sounds like 869625 was a case where the reporter started firewalld after libvirtd. I can reproduce that right now, even restarting libvirtd after starting firewalld, I cannot ssh from a libvirt guest to the host, with the host running F18 and firewalld - I get 'no route to host'. twoerner says this is a bug and needs to get fixed, we are looking into it now. I think we can keep this bug separate and have it cover this problem for now. It would help to know _exactly_ what other things are not working for you. "This included a lot of IPv6, and especially ssh -4 and ssh -6." is pretty vague.
So just to confirm for me, my test case is this: setup - my regular box, a lived-in f18 install, as the vm host. A virt-manager created VM as the guest, with F18 Desktop TC1 live image (doesn't really matter what guest image you use). Networking perfectly standard (for virt-manager) NAT. test 1: systemctl disable iptables.service systemctl stop iptables.service systemctl enable firewalld.service systemctl start firewalld.service systemctl restart libvirtd.service virt-manager, fire up test VM ssh adamw.122.1 test 2: systemctl disable firewalld.service systemctl stop firewalld.service systemctl enable iptables.service systemctl start iptables.service systemctl restart libvirtd.service virt-manager, fire up test VM ssh adamw.122.1 the result of test 1 is 'no route to host'. The result of test 2 is a successful connection. I am using libvirt-0.10.2.2-3.fc18.x86_64 and firewalld-0.2.11-2.fc18.noarch on the host, I get same results with the last couple of libvirt builds.
Gene, I'm curious if you can come up with a specific test case we can try? I've ported firewalld to Gentoo unstable and run it on my Gentoo unstable box with a number of VMs and haven't seen a specific issue. I've got the following: firewalld-0.2.9 libvirt-1.0.0 (just upgraded to 1.0.1) Adam, That ssh is from the VM? Or from the host?
from VM to host.
OK, I am going to restart this effort and put all info here rather than in mailing lists. One of the things that confused me was the result of a routing problem now corrected. 1. All systems are up to date. One Fedora 17 virtualization host and one Fedora 18 virtualization host. In addition to base, each has dnsmasq-2.65, libvirt-1.0.1, and NetworkManager-git20121130 installed so that IPV6 is fully supported by DHCPv6 (plus RA routing). [That software has been running for some time now and should be available "real soon now."] The F17 systems uses iptables and ip6tables. The F18 system uses firewalld. 2. There is a F17 guest and a F18 guest on each of the hosts. Besides the regular software, they have NetworkManager-git121130 installed for dynamic DNS support for IPv6/DHCPv6. [One of my big interests is IPv6 on the virtual guests.] Sometimes stuff has worked and sometimes is has not. Therefore, I am trying to be very careful and controlled about the testing. That is, duplicating the same test in all four situations and recording the result(s). If there is some specific test someone would like me to try, just ask. Sometimes a problem on one system cannot be duplicated on another one.
One other little thing about the configuration. All hardware systems run IPv4/IPv6 dual stacks with dhcp assigned addressing. All virtual guests run IPv4/IPv6 dual stacks with dhcp assigned addressing.
Please add the things that were working versus the things that have not been working for F-17 and F-18.
Created attachment 666203 [details] image of first results table. Both working and not working test reports are included. Here is the testing so far. First results are attached. First thing is that IPv6 is not working for guests running on the F18 host. That plus ssh -4 <the_virtualization_host> not working when doing ssh -4 to an external local server working was a surprise. Note: the path to the <local-server> from the two virtualization hosts is the same. In the image, the first designation such as "F17" is the host and the second is the guest. In all of this, syslog is very quiet. Is there something I can turn on to produce more logging from firewalld choices. Suggestion (RFE?) if there is no additional logging mode, maybe there should be.
I have a small patch for firewalld to enable the default zone for all interfaces that are not set to be part of another zone. With this patch it should behave for guests like the old static firewall model in F-17. After some more testing I will create a test package for this.
(In reply to comment #8) > In all of this, syslog is very quiet. Is there something I can turn on to > produce more logging from firewalld choices. Add FIREWALLD_ARGS=--debug or even FIREWALLD_ARGS=--debug=2 to /etc/sysconfig/firewalld restart firewalld check /var/log/firewalld
Created attachment 666225 [details] wireshare trace run on virtual guest This traces covers the period when, on a F17 guest on a F18 host, had the following issued: ssh -4 hawk.lcl ssh -6 hawk.lcl hawk.lcl is the F18 host. I already did this so I thought I might as well add it.
OK, a patch good!. If you can supply me the patch, I am perfectly able and willing to build my own test rpm. Question: will this patch address the IPv6 problems? Also, I am glad to see that firewalld has built in debugging. I am going to enable it. Given that libvirt gets all screwed up is firewalld is restarted, I will then reboot.
Created attachment 666229 [details] Use default zone for all interfaces, that are not set to part of another zone. This is the source patch. It applies with some offset messages to 0.2.11.
if you restart firewalld libvirt is resubmitting it's rules. There are some log messages about the removal of rules that failed, but this can be ignored. libvirt tries to cleanup the old rules first. These messages are no errors and are likely to get removed.
I tried the patch and it certainly fixes my ssh test case, Gene could you run it on your test cases?
Unfortunately, it did not fix mine. ssh -4, ssh -6, and any IPv6 still does not work although I am getting an address from dnsmasq's DHCPv6 service (on both F17 and F18 guests). Now, I may have screwed something up. I applied the patch to firewalld-0.2.11-2 and then installed the resulting noarch rpm (along with a bunch of other updates which just appeared) and rebooted because of all the updates. I had previously checked the default from public to internal so I changed it back to public and restarted firewalld. While I have --debug=2 specified for firewalld and there are lots of messages recording the communications with libvirtd, there is still nothing that points to the ip6tablers rules that is blocking things. By any chance is there another level of debug that adds some logging to the iptables/ip6tables rules? What can I do to help debug this problem?
I tested by applying the patch directly to a running system and restarting firewalld and libvirtd, FWIW. Not to sound rude, but can you just do the double-check that you actually got the patch in and applied in the rebuild? I have managed to fail on this more than once before - usually by adding Patch0: blahblah.patch and changing the changelog but forgetting to add a %patch0 line in %setup...
Oops ... pilot error ... I screwed up! I did an update and a large bunch of updates were pending so I tried to install them all and did not see that firewalld was skipped because of dependency. Anyway, that has been fixed and firewalld plus firewall-* are updated. I brought up a virtual and it is good news. I can ssh -4 and ssh -6 to the host. I can ssh -6 to external systems (and ping6 too and http too). Color it fixed!
Great. Thomas, can you do a build and submit an update? I don't see a reason to take this through the freeze as it's host-side rather than guest-side, but it'd be great to have it as a 0-day.
I will provide a 0-day update for firewalld with this fix.
I have been running the patched firewalld since the 19th and everything has worked smoothly.
Fixed in GIT: http://git.fedorahosted.org/cgit/firewalld.git/commit/?id=4ec98e390102b5c065f7b2855204e01c08af88c1
firewalld-0.2.12-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/firewalld-0.2.12-1.fc18
Package firewalld-0.2.12-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firewalld-0.2.12-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0810/firewalld-0.2.12-1.fc18 then log in and leave karma (feedback).
firewalld-0.2.12-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.