I've found bugtracks concerning my problem : <br><a href="http://bugs.xelerance.com/view.php?id=294">http://bugs.xelerance.com/view.php?id=294</a> (closed)<br><br><a href="http://bugs.xelerance.com/view.php?id=867">http://bugs.xelerance.com/view.php?id=867
</a><br>could you confirm me : it conerns what you have described in previous emails ?<br><br>is there a patch available ? (a patch that allows rekeys to happen to "the same ip/port as currently used")<br>Do you believe that Vista SP1 will fix that ?
<br><br>Thanks<br><br>Julien<br><br><div><span class="gmail_quote">2008/1/15, Julien DELEAN <<a href="mailto:julien.delean@gmail.com">julien.delean@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<pre>I haven't found anything in Openswan's mailinglists after this quoted email.<br>Has anybody found a solution (patch) to workaround this Vista Bug ?<br><br>I've tried to regularly restart Vista connections with "ipsec auto --replace <conn_name>" to prevent Vista rekeying.
<br><br><br>It's a little better but not acceptable <br><br>Thanks !<br><br>Regards<br><br>Julien<br><br>-------------------<br>On Wed, 3 Oct 2007, Christian Hocken wrote:<br><br>><i> Thanks for your fast reply.<br>
</i><br>><br><i> Sounds good that it's not a consequence of misconfiguration. Exists a<br></i>><i> workaround solution?<br></i><br>Unfortunately not for roadwarriors. One work around would be to initiate<br>our own rekeying before Vista starts to rekey, but with right=%any we
<br><br><br>can't rekey, since we "don't know where they are".<br><br>Though if someone would write a patch that allows rekeys to happen to<br>"the same ip/port as currently used", then this, if no other bugs exist
<br><br><br>in Vista, it would workaround the current Vista bug.<br><br>Paul<br><br><br>><i> Christian<br></i>><i><br></i>><i> Am 03.10.2007 um 16:56 schrieb Paul Wouters:<br></i>><i><br></i>><i> > On Wed, 3 Oct 2007, Christian Hocken wrote:
<br><br><br></i>><i> ><br></i>><i> >> running on Fedora Core 6 with kernel 2.6.22.7-57.fc6.<br></i>><i> >> Several road warriors with different operating systems are connected<br></i>><i> >> to the gateway, including Windows XP SP2,
<br><br><br></i>><i> >> Windows Vista and Mac OS X. All of them are using a combination of<br></i>><i> >> ipsec and l2tp.<br></i>><i> >> Initialising the connection works fine but the Vista client gets
<br><br><br></i>><i> >> disconnected after one hour. It seems as if something during<br></i>><i> >> the rekey attempt goes wrong.<br></i>><i> ><br></i>><i> > Correct. I've notified Microsoft of this issue. You are not the fist
<br><br><br></i>><i> > to encounter this. It seems their rekeying code contains a bug where<br></i>><i> > it tries to negotiate a "new" connection for the current one.<br></i>><i> ><br></i>>
<i> >> #4: STATE_QUICK_R2: IPsec SA established {ESP=>0x67d65cc2 <0x4d8fe6fb<br><br><br></i>><i> >> xfrm=AES_128-HMAC_SHA1 NATD=<a href="http://80.130.250.50:4500/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
80.130.250.50:4500</a> DPD=none}<br></i>><i> ><br><br></i>><i> >> Oct 2 23:55:30 gateway pluto[7841]: "l2tp-cert-nat"[5] <br><a href="http://80.130.250.50/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
80.130.250.50</a><br></i>><br><i> >> #5: responding to Quick Mode {msgid:02000000}<br></i>><i> >> Oct 2 23:55:30 gateway pluto[7841]: "l2tp-cert-nat"[5] <a href="http://80.130.250.50/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
<br>80.130.250.50</a><br></i>><i> >> #5: cannot install eroute -- it is in use for "l2tp-cert-nat"[4]<br></i>><i> >> <a href="http://80.130.250.50/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
<br>80.130.250.50</a> #4<br></i>><i> ><br></i>><br><i> > Paul</i></pre>
</blockquote></div><br>