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