[vpn-help] Problem with Phase 2 SA lifetime rekeying

[Mark A. Sibert]

On Thu, Apr 12, 2012 at 1:58 PM, Mark A. Sibert <marksibert at gmail.com>wrote:

>
>
> Date: Wed, 11 Apr 2012 22:42:18 -0400
>> From: Kevin VPN <kvpn at live.com>
>> Subject: Re: [vpn-help] Problem with Phase 2 SA lifetime rekeying
>>        between ShrewSoft 2.1.7 and Cisco IOS
>> To: vpn-help at lists.shrew.net
>> Message-ID: <BLU0-SMTP30773189AB89CCFAA122200A03A0 at phx.gbl>
>> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>>
>> On 04/11/2012 12:28 PM, Mark A. Sibert wrote:
>> > Has anyone figured out the cause of this problem and/or a solution to
>> it?
>> >
>> > My connection drops briefly every 48 minutes.  It appears it's the
>> > same issue as described here - the SA expires and Shrew does
>> > re-establish the connection automatically, but traffic stops for maybe
>> > 30 seconds during the process.  Long enough to terminate the
>> > connections for some of the programs I'm running.
>> >
>> > Cisco AnyConnect works fine, but doesn't allow me to do split
>> > tunneling like Shrew does.  I'm running 2.2.0-beta-2.
>> >
>> > Thanks!
>> >
>> > - Mark
>> >
>> >
>> > On Mon, 21 Mar 2011 02:25:51 +0200
>> > "Nikolaj Griscenko"<n.griscenko at gmail.com>  wrote:
>> >
>> >>
>> >> I have encountered a problem I can't solve. The connection between
>> >> shrewsoft 2.1.7 client (Win 7 x64) and Cisco 2811 router (12.4.(3g)
>> >> IOS) is established normally and traffic passes ok, but when phase 2
>> >> security association life-time expires - shrewsoft can't renegotiate
>> >> a new SA with Cisco and former SA is deleted. I checked the SA
>> >> parameter both on Cisco and Shrewsoft and tried different SA values,
>> >> but no luck. I also attach my trace files. What could be the problem?
>> >> Could it be a software bug? Thanks.
>> >>
>> >
>> > Hi Nikolaj,
>> >
>> > I looked at your ike trace and it does look like the Phase 2
>> > re-negotiation is failing.  I can see a bunch of phase2 resends:
>> >
>> > 11/03/21 01:50:21 ->  : resend 1 phase2 packet(s) 192.168.0.125:4500 ->
>> > X.X.X.X:4500
>> > 11/03/21 01:50:21 ->  : resend 1 phase2 packet(s) 192.168.0.125:4500 ->
>> > X.X.X.X:4500
>> > 11/03/21 01:50:26 ->  : resend 1 phase2 packet(s) 192.168.0.125:4500 ->
>> > X.X.X.X:4500
>> > 11/03/21 01:50:26 ->  : resend 1 phase2 packet(s) 192.168.0.125:4500 ->
>> > X.X.X.X:4500
>> >
>> > Unfortunately, the log doesn't suggest (to me at least) any reason why
>> > the phase2 packets aren't going through.  If you checked that the Phase
>> > 2 SA lifetime parameter was the same in the Shrew client and the Cisco,
>> > Phase 2 re-negotiation should occur many times because your Phase 1
>> > lifetime is 86400 seconds (vs 300 seconds for Phase 2).
>> >
>> > Perhaps someone with more experience with Cisco can help?  I know
>> > there's some settings regarding Cisco compatible vendor IDs, but I
>> > don't know what they do.
>> >
>>
>> Hi Mark,
>>
>> My observation of Shrew's behaviour is that it actually tries to setup a
>> new SA *before* the old one expires.  If you look in the Trace Utility
>> at the SA tab close the the expiry time, you may find that there's two
>> SAs, the old one with status DYING and a new one.
>>
>> I've sometimes seen that one end of the tunnel switches to the new SA
>> before the other end, so you end up with a strange situation of bytes in
>> one direction using one SA and bytes in the other direction using the
>> other SA.
>>
>> Perhaps there is a problem with this process.  Either the Cisco does not
>> allow two concurrent SAs, so Shrew has to wait until the first SA has
>> completely died before starting the re-negotiation, or the Cisco balks
>> at the "split-SA" condition and drops packets that Shrew sends over the
>> new SA before the Cisco has switched to it?
>>
>>
>
> I agree with your observation.  Shrew appears to be setting up a new SA
> before the old one expires, which seems like a reasonable thing to do.
> There's definitely something weird going on with the transition to the new
> SA, though.  As far as I can tell, Cisco Anyconnect doesn't have a trace
> utility that can be used to compare the behavior.
>
> I've played around with a bunch of the configuration settings, none of
> which helped.
>
> - Mark
>

Today, I tried setting the Phase 1 and Phase 2 Key Life Time Limits to
28,800 seconds.  (Since that was the maximum allowable value for Phase 2.)
 Approximately 6 hours and 24 minutes later, I got the same behavior where
traffic stops temporarily, then resumes.  This happens at 80% of the
lifetime limit, just as 48 minutes was 80% of the 1-hour limit I had
specified previously.  I looked through the IKE Service tab of the Trace
Utility and confirmed that the 'traffic hiccup' occurred while Shrew was
setting up new SAs.

This has now gone from being a major hassle to a minor nuisance.  I can
live with a 'hiccup' every six hours if it means I can use split tunneling.
 :-)  Still, it would be nice if someone knowledgeable in such things could
determine what is happening and why.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20120413/9bb9133c/attachment-0002.html>