[Openswan Users] 2.4.4 mangles SPI?

Paul Wouters paul at xelerance.com
Wed Nov 29 19:27:49 EST 2006

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) >
> 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) > 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.


More information about the Users mailing list