Bug 243739

Summary: state does not work with netfilter v6
Product: Red Hat Enterprise Linux 5 Reporter: Thomas Woerner <twoerner>
Component: kernelAssignee: Neil Horman <nhorman>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: low Docs Contact:
Priority: low    
Version: 5.0CC: davem, dzickus, kbsingh, madko, nhorman, redhat-bugzilla, robert.scheck, tao, tgraf, tomek, wnefal+redhatbugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-22 10:56:08 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 232931, 243741, 425461    

Description Thomas Woerner 2007-06-11 12:40:49 EDT
Description of problem:
The stage module in the kernel is not able to be used with netfilter v6 without
stucking the netfilter v4 firewall. State is working with the latest upstream
kernels. There are lots of conntrack fixes.

Version-Release number of selected component (if applicable):
kernel-2.6.18-8.el5

How reproducible:
Always
Configure firewall with state module usage for ip6tables.

Steps to Reproduce:
1. Configure firewall with state module usage for ip6tables.
2. Establish some connections to the IPv6 and IPv4 firewall.
3. Stop iptables -> Failes
  
Actual results:
Failure on module onloading

Expected results:
No error

Additional info:
Comment 1 Tomasz Kepczynski 2007-08-13 16:15:22 EDT
I haven't tried to unload module (yet) but I also see probles with
statefull firewall. It actually looks like firewall treats all
incoming ipv6 packets as INVALID (or at least - not ESTABLISHED
and RELATED). Simply speaking - statefull filtering is useless.
Comment 3 Neil Horman 2007-12-03 16:07:33 EST
twoerner, can you provide some detail please regarding the details of the error
mesage you get when you try to load ip6tables.  If you could provide your
ip6tables config as well that would be helpful.  Thanks!
Comment 5 Neil Horman 2007-12-05 16:49:31 EST
before I start my search, you don't know off the top of your head which upstream
commit(s) added v6 conntrack support do you?
Comment 6 Neil Horman 2007-12-06 09:47:24 EST
better still do you have a test bed already set up that I can use to debug this
issue with?  If you already have one set up, it will save me a good deal of time.
Comment 7 Tomasz Kepczynski 2007-12-06 16:17:14 EST
I may help here. Drop me a line directly with what you may need
and I see what I can do.
Comment 8 Thomas Woerner 2007-12-07 05:24:37 EST
About the kernel changes: I do not remember correctly which patches, there were
many for netfilter since 2.6.18.
I could help you with a test case. I have had one, but it is gone.
Comment 9 Neil Horman 2007-12-07 16:17:17 EST
yes, there have been a large number of changes to netfilter, but theres nothing
that jumps out as a significant change in the conntrack code for ipv6 support. 
We're going to have to recreate and debug this problem.  So if you could rebuild
your test case so that I could see it, that would be great.
Comment 10 Tomasz Kepczynski 2007-12-08 15:28:06 EST
For stateful firewall test case I suggest the following:
1. 2 Machines, each with one ipv6 interface, mutually pingable
   with ipv6. I assume below eth0 is configured for ipv6.
2. On machine 1 enter the following ip6tables rules:
# ip6tables -N TEST
# ip6tables -A INPUT -i eth0 -j TEST
# ip6tables -A TEST -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT
# ip6tables -A TEST -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT
# ip6tables -A TEST -m state --state RELATED,ESTABLISHED -j ACCEPT
# ip6tables -A TEST -j DROP
3. Ping6 machine 2 from machine 1. You should see answers but
   you won't. This is a fault.
4. Now replace rule with RELATED,ESTABLISHD with INVALID:
# ip6tables -R TEST 3 -m state --state INVALID -j ACCEPT
5. You see pongs coming in. This is a fault.

The same test case on Fedora 8 passes.
Comment 11 Neil Horman 2007-12-12 16:22:11 EST
Note to self: Looking at the ip6tables code in the kernel, its occured to me
that we don't even currently build the connection tracking ipv6 netfilter code
(it doesn't exist in the .config file), which probably explains why the above is
failing.  My testing has shown that despite trying to load the connection
tracking module above, we're actually just loading the filter table, and the
--state INVALID rule is just acting as a universal match, since we do load the
xt_match module.

I see why we don't enable ipv6 connection tracking: Its implemented on top of
generic Netfilter connection tracking, while ipv4 connection tracking is still
standalone.  The two implementations are mutually exclusive, which is why the
ipv6 version was never enabled.  I'm currently building a kernel to enable
generic nf contrack for both ipv4 and ipv6.  This is a huge change and not one
that we can safely make in 5.2, but perhaps for 5.3 it might be possible.
Comment 12 Neil Horman 2007-12-13 19:11:51 EST
I've got the generic netfilter stuff enabled and am beginning to test, but from
the looks of it this may well be a large ABI break, and possibly something that
we can't do in RHEL5.
Comment 13 Tomasz Kepczynski 2007-12-14 01:03:26 EST
I have one remark which probably should be filed as a bug against
iptables.
You mentioned above, that kernel does not have ipv6 connection
tracking enabled due to its incompatibility with ipv4 netfilter
code. The problem is that ip6tables seems to be compiled with
connection tracking enabled. All together this leads to
confusion and may cause problems with ipv4 code as mentioned
in original bug report.
I suggest you disable connection tracking in ip6tables until
kernel support is in place.
Comment 14 Neil Horman 2007-12-14 11:13:09 EST
Thomas, Would you mind looking over my findings here, and offering a second
opinion?  The more I look at this, the more I'm convinced that this is going to
be a non-started for RHEL5, given the build changes required, but I'd like to be
certain that I'm not just missing some way to get ipv6 connection tracking
compiled in without disturbing the current v4 setup.  Thanks!
Comment 15 Daniel Riek 2007-12-17 18:14:50 EST
Looking at the different comments and assuming, that I understand it correctly,
it looks to me like there currently is no upstream solution to be able to run
ipv6 and ipv4 stateful firewall at the same time. Correct?

If so, I would recommend to concentrate on solving that issue upstream first. It
would be on the list for RHEL 6. A backport can be discussed, but we would need
some clear customer requirements.
Comment 16 Thomas Graf 2007-12-17 19:13:43 EST
Upstream has moved to a protocol independent connection tracking layer and
supports both IPv4 and IPv6. This layer exists in RHEL5 but can't be enabled
unless the old IPv4 only code is disabled. Doing so breaks ABI. Therefore we can
only switch if we find some way to map the old interface to the new one.
Comment 17 Neil Horman 2007-12-21 08:49:48 EST
BAsed on email conversations, and the inability to implement this request in
RHEL5 without serious ABI breakage, I'm proposing that we move this to RHEL6. 
At that point it should all just work, as the IP4 and IP6 netfilter
implementations are based on the same common code.  Daniel, how should we mark
this bug?
Comment 20 Daniel Riek 2008-02-22 10:56:08 EST
RHEL5 does not support IPv6 connection tracking.
Comment 21 Robert Scheck 2008-10-25 19:07:24 EDT
Well, moving to RHEL6 is not very nice at that point - as long as RHEL6 is
not directly around the corner. For the time being, useful IPv6 firewalling
is nearly impossible using RHEL5...
Comment 22 Robert Scheck 2008-10-28 19:38:28 EDT
Neil, can you please describe how you enabled the common iptables conntrack module in RHEL5? How is the module in /boot/config-VERSION exactly named? I
would like to do this for myself, because I really need conntrack on a RHEL
5 machine for IPv6, independent whether it is supported or not.
Comment 23 Neil Horman 2008-10-28 19:53:18 EDT
I'd have to go back and look at the config options to remember exactly how I did it.  But as a start I remember enabling all NF_CONNTRACK and all its dependencies.  But of course it didn't build, since its exclusive with the IPv4 specific implementation, so you'll need to disable all those options.
Comment 24 Robert Scheck 2008-10-29 06:39:38 EDT
That doesn't really bring me to more...so you've no more details about that?
Comment 25 Thomas Graf 2008-10-29 06:57:03 EDT
Enable the option EXPERIMENTAL, NF_CONNTRACK and then NF_CONNTRACK_IPV6 before you compile your kernel.