[Openswan Users] 2.4.4 mangles SPI?

[Paul Wouters]

On Tue, 28 Nov 2006, Christian Brechbühler wrote:

> Openswan 2.4.4 sets up a VPN tunnel to a Cisco router OK:
>
> 004 "NYC" #58: STATE_QUICK_I2: sent QI2, IPsec SA established
> {ESP=>0x91af5acc <0xdd787655 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
>
> Packets sent from the Cisco side work fine.
>
> But when sending a packet from Openswan through the tunnel, a slightly
> different SPI is used (tcpdump):
>
> 16:34:12.535324 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ESP
> (50), length: 136) 66.99.99.99 > 38.111.111.111:
> ESP(spi=0x91af4878,seq=0x1254001a), length 116
> 16:34:12.563423 IP (tos 0x20, ttl 240, id 22448, offset 0, flags [none],
> proto: UDP (17), length: 104) 38.111.111.111.500 > 66.99.99.99.500: isakmp
> 1.0 msgid : phase 2/others ? inf[E]: [encrypted hash]
>
> In the first message, note the spi=0x91af4878 instead of 0x91af5acc -- the
> last four digits (some of the lower 16 bits) are changed.  Sometimes the
> discrepancy is in the high 16 bits.

Note that an "IPsec connection" actually consists of two SPI's, one for
each direction.

> The second message is the "Delete SA" message that the Cisco sends back.
> Openswan doesn't know about that SPI either:
>
> Nov 28 16:34:04 [pluto] "NYC" #57: ignoring Delete SA payload:
> PROTO_IPSEC_ESP SA(0x91af4978) not found (maybe expired)

This can happen when Openswan deletes the connection, and the remote sends one
as well, but openswan already deleted it.

> What could be causing this?

I would have to see the complete (plutodebug=none) log with the spi
numbers to see what happened.

Another reason for a changed SPI could be an "IPsec passthrough" router in
between, messing with the packets.

Paul