Bug 801182 - Default ip6tables ruleset does not permit ICMPv6
Default ip6tables ruleset does not permit ICMPv6
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
17
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-07 16:04 EST by Tore Anderson
Modified: 2012-03-26 09:24 EDT (History)
2 users (show)

See Also:
Fixed In Version: firewalld-0.2.4-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-21 15:05:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Match and accept ICMPv6 before jumping to the INPUT_* chains (1.18 KB, patch)
2012-03-09 09:35 EST, Tore Anderson
no flags Details | Diff
Allow (ipv6-)icmp before conntrack checking (1.88 KB, patch)
2012-03-26 09:24 EDT, Jiri Popelka
no flags Details | Diff

  None (edit)
Description Tore Anderson 2012-03-07 16:04:30 EST
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.
Comment 1 Thomas Woerner 2012-03-09 07:00:00 EST
Upstream fixed:

commit 18670eaab2c24ecea40dd8804d13360b6a3585ab
Author: Thomas Woerner <twoerner@redhat.com>
Date:   Fri Mar 9 12:56:56 2012 +0100

    - fixed icmp protocol used for ipv6 (rhbz#801182)
Comment 2 Tore Anderson 2012-03-09 09:35:21 EST
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
Comment 3 Thomas Woerner 2012-03-12 07:43:36 EDT
Here is the fix for the remaining problem:

commit 119dec410a1116631d187b8b7a7877d2ea1ae6f7
Author: Thomas Woerner <twoerner@redhat.com>
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
Comment 4 Tore Anderson 2012-03-13 16:08:57 EDT
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
Comment 5 Fedora Update System 2012-03-15 17:44:44 EDT
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
Comment 6 Fedora Update System 2012-03-15 22:41:48 EDT
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).
Comment 7 Fedora Update System 2012-03-16 11:49:12 EDT
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
Comment 8 Tore Anderson 2012-03-16 15:23:48 EDT
(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
Comment 9 Thomas Woerner 2012-03-19 06:36:24 EDT
Please use https://admin.fedoraproject.org/updates/firewalld-0.2.4-1.fc17 it replaced the old version (see comment #7)
Comment 10 Tore Anderson 2012-03-19 15:32:08 EDT
(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
Comment 11 Fedora Update System 2012-03-21 15:05:36 EDT
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.
Comment 12 Jiri Popelka 2012-03-26 09:24:33 EDT
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

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