Re: More IPSEC trouble

[Nicolas DICHTEL <nicolas.dichtel@xxxxxxxxx>]

When the stack check the mtu for this packet, it doesn't know the size of
the overhead. So the total length of the packet don't include the size
of the esp or ah header. The same bug appears when you run
IPSEC in IPv4 transport mode over a 4in4 tunnel. A fix for this bug
is to allow locally the fragmentation of the packet.

Nicolas Dichtel

Here is a patch:

--- a/linux26/net/ipv4/xfrm4_output.c    Thu Mar 10 15:50:30 2005
+++ b/linux26/net/ipv4/xfrm4_output.c    Thu Mar 10 15:51:49 2005
@@ -116,6 +116,9 @@ int xfrm4_output(struct sk_buff *skb)

    xfrm4_encap(skb);

+    /* We still allow to fragment this packet locally */
+    skb->local_df = 1;
+   
    err = x->type->output(skb);
    if (err)
        goto error;

Steve Hill wrote:

> Unfortunately I've found another IPSEC kernel bug (2.6.10):
>
> Running IPSEC in IPv4 tunnel mode - obviously the packets grow in size 
> when encrypted and when I send a packet that grows to > MTU size when 
> encrypted the machine locks up solid (the packet is generated by a 
> different machine that is routing it via the Linux IPSEC router whcih 
> is having problems).  When it locks up I get no errors from the kernel 
> - it just freezes up solid.
>
> All interfaces have an MTU of 1500 bytes.  The IP address of the 
> machine generating the packet is 10.101.0.42 and the public address of 
> it's ipsec gateway (which is the one locking up) is "a.b.c.d" in the 
> below logging. The VPN server at the other end, also running the 
> 2.6.10 kernel, is w.x.y.z.  The below logging shows a large ICMP 
> packet that produces an MTU-sized encrypted packet and works ok:
>
> $ ping -n 10.254.3.19 -c 1 -s 1372
> PING 10.254.3.19 (10.254.3.19) 1372(1400) bytes of data.
> 1380 bytes from 10.254.3.19: icmp_seq=0 ttl=62 time=94.8 ms
>
> # tcpdump -n -i eth0 proto ICMP -v
> 12:35:50.064417 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], 
> proto 1, length: 1400) 10.101.0.42 > 10.254.3.19: icmp 1380: echo 
> request seq 0
>
> # tcpdump -n -i eth1 proto 50 or proto 51 or proto ICMP -v
> 12:28:53.427655 IP (tos 0x0, ttl  64, id 8224, offset 0, flags [DF], 
> proto 51, length: 1500) a.b.c.d > w.x.y.z: 
> AH(spi=0x07260bb2,sumlen=16,seq=0x2d): IP (tos 0x0, ttl  64, id 55247, 
> offset 0, flags [DF], proto 50, length: 1456) a.b.c.d > w.x.y.z: 
> ESP(spi=0x041b1078,seq=0x2d)
>
> Increasing the packet size by 1 byte would obviously require 
> fragmentation of the encrypted packet and causes the machine to lock up.
>
> I will continue to do some debugging but any insight would be 
> appreciated. Thanks.
>
> - Steve Hill (BSc)
> Senior Software Developer                        Email: 
> steve@xxxxxxxxxxxx
> Navaho Technologies Ltd.                           Tel: +44-870-7034015