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:
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.
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!
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?
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.
I may help here. Drop me a line directly with what you may need and I see what I can do.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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?
RHEL5 does not support IPv6 connection tracking.
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...
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.
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.
That doesn't really bring me to more...so you've no more details about that?
Enable the option EXPERIMENTAL, NF_CONNTRACK and then NF_CONNTRACK_IPV6 before you compile your kernel.