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
|