Setting Up an IPSec L2TP VPN server on Debian for Windows clients

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

Unfortunately, Libreswan is new enough that it's not in the official Debian repositories yet. It was forked off of Openswan when many of the developers switched. No worries, we'll just get the latest version and work with that.

Download the latest version of Libreswan to your computer.
wget https://download.libreswan.org/libreswan-3.5.tar.gz

Expand the file and enter the directory
tar -zxvpf libreswan-3.5.tar.gz
cd libreswan-3.5

In order to actually compile the program, we just need to install a few packages from the default Debian repositories. Then we can compile Libreswan. We do these with the commands below.
apt-get install libnss3-dev libnspr4-dev pkg-config libpam-dev libcap-ng-dev libcap-ng-utils libselinux-dev libcurl4-nss-dev libgmp3-dev flex bison gcc make libunbound-dev
make programs

At this point, if there were no errors in the compiling, we can go ahead and install it.
make install

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

Libreswan is not set to auto start on Debian. Two quick changes will fix that. First, etc /etc/init.d/ipsec. Set the default start to 2 3 4 5. Next, run the command
update-rc.d ipsec defaults
to have Debian automatically start things when the computer is started.

Now copy the same configuration file docs/examples/l2tp-psk.conf to /etc/ipsec.d/. For example:
cp docs/examples/l2tp-psk.conf /etc/ipsec.d/l2tp-psk.conf
nano /etc/ipsec.d/l2tp-psk.conf

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: PSK "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 -anu.

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

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.

If things aren't working, review the steps above and also use the command ipsec verify to have IPsec do some checks of its own. You may have to mess with /etc/sysctl.conf. Note that the ipsec verify command checks for default and not all.

Since Windows default client is more than just IPSec, it uses L2TP inside of an IPSec SA, we need a daemon to handle that.

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. I reject by default, but then have a rule that 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.

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

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 Debian 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 and haven't updated it for a while.

6.1) Getting a certificate for your VPN server

6.2) Setting Libreswan to use certificates rather than PSKs

6.3) Getting the Windows client to work with certificates

7) Finished!