The network in question is -not- using NAT, it supplies &quot;real&quot; IP addresses to clients, but isolates them behind a high-security firewall. It&#39;s an odd setup, for sure, but it&#39;s located at a high-security facility with paranoid policies.<div>
<br class="webkit-block-placeholder"></div><div>Presumably, if I move the IPsec server to an exposed host on my network, I can use regular IPsec for the special-case network, and use NAT-T for any roadwarrior clients that happen to be behind NAT at normal, unrestricted access points (like home, hotels, etc.)</div>
<div><br class="webkit-block-placeholder"></div><div>Or will pluto require that NAT-T always be used, regardless of whether the endpoints are actually behind NAT or not?</div><div><br class="webkit-block-placeholder"></div>
<div>-Ryan</div><div><br><br><div class="gmail_quote">On Feb 5, 2008 1:35 PM, Paul Wouters &lt;<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Tue, 5 Feb 2008, Ryan Cabell wrote:<br><br></div><div class="Ih2E3d">&gt; Unfortunately, I have no control over the security policies on the wireless<br>&gt; network at the customer&#39;s facility, but on the plus side this network does<br>
&gt; hand out un-NATed IPs.<br><br></div>Anyone allowing proto 50/51 and udp 500, and not udp 4500, and using NAT,<br>has misconfigured their network.<br><div class="Ih2E3d"><br>&gt; I&#39;ll look into moving the L2TP/IPsec server to an exposed host on our end.<br>
<br></div>Even if only one endpoint is behind NAT, you need udp port 4500. Moving<br>openswan to a public ip while clients are still behind a NAT that blocks<br>port 4500 will not help you.<br><br>Paul<br><div><div></div>
<div class="Wj3C7c"><br>&gt;<br>&gt;<br>&gt; thanks,<br>&gt; Ryan<br>&gt;<br>&gt; On Feb 5, 2008 12:22 PM, Paul Wouters &lt;<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>&gt; wrote:<br>&gt;<br>&gt; &gt; On Tue, 5 Feb 2008, Ryan Cabell wrote:<br>
&gt; &gt;<br>&gt; &gt; &gt; I&#39;m trying to work out an issue that I&#39;ve been struggling with for over<br>&gt; &gt; a<br>&gt; &gt; &gt; week now. I am trying to support roadwarrior clients (using Mac OS X)<br>&gt; &gt; &gt; connecting to xl2tpd on an Openswan (2.4.10) server behind a NAT router.<br>
&gt; &gt; &gt; Some of these clients are using a customer&#39;s wireless network that does<br>&gt; &gt; not<br>&gt; &gt; &gt; allow access to port 4500, only UDP port 500 and ESP/AH, so I can&#39;t use<br>&gt; &gt; &gt; NAT-T.<br>
&gt; &gt;<br>&gt; &gt; Then you cannot use IPsec.<br>&gt; &gt;<br>&gt; &gt; &gt; I finally got the IPsec handshake working by turning off NAT-T and<br>&gt; &gt; enabling<br>&gt; &gt; &gt; &quot;IPsec Passthrough&quot; on the gateway. However, clients can&#39;t access the<br>
&gt; &gt; L2TP<br>&gt; &gt; &gt; server (or anything else) when connected.<br>&gt; &gt;<br>&gt; &gt; ipsec passthrough will not work with more then one client - if you get it<br>&gt; &gt; to<br>&gt; &gt; work at all in transport mode.<br>
&gt; &gt;<br>&gt; &gt; The fix is to allow port 4500. It&#39;s mandatory. Push it through or switch<br>&gt; &gt; ISP&#39;s.<br>&gt; &gt;<br>&gt; &gt; Paul<br>&gt; &gt;<br>&gt;<br><br></div></div><font color="#888888">--<br>
Building and integrating Virtual Private Networks with Openswan:<br><a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155" target="_blank">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a><br>
</font></blockquote></div><br></div>