Description of problem: The default ip6tables ruleset I get after installing firewalld on Fedora 17, does not allow inbound ICMPv6 traffic. ICMPv6 is an essential part of the IPv6 protocol, so this completely breaks all form of IPv6 connectivity. The host can not participate in ICMPv6 Neighbor Discovery (equivalent to IPv4 ARP, also includes the mandatory IPv6 Duplicate Address Detection) for example, nor can it receive ICMPv6 Router Advertisements, which is the only way an IPv6 node can go about auto-configuring its IPv6 network connectivity. ICMPv6 and IPv6 works fine in previous releases for Fedora, so if firewalld is indeed going to be the default firewall solution for F17 (cf. FESCo ticket #805), this bug must be fixed in order to prevent a regression. Version-Release number of selected component (if applicable): firewalld-0.2.2-1.fc17.noarch How reproducible: Install firewalld-0.2.2-1 on Fedora Steps to Reproduce: 1. Install firewalld-0.2.2-1 and start it or reboot 2. Run "ip6tables-save | grep ipv6-icmp" 3. Actual results: No rules allowing ICMPv6 are present, breaking IPv6 connectivity. Expected results: Some ACCEPT rule(s) allowing for ICMPv6. IPv6 continuing to work as well as it did prior to the installation of firewalld. Additional info: There are two conspicuous rules in the default ip6tables rule set, both at position #6 in their respective chains: -A INPUT -p icmp -j ACCEPT -A FORWARD -p icmp -j ACCEPT These doesn't make much sense, as they allow for ICMPv4 (protocol number 1), a protocol that I at least have never ever seen being used in conjunction with IPv6. I believe it is likely that this is just a simple thinko bug, and that these two rules were always intended to match ICMPv6 (protocol number 58). That said, changing these two rules from matching ICMPv4 to ICMPv6 does not fix IPv6 connectivity. An inbound ICMPv6 packet appears to follow the following path through the chains: 1) INPUT, then 2) INPUT_direct, where no rules match, so return to 3) INPUT, then 4) INPUT_ZONES, then 5) IN_ZONE_public, then 6) IN_ZONE_public_deny, where no rules match, so return to 7) IN_ZONE_public, then 8) IN_ZONE_public_allow, where no rules match, so return to 9) INPUT_ZONE_public, where it hits a catch-all rule: 10) REJECT --reject-with icmp6-adm-prohibited Adding e.g. "ip6tables -I INPUT 4 -p ipv6-icmp -j ACCEPT" allows IPv6 to start working again.
Upstream fixed: commit 18670eaab2c24ecea40dd8804d13360b6a3585ab Author: Thomas Woerner <twoerner> Date: Fri Mar 9 12:56:56 2012 +0100 - fixed icmp protocol used for ipv6 (rhbz#801182)
Created attachment 568914 [details] Match and accept ICMPv6 before jumping to the INPUT_* chains (In reply to comment #1) > Upstream fixed Not quite, even though the match now is correct it is never reached. As I explained in the original report, this happens because it hits a catch-all REJET rule in IN_ZONE_public first. This is at least the case when the patch is applide on top of firewalld-0.2.2-1.fc17.src.rpm. I've attached a patch which reorders the match a bit so that it works for me, at least. Tore
Here is the fix for the remaining problem: commit 119dec410a1116631d187b8b7a7877d2ea1ae6f7 Author: Thomas Woerner <twoerner> Date: Mon Mar 12 12:41:28 2012 +0100 - do not REJECT in each zone, use RETURN to get back to the builtin chain; this makes icmp usable without adding it to each zone diff --git a/src/firewall/core/fw_zone.py b/src/firewall/core/fw_zone.py index b688af9..3e92b6c 100644 --- a/src/firewall/core/fw_zone.py +++ b/src/firewall/core/fw_zone.py @@ -128,7 +128,7 @@ class FirewallZone: "-j", "%s_allow" % (_zone) ])) if table == "filter": rules.append((ipv, [ _zone, 3, "-t", table, - "-j", "%%REJECT%%" ])) + "-j", "RETURN" ])) if create: # handle chains first
Confirmed, that fixes the problem, ICMPv6 are now let through and IPv6 works again. That said, the new "-j RETURN" at the end of IN_ZONE_public is rather pointless, as there is an implicit RETURN at the end of each non-built-in iptables chain anyway. So I think you could just as well remove the rule completely, and thus slim down the ruleset a bit. Tore
firewalld-0.2.3-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/firewalld-0.2.3-1.fc17
Package firewalld-0.2.3-1.fc17: * should fix your issue, * was pushed to the Fedora 17 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.3-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3817/firewalld-0.2.3-1.fc17 then log in and leave karma (feedback).
firewalld-0.2.4-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/firewalld-0.2.4-1.fc17
(In reply to comment #6) > Package firewalld-0.2.3-1.fc17: > * should fix your issue, > * was pushed to the Fedora 17 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.3-1.fc17' > as soon as you are able to. > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2012-3817/firewalld-0.2.3-1.fc17 > then log in and leave karma (feedback). Fix confirmed, DHCPv6 opening also much appreciated. Could not figure out how to leave positive karma though - it says status obsolete, maybe that's why? Tore
Please use https://admin.fedoraproject.org/updates/firewalld-0.2.4-1.fc17 it replaced the old version (see comment #7)
(In reply to comment #9) > Please use https://admin.fedoraproject.org/updates/firewalld-0.2.4-1.fc17 it > replaced the old version (see comment #7) Ah, didn't notice there was a new version out. Tested, fix confirmed, and positive karma added. Tore
firewalld-0.2.4-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 572753 [details] Allow (ipv6-)icmp before conntrack checking I found out, that replies to ICMPv6 Echo requests sent to IPv6 multicast address are still not let through, for example 'ping6 -I eth0 ff02::1'. Problem is that conntrack marks these replies as INVALID and they are rejected because of matching this rule: "-I INPUT -m conntrack --ctstate INVALID -j --reject-with icmp6-adm-prohibited" I asked netfilter upstream and if I understand the response [1] correctly there's no way how this can be "fixed" in conntrack module so we should probably move the rule "-I INPUT -p %%ICMP%% -j ACCEPT" before the conntrack one. [1] http://www.spinics.net/lists/netfilter/msg52580.html