Red Hat Bugzilla – Bug 209945
ip6tables match state not working
Last modified: 2008-05-06 20:56:47 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060913 Fedora/1.5.0.7-1.fc5 Firefox/1.5.0.7 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): iptables-ipv6-1.3.5-1.2.1 How reproducible: Always 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:
If you are using iptables-save or iptables -L, is the rule still intact?
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 RELATED,ESTABLISHED ACCEPT tcp anywhere anywhere state NEW tcp dpt:ssh ACCEPT udp anywhere anywhere state NEW udp dpt:netbios-ns ACCEPT udp anywhere anywhere state NEW udp dpt:netbios-dgm ACCEPT tcp anywhere anywhere state NEW tcp dpt:netbios-ssn ACCEPT tcp anywhere anywhere state NEW tcp dpt:microsoft-ds ACCEPT tcp anywhere anywhere state NEW tcp dpt:https ACCEPT tcp anywhere anywhere state NEW tcp dpt:http DROP all anywhere anywhere
This is a kernel issue, then. Assigning to kernel.
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. Jay
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp