ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Peter Bieringer]

Hi all,

(first a Merry Christmas to all)

I ran here into a major problem:

2 IPv6 hosts can successfully connect each other in case of unencrypted 
traffic, filtering with ip6table works fine.

Now I'v setup between this two hosts encryption (setkey & racoon). IKE 
phase 1 & 2 works perfectly.

But now, no ip6table-ACCEPT rule matches anymore. I played around, but 
without success.

I got following log message (some MAC,IPv4,IPv6 addresses are changed for 
privacy):

Dec 24 10:22:27 gate kernel: extIN-FW6-default:IN=sit_sixxs OUT= 
MAC=00:11:22:33:44:01->00:11:22:33:44:02 TUNNEL=212.224.  0.188-> 84.000. 
0. 12 SRC=2001:06f8:0900:0449:0000:0000:0000:0002 
DST=2001:06f8:0900:0094:0000:0000:0000:0002 LEN=116 TC=0 HOPLIMIT=63 
FLOWLBL=0 OPT ( ) PROTO=59

Caused by following ruleset:

# ip6tables -vn -L extIN --line-num
Chain extIN (4 references)
num   pkts bytes target     prot opt in     out     source 
destination
1        0     0 ACCEPT     all      *      *       2001:6f8:900:449::2/128 
2001:6f8:900:94::2/128
2        0     0 ACCEPT     tcp      *      *       ::/0 
3ffe:400:100:f101::1/128tcp spts:1024:65535 dpt:80
3       27  2808 ACCEPT     icmpv6    *      *       ::/0 
::/0
4        6   888 ACCEPT     udp      *      *       2001:6f8:900:449::2/128 
2001:6f8:900:94::2/128udp spt:500 dpt:500
5        0     0 ACCEPT     esp      *      *       2001:6f8:900:449::2/128 
2001:6f8:900:94::2/128
6        0     0 ACCEPT     59       *      *       2001:6f8:900:449::2/128 
2001:6f8:900:94::2/128
tcp spts:512:65535 dpt:22
10       0     0 ACCEPT     tcp      *      *       ::/0 
::/0               tcp spts:1:65535 dpts:32768:60099 flags:!0x16/0x02
11       0     0 ACCEPT     udp      *      *       ::/0 
::/0               udp spts:1:65535 dpts:32768:60099
12      13  1564 LOG        all      *      *       ::/0 
::/0               limit: avg 5/min burst 5 LOG flags 0 level 7 prefix 
`extIN-FW6-default:'
13      13  1564 DROP       all      *      *       ::/0 
::/0


As you see, neither rule 1 nor rule 6 matches, which is strange indeed - 
what's the reason?

Why matches the DROP rule (13), but not the global ACCEPT rule (1)?

Both sides are using Linux kernel 2.6.9-1.681_FC3 from Fedora Core 3 
updates.


BTW: can someone fix the log statement?
	TUNNEL=212.224.  0.188-> 84.128.  0. 12
-> leading spaces instead of leading 0 are not very well.

Thank you very much.

	Peter
-- 
Dr. Peter Bieringer                        http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                  mailto: pb at bieringer dot de
Deep Space 6 Co-Founder and Core Member     http://www.deepspace6.net/

Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Peter Bieringer]

Hi again,

one update (after playing now with openswan):

> Dec 24 10:22:27 gate kernel: extIN-FW6-default:IN=sit_sixxs OUT=
> MAC=00:11:22:33:44:01->00:11:22:33:44:02 TUNNEL=212.224.  0.188-> 84.000.
> 0. 12 SRC=2001:06f8:0900:0449:0000:0000:0000:0002
> DST=2001:06f8:0900:0094:0000:0000:0000:0002 LEN=116 TC=0 HOPLIMIT=63
> FLOWLBL=0 OPT ( ) PROTO=59

I found a difference in handling of following rules:

#1
ip6tables -A extIN -p all -s 2001:6f8:900:94::2 -d 2001:6f8:900:449::2 -j 
ACCEPT

#2
ip6tables -A extIN -s 2001:6f8:900:94::2 -d 2001:6f8:900:449::2 -j ACCEPT


Rule #1 doesn't match that strangeness, while rule #2 does (and - partially 
- solve my problem now)!

Looks like there is something going wrong in the protocol matching 
algorithm in netfilter6.


So at the moment, I can't filter the traffic, but connection is encrypted.


Perhaps for interesting, using openswan of Fedora Core 3 and following very 
simple configuration:

conn ipv6-location1-location2
        connaddrfamily=ipv6
        left=2001:6f8:900:94::2
        right=2001:6f8:900:449::2
        authby=secret
        type=transport


	Peter
-- 
Dr. Peter Bieringer                        http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                  mailto: pb at bieringer dot de
Deep Space 6 Co-Founder and Core Member     http://www.deepspace6.net/

Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Peter Bieringer wrote:
> Looks like there is something going wrong in the protocol matching 
> algorithm in netfilter6.

Does this patch fix the problem ?

Regards
Patrick

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 447 bytes --]

===== net/ipv6/netfilter/ip6_tables.c 1.34 vs edited =====
--- 1.34/net/ipv6/netfilter/ip6_tables.c	2004-11-10 01:44:26 +01:00
+++ edited/net/ipv6/netfilter/ip6_tables.c	2004-12-25 16:42:21 +01:00
@@ -234,7 +234,7 @@
 			 * we will change the return 0 to 1*/
 			if ((currenthdr == IPPROTO_NONE) || 
 				(currenthdr == IPPROTO_ESP))
-				return 0;
+				break;
 
 			hp = skb_header_pointer(skb, ptr, sizeof(_hdr), &_hdr);
 			BUG_ON(hp == NULL);

Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Peter Bieringer]

Hi,

--On Saturday, December 25, 2004 04:46:23 PM +0100 Patrick McHardy
<kaber@trash.net> wrote:

> Peter Bieringer wrote:
>> Looks like there is something going wrong in the protocol matching 
>> algorithm in netfilter6.
> 
> Does this patch fix the problem ?
> 
> Regards
> Patrick

Yes, this patch fix the problem on the incoming side:

I ping6 to a remote host via IPsec in transport mode:

IPv6 INPUT chain:

    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
ipv6-icmp type 128
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
ipv6-icmp type 129
    1   156 ACCEPT     esp      *      *       remote/128  local/128
    0     0 ACCEPT     all      *      *       remote/128  local/128


So the proper chain matches.


But I wonder a little bit because of the result of the OUTPUT chain:

    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
ipv6-icmp type 129
    1   104 ACCEPT     icmpv6    *      *       ::/0                 ::/0
ipv6-icmp type 128
    0     0 ACCEPT     esp      *      *       local/128  remote/128
    0     0 ACCEPT     all      *      *       local/128  remote/128


Here, the ICMPv6 rule matches.

This means for me that the traffic goes like this:

OUTPUT: ping6 -> netfilter -> encryption -> ESP
INPUT : ESP -> netfilter -> decryption -> ping6

Is this logical?

BTW: how to filter incoming traffic after decryption?

        Peter
-- 
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D               mailto: pb at bieringer dot de 
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/

Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Patrick McHardy]

Peter Bieringer wrote:
>>Does this patch fix the problem ?
>>
> Yes, this patch fix the problem on the incoming side:

Thanks.

> 
> I ping6 to a remote host via IPsec in transport mode:
> 
> IPv6 INPUT chain:
> 
>     0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
> ipv6-icmp type 128
>     0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
> ipv6-icmp type 129
>     1   156 ACCEPT     esp      *      *       remote/128  local/128
>     0     0 ACCEPT     all      *      *       remote/128  local/128
> 
> 
> So the proper chain matches.
> 
> 
> But I wonder a little bit because of the result of the OUTPUT chain:
> 
>     0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
> ipv6-icmp type 129
>     1   104 ACCEPT     icmpv6    *      *       ::/0                 ::/0
> ipv6-icmp type 128
>     0     0 ACCEPT     esp      *      *       local/128  remote/128
>     0     0 ACCEPT     all      *      *       local/128  remote/128
> 
> 
> Here, the ICMPv6 rule matches.
> 
> This means for me that the traffic goes like this:
> 
> OUTPUT: ping6 -> netfilter -> encryption -> ESP
> INPUT : ESP -> netfilter -> decryption -> ping6

More specific, with transport mode it goes:

OUTPUT: ping6 -> LOCAL_OUT -> encryption -> POST_ROUTING
INPUT: ESP -> PRE_ROUTING -> LOCAL_IN -> decryption -> ping6

Filtering for IPv6 happens on LOCAL_IN/LOCAL_OUT (and FORWARD).

> Is this logical?

Not very. Patches to improve this for IPv4 will be submitted
next week, but IPv6 still needs some work.

> 
> BTW: how to filter incoming traffic after decryption?

Use tunnel-mode. The decrypted packets will hit PRE_ROUTING
and LOCAL_IN again.

Regards
Patrick

Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Peter Bieringer]

--On Sunday, January 02, 2005 12:42:54 PM +0100 Patrick McHardy
<kaber@trash.net> wrote:

>> But I wonder a little bit because of the result of the OUTPUT chain:
>> 
>>     0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0
>> ipv6-icmp type 129
>>     1   104 ACCEPT     icmpv6    *      *       ::/0                 ::/0
>> ipv6-icmp type 128
>>     0     0 ACCEPT     esp      *      *       local/128  remote/128
>>     0     0 ACCEPT     all      *      *       local/128  remote/128
>> 
>> 
>> Here, the ICMPv6 rule matches.
>> 
>> This means for me that the traffic goes like this:
>> 
>> OUTPUT: ping6 -> netfilter -> encryption -> ESP
>> INPUT : ESP -> netfilter -> decryption -> ping6
> 
> More specific, with transport mode it goes:
> 
> OUTPUT: ping6 -> LOCAL_OUT -> encryption -> POST_ROUTING
> INPUT: ESP -> PRE_ROUTING -> LOCAL_IN -> decryption -> ping6
> 
> Filtering for IPv6 happens on LOCAL_IN/LOCAL_OUT (and FORWARD).
> 
>> Is this logical?
> 
> Not very. Patches to improve this for IPv4 will be submitted
> next week, but IPv6 still needs some work.
> 
>> 
>> BTW: how to filter incoming traffic after decryption?
> 
> Use tunnel-mode. The decrypted packets will hit PRE_ROUTING
> and LOCAL_IN again.

Ok, confirmed working in tunnel mode, ping6 packet was counted twice in
different rules (esp and icmpv6)

But for outgoing ping6 packets, this won't work, packet is only counted
(and accepted) by the icmpv6 rule, esp rule got no match, also not the
"all" rule.

Looks like at the moment, outgoing packet is passing netfilter only one
time, even if encryption is in tunnel mode.

By design / bug / missing feature?

        Peter
-- 
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D               mailto: pb at bieringer dot de 
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/

Re: ip6tables: accept of IPv6 transport esp packages not possible - no rule matches

[Patrick McHardy]

Peter Bieringer wrote:

>>>BTW: how to filter incoming traffic after decryption?
>>>
>>Use tunnel-mode. The decrypted packets will hit PRE_ROUTING
>>and LOCAL_IN again.
>>
>
>Ok, confirmed working in tunnel mode, ping6 packet was counted twice in
>different rules (esp and icmpv6)
>
>But for outgoing ping6 packets, this won't work, packet is only counted
>(and accepted) by the icmpv6 rule, esp rule got no match, also not the
>"all" rule.
>
>Looks like at the moment, outgoing packet is passing netfilter only one
>time, even if encryption is in tunnel mode.
>
That is correct.

>
>By design / bug / missing feature?
>
By design and missing feature :) As I said, patches to fix this for
IPv4 will be submitted this week .. IPv6 will hopefully follow soon.

Regards
Patrick