ios version = 12.3(6a)
ios image = c1700-k9o3sy7-mz.123-6a.bin
vpn client = 4.0.3(F)
I've never seen this one before... Typically when a 4.0.3x vpn client session times out, I see the following two messages in the syslog output:
4128: May 12 16:47:46: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4129: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
Then that's the end of the story. However, this morning I find my syslog logs filling up with the following:
...
4146: May 12 16:52:59: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4151: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4150: May 12 16:54:42: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4152: May 12 16:55:43: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4153: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4155: May 12 16:56:45: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4156: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4158: May 12 16:57:46: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4159: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4161: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4160: May 12 16:58:47: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4163: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4162: May 12 16:59:48: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
4165: <009>destaddr=xxx.xxx.xxx.xxx, prot=50, spi=0x99BA67EE(-1715836946), srcaddr=yyy.yyy.yyy.yyy
4164: May 12 17:00:51: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
...
The frequency is fairly regular, a message pair about once every minute. It seems as if the client is still trying to re-establish (every one minute) the tunnel with the old spi from the tunnel session that timed out.
Any suggestions or explanations?
