<div dir="ltr">Sorry for posting late.<br><br>As per my previous post::<br><br>openswan --- gw --- router --- NATbox --- RW<br>
<br>
openswan detects NAT-Traversal as "both are NATed" instead of "peer is NATed".<br>
<br>
Later on I receive,<br>
DPD: Serious: could not find newest phase 1 state<br>
DPD: Warning: received old or duplicate R_U_THERE<br>
<br>
After some time client breaks the connection due of not getting DPD_R_U_THERE_ACK<br>
<br>
Thanks for your time.<br>
<font color="#888888"><br>
-hiren</font><br><br><div class="gmail_quote">On Fri, Jul 11, 2008 at 11:15 PM, Paul Wouters <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> 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">On Thu, 10 Jul 2008, hiren joshi wrote:<br>
<br>
> The bug exists in 2.4.12 too.<br>
><br>
> In aggressive mode initiator uses port 500 to generate the hash (because the<br>
> packet was received on 500) and sends it in NAT-D payload.<br>
<br>
</div><div class="Ih2E3d">> Responder uses 4500 to verify received hash as it has switch to 4500.<br>
<br>
</div><div class="Ih2E3d">> "aggr-1"[2] <a href="http://172.16.2.1" target="_blank">172.16.2.1</a> #62: NAT-Traversal: Result using RFC 3947<br>
> (NAT-Traversal): both are NATed<br>
<br>
</div>Apart from seeing "both are NATed" instead of "client is NAT'ed", there should<br>
not be any operational difference, since NAT-T is just being enabled.<br>
<br>
Do you experience any problem?<br>
<font color="#888888"><br>
Paul<br>
</font></blockquote></div><br></div>