<div dir="ltr">Hello,<br><br>While working on the issue I observe that: in programs/pluto/demux.c<br>&#39;complete_state_transition&#39; calls &#39;nat_traversal_change_port_lookup&#39; only if the state transition requested to send a reply packet.<br>
As in aggressive mode, there will be no reply packet in transition from STATE_AGGR_R1 to STATE_AGGR_R2, port floating will not happen for p1st (phase-1 SA).<br><br>The following patch calls &#39;nat_traversal_change_port_lookup&#39; unconditional to sending reply packet.<br>
<br>--- demux.c.orig&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wed Aug 27 17:51:48 2008<br>+++ demux.c&nbsp;&nbsp;&nbsp;&nbsp; Wed Aug 27 20:57:02 2008<br>@@ -2463,6 +2463,12 @@ complete_state_transition(struct msg_dig<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* free previous transmit packet */<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; freeanychunk(st-&gt;st_tpacket);<br>
&nbsp;<br>+#ifdef NAT_TRAVERSAL<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (nat_traversal_enabled) {<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nat_traversal_change_port_lookup(md, md-&gt;st);<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>+#endif<br>+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* if requested, send the new reply packet */<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (smc-&gt;flags &amp; SMF_REPLY)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>@@ -2480,12 +2486,6 @@ complete_state_transition(struct msg_dig<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clonetochunk(st-&gt;st_tpacket, md-&gt;reply.start<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; , pbs_offset(&amp;md-&gt;reply), &quot;reply packet&quot;);<br>
&nbsp;<br>-#ifdef NAT_TRAVERSAL<br>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (nat_traversal_enabled) {<br>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nat_traversal_change_port_lookup(md, md-&gt;st);<br>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>-#endif<br>-<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* actually send the packet<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Note: this is a great place to implement &quot;impairments&quot;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * for testing purposes.&nbsp; Suppress or duplicate the<br><br>Although the patch is not thourouly tested, now phase-1 SA sends DPD_R_U_THERE_ACK using source port 4500, (as the NATbox has conntrack entry for client:4500 -&gt; server:4500) peer receives the packet, and connection remains established.<br>
<br>Please share your views on this.<br><br>Thanks for your time.<br><br>Regards,<br>-hiren<br><br><br><div class="gmail_quote">On Tue, Jul 22, 2008 at 11:29 AM, hiren joshi <span dir="ltr">&lt;<a href="mailto:joshihirenn@gmail.com">joshihirenn@gmail.com</a>&gt;</span> 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 dir="ltr">Filed a bug report: <a href="http://bugs.xelerance.com/view.php?id=972" target="_blank">http://bugs.xelerance.com/view.php?id=972</a><br>
<br>Thanks for all your answers on this.<br><font color="#888888"><br>-hiren</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">
On Tue, Jul 22, 2008 at 9:10 AM, Paul Wouters &lt;<a href="mailto:paul@xelerance.com" target="_blank">paul@xelerance.com</a>&gt; 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>On Fri, 18 Jul 2008, hiren joshi wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is it the same for 2.4.12 also?<br>
I tested this on openswan-2.4.12.<br>
</blockquote>
<br></div>
No, DPD on openswan 2.4.12 or 2.4.13 should work fine.<br><font color="#888888">
<br>
Paul</font><div><div></div><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Jul 18, 2008 at 3:12 AM, Paul Wouters &lt;<a href="mailto:paul@xelerance.com" target="_blank">paul@xelerance.com</a>&gt; wrote:<br>
 &nbsp; &nbsp; &nbsp;On Thu, 17 Jul 2008, hiren joshi wrote:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;openswan detects NAT-Traversal as &quot;both are<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NATed&quot; instead of &quot;peer is<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;NATed&quot;.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Later on I receive,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;DPD: Serious: could not find newest phase 1 state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;DPD: Warning: received old or duplicate R_U_THERE<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;After some time client breaks the connection due<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of not getting<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;DPD_R_U_THERE_ACK<br>
<br>
<br>
DPD is broken on the 2.6.x series. We&#39;re looking into it.<br>
<br>
Paul<br>
<br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>