<pre>I haven&#39;t found anything in Openswan&#39;s mailinglists after this quoted email.<br>Has anybody found a solution (patch) to workaround this Vista Bug ?<br><br>I&#39;ve tried to regularly restart Vista connections with &quot;ipsec auto --replace &lt;conn_name&gt;&quot; to prevent Vista rekeying.
<br><br>It&#39;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>&gt;<i> Thanks for your fast reply.<br></i>
&gt;<br><i> Sounds good that it&#39;s not a consequence of misconfiguration. Exists a<br></i>&gt;<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>can&#39;t rekey, since we &quot;don&#39;t know where they are&quot;.<br><br>Though if someone would write a patch that allows rekeys to happen to<br>&quot;the same ip/port as currently used&quot;, then this, if no other bugs exist
<br><br>in Vista, it would workaround the current Vista bug.<br><br>Paul<br><br><br>&gt;<i> Christian<br></i>&gt;<i><br></i>&gt;<i> Am 03.10.2007 um 16:56 schrieb Paul Wouters:<br></i>&gt;<i><br></i>&gt;<i> &gt; On Wed, 3 Oct 2007, Christian Hocken wrote:
<br><br></i>&gt;<i> &gt;<br></i>&gt;<i> &gt;&gt; running on Fedora Core 6 with kernel 2.6.22.7-57.fc6.<br></i>&gt;<i> &gt;&gt; Several road warriors with different operating systems are connected<br></i>&gt;<i> &gt;&gt; to the gateway, including Windows XP SP2,
<br><br></i>&gt;<i> &gt;&gt; Windows Vista and Mac OS X. All of them are using a combination of<br></i>&gt;<i> &gt;&gt; ipsec and l2tp.<br></i>&gt;<i> &gt;&gt; Initialising the connection works fine but the Vista client gets
<br><br></i>&gt;<i> &gt;&gt; disconnected after one hour. It seems as if something during<br></i>&gt;<i> &gt;&gt; the rekey attempt goes wrong.<br></i>&gt;<i> &gt;<br></i>&gt;<i> &gt; Correct. I&#39;ve notified Microsoft of this issue. You are not the fist
<br><br></i>&gt;<i> &gt; to encounter this. It seems their rekeying code contains a bug where<br></i>&gt;<i> &gt; it tries to negotiate a &quot;new&quot; connection for the current one.<br></i>&gt;<i> &gt;<br></i>&gt;<i> &gt;&gt; #4: STATE_QUICK_R2: IPsec SA established {ESP=&gt;0x67d65cc2 &lt;0x4d8fe6fb
<br><br></i>&gt;<i> &gt;&gt; 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>&gt;<i> &gt;<br>
</i>&gt;<i> &gt;&gt; Oct  2 23:55:30 gateway pluto[7841]: &quot;l2tp-cert-nat&quot;[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>&gt;
<i> &gt;&gt; #5: responding to Quick Mode {msgid:02000000}<br></i>&gt;<i> &gt;&gt; Oct  2 23:55:30 gateway pluto[7841]: &quot;l2tp-cert-nat&quot;[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>&gt;<i> &gt;&gt; #5: cannot install eroute -- it is in use for &quot;l2tp-cert-nat&quot;[4]<br></i>&gt;<i> &gt;&gt; <a href="http://80.130.250.50/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
80.130.250.50</a> #4<br></i>&gt;<i> &gt;<br></i>&gt;<br><i> &gt; Paul</i></pre>