<div dir="ltr">With the following patch, I was able to correct the NAT-T detection. However the problem still persists.<br><br>--- programs/pluto/nat_traversal.c.orig Wed Nov 7 08:08:21 2007<br>+++ programs/pluto/nat_traversal.c Sat Jul 19 15:47:12 2008<br>
@@ -267,7 +267,7 @@<br> _natd_hash(st->st_oakley.hasher, hash_me<br> , st->st_icookie, st->st_rcookie<br> , &(md->iface->ip_addr)<br>- , ntohs(md->iface->port));<br>+ , st->st_state == STATE_AGGR_R1 ? ntohs(IKE_UDP_PORT) : ntohs(md->iface->port));<br>
<br>/**<br>* The others with sender IP & port <br><br>Digging the problem I found:<br><br>ipsec client <a href="http://172.16.1.2">172.16.1.2</a> --- <a href="http://172.16.1.1">172.16.1.1</a> NATbox <a href="http://172.16.2.1">172.16.2.1</a> --- <a href="http://172.16.2.2">172.16.2.2</a> openswan-server<br>
<br>Client packets are being S-NATed by the NATbox (one to one IP mapping: <a href="http://172.16.1.2">172.16.1.2</a> -> <a href="http://172.16.2.1">172.16.2.1</a>).<br><br>As the client initiates the connection, openswan detects: both are NATed.<br>
<br>NATbox generates connection tracking / conntrack entries:<br>1. client ip and port (<a href="http://172.16.1.2:500">172.16.1.2:500</a>) <-> server ip and port (<a href="http://172.16.2.2:500">172.16.2.2:500</a>)<br>
2. client ip and port (<a href="http://172.16.1.2:4500">172.16.1.2:4500</a>) <-> server ip and port (<a href="http://172.16.2.2:4500">172.16.2.2:4500</a>)<br><br>openswan sends DPD_R_U_THERE packets using 500 as the source port and 4500 as the destination port.<br>
<br>As the NATbox is not having any conntrack entry for <a href="http://172.16.1.2:4500">172.16.1.2:4500</a> <-> <a href="http://172.16.2.2:500">172.16.2.2:500</a>, it thinks the packet is for itself and rejects the packet. Connection breaks after DPD timeout interval.<br>
<br>In main mode, it sends packets using 4500 as source and destination ports.<br><br>Thanks for your time.<br><br>-hiren<br><br><div class="gmail_quote">On Fri, Jul 18, 2008 at 8:24 PM, hiren joshi <<a href="mailto:joshihirenn@gmail.com">joshihirenn@gmail.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 dir="ltr">Is it the same for 2.4.12 also?<br>I tested this on openswan-2.4.12.<div><div>
</div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Fri, Jul 18, 2008 at 3:12 AM, Paul Wouters <<a href="mailto:paul@xelerance.com" target="_blank">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>On Thu, 17 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;">
openswan detects NAT-Traversal as "both are NATed" instead of "peer is<br>
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<br>
DPD_R_U_THERE_ACK<br>
</blockquote>
<br></div>
DPD is broken on the 2.6.x series. We're looking into it.<br><font color="#888888">
<br>
Paul<br>
</font></blockquote></div><br></div></div></div>
</blockquote></div><br></div>