Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Need help with IPSec tunnel periodically collapsing

Reply
Thread Tools

Need help with IPSec tunnel periodically collapsing

 
 
Ted Mittelstaedt
Guest
Posts: n/a
 
      07-18-2004
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


 
Reply With Quote
 
 
 
 
chris@nospam.com
Guest
Posts: n/a
 
      07-19-2004
On Sun, 18 Jul 2004 15:12:26 -0700, "Ted Mittelstaedt"
<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Gary
Guest
Posts: n/a
 
      07-19-2004

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


 
Reply With Quote
 
Hansang Bae
Guest
Posts: n/a
 
      07-21-2004
In article <newscache$j0j21i$qs5$(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) 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.
************************************************** ******************
 
Reply With Quote
 
ciscobiz
Guest
Posts: n/a
 
      07-21-2004
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <newscache$j0j21i$qs5$(E-Mail Removed)>,
> (E-Mail Removed) 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.
> ************************************************** ******************



 
Reply With Quote
 
sriggs
Guest
Posts: n/a
 
      07-22-2004
Ditch the Linksys and use a real Cisco product like 800 series...they
work all the time....

"ciscobiz" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article <newscache$j0j21i$qs5$(E-Mail Removed)>,
> > (E-Mail Removed) 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.
> > ************************************************** ******************

 
Reply With Quote
 
Hansang Bae
Guest
Posts: n/a
 
      07-22-2004
In article <(E-Mail Removed) >,
(E-Mail Removed) 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.
************************************************** ******************
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
One IPsec tunnel and no ISAKMP tunnel. AM Cisco 7 07-19-2007 03:11 PM
IPSec Tunnel problem, need help !! yellow Cisco 3 01-04-2007 02:50 AM
Revisited - Need help with IPSec tunnel periodically collapsing with 7206 to Linksys BEFVP41 Ted Mittelstaedt Cisco 0 12-10-2004 08:08 PM
Split Tunnel Blocks http through tunnel but passes http around tunnel a.nonny mouse Cisco 2 09-19-2004 12:10 AM
Termination of an IPSec VPN tunnel and a GRE Tunnel on one physical interface. John Ireland Cisco 1 11-11-2003 04:47 PM



Advertisments