This will allow the Windows clients to create an IPSec SA between itself and the VPN server.

Unfortunately, the version of Openswan that comes with Lucid is now pretty out of date, and you may have trouble getting iPhones and iPads connected to this same setup if you use their package. I realize this guide is for Windows clients, but we try to be accommodating. If you want to try the regular Ubuntu packages, see the previous version of this document. As for the rest of us, we will continue on with the latest versions of things.

Download the latest version of Openswan to your computer.
wget http://openswan.org/download/openswan-2.6.35.tar.gz

Expand the file and enter the directory
tar -zxvpf openswan-2.6.35.tar.gz
cd openswan-2.6.35

In order to actually compile the program, we just need to install a few packages from the default Ubuntu repositories. Then we can compile Openswan. We do these with the commands below.
apt-get install libgmp3-dev bison flex
make programs

At this point, if there were no errors in the compiling, we can go ahead and install it. (If you have the Ubuntu version of Openswan installed, you can uninstall it first with apt-get remove openswan)
sudo make install

Congratulations! The latest version of Openswan is now installed. Now we can get on with the setup.

Set left=12.34.56.78 [should be set to your external IP address on the machine users will connect to]
leftnexthop=12.34.56.1 [set this to your external gateway]

Add: include /etc/ipsec.d/l2tp-psk.conf
Also, for Windows Vista to work properly, we need to tell it which private subnets are allowed, and which are not. In our example, since our company's internal subnet is 192.168.1.0/24, we disallow that (at the end of the line).
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v6:fd00::/8,%v6:fe80::/10,%v4:!192.168.1.0/24

Add: 12.34.56.78 %any: "yourSharedPSK!"

At this point, your VPN server should be listening on port 500/udp and 4500/udp for connections. You can check this using netstat -antu.

This will check to see if the IPSec side of things is working properly.

You'll need to allow udp/500 and udp/4500 to your external interface through the firewall on your INPUT chain. I also added protocol 50. How this looks depends on your firewall implementation, but my iptables filter rules look like this:
-A INPUT -p 50 -j ACCEPT
-A INPUT -p udp -d 12.34.56.78 --dport 500 -j ACCEPT
-A INPUT -p udp -d 12.34.56.78 --dport 4500 -j ACCEPT

On a Windows XP client, we set things up for a quick test:
Control Panel > Network Connections > File > New connection...
Select Connect to the network at my workplace
Select Virtual Private Network connection
Company Name: Your Company
Select Do not dial the initial connection
Host name or IP address: 12.34.56.78
Properties > Security > IPSec Settings > Check Use pre-shared key for authentication
Pre-shared key: yourSharedPSK!
Properties > Network > Type of VPN: L2TP IPSec VPN
Whether you want to allow split tunneling is up to you: Properties > Networking > TCP/IP > Properties > Advanced... > General > Uncheck Use default gateway on remote network

Pay atention to Windows clients that conects to L2TP server behind NAT:

To create and configure the

http://support.microsoft.com/kb/926179/en-us

Now, monitor /var/log/auth.log (perhaps with tail -f /var/log/auth.log) and connect with the Windows client.

In the end, the connection will fail, but you should see connection attempts on the VPN server with a STATE_QUICK_R2: IPsec SA established. This means the IPSec side of things is working with the pre-shared key.

registry value, follow these steps:

1. Log on to the Windows Vista client computer as a user who is a member of the Administrators group.
2. Click Start
    Collapse this imageExpand this image

   
   , point to All Programs, click Accessories, click Run, type regedit, and then click OK. If the User Account Control dialog box is displayed on the screen and prompts you to elevate your administrator token, click Continue.
3. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
   Note You can also apply the
   AssumeUDPEncapsulationContextOnSendRule
   DWORD value to a Microsoft Windows XP Service Pack 2 (SP2)-based VPN client computer. To do this, locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec
4. On the Edit menu, point to New, and then click DWORD (32-bit) Value.
5. Type AssumeUDPEncapsulationContextOnSendRule, and then press ENTER.
6. Right-click AssumeUDPEncapsulationContextOnSendRule, and then click Modify.
7. In the Value Data box, type one of the following values:
   • 0
     A value of 0 (zero) configures Windows so that it cannot establish security associations with servers that are located behind NAT devices. This is the default value.
   • 1
     A value of 1 configures Windows so that it can establish security associations with servers that are located behind NAT devices.
   • 2
     A value of 2 configures Windows so that it can establish security associations when both the server and the Windows Vista-based or Windows Server 2008-based VPN client computer are behind NAT devices.
8. Click OK, and then exit Registry Editor.
9. Restart the computer.

Since Windows default client is more than just IPSec, it uses L2TP inside of an IPSec SA, we need a daemon to handle that. Like Openswan, there have been a few bugs fixed since the version in the Ubuntu repository. Rather than compile it though, I just download a later version from a later version of Ubuntu.

After you have the .deb file downloaded, you can install it with a command such as: dpkg -i xl2tpd_1.2.8+dfsg-1_i386.deb.

Modify /etc/xl2tpd/xl2tpd.conf so it includes at least the following:

The IP range specified above should be set to IP addresses of your internal network which can be given to your VPN clients. Don't worry much that we are refusing CHAP and PAP methods, because we will require MS-CHAP v2 next.

Change noauth to auth.
Set name l2tpd. You can really set it to something other than l2tpd, but you have to match it in the next file.
Set mru 1280 and mtu 1280. I had some weird trouble with Vista's Remote Desktop not working over the VPN if these were left at their defaults of 1500. 1280 is chosen because that is the minimum required if the IPv6 protocol is to work as well (although that is not covered in this document).

#client	server		secret		IP addresses
username	l2tpd		"password"	192.168.1.1/24
l2tpd		username	"password"	192.168.1.1/24

Match the l2tpd with the name in the previous file. You can use this to test your CHAP authentication if you want... but you'd have to temporarily change the refuse chap = yes line above. I put it here just so you know how to test it if you want.

At this point, you need to add an extra rule to your firewall. Some of the sites I reference urge you to be security-minded here because if you open up this port to the whole world, then anyone may try to authenticate without IPSec. Basically, you want to allow connections to udp/1701, but they'd better be connected via IPSec. My filter rule looks like the following:
-A INPUT -m policy --dir in --pol ipsec -p udp --dport 1701 -j ACCEPT
This will allow L2TP traffic to connect to us ONLY if it shows up in an IPSec packet. The best information I've found about how IPSec (NETKEY) interacts with the iptables firewall was found in this post by Nigel Metheringham.

The last firewall modification we need to make for xl2tpd (which we could probably get more picky if you wanted). When an L2TP connection is made, it creates a ppp# interface on the VPN server, so we need to allow it to talk to the other interfaces.
-A FORWARD -i ppp+ -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

I wanted to have the authentication based off of the Windows AD rather than some /etc/ppp/chap-secrets file.

Make sure /etc/resolv.conf points to your DNS servers that have your AD information. Add an A and PTR record for the machine if you don't already have that.

Kerberos servers for your realm: windowsserver.example.local
Administrative servers for your realm: windowsserver.example.local

workgroup = EXAMPLE
interfaces = eth0 lo
bind interfaces only = true
security = ADS
realm = EXAMPLE.LOCAL
password server = windowsserver.example.local
idmap uid = 10000-20000
idmap gid = 10000-20000

default-realm = EXAMPLE.LOCAL
[REALMS]
	EXAMPLE.LOCAL = {
		kdc = windowsserver.example.local
		admin_server = windowsserver.example.local
	}

Note that the clocks of the Windows server and the VPN server must be within 5 minutes of each other for the next commands:

This joins the Ubuntu server to the Windows domain. On one machine, I had to make sure that the FQDN was listed in /etc/hosts before it let me join the domain.

This line tests to see if the VPN server was properly joined to the AD domain.

require-mschap-v2
# We can enable MPPE for additional encryption, but all this should be coming over IPSec anyway
#require-mppe-128
ms-dns 192.168.1.3
ms-dns 192.168.1.4
# The following lines let the authentication occur against the Windows domain, and require the user to be a member of the 'VPN Users' group on the 'EXAMPLE' domain.
plugin winbind.so
ntlm_auth-helper '/usr/bin/ntlm_auth --helper-protocol=ntlm-server-1 --require-membership-of="EXAMPLE\\VPN Users"'

This assumes that you already have Certificate Services set up on your Windows Server. I don't go into a lot of detail here.

6.1) Getting a certificate for your VPN server

6.2) Setting openswan to use certificates rather than PSKs

6.3) Getting the Windows client to work with certificates

7) Finished!