Large FTP transfers fail - IPSec invalid SPI's

droeun141 · ‎04-23-2010

We're having a problem with large FTP transfers (400+mb) failing via site-to-site VPN, we get about half way through & the connection fails followed by a new phase 1 exchange. This is only affecting 1 of 7 tunnels. Last week we enabled invalid SPI recovery & isakmp keepalives, and it seems the next day is when we started having issues - fix one thing, break another! We only had one of these errors last week, but since the commands were introduced the next day there are literally tons. It kind of seems like it's doing the complete opposite of what it was intended. Thoughts?

Commands:

crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10

Errors:

Apr 23 12:26:22 10.254.254.1 2528495: Apr 23 12:27:04.796 EDT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.255.254.1, prot=50, spi=0x5D6B57DC(1567315932), srcaddr=192.168.1.1
Apr 23 12:28:43 10.254.254.1 2528879: Apr 23 12:29:25.533 EDT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.255.254.1, prot=50, spi=0x9D3555FA(2637518330), srcaddr=192.168.1.1
Apr 23 12:45:21 10.254.254.1 2529923: Apr 23 12:46:04.090 EDT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.255.254.1, prot=50, spi=0xA3BBF6AD(2747004589), srcaddr=192.168.1.1
Apr 23 13:11:16 10.254.254.1 2531695: Apr 23 13:11:58.555 EDT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.255.254.1, prot=50, spi=0x3D0C507C(1024217212), srcaddr=192.168.1.1
Apr 23 13:11:32 10.254.254.1 2531753: Apr 23 13:12:13.280 EDT: %CRYPTO-4-IKMP_NO_SA: IKE message from 192.168.1.1 has no SA and is not an initialization offer

Dirk Feldhaus · ‎05-07-2010

Hello,

starting with the easiest parameters: Have you checked the sa lifetimes on both devices. Maybe the sa lifetime or volume threshold is reached during the ftp transfer and one of the endpoints tries to create new keys.

droeun141 · ‎05-10-2010

Thanks for the reply. I was actually thinking the same thing but found out the devices will create new sessions before exceeding volume limit. As it turns out, we had keepalives enabled and UDP/500 was only permitted in one direction. We fixed the issue by disabling keepalives.