Bug 209945 - ip6tables match state not working
Summary: ip6tables match state not working
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-08 17:59 UTC by Michael H. Warfield
Modified: 2008-05-07 00:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-07 00:56:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michael H. Warfield 2006-10-08 17:59:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060913 Fedora/ Firefox/ pango-text

Description of problem:
The -m state functionality is not working in ip6tables.  The rules are not being matched, even when they should, so connections can not be established.

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

How reproducible:

Steps to Reproduce:
1.Add (or verify) rules in ip6table
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
2.Attempt to make a connection to ssh using IPv6 from another system
(fails with time out - no SYN packet received)
3.Attempt to make a connection to make an ssh connection to another system
(failts with time out - no SYN ACK received - other system is in SYN RECV state)
4.Add a ip6table rule
-I RH-Firewall-1-INPUT -m tcp -p tcp --dport 22 -j ACCEPT
5.Attempt connection to ssh from another system on IPv6.  Succeeds.
6.Attempt connection to ssh on another system.  Still fails. (ESTABLISHED not matched.

Actual Results:
Inbound connections fail to be established.  Outbound connections fail to function even after being established.

Expected Results:
Inbound connections should have been established and established outbound connections should have been enabled.

Additional info:

Comment 1 Thomas Woerner 2006-10-09 11:34:23 UTC
If you are using iptables-save or iptables -L, is the rule still intact?

Comment 2 Michael H. Warfield 2006-10-09 13:12:39 UTC
Confirmed, it is (they are)...  So, it may possibly be a kernel issue. 
Discussion taking  place on Fedora-Test and another poster has tested against
2.6.19-rc1 and verified.

[root@cabra iptables]# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all      anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all      anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all      anywhere             anywhere
ACCEPT     ipv6-icmp    anywhere             anywhere
ACCEPT     ipv6-crypt    anywhere             anywhere
ACCEPT     ipv6-auth    anywhere             anywhere
ACCEPT     udp      anywhere             ff02::fb/128       udp dpt:mdns
ACCEPT     udp      anywhere             anywhere           udp dpt:ipp
ACCEPT     tcp      anywhere             anywhere           tcp dpt:ipp
ACCEPT     all      anywhere             anywhere           state
ACCEPT     tcp      anywhere             anywhere           state NEW tcp dpt:ssh
ACCEPT     udp      anywhere             anywhere           state NEW udp
ACCEPT     udp      anywhere             anywhere           state NEW udp
ACCEPT     tcp      anywhere             anywhere           state NEW tcp
ACCEPT     tcp      anywhere             anywhere           state NEW tcp
ACCEPT     tcp      anywhere             anywhere           state NEW tcp dpt:https
ACCEPT     tcp      anywhere             anywhere           state NEW tcp dpt:http
DROP       all      anywhere             anywhere

Comment 3 Thomas Woerner 2006-10-09 13:16:18 UTC
This is a kernel issue, then. Assigning to kernel.

Comment 4 Tomas Mraz 2006-10-12 14:55:04 UTC
On Thu, Oct 12, 2006 at 02:01:23AM -0400, Dave Jones wrote:
> On Wed, Oct 11, 2006 at 09:20:59PM -0500, Jay Cliburn wrote:
>  > >  I've found that the IPv6 state matching is non-functional in FC6.  I
>  > > first tried it in Test3 and have just reinstalled the entire system from
>  > > scratch from rawhide and verified it from the latest rawhide.
>  > [snip]
>  > >  Filed in bugzilla: 209945
>  > > 
>  > >  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209945
>  > 
>  > This is a kernel configuration issue.  Configure the kernel as follows and 
>  > rebuild it.  After that, ip6tables will honor "-m state".  If you don't build 
>  > the kernel with these options, all IPv6 packets are seen as INVALID by 
>  > netfilter.  (To see this for yourself, set up a log rule matching on "-m state 
>  > INVALID".)
>  > 
>  > Here are the kernel config options:
>  > 
>  > Networking->Networking options->Network packet filtering (replaces 
>  > ipchains)->IP: Netfilter Configuration
>  > 
>  > Unset this option:
>  > < > Connection tracking (required for masq/NAT)
>  > 
>  > Networking->Networking options->Network packet filtering (replaces 
>  > ipchains)->Core Netfilter Configuration
>  > 
>  > Set these options:
>  > <*> Layer 3 Independent Connection tracking (EXPERIMENTAL)
>  > [*]   Connection tracking flow accounting
>  > [*]   Connection mark tracking support
>  > [*]   Connection tracking security mark support
>  > [*]   Connection tracking events (EXPERIMENTAL)
> This is marked EXPERIMENTAL for a reason. It's incomplete for some
> features.  You can only enable this if you disable the old conntrack code.
> >From conversation with the upstream networking folks, enabling this
> will also break NAT.  It'll not be completely usable until at least 2.6.20

Noted, and thank you for the amplifying information.  At least we now know:

a) why IPv6 netfilter state matching doesn't work on as-delivered Fedora;
b) what we need to do to make IPv6 netfilter state matching work;
c) what some of the side effects are.

Prior to now, all we had was an apparent nonfunctioning IPv6 stack when 
the default Fedora ip6tables rules were activated.


Comment 5 Bug Zapper 2008-04-03 18:28:21 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 6 Bug Zapper 2008-05-07 00:56:45 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

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