Need help with IPSec tunnel periodically collapsing

Hi All,

Here is the situation: We have a remote site that is running a Linksys
BEFVP41
that has an IPSec tunnel to a Cisco 7206. This tunnel runs over the
Internet, but
it is setup to encapsulate all Internet traffic. In short, Internet traffic
for this site
comes in to our 7206, is put into the tunnel, is shipped back out over the
Internet
to this remote site, where it is de-encapsulated at the remote site, and
that
is that remote site's Internet feed. I know it sounds strange and it
perhaps is,
but the situation is due to some billing/contractual/operational things that
happened
which I won't get into. Basically, the remote site isn't permitted to
access
any host on the Internet except for ours - so they go through ours to get to
the Internet.

The problem is that periodically for what appears to be no reason, the
IPSec
tunnel dies. It does not happen regularly, it can happen once every couple
of
days or once every month. The log on the 7206 shows the following error
message immediately before the tunnel dies:

Jul 18 14:24:25 PDT: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an
IPSEC packet.
(ip) dest_addr= 155.56.12.24, src_addr= 55.5.97.5, prot= 17
Jul 18 14:26:02 PDT: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an
IPSEC packet.
(ip) dest_addr= 155.56.12.24, src_addr= 55.5.97.5, prot= 17

The IP numbers have of course been changed to protect the site, the source
address of 55.5.97.5 is the IP number of the first host after the Linksys on
the
subnet behind their Linksys, and the destination address of
155.56.12.24 is our DNS server. Since 55.5.97.5 can always reach
155.56.12.24
regardless of whether the tunnel is up or down, I am pretty much discounting
this
log entry as a side-effect.

On the Linksys side, if you access it, it shows the VPN tunnel down, with no
log entry whatsover as to why it's down. If
you try to bring it up again by clicking the VPN button it barks about
"target
cannot be initiator" or some such. Power cycling the Linksys does not make
the tunnel come back.

If I log into the 7206 and issue the command:

clear crypto sa

then the tunnel comes back and everything is as it was before, and I get the
following log entry in the Linksys:

(our 7206 IP # is 1.2.3.4)

00:00:00 --
00:00:00 v1.41.1 (00-0c-41-4e-78-00)
00:00:00 VPN Crypto Sub_System Initialization Success !
00:12:29 IKE[1] Rx << MM_I1 : 1.2.3.4 SA
00:12:29 IKE[1] Tx >> MM_R1 : 1.2.3.4 SA
00:12:29 IKE[1] ISAKMP SA CKI=[38e0368 81eb7c8b] CKR=[20546b0b d2f66546]
00:12:29 IKE[1] ISAKMP SA DES / MD5 / PreShared / MODP_768 / 3600 sec (*3600
sec)
00:12:29 IKE[1] Rx << MM_I2 : 1.2.3.4 KE, NONCE, VID
00:12:29 IKE[1] Tx >> MM_R2 : 1.2.3.4 KE, NONCE
00:12:30 IKE[1] Rx << MM_I3 : 1.2.3.4 ID, HASH
00:12:30 IKE[1] Tx >> MM_R3 : 1.2.3.4 ID, HASH
00:12:30 IKE[1] Rx << QM_I1 : 1.2.3.4 HASH, SA, NONCE, ID, ID
00:12:30 IKE[1] Tx >> QM_R1 : 1.2.3.4 HASH, SA, NONCE, ID, ID
00:12:30 IKE[1] Rx << QM_I2 : 1.2.3.4 HASH
00:12:30 IKE[1] ESP_SA DES / MD5 / 3600 sec (*3600 sec) /
SPI=[94dd16cd:1d520d8f]
00:12:30 IKE[1] Set up ESP tunnel with 1.2.3.4 Success !
00:12:30

The configs on the Linksys and 7206 are basically textbook out of box
configs.
Encryption is standard DES, (not 3DES) MD5, IKE key management, a preshared
key that matches on both sides, key lifetime of 3600 seconds, the Linksys
offers a
proposal of DES/MD5/768 bit/28800 seconds key lifetime for proposal 1, and
DES/MD5/768 bit/3600 seconds key lifetime for the second proposal

On the 7206 the config is:


!
crypto isakmp policy 1
hash md5
authentication pre-share
lifetime 3600
crypto isakmp key password address 5.6.7.8
!
!
crypto ipsec transform-set eatme esp-des esp-md5-hmac
!
crypto map blowme 1 ipsec-isakmp
set peer 5.6.7.8
set transform-set eatme
match address 150
!
!
!
!
interface FastEthernet0/0
ip address 1.2.3.4 255.255.255.224
no ip route-cache
no ip mroute-cache
half-duplex
crypto map blowme

access-list 150 permit ip any 55.5.97.0 0.0.0.7

We have tried MANY different IOS versions, it is immaterial what version of
IOS
the 7206 runs, whether it's 56 bit or 3des, nor whether it's any version
from 12.3t to
12.0, nor any release from ip only to enterprise, they all do it.

The linksys is running the latest firmware.

Any suggestions other than a smartass one about setting a complicated script
up to poll
the router and if it sees the vpn down, use an expect script to issue the
"clear crypto sa" command?

Ted

 

This isn't a strange setup at all. It lets the central site control
the firewall, external boundaries, and monitor internet usage. Things
you may not trust or have funding at the remote site to do.

Otherwise, I apologize that I don't have anything usefull to add.

-Chris

 

I have similar problem.

LinkSYs to 3640 rtr

All fine for several days and then it drops?

LinkSys is 8 port vpn router model RV082 - Seems to point at the Linksys...

Did not investigate yet but if you see a solution let me know please.

Gary

 

Which VAM card (if any) are you using? Have you tried using 12.2.24a or
12.1.19E3 (or was that 12.2.19E3?)

SO it sounds like the SAs are getting stale. This can happen when you
have mismatched ACLs and the SPI (Security Payload Index - IIRC) gets
confused. I.e

permit tcp any 1.1.1.1
permit ip any 1.1.1.1

can cause IOS to freak out. Both may be OK (however redundant), but we
found a bug where this causes the SPIs to not match. Then the IPSec SA
becomes stale but ISAKMP SA does not.

How are your process switching on the FastE? So you can debug the
packets? Also, how are you handling the IPSec overhead for 1500 byte
packets? Are you using tcp-mss intercept or doing PMTU-D?

Does the Linksys support paranoid keepalives or dead-peer detection?


--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

 

Hi,

I've seen this with DMVPN, and isakmp DPD keepalives fixed it. Essentially,
if the Hub site was reloaded, it would cause a major outage because the
spokes would retain their old sa's and would have to timeout first before
re-negotiating.

On a slightly different but related note, I've just upgraded to 12.3.9 k9
and am now seeing the sa's intermittently go stale at the spokes and this
causes OPSF to drop across the mGRE tunnel and come back up when the new sa
is renogotiated 30s before the old one expires. It happens at all sites, but
not every hour - may be once or twice every 24hrs each but always just as
the new sa is negotiated. Causes a loss of connectivity for about a minute -
fortunately this happens mostly at night, when interestingly there isn't any
traffic going across the links. I'm thinking of increasing the IPSEC sa
lifetime to 12h or something to test it under a new transform for a single
spoke.

We are using the new VAM modules that support hardware compression and were
forced to move to 12.3.9 k9 in order to support the module. Platform is
2621XM.

If any one has anything to add to this problem - shout!

Thanks,

Chris

 

Ditch the Linksys and use a real Cisco product like 800 series...they
work all the time....

 

I *HIGHLY* doubt it. We have 6500's, 7200's, 7500's and 1700 series and
everything in between. IPSec is not Cisco's strong suit.


--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************