Thread: Re: [Ipsec-tools-devel] Deleting Phase 2 SA's
Brought to you by:
mit_warlord,
netbsd
From: Victor B. <Vic...@qu...> - 2007-11-28 23:14:18
|
I found the same problem - when a remote peer disconnects non-cleanly (e.g. reboot or the client on their side is killed), the phase 2 SA remains. Instead of negotiating a new one racoon tries to use the existing one, which no longer exists on the peer. This prevents renegotiation.=20 =20 I haven't found a solution, except telling clients to wait 10 minutes or so for the phase 2 SA to expire (by definition, it will be completely idle), so that a new one is negotiated when they connect. =20 Cheers, =20 V =20 _____ =20 From: ips...@li... [mailto:ips...@li...] On Behalf Of Doug Oucharek Sent: Thursday, 29 November 2007 10:02 AM To: ips...@li... Subject: [Ipsec-tools-devel] Deleting Phase 2 SA's =20 I am developing on Linux 2.6.17 with ipsec-tools 0.6.6 for an embedded product. It is important that this product be self-maintaining in real-time and not require human intervention. When an IPSec SA has been established, and the remote end reboots, I find the SA cannot be re-established. =20 It is a requirement that the lifetimes be zero (I know, not secure, but it is a requirement for now) so there is no attempt on the side which did not reboot to re-establish the SA's as it thinks they are just fine. I am using PSK ESP. =20 I have a daemon which can detect that communication with the remote party is no longer possible (due it the remote rebooting) and take some sort of action (like purging the isakmp and ipsec SA's for that remote party). I thought the perfect tool for this would be to invoke "racoonctl vpn-disconnect <addr>". However, when I do this, only the isakmp SA gets deleted; the ipsec SA's persist (and keep getting used preventing re-negotiation). Likewise, "racoonctl delete-sa" will only affect the isakmp SA's. I looked over the code and this is certainly the case. =20 I take it that a solution like the one described here did not happen: http://article.gmane.org/gmane.network.ipsec.tools.devel/426 =20 Does anyone have a good suggestion on how I can achieve what I want? =20 Doug |
From: Krzysztof O. <ol...@an...> - 2007-11-28 23:18:12
|
On Thu, 29 Nov 2007, Victor Bajanov wrote: > I found the same problem - when a remote peer disconnects non-cleanly > (e.g. reboot or the client on their side is killed), the phase 2 SA > remains. Instead of negotiating a new one racoon tries to use the > existing one, which no longer exists on the peer. This prevents > renegotiation. > > > > I haven't found a solution, except telling clients to wait 10 minutes or > so for the phase 2 SA to expire (by definition, it will be completely > idle), so that a new one is negotiated when they connect. DPD (Dead Peer Detection) is what you probably need. Best regards, =09=09=09Krzysztof Ol=EAdzki |
From: Stephen C. <Ste...@se...> - 2007-11-29 12:58:17
|
Krzysztof Oledzki wrote: > > > On Thu, 29 Nov 2007, Victor Bajanov wrote: > >> I found the same problem - when a remote peer disconnects non-cleanly >> (e.g. reboot or the client on their side is killed), the phase 2 SA >> remains. Instead of negotiating a new one racoon tries to use the >> existing one, which no longer exists on the peer. This prevents >> renegotiation. >> >> >> >> I haven't found a solution, except telling clients to wait 10 minutes or >> so for the phase 2 SA to expire (by definition, it will be completely >> idle), so that a new one is negotiated when they connect. > > > DPD (Dead Peer Detection) is what you probably need. > > Best regards, > > Krzysztof Olędzki > >------------------------------------------------------------------------ > >------------------------------------------------------------------------- >SF.Net email is sponsored by: The Future of Linux Business White Paper >from Novell. From the desktop to the data center, Linux is going >mainstream. Let it simplify your IT future. >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > >------------------------------------------------------------------------ > >_______________________________________________ >Ipsec-tools-devel mailing list >Ips...@li... >https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > What we have done is when our monitoring daemon determines that the vpn is no longer passing traffic besides using racoonctl to purge the phase 1 sa, we also use setkey to purge the associated phase 2 sa. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) |