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. Advertising

  2. Ted Mittelstaedt

    Guest

    On Sun, 18 Jul 2004 15:12:26 -0700, "Ted Mittelstaedt"
    <> wrote:

    >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.


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

  3. Ted Mittelstaedt

    Gary Guest

    <> wrote in message
    news:...
    > On Sun, 18 Jul 2004 15:12:26 -0700, "Ted Mittelstaedt"
    > <> wrote:
    >
    > >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.

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

    Hansang Bae Guest

    In article <newscache$j0j21i$qs5$>,
    says...
    > Here is the situation: We have a remote site that is running a Linksys
    > BEFVP41
    > that has an IPSec tunnel to a Cisco 7206.

    [snip]
    > 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.


    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?)


    > 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 of155.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,



    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.

    > 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


    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?


    > 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?


    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

    "Hansang Bae" <> wrote in message
    news:...
    > In article <newscache$j0j21i$qs5$>,
    > says...
    > > Here is the situation: We have a remote site that is running a

    Linksys
    > > BEFVP41
    > > that has an IPSec tunnel to a Cisco 7206.

    > [snip]
    > > 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.
    >
    > 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?)
    >
    >
    > > 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

    of155.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,

    >
    >
    > 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.
    >
    > > 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

    >
    > 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?
    >
    >
    > > 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?

    >
    > 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.
    > ********************************************************************
    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....

    "ciscobiz" <> wrote in message news:<RYtLc.1$Kf7.278@psinet-eu-nl>...
    > 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
    >
    > "Hansang Bae" <> wrote in message
    > news:...
    > > In article <newscache$j0j21i$qs5$>,
    > > says...
    > > > Here is the situation: We have a remote site that is running a

    > Linksys
    > > > BEFVP41
    > > > that has an IPSec tunnel to a Cisco 7206.

    > [snip]
    > > > 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.
    > >
    > > 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?)
    > >
    > >
    > > > 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

    > of155.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,

    > >
    > >
    > > 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.
    > >
    > > > 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

    > >
    > > 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?
    > >
    > >
    > > > 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?

    > >
    > > 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.
    > > ********************************************************************
    sriggs, Jul 22, 2004
    #6
  7. Ted Mittelstaedt

    Hansang Bae Guest

    In article <>,
    says...
    > 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.
    ********************************************************************
    Hansang Bae, Jul 22, 2004
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. aip
    Replies:
    0
    Views:
    1,558
  2. John Ireland
    Replies:
    1
    Views:
    1,035
    Claude LeFort
    Nov 11, 2003
  3. a.nonny mouse
    Replies:
    2
    Views:
    1,071
  4. Ted Mittelstaedt
    Replies:
    0
    Views:
    1,218
    Ted Mittelstaedt
    Dec 10, 2004
  5. AM
    Replies:
    7
    Views:
    4,386
    kh_alex81
    Jul 19, 2007
Loading...

Share This Page