<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Jacco,<br>
I noticed that recompiling the kernel wasn't necessary because FC3
supports NETKEY and thereby supports NAT-T. Thanks. So I recompiled
openswan 2.4.4 with the patch for NAT-ed servers, but now things have
got worse.<br>
I now have the following in my ipsec.conf:<br>
<br>
conn roadwarrior<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pfs=no<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left=192.168.1.52<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftsubnet=192.168.1.0/24<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftnexthop=192.168.1.1<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; leftid=@Servername<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; right=%any<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightsubnet=vhost:%no,%priv<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rightid=@Clientname<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=add<br>
<br>
together with:&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24<br>
in the config setup section. <br>
<br>
With this configuration, the client does not even make it to my server:
no messages in the log files, so no security negotiations, and the
WinXP client gives: "Error 789: The L2TP connection attempt failed
because the security layer encountered a processing error during
initial negotiations with the remote computer". But nothing has changed
in the config of both NAT devices!<br>
<br>
By the way:<br>
<blockquote type="cite">The user's workstation located behind the NAT
device has a private IP address from one of the ranges defined in <a
 href="http://www.ietf.org/rfc/rfc1918.txt">RFC 1918</a> (let's say <tt>192.168.111.40</tt>).
Openswan needs to know a little bit about this address before it can
negotiate a connection. The public IP address of the user's NAT device
is specified with the <tt>right=</tt> parameter. There are three ways
to specify the private address of the user's workstation behind the NAT
device:
  <ul>
    <li><tt>rightsubnet=192.168.111.40/32 &nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Method 1</tt>
    </li>
    <li><tt>rightsubnetwithin=192.168.111.0/24 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # Method 2</tt>
    </li>
    <li><tt>virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24<br>
rightsubnet=vhost:%no,%priv&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # Method 3
(recommended)</tt></li>
  </ul>
</blockquote>
This quote from your site is confusing me. When Method 3 is combined
with right=PUBLIC-NAT-IP, openswan complains that virtual_private
should go hand in hand with right=%any.<br>
<br>
For me, right=%any is obligatory, since I want to use (for the time
being) PSKs. But what does this mean:<br>
<blockquote type="cite">You will have to specify <tt>right=%any</tt>
and use <tt>leftid=</tt> / <tt>rightid=</tt>, which means that the
PSK is shared by all Road Warriors. </blockquote>
Is the above roadwarrior conn section in agreement with this advice?<br>
<br>
</body>
</html>