+++ This bug was initially created as a clone of Bug #144832 +++ Description of problem: During setup of IPv6 firewalling I found that IPv6 netfilter code has two bugs, one about matching on esp, the other matching on icmpv6 with options. With help of developers, I got fixes which solve the issues. Version-Release number of selected component (if applicable): kernel-2.6.10-1.737_FC3 How reproducible: Always Steps to Reproduce: 1. setup rule which should match IPv6 esp packages 2. setup rule which should match ICMPv6 packages regardless packages contain option headers Actual Results: No match Expected Results: Match Additional info: See threads: http://www.linux-ipv6.org/ml/usagi-users/msg03166.html http://oss.sgi.com/projects/netdev/archive/2005-01/msg00015.html And here the patch: --- net/ipv6/netfilter/ip6_tables.c.orig 2004-12-26 19:16:57.461634470 +0100 +++ net/ipv6/netfilter/ip6_tables.c 2004-12-26 19:17:45.456219406 +0100 @@ -220,7 +220,7 @@ u_int16_t ptr; /* Header offset in skb */ u_int16_t hdrlen; /* Header */ - ptr = IPV6_HDR_LEN; + ptr = ((char *) ipv6 - (char *) skb->data) + IPV6_HDR_LEN; while (ip6t_ext_hdr(currenthdr)) { /* Is there enough space for the next ext header? */ @@ -232,7 +232,7 @@ * we will change the return 0 to 1*/ if ((currenthdr == IPPROTO_NONE) || (currenthdr == IPPROTO_ESP)) - return 0; + break; hdrptr = (struct ipv6_opt_hdr *)(skb->data + ptr); -- Additional comment from davej on 2005-07-15 14:34 EST -- An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. -- Additional comment from pb on 2005-08-13 10:38 EST -- At least the problem with the option header still exist: Aug 13 16:34:59 host kernel: FW6-default-DROP-intOUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:0280:c8ff:feb9:cef9 DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=143 CODE=0 Roule still does't match: Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT icmpv6 * * fe80::/10 ff02::16/128 ipv6-icmp type 143 HL match HL == 1 0 0 ACCEPT icmpv6 * * ::/128 ff02::16/128 ipv6-icmp type 143 HL match HL == 1 6 400 ACCEPT icmpv6 * * ::/0 ::/0 Kernel: 2.6.12-1.1398_FC4 -- Additional comment from pb on 2005-08-13 10:43 EST -- Note that while kernel log do no longer show "OPT ( )", a Hop-By-Hop option is still in the packet: Frame 1 (110 bytes on wire, 110 bytes captured) Arrival Time: Aug 13, 2005 16:43:19.386977000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 110 bytes Capture Length: 110 bytes Protocols in frame: eth:ipv6:icmpv6 Ethernet II, Src: D-Link_b9:ce:f9 (00:80:c8:b9:ce:f9), Dst: IPv6-Neighbor-Discovery_00:00:00:16 (33:33:00:00:00:16) Destination: IPv6-Neighbor-Discovery_00:00:00:16 (33:33:00:00:00:16) Source: D-Link_b9:ce:f9 (00:80:c8:b9:ce:f9) Type: IPv6 (0x86dd) Internet Protocol Version 6 Version: 6 Traffic class: 0x00 Flowlabel: 0x00000 Payload length: 56 Next header: IPv6 hop-by-hop option (0x00) Hop limit: 1 Source address: fe80::280:c8ff:feb9:cef9 (fe80::280:c8ff:feb9:cef9) Destination address: ff02::16 (ff02::16) Hop-by-hop Option Header Next header: ICMPv6 (0x3a) Length: 0 (8 bytes) Router alert: MLD (4 bytes) PadN: 2 bytes Internet Control Message Protocol v6 Type: 143 (Multicast Listener Report Message v2) Code: 0 (Should always be zero) Checksum: 0xd3b5 [correct] Changed to exclude: ff05::1:3 (ff05::1:3) Mode: Changed to exclude Aux data len: 0 Multicast Address: ff05::1:3 Changed to exclude: ff02::1:2 (ff02::1:2) Mode: Changed to exclude Aux data len: 0 Multicast Address: ff02::1:2 -- Additional comment from davej on 2005-09-30 02:52 EST -- Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks. -- Additional comment from pb on 2005-10-03 16:36 EST -- I can confirm that match works now (btw: packets are generated by dhcp6s): 2 192 ACCEPT icmpv6 * * fe80::/10 ff02::16/128 ipv6-icmp type 143 HL match HL == 1 +++ End of original bug report Same seen now on RHEL4 running kernel-2.6.9-34.EL during adding a new IPv6 address on a running system: # ip addr add 2001:7b0:1101:1::37:2/64 dev eth0 causes: May 2 13:37:42 rhel4 OUTPUT-FW6/cleanup:IN= OUT=eth0 SRC=fe80:0000:0000:0000:0240:63ff:fedb:ff6b DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=196 TC=0 HOPLIMIT=1 FLOWLBL=0 OPT ( ) PROTO=ICMPv6 TYPE=143 CODE=0
Can it be that the same bug prevents me from using RHEL4's IPsec configuration? After successful using IPsec host-to-host with IPv4, I play now with IPv6, but strange things are happen here. Config on both hosts (only src/dst exchanged): ifcfg-ipsec0 SRC=2001:db8:1234:1::54:1 DST=2001:db8:1234:1::164:1 TYPE=IPSEC IKE_METHOD=PSK IKE_PSK=secret ESP_PROTO=aes128 IPv6 firewalling is active on both hosts, too. While IKE (phase 1) and IPsec (phase 2) are proper established, a ping6 or a ssh connect results in: Dst host: Aug 10 17:10:59 host INPUT-FW6/cleanup:IN=eth0 OUT= MAC=00:40:63:**:**:**:00:e0:1e:56:91:**:**:** SRC=2001:0db8:1234:0001:0000:0000:0164:0001 DST=2001:0db8:1234:0001:0000:0000:0054:0001 LEN=140 TC=0 HOPLIMIT=60 FLOWLBL=0 OPT ( ) OPT ( ) PROTO=59 It only let the traffic pass, if I append following rule: ip6tables -I INPUT -s 2001:db8:1234::/48 -d 2001:db8:1234::/48 -j ACCEPT If I replace it by e.g. ip6tables -I INPUT -s 2001:db8:1234::/48 -d 2001:db8:1234::/48 -j ACCEPT -p tcp traffic is blocked. Used: kernel-2.6.9-34.0.2.EL Could one please check if the upper shown minor patch is included in latest RHEL4 U4 candidate kernel, and if not, please include it.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
RHEL4 has entered the Extended Life Phase. There will be no more minor releases. I'm closing this bug due to inactivity. Please reopen and provide an explanation if you need this issue to be addressed in RHEL4. Please note that only security and critical bugfixes are considered at this point.