The steps described apply to Windows 7. I haven’t tried on any other versions of windows, but at least the registry keys probably changed from older versions.

First we have to import the Client certificate, which was signed by a CA trusted by the server (might even be our own CA, but in that case we must either export the CA certificate together with the client certificate itself or export only the CA certificate and import it into the client). Importing the certificate by double click won’t work. Windows will import your certificate into a “User store” and that won’t work.

Instead open management console (start, run, mmc) and choose File-> Add/Remove snap-in… from the list presented, choose Certificates, and then “Computer Account”, so we can manage certificates globally for this computer and IP Security Policy Management. Now, expand Certificates (Local Computer), right click on Personal and choose All Tasks –> Import. If the CA root certificate was imported together with the Client certificate, move it to Trusted Root Certification Authorities->Certificates.

Now right click on IP Security Policies on Local Computer, and choose Create IP Security Policy. Give it a name and continue to the end, leaving the “Edit Properties” checkbox checked. On the rules tab, select the default IP security rule and click edit. Go to the Authentication Methods tab, remove the kerberos method and click add. Choose “Use a certificate from this certification authority (CA) and browse to your root CA certificate. Press ok a couple of times to close all of the open windows. Right click the policy created and choose assign.

Now, both the server and the client are behind NAT, and that isn’t supported in windows since Windows XP SP2. Microsoft claim’s it’s not secure (LOL). Ok, we believe that, but we need our vpn to be accessible Fire up regedit and go to HLKM\System\CurrentControlSet\services\PolicyAgent and create a 32-bit dword key named AssumeUDPEncapsulationContextOnSendRule. Give it the value 2 (both client and server are behind nat). Google for other values. This same key, with the same value should also be created under HKLM\System\CurrentControlSet\services\IPSec. Reboot. Restarting the policy agent service,  as I’ve seen in some pages, won’t work. Now, hopefully everything works as expected and Windows 7 client behind NAT can connect to openswan, also behind NAT, using certificates.

I don’t think of my self as a security paranoid guy (if someone possesses the knowledge and wants to hack you, he/she will hack you anyway, unless you aren’t connected to the net) , however, whenever i see my apache logs and find out some guys where scanning it for phpmyadmin (DISCLAIMER: I DON’T FUCKING USE PHPMYADMIN !!!!! I USE mysql –u someuser –p somedatabasename !!!!) I freak out. Anyway, I decided to access my home network using a vpn. First I’ve tried OpenVPN, but I just found out it’s too slow (beside having to install some client on windows).

After a week tweaking ipsec.conf settings, you’ll laugh at the the end of this article, but (at least for future reference) I’ll describe the (hopefully less) painful steps to get this configuration working in gentoo.

Before start I definitely recommend you get your hands on this book. It’s very helpful and  you’ll get to understart the nitty-gritty details of openswan and the ipsec protocol (among others).

Configuring your kernel:

If you don’t have it done already compile your kernel with ipsec, ah and esp transformation, netfilter and ppp. Also, on cryptographic options, turn on Cryptographic APICompile it and install. Reboot and verify everything works as expected. These were the specific options I selected (among with other I had already selected) on my kernel’s configuration:

Networking support  —>
   Networking options  —>
      <*> PF_KEY socket      
      [*] TCP/IP networking
      <*>   IP: AH transformation
      <*>   IP: ESP transformation
      <*>   IP: IPComp transformation
      <*>   IP: IPsec transport mode
      <*>   IP: IPsec tunnel mode

   Device Drivers —>
      [*] Network device support   
         <*> PPP (point-to-point protocol) support
         <*>   PPP support for async serial ports
         <*>   PPP support for sync tty ports
         <*>   PPP Deflate compression 
         <*>   PPP BSD-Compress compression
         <*>   PPP over Ethernet (EXPERIMENTAL)
         <*>   PPP over L2TP (EXPERIMENTAL)
      Character devices  —>
         -*- Unix98 PTY support

   Cryptographic API —>
         <*> Null Algorithms
         -*- HMAC support
         -*- MD5 digest algorithm
         -*- SHA1 digest algorithm
         -*- AES chiper algorithms
         -*- DES and Triple DES EDE cipher algorithms
         -*- Deflate compression algorithm
         <*> Zlib compression algorithm
         <*> LZO compression algorithm   

After reboot, everything was working, so I emerged openswan, ppp, xl2tp and ipsec-tools packages. I had to unmask ipsec-tools.

echo "net-firewall/ipsec-tools ~x86" >> /etc/portage/package.keywords

Also, during emerge ipsec-tools, I got some error about swab.h not being found on my system (I’m running 2.6.31 kernel, and don’t know why, but portage only had 2.6.27 linux headers. I solved this problem creating a symlink from /usr/src/linux/arch/x86/include/asm/swab.h to /usr/include/asm/swab.h

# ln -s /usr/src/linux/arch/x86/include/asm/swab.h /usr/include/asm/swab.h
# emerge -av net-firewall/ipsec-tools
# rm /usr/include/asm/swab.h

After emerge completed successfully, I removed the symlink.

As stated on openswan book I turned on ip forward, and turned off send redirects and accept redirects. On gentoo you can edit /etc/sysctl.conf and set the default options there.

All my certificate stuff was generated as explained on the book and my configuration was almost verbatim the book’s examples (leftnexthop on ipsec.conf is the nat gateway’s ip address):

/etc/ipsec/ipsec.conf:

version 2.0

config setup
        nat_traversal=yes
        nhelpers=0
        plutodebug="control parsing"

conn L2TP-X509
        authby=rsasig
        pfs=no
        rekey=no
        keyingtries=3
        left=%defaultroute
        leftprotoport=17/1701
        leftrsasigkey=%cert
        leftcert=servercert.pem
        leftnexthop=192.168.112.1
        right=%any
        rightprotoport=17/%any
        rightrsasigkey=%cert
        auto=add

/etc/xl2tpd/xl2tpd.conf:

[global]
listen-addr = 192.168.112.128

[lns default]
ip range = 192.168.112.241-192.168.112.254
local ip = 192.168.112.240
require chap = yes
refuse pap = yes
require authentication = yes
name = test
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes

/etc/ppp/options.l2tpd:

ipcp-accept-local
ipcp-accept-remote
ms-dns 192.168.112.1
noccp
auth
crtscts
idle 1800
mtu 1200
mru 1200
nodefaultroute
debug
lock
proxyarp
connect-delay 5000

/etc/ppp/chap-secrets

vpnuser          *      vPnP@ssVVd1234                192.168.112.241/28

(it’s obvious this username and password doesn’t work on my real vpn setup, it’s just an example).

And that was the openswan setup. After that I started openswan, and added it to the default runlevel. On my next article (hopefully shorter than this one, I’ll describe the windows client setup).