Need help with IPSec tunnel periodically collapsing

Discussion in 'Cisco' started by Ted Mittelstaedt, Jul 18, 2004.

  1. 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
     
    Ted Mittelstaedt, Jul 18, 2004
    #1
    1. Advertisements

  2. Ted Mittelstaedt

    chris Guest

    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
     
    chris, Jul 19, 2004
    #2
    1. Advertisements

  3. Ted Mittelstaedt

    Gary Guest

    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
     
    Gary, Jul 19, 2004
    #3
  4. Ted Mittelstaedt

    Hansang Bae Guest

    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.
    ********************************************************************
     
    Hansang Bae, Jul 21, 2004
    #4
  5. Ted Mittelstaedt

    ciscobiz Guest

    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

     
    ciscobiz, Jul 21, 2004
    #5
  6. Ted Mittelstaedt

    sriggs Guest

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

     
    sriggs, Jul 22, 2004
    #6
  7. Ted Mittelstaedt

    Hansang Bae Guest


    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.
    ********************************************************************
     
    Hansang Bae, Jul 22, 2004
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.