VPN doesn't re-establish after power loss

rtjensen4 · ‎02-10-2010

Hi All,

I'm having a weird problem with an IPSEC GRE tunnel I have. The setup is a central router (2801) connected to internet and a remote location (1811 i think) bringing up a secure tunnel between the locations.

The tunnel will come up and be fine. If the remote router loses power (happens fairly often), the only way to re-establish the connection is to clear crypto sa on the 2801 router.

The ISAKMP peers show as up "QM_IDLE", but the Tunnel interface is UP/DOWN. I will post IOS / configs when I get access to them. Anyone had this same problem?

rtjensen4 · ‎02-10-2010

attached are sanitized configs. It's odd... I remember when setting this up, if I try to setup tunnel / VPN using the primary IP on the interface, it doesn't work, but if I point to the secondary IP, it establishes. I was seeing requests on the remote router from the primary IP on the hub router. What a mess.... maybe the IOS on the hub has some issues?

rtjensen4 · ‎02-10-2010

Here's the output of the show cry isa from both routers when things are working properly:

Hub Router:

Router-HUB#sh cry isa sa
dst             src             state          conn-id slot status
10.254.255.254 10.254.255.251 QM_IDLE           1370    0 ACTIVE
.33   .91   QM_IDLE           1375    0 ACTIVE
.91   .32   QM_IDLE           1376    0 ACTIVE

Remote Router:

Router-remote#sh cry isa sa
dst             src             state          conn-id slot status
.91   .32   QM_IDLE              2    0 ACTIVE
.33   .91   QM_IDLE              1    0 ACTIVE

With the debugs and log messages I was seeing, it looks like the remote site is talking to the secondary IP on the hub router, but the hub router is responding with it's primary interface IP. Here's a log snippet from the remote router to confirm this:

Feb 10 16:06:05: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
destaddr=.91, prot=50, spi=0xAA4A0E38(2856980024), srcaddr=.32
Feb 10 16:07:05: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for
destaddr=.91, prot=50, spi=0xAA4A0E38(2856980024), srcaddr=.32

The only way we got this tunnel to work in the first place was to set the crypto map and crypto ACL and isakmp peers to be BOTH of the IPs on the hub router. Looks like it could be a wonkey IOS on the 2801, any other thoughts?