I found a <b>*dirty*</b> way to workaround this issue : <br><br>In first, you can change ike and key lifetime in your ipsec.conf : <br> ikelifetime=8h<br> keylife=24h<br><br>But with these values, you will probably reach volume transfer limitation on Windows Vista side.<br>
Normally, you can change default values of transfer limit on Vista. (editing Security Policy)<br><br>But I can't do this for several reasons in my case (why ? it's out of scope ;) ).<br><br>So in order to force a connection renewal (and not rekeying), I shutdown the ipsec connection every X minutes.<br>
X depends on your bandwith usage. Default transfer volume limitation on Vista is about 100Mo (if I remember correctly...).<br>If you need a speed of 500kb/s (during a long time : ie > 4mn), you need to do this every 2-3 minutes...<br>
<br>If you don't have a lot of data transfer volume through the ipsec connection, you can do this every 30-45mn... <br>The important is : Before rekeying !<br><br>I do this with a crontab :<br>*/2 * * * * /usr/local/sbin/ipsec auto --down roadwarrior-l2tp<br>
<br>But in some cases (with a lot of connected Vista roadwarriors), it doesn't work and provoke disconnections. :(<br><br>I hope that it will be helpful for you, James... It's not perfect but it could be better ;)<br>
<br>Julien<br>(Sorry for my "rough" English ;))<br> <br><div class="gmail_quote">2008/6/12 James <<a href="mailto:james@nttmcl.com">james@nttmcl.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yeah that's the exact same problem I have.<br>
<br>
I have one user here that has been able to minimize their rekeying by doing a split tunnel and manual routing but there's problems with that obviously.<br>
don't want everyone split tunneling.<br>
<br>
-James<br>
<br>
Julien DELEAN wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
I tried your patch on openswan 2.4.12 but it doesn't seem to prevent Vista deconnections.<br>
<br>
In order to quickly provoke this behavior, I download a large file, on Vista client, to reach transfer volume limitations on Windows side and to force rekeying.<br>
<br>
I still have the same error message :<br>
Jun 12 11:56:02 xxx pluto[6962]: "roadwarrior-l2tp"[1] xx.xx.xx.xx #1: responding to Main Mode from unknown peer xx.xx.xx.xx<br>
...<br>
Jun 12 11:56:03 xxx pluto[6962]: "roadwarrior-l2tp"[2] xx.xx.xx.xx #2: STATE_QUICK_R2: IPsec SA established {ESP=>0xfb7982a1 <0xf516b8d0 xfrm=AES_128-HMAC_SHA1 NATD=xx.xx.xx.xx:4500 DPD=none}<br>
Jun 12 12:18:18 xxx pluto[6962]: "roadwarrior-l2tp"[3] xx.xx.xx.xx #3: responding to Quick Mode {msgid:02000000}<br>
Jun 12 12:18:18 xxx pluto[6962]: "roadwarrior-l2tp"[3] xx.xx.xx.xx #3: cannot install eroute -- it is in use for "roadwarrior-l2tp"[2] xx.xx.xx.xx #2<br>
<br>
James, are we talking about the same problem ?<br>
<br>
I think that the only solution is, as you said Paul, to write a patch that allows rekeys to happen to "the same ip/port as currently used". Am I right ?<br>
<br>
I could try to write this patch but I really don't know how begin to study Pluto's source code. Could anybody help me ?<br>
<br>
--<br>
Julien<br>
<br>
<br>
<br></div>
2008/6/11 Paul Wouters <<a href="mailto:paul@xelerance.com" target="_blank">paul@xelerance.com</a> <mailto:<a href="mailto:paul@xelerance.com" target="_blank">paul@xelerance.com</a>>>:<div class="Ih2E3d"><br>
<br>
On Wed, 11 Jun 2008, James wrote:<br>
<br>
How would i configure ipsec.conf to do that?<br>
<br>
<br>
the workaround is a hack, not a config option. diff against<br></div>
<a href="http://2.6.14." target="_blank">2.6.14.</a> <<a href="http://2.6.14" target="_blank">http://2.6.14</a>.>..<div><div></div><div class="Wj3C7c"><br>
Might require tweaking for 2.4.x<br>
<br>
diff --git a/programs/pluto/ikev1_main.c b/programs/pluto/ikev1_main.c<br>
index e7dbe4f..64a9c00 100644<br>
--- a/programs/pluto/ikev1_main.c<br>
+++ b/programs/pluto/ikev1_main.c<br>
@@ -2948,11 +2948,27 @@ accept_delete(struct state *st, struct<br>
msg_digest *md, struct payload_digest *p)<br>
}<br>
else<br>
{<br>
+<br>
+ /*<br>
+ * attempt at workaround bug 888. If we're in<br>
STATE_QUICK_R2, and<br>
+ * we receive a Delete AND Rekey, we will hit<br>
+ * the passert(sr->eroute_owner == SOS_NOBODY) in<br>
state.c<br>
+ * Workaround: don't delete IPsec SA now, let it<br>
linger<br>
+ */<br>
+ if(dst->st_state == STATE_QUICK_R2) {<br>
+ loglog(RC_LOG_SERIOUS, "BUG 888 workaround<br>
triggered\n. Received and "<br>
+ "ignored Delete SA(0x%08lx) payload:<br>
keeping IPSEC state #%lu"<br>
+ , (unsigned long)ntohl((unsigned<br>
long)*(ipsec_spi_t *)spi)<br>
+ , dst->st_serialno);<br>
+ }<br>
+ else<br>
+ {<br>
loglog(RC_LOG_SERIOUS, "received Delete<br>
SA(0x%08lx) payload: "<br>
"deleting IPSEC State #%lu"<br>
, (unsigned long)ntohl((unsigned<br>
long)*(ipsec_spi_t *)spi)<br>
, dst->st_serialno);<br>
delete_state(dst);<br>
+ }<br>
}<br>
<br>
/* reset connection */<br>
<br>
<br>
<br>
</div></div></blockquote>
</blockquote></div><br>