IKE/IPSec problem

Raymakers, Guy guy.raymakers at eds.com
Thu Aug 9 02:15:28 EDT 2001


Jerry,

It's in global config mode : crypto isakmp keepalive 10 . The value can go
up to 3600.

Best regrads,
Guy

-----Original Message-----
From: Jerry Roy [mailto:jroy at axcelerant.com]
Sent: Wednesday, August 08, 2001 8:31 PM
To: VPN at securityfocus.com
Subject: RE: IKE/IPSec problem


Hi Guy,

Great find. I believe this does work. I have noticed that the node gets
purged on the remote side when the clear crypto is is run on the head
end. A few minutes go by but it does eventually happen. Question, how do
I set the IKE keepalives?

Best Regards,

Jerry Roy

-----Original Message-----
From: Raymakers, Guy [mailto:guy.raymakers at eds.com]
Sent: Wednesday, August 08, 2001 6:22 AM
To: 'VPN mailing list'
Subject: RE: IKE/IPSec problem
Importance: High



Hi All,

I've found some documentation about this on the Cisco Website :

"One of the most common issues today in large-scale VPNs is the stale
SA,
which occurs when one device at the end of the tunnel maintains the
tunnel
state but the other remote end does not. The loss of state could occur
during link failure, misconfiguration, troubleshooting, system
maintenance,
or complete device failure. IKE keepalives resolve this issue by
removing
the state of the old tunnel and setting up a new tunnel. Routing
protocol
resilience, however, keeps the tunnels up at all times and, therefore,
is
more likely to run into a stale SA problem. There is no feedback link
between network reachability over a tunnel and tunnel status. In other
words, if a network is no longer reachable over a tunnel, the tunnel is
not
torn down until it times out. When the remote device comes back on line,
if
it had lost tunnel state, it will attempt to establish a new tunnel. The
device that remained active will receive a tunnel-establishment request
for
a tunnel for which it already has state. Believing the request to be a
possible denial-of-service (DoS) attack, the device will ignore the
request.
This ignoring of the request could be an issue in everyday system
administration when devices are taken off line for maintenance. Cisco
recommends that when you are taking headend VPN devices off line for
maintenance that you clear the IKE SAs on the remote devices to
facilitate
IKE reestablishment." 

The last sentence gives me a bad feeling, how could you clear all SA's
on
e.g. 2000 remotes ?   Could this be done by simply issue the "clear cry
isa"
command on the headend routers .....

Does anyone have experience with this ?

Many Thanks,
Guy


-----Original Message-----
From: Raymakers, Guy 
Sent: Tuesday, August 07, 2001 3:50 PM
To: 'VPN mailing list'
Subject: IKE/IPSec problem


Hi All,

I've the following situation : 

	HQ Network ------ VPN RTR ------ Leased Line ------ Internet
-------- ISDN------- Remote VPN RTR ----remote network

The scenario is : the Remote VPN RTR has an active SA with the VPN RTR.
For
a while there's no data going over the ISDN line so the idle timer drops
the
connection. Some moments after this , due maintenance or something , the
central VPN RTR is rebooted or all the SA's are cleared. After the
reboot
the central VPN RTR has no active SA's while the Remote VPN RTR still
has
the 'old' established SA active. When the Remote wants to send data
again,
the ISDN link comes up and the Remote VPN RTR will start sending data
using
the old SA.  From my tests, I had to manually clear the SA's on the
Remote
VPN RTR to get the IPSEC up and running again. Does anyone have
experienced
this also and found a solution for it ? 

The routers are Cisco 's 1720 and 7140...

Many Thanks
Guy


VPN is sponsored by SecurityFocus.com

VPN is sponsored by SecurityFocus.com


VPN is sponsored by SecurityFocus.com

VPN is sponsored by SecurityFocus.com





More information about the VPN mailing list