Hi All, i've found out that since i've upgraded to kernel 2.6.14.2 ( problem also applies to 2.6.14 ), my IPSEC tunnels don't work anymore. It used to work fine up to kernel 2.6.13.4. I've investigated a little bit and i found out the following: StrongSwan sets up the tunnels as usual, everything is fine. I can find correct entries in the SPD and SAD. For example: ipsec auto --up tunnel 104 "tunnel" #1: STATE_MAIN_I1: initiate 003 "tunnel" #1: ignoring Vendor ID payload [strongSwan 2.4.1] 003 "tunnel" #1: received Vendor ID payload [Dead Peer Detection] 106 "tunnel" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "tunnel" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "tunnel" #1: STATE_MAIN_I4: ISAKMP SA established 112 "tunnel" #2: STATE_QUICK_I1: initiate 004 "tunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x52c4d596 <0x8a813344} setkey -D SS.SS.SS.SS DD.DD.DD.DD esp mode=tunnel spi=1388631446(0x52c4d596) reqid=16397(0x0000400d) E: aes-cbc 55770e41 3d85cebe 2898709e 0890095a A: hmac-sha1 bc6cf8ab fff30e24 8c9d0d02 787abc2b 5b07ada1 seq=0x00000000 replay=32 flags=0x00000000 state=mature created: Nov 14 23:00:20 2005 current: Nov 14 23:06:42 2005 diff: 382(s) hard: 0(s) soft: 0(s) last: Nov 14 23:00:38 2005 hard: 0(s) soft: 0(s) current: 304(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2 hard: 0 soft: 0 sadb_seq=1 pid=31577 refcnt=0 DD.DD.DD.DD SS.SS.SS.SS esp mode=tunnel spi=2323723076(0x8a813344) reqid=16397(0x0000400d) E: aes-cbc 1b924bd2 6470fb88 ebd2499b 2f1d3720 A: hmac-sha1 83c00122 97676816 2cc4b000 1a4a0482 ddf52560 seq=0x00000000 replay=32 flags=0x00000000 state=mature created: Nov 14 23:00:20 2005 current: Nov 14 23:06:42 2005 diff: 382(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=31577 refcnt=0 So far, so good. Now when i try to ping a host on the remote subnet, i get no answer. Using tcpdump i see the following: 23:00:38.939501 IP (tos 0x0, ttl 64, id 256, offset 0, flags [DF], proto 50, length: 152) SS.SS.SS.SS > DD.DD.DD.DD: ESP(spi=0x52c4c61b,seq=0xf7b0001) 23:00:39.953189 IP (tos 0x0, ttl 64, id 4096, offset 0, flags [DF], proto 50, length: 152) SS.SS.SS.SS > DD.DD.DD.DD: ESP(spi=0x52c4c61b,seq=0xf7b0002) As you can see the SPI used in the outgoing packet is not correct. It should be 0x52c4d596 as stated by the above SPD output. Every time i tried, i noticed that the last 2 bytes of the SPI have been corrupted. What's even weirder is that when i log into the remote lan and i try to ping my machine, it works fine, the reply packets sent by my computer have the correct SPI. So it appears that the corruption of the SPI only occurs when the packet is initiated by my computer, not when it's a reply from an other packet. So far, i've looked into net/ipv4/esp4.c and i can confirm that the correct spi has been selected and inserted into the packet in function esp_output esph->spi = x->id.spi; ( line 97 ). It looks as if the corruption happens later down the stack ..... Has anyone seen this ? Any help would be greatly appreciated ! Some general Info: cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2400+ stepping : 1 cpu MHz : 2000.448 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 4004.39 I'm attaching my kernel config. StrongSwan version is 2.5.6 and ipsec-tools is 0.5-4. Please CC me when replying to this email since i'm not subscribed to the list. -- Charles-Edouard Ruault PGP Key ID E4D2B80C