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
|