Deploying Affordable IPSec VPNs with FreeS/WAN

Finally, we have arrived at the point at which we can rush away from the theoretical aspects and do some hands-on work. The de facto standard for establishing IPSec communication using Linux (kernel 2.4) is a package called FreeS/WAN (http://www.freeswan.org), started by John Gilmore in 1996. The S/WAN part of the name stands for Secure Wide Area Network, a project run among several companies to ensure the interoperability of different IPSec implementations, and the Free part indicates that it is distributed under the GPL. The package supports most of the features you will need for day-to-day VPN operations. Several patches exist to advance FreeS/WAN and make it more customizable. Apparently, an alternative and highly patched solution is called Super FreeS/WAN (http://www.freeswan.ca). We focus on Super FreeS/WAN while guiding you through the installation and configuration process. Whenever we mention FreeS/WAN in the text, we actually address its patched version, Super FreeS/WAN.

It is best to view FreeS/WAN as consisting of two parts: KLIPS and Pluto. KLIPS (kernel IP security) is integrated into the Linux kernel and can be compiled as a part of the kernel or as a loadable module. It implements AH, ESP, and packet handling within the kernel. Pluto is responsible for implementing IKE and is used for connection negotiation with other systems.

FreeS/WAN Compilation

We assume that apart from RPMing or apt-geting, you feel pretty confident at compiling programs from source. In fact, it is possible to get FreeS/WAN as a package, but most likely it will not include support for some of the new "kewl" features you might require.

Before you start installing FreeS/WAN, be sure to familiarize yourself with the process of kernel compilation from source. The sources can be obtained from http://www.kernel.org. The stable version at the time of writing is 2.4.24. Make sure the kernel you have compiled has all the necessary features included and that your machine boots and works flawlessly with it.

The next step is to obtain the source for FreeS/WAN. The current stable version of FreeS/WAN is 2.00, available from http://www.freeswan.org. The current patched version of Super FreeS/WAN is 1.99.7, available from http://www.freeswan.ca. The version you choose to install is up to you, but we opt for Super FreeS/WAN.

Download the latest version of FreeS/WAN into /usr/local/src/ and untar the archive:

arhontus:~#cd /usr/local/src

arhontus:~#tar xvzf super-freeswan-1.99.7.tar.gz

arhontus:~#cd super-freeswan-1.99.7

Now you are ready to install. The four SuperFreeS/WAN commands you can use to compile are shown in Table 14-1.

Table 14.1. Super FreeS/WAN Compile Commands

SuperFreeS/WAN	Kernel
make menugo	make menuconfig
make xgo	make xconfig
make ogo	make config
make oldgo	make oldconfig

If you are using an X Windows system, type #make xgo; this presents you with a nice GUI from which to choose the kernel options. If you don't have or don't want to use X Windows, type #make menugo or #make ogo (if you feel like spending hours going through every kernel option). The standard kernel configuration screen appears (see Figures 14-8 and 14-9). Now go to the networking options.

Figure 14.8. Menuconfig IPSec configuration section in the kernel.

[View full size image]

Figure 14.9. Xconfig IPSec configuration section in the kernel.

[View full size image]

Scroll to the bottom and you will see new IPSec-related options. Let's see what each option is responsible for.

• IP Security Protocol (FreeS/WAN IPSEC). Turn this option on if you want IPSec to work; it is a KLIPS part in your kernel.

• IPSEC: IP-in-IP encapsulation (tunnel mode). We advise you to turn this option on, unless you do not want to use the tunnel mode.

• IPSEC: Authentication Header. If you want to use AH, turn this option on. If you want to use ESP on its own, without additional AH authentication, you can deselect it.

• HMAC-MD5 authentication algorithm. Select this option if you want to use the MD5 hashing function.

• HMAC-SHA1 authentication algorithm. The SHA1 hashing function is cryptographically stronger than MD5. We recommend turning both options on, especially if you are concerned with interoperability with other IPSec implementations.

• IPSEC: Encapsulating Security Payload. By selecting this option you will be able to use IPSec in ESP mode. You should select this option.

• 3DES encryption algorithm. A standard CPU-intensive cryptographic algorithm. It is a good idea to select this option mainly for interoperability issues.

• IPSEC Modular Extensions. Say yes here if you want to use additional features provided by Super FreeS/WAN.

• HMAC_MD5 auth algorithm (modular alg). Say no here.

• HMAC_SHA1 auth algorithm (modular alg). Say no here as well.

• HMAC_SHA2 auth algorithm. SHA2 provides a cryptographically stronger hash function that uses 256- or 512-bit as opposed to 128-bit used by SHA1. We do advise that you use SHA2.

• 3DES encryption algorithm (modular alg). Say no here.

• AES encryption algorithm. AES provides much stronger security than its predecessor, DES. We recommend you use this algorithm, because in our experience it provides one of the best performance/cryptographic strength ratios. On our machines, 256-bit AES encrypts and decrypts data two times faster than 3DES (in software).

• BLOWFISH encryption algorithm. This pretty old, free, and reliable 64-bit block algorithm is the predecessor to the TWOFISH cryptographic algorithm.

• TWOFISH encryption algorithm. This is one of the AES finalists developed by Bruce Schneier.

• SERPENT encryption algorithm. This was another AES finalist. In our opinion, this algorithm is the most secure AES candidate from a mathematical viewpoint. If you do not trust AES to protect your data, SERPENT is the definite choice for encryption.

• CAST encryption algorithm. The algorithm is patented for commercial use and was also one of the first-round AES finalists.

• NULL encryption algorithm. No encryption. It is unwise to use ESP with no encryption. Unless you have a strange sense of humor, consider using the AH mode.

• CRYPTOAPI ciphers support. This provides additional support for using ciphers included with the cryptoapi kernel patch.

• 1DES **INSECURE** encryption algorithm. This is included for greater interoperability with legacy IPSec implementations.

• IPSEC: IP Compression. You might want to experiment with compression to combat the negative impact of the increased overhead. Note that it is rather CPU intensive.

• IPSEC Debugging Option. When selected, KLIPS outputs debugging information into syslog. It is a good idea to turn it on, especially when setting up your first VPN.

• IPSEC NAT-Traversal. If you plan to run IPSec tunnel when one of the peers is behind the NAT, turn this option on.

In terms of selecting a cryptographic algorithm properly and efficiently, it is best to refer to Chapter 11 for a discussion of each algorithm and its implementations in more details. Understanding applied cryptography is the key to successful VPN deployment.

Once the options are selected, go ahead and save the configuration. FreeS/WAN will do the rest, compiling all the utilities and building the kernel. When the compilation process is complete, type cd /usr/src/linux; inform modules_install to install the modules.

The next thing you need to do is to copy the newly compiled kernel image into your boot directory and make lilo (or another boot loader) about it. Do the following:

arhontus:~#cp /usr/src/linux/arch/i386/boot/bzImage \

     /boot/vmlinuz-ipsec-'kernel version'

Now open lilo.conf in your favorite editor (vi is our choice):

arhontus:~#vi /etc/lilo.conf

Add the following lines:

image = /boot/vmlinuz-ipsec-'kernel version'

root = /dev/'boot_device'

label = Linux-sfswan

read-only

Save the file, quit, and rerun lilo by typing

arhontus:~#lilo

If no errors occurred, reboot the machine, and when presented with the boot loader screen, select new kernel. Cross your fingers, knock on wood, spit three times over your left shoulder, and say a little prayer to Mr. Torvalds, and hopefully you will successfully boot the first time.

FreeS/WAN Configuration

We have discussed different types of VPN topologies, but due to space constraints we discuss only two scenarios in more detail: network-to-network and host-to-network using a Road Warrior setup. These types are suitable for protecting wireless point-to-point and point-to-multipoint links. Besides, once you know how to configure these types of VPN topologies, it should not be that difficult for you to configure the rest, if necessary.

Key Generation

The first action you need to perform is generating keys to be used for the IKE initialization. All your keys are stored in /etc/ipsec.secrets. Make sure the permissions are set to 600, and if not, do this:

arhontus:~#chmod 600 /etc/ipsec.secrets

Symmetric Key Generation

The Super FreeS/WAN suite has a built-in symmetric key generation command. To generate a 64-bit key, you have enter the following command:

arhontus:~#ipsec ranbits --continouous 64 > /tmp/symm.key

We have used 64 bits in this example to conserve some space; please use greater sizes when generating keys for a real-life VPN connection.

To the right of it add a large ! symbol in the empty space.

The pseudorandom number is generated and saved in /tmp/symm.key. Now add the contents of symm.key to /etc/ipsec.secrets, and use the PSK identifier, so the resulting file will look similar to this:

: PSK "0xe687f51034f33f07"

Make sure both of the hosts participating in the communication have matching entries in /etc/ipsec.secrets.

RSA Key Generation

The IPSec suite also allows for RSA public and private key pair generation. In the following example we demonstrate how to generate 64-bit keys. When you generate keys for a real-life situation, please use much larger integers for keys.

To generate an RSA key pair, enter the following command:

# ipsec rsasigkey –verbose 64 > /tmp/rsa.key

Now, for IPSec to take advantage of the generated keys, you have to perform some modifications to the generated data. The first step you need to perform is to add ": RSA{" to the beginning and "}" to the end of the file, so that it results in the following format:

: RSA   {

        output of the rsakeygen

        }

Make sure that each line in the file is preceded by a tabulation, otherwise FreeS/WAN cannot understand it. Once you have completed editing the file, copy the contents to /etc/ipsec.secrets. It will look similar to this:

: RSA   {

        # RSA 64 bits   dyno   Sat May 31 17:08:13 2003

        # for signatures only, UNSAFE FOR ENCRYPTION

        #pubkey=0sAQNrYsldIB3h4w==

        #IN KEY 0x4200 4 1 AQNrYsldIB3h4w==

        # (0x4200 = auth-only host-level, 4 = IPSec, 1 = RSA)

        Modulus: 0x6b62c95d201de1e3

        PublicExponent: 0x03

        # everything after this point is secret

        PrivateExponent: 0x11e5cc39f8be86f3

        Prime1: 0xa889727b

        Prime2: 0xa31d45b9

        Exponent1: 0x705ba1a7

        Exponent2: 0x6cbe2e7b

        Coefficient: 0x25a4fd62

        }

It is possible to have multiple keys in ipsec.secrets, but you have to index each one of them independently in the following manner:

@vpn1.arhont.com: RSA        {

        rsasigkey output

        }

@vpn2.arhont.com: RSA        {

        rsasigkey output

        }

An additional operation you have to perform is extracting your public key and making it available for other involved parties. The part in the #pubkey= is your public key that can be safely transmitted in the open to others. Later you will have to add it to the ipsec.conf of the involved parties. Remember that your public key is the character sequence and it does not include "#pubkey=".

X.509 Certificate Generation

X.509 certificate creation requires that you have OpenSSL installed and working. First you need to create your own CA, unless you want to send out certificates to be signed by your trusted CA, but that will cost money.

The location of the OpenSSL executables will depend on the distribution you are using. Slackware stores OpenSSL files in /etc/ssl/, whereas Debian stores them in /usr/lib/ssl/. In this example we use the Slackware path:

arhontus:~#cd /etc/ssl/misc

arhontus:#./CA.sh -newca

arhontus:#mv ./demoCA/cacert.pem ./demoCA/newca.pem

arhontus:#openssl x509 -in ./demoCA/newca.pem -days 1024 \

  -out ./demoCA/cacert.pem -signkey ./demoCA/private/cakey.pem

arhontus:#rm ./demoCA/newca.pem

Just press Enter when asked for a file name, then enter information after the prompts. The password you are asked for will be your CA password; make sure you remember it. Then we extend the life of CA to 1,024 days (use a shorter life for security-critical set-ups). Once the process completes, you have the private (cakey.pem) and public (cacert.pem) parts of your CA. Now copy the public part of the CA to the place where SuperFreeS/WAN can find it:

arhontus:~#cp /etc/ssl/misc/demoCA/cacert.pem /etc/ipsec.d/cacerts/

As the CA is generated, you have to create two certificates: one for each end of the VPN connection. Both certificates will have a public and private part.

The process of creating certificates is described next.

arhontus:~#cd /etc/ssl/misc

arhontus:#./CA.sh -newreq

Enter the information required after the prompts, and make sure you remember the password, because it is your FreeS/WAN certificate password to live with. When prompted for a challenge password and an optional company name, press Enter (do not enter anything).

Now you have to sign the certificate with your CA. Enter this:

arhontus:#./CA.sh -sign

When prompted for the PEM password, just enter the password for your CA. Your new certificate is created and signed. The public part is located in newcert.pem and the private part is located in newreq.pem. Now let's move these files to the location where FreeS/WAN can recognize them:

arhontus:#mv ./newreq.pem /etc/ipsec.d/private/freeswan-priv.pem

arhontus:#mv ./newcert.pem /etc/ipsec.d/freeswan-cert.pem

Repeat the procedure for the second pair of certificates. Remember to name the certificates differently this time.

Make sure you let FreeS/WAN know about the certificate. Add the following entry to /etc/ipsec/secrets:

: RSA freeswan-priv.pem "certificate password"

Because the password is stored in cleartext and IPSec configuration files are considered to be private information, make sure the permissions for these files are set to disallow group/user read access. Enter the following:

arhontus:~#chmod 600 /etc/ipsec.secrets

arhontus:~#chmod 644 /etc/ipsec.conf

Next we need to generate an empty certificate revocation list (CRL). To do so, enter this:

arhontus:~#openssl ca -gencrl -out /etc/ipsec.d/crls/crl.pem

Your certificates are generated and ready to use.

Ipsec.conf Organization

Before we start configuring FreeS/WAN, it is useful to understand the general organization of the main configuration file. The typical ipsec.conf looks similar to this:

config setup

        interfaces="ipsec0=eth0"

        klipsdebug=none

        plutodebug=none

        plutoload=%search

        plutostart=%search

        uniqueids=yes



conn %default

        keyingtries=0

        auth=esp

        authby=rsasig

        esp=aes128-sha2_256

        pfsgroup=modp1536

        ike=aes256-md5-modp4096

        pfs=yes

        compress=no



conn gate1-gate2

        left=192.168.50.100

        leftid=@vpn1.core.arhont.com

        leftnexthop=192.168.50.251

        leftsubnet=192.168.10.0/24

        leftrsasigkey=0sAQNgvfFH2bGl...

        right=192.168.100.150

        rightid=@vpn2.core.arhont.com

        rightnexthop=192.168.100.251

        rightsubnet=192.168.15.0/24

        rightrsasigkey=0sAQPFb2ffuPhn...

        auto=start

The ipsec.conf is split into two parts, a config part that specifies general configuration options and the conn section defining connection details. Table 14-2 shows some of the relevant parameters and their descriptions.

Table 14.2. FreeS/WAN Parameters

Parameter	Description
config setup	General configuration section.
interfaces	Here you specify to which physical interface the IPSec interface should bind. You can have more than one IPSec interface and assign them to different physical interfaces.
klipsdebug	Specifies the debug level for KLIPS.
plutodebug	Specifies the debug level for Pluto.
plutoload	You can set which connections should be loaded into Pluto's database on start. If you set %search here, all the connections with auto=add, route, or start are loaded.
plutostart	You can set which connections are to be automatically started on Pluto start. If $search is set here, all the connections with auto=start or route will be started automatically.
uniqueids	Configures Pluto to use unique IDs for each automatically keyed connection.
conn %default	Default connection configuration section.
keyingtries	Specifies the number of attempts that should be made to negotiate a connection or replace an old one.
auth	Defines whether authentication should be performed as a part of ESP encryption or separately by AH protocol.
authby	Specifies how the authentication should be performed between nodes.
esp	Specifies the ESP encryption/authentication algorithm for ISAKMP Phase 2.
pfsgroup	Sets the PFS group to be used, if PFS is on.
ike	Specifies the IKE encryption/authentication algorithm to be used in ISAKMP Phase 1.
pfs	Set to use PFS. It is always advisable to use it.
compress	Specifies whether you want to use the IPComp for compression.
conn "name"	Configuration settings relevant for a specific connection.
left	Specifies the IP address of the participant. It is not important which participant is left and right, as the settings are the same for both participants.
right
leftsubnet	Specifies the private subnet range behind the VPN gateway that should be allowed communication through the tunnel.
rightsubnet
leftnexthop	Specifies the next hop gateway address for a participant. This is required for proper routing of the subnets behind.
rightnexthop
leftid	Sets the identification for the authentication of the participant. Can be either an IP address or a fully qualified domain name preceded with @.
rightid
leftrsasigkey	Defines the participant's RSA public key used for authentication.
rightrsasigkey
auto	Determines how the connection should be handled by Pluto.

There are many more configuration settings for fine-tuning of Super FreeS/WAN. We certainly cannot describe all of them in this chapter. For more information you can consult the project documentation.

Network-to-Network VPN Topology Setting

First you need to tweak some kernel parameters. To enable forwarding between interfaces, enter this:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Next, you have to generate two sets of keys. The process was explained in the previous section, so we assume you have a set of keys generated. In the following example we show how to use FreeS/WAN to set up the network-to-network tunnel. The sample ipsec.conf is presented here:

config setup

        interfaces="ipsec0=eth0"

        klipsdebug=none

        plutodebug=none

        plutoload=%search

        plutostart=%search

        uniqueids=yes



conn %default

        keyingtries=0

        auth=esp

        authby=rsasig

        esp=aes128-sha2_256

        pfsgroup=modp1536

        ike=aes256-md5-modp4096

        pfs=yes

        compress=no



conn gate1-gate2

        left=192.168.50.100

        leftid=@vpn1.core.arhont.com

        leftnexthop=192.168.50.251

        leftsubnet=192.168.10.0/24

        leftrsasigkey=0sAQNgvfFH2bGl...

        right=192.168.100.150

        rightid=@vpn2.core.arhont.com

        rightnexthop=192.168.100.251

        rightsubnet=192.168.15.0/24

        rightrsasigkey=0sAQPFb2ffuPhn...

        auto=start

Note that we set up a tunnel using ESP and encrypt it with 128-bit AES we defined by the esp=aes128-sha2_256 parameter. If you want a different encryption algorithm, you should check what algorithms are available to Pluto by entering this:

arhontus:~#ipsec auto --status | grep alg.*ESP

Host-to-Network VPN Topology Setting

In this type of configuration, we set up the vpn1.core.arhont.com to be the gateway with the wireless host accessing the internal network resources through the VPN. This time we are going to use X.509 certificates for authentication. On the network gateway host, make sure that packet forwarding is enabled by entering the following:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Also check that both public parts of the certificates are located in /etc/ipsec.d/, the private part of the peer certificate is located in /etc/ipsec.d/private/, and the corresponding entry is present in /etc/ipsec.secrets. Thus, the ipsec.conf should look similar to this:

config setup

        interfaces="ipsec0=eth0"

        klipsdebug=none

        plutodebug=none

        plutoload=%search

        plutostart=%search

        uniqueids=yes



conn %default

        keyingtries=0

        auth=esp

        authby=rsasig

        esp=aes128-sha2_256

        pfsgroup=modp1536

        ike=aes256-md5-modp4096

        pfs=yes

        compress=no



conn pingo-dyno

        left=192.168.50.101

        leftsubnet=0.0.0.0/0

        leftnexthop=%direct

        leftcert=pingo-cert.pem

        right=192.168.50.6

        rightnexthop=%direct

        rightcert=dyno-cert.pem

        auto=start

In the current configuration, the authentication is performed using an X.509 certificate. The leftsubnet=0.0.0.0/0 string specifies that the left peer is the default gateway for all traffic. The situation is common when you have wireless hosts on the network that do not only need to communicate with the rest of the LAN, but also have an ability to communicate with the Internet directly.

If you have a large number of certificates or often change the certificates' names, it is possible to avoid defining the exact names of these certificates. Instead you can enter the information about the certificate and FreeS/WAN will search through all the available ones until it finds a proper match. A sample setup is shown here:

conn pingo-dyno

        left=192.168.50.101

        leftsubnet=0.0.0.0/0

        leftnexthop=%direct

        leftcert=pingo-cert.pem

        right=192.168.50.6

        rightid="C=UK, ST=Some-State, L=Bristol, O=Arhont Ltd, CN=pingo.core.arhont.com,

 E=info@arhont.com"

        rightrsasigkey=%cert

        rightnexthop=%direct

        auto=start

Windows 2000 Client Setup

Unfortunately, not all of us have the pleasure of using a Linux operating system, so for the less fortunate we guide you through setting up your Windows box for secure communication to a FreeS/WAN-based VPN concentrator. Prepare for a "clicking session."

Windows does not understand the *.pem format of OpenSSL, so first you need to convert the certificate using this:

arhontus:~#openssl pkcs12 -export -in /etc/ipsec.d/client.pem \

-inkey /etc/ipsec.d/private/client.pem -certfile \

/etc/ssl/misc/demoCA/cacert.pem -out /tmp/client.p12

arhontus:~#openssl x509 -in /etc/ipsec.d/freeswan-cert.pem \

-out /tmp/freeswan-cert.pem

When prompted for a password, enter a password for that specific certificate. Next you will be prompted for an export password. Enter a new password and remember it, as you will be asked for it later when you import the certificate into Windows 2000. Once the files are generated, transfer them in a secure manner to your Windows machine, and make sure to erase them from /tmp.

The default Windows installation does not support strong encryption, and you are limited to using DES only. If you have not done so already, fetch the High Encryption Pack for Windows 2000 from the Microsoft Web site (http://www.microsoft.com/WINDOWS2000/downloads/recommended/encryption/default.asp).

Once the pack is installed, you have to import the certificates into Windows. To do so, go to the Start menu, click Run, and enter mmc. A window will pop up. In the Console menu, click Add/Remove Snap-in (see Figure 14-10).

Figure 14.10. Console/Add/Remove snap-in.

[View full size image]

Once the new window appears, click Add and select Certificates in the window that appears, and click Add again (see Figure 14-11).

Figure 14.11. Certificates snap-in.

[View full size image]

Yet another window will appear. Select Computer Account and click Next (see Figure 14-12).

Figure 14.12. Console computer selection.

[View full size image]

Make sure that Local computer is selected and click Next.

Now close the Add Standalone Snap-In window.

Finally we are ready to import our CA and client certificate. Double-click Certificates and right-click Personal, select All Tasks, and select Import (see Figure 14-13).

Figure 14.13. Certificate import sequence.

[View full size image]

An Import Wizard appears (see Figure 14-14). Click Next and then Browse and select the client.p12 file. Click Next again and enter the export password for the CA.

Figure 14.14. Certificate Import Wizard.

[View full size image]

Click Next, leave all the options in the default state (see Figure 14-15), and click Next and then Finish.

Figure 14.15. Store selection for certificate.

[View full size image]

A message will appear indicating that the certificate was imported successfully.

Now both the CA and client certificate are imported and located in the Personal list, but the CA belongs in the Trusted Root Certificate Authorities, so it has to be moved. Highlight the CA, right-click, and select Cut (see Figure 14-16).

Figure 14.16. Cut the imported CA.

[View full size image]

Now highlight Trusted Root Certificate Authorities and select Paste (see Figure 14-17). Certificates are imported successfully now.

Figure 14.17. Paste the CA in the right place.

[View full size image]

You can close all the windows and move to configuring the IPSec client.

Windows 2000 IPSec Client Configuration

We will not be creating a real VPN connection; rather we will be modifying the properties of the TCP/IP connection by applying a security policy so that the traffic will be always protected. This is the easiest solution when you are accessing your company's LAN over wireless. Besides, you do not incur additional software costs.

Like most of the other configuration settings in Windows, the IPSec policies are defined in Control Panel. To create a policy, go to Control Panel, open Administrative Tools, and double-click Local Security Settings.

We are going to create our own policy. To do so, click Action and select Create IP Security Policy (see Figure 14-18).

Figure 14.18. Create IP Security Policy.

[View full size image]

A wizard appears. Click Next, and in the following window name your policy whatever you like (you can also add a description if you wish). Now click Next and on the next screen clear the Activate the default response rule check box and click Next, and then click Finish.

Now we need to create two IP security rules, one for the outgoing traffic and one for incoming traffic (see Figure 14-19).

Make sure that Use Add Wizard is not selected, and add a rule by clicking Add. A New Rule Properties window appears. Select IP Filter List and click Add (see Figure 14-20).

In the new window, click Add, name the IP filter something sensible to reflect the nature of the tunnel, like win2k_to_linux, and click Add to enter the filter properties (see Figure 14-21).

In the Source Address field, select My IP Address. In the Destination Address select Specific IP address and enter the IP address of the Linux VPN gateway (see Figure 14-22). Make sure that the Mirrored check box is cleared and click OK.

Now you need to create another IP filter list. This time name it linux_to_win2k, click Add, and in the Filter Properties, enter the opposite information to what you entered before. Therefore, your Destination IP becomes Source IP and vice versa. Make sure the Mirrored check box is cleared and click OK and then Close.

Now check linux_to_win2k in the IP Filter List, move to the next tab, Filter Action, and select Require Security and click Edit (see Figure 14-23).

Now move the Security Method so the one using 3DES for ESP confidentiality and MD5 for ESP Integrity is first in line (see Figure 14-24).

Now close the window by clicking OK, then move to the Connection Type tab and select Local area network (LAN). Slide to the tab on the left (Tunnel Setting) and enter your IP address in the box provided (see Figure 14-25).

Now select Authentication Methods, highlight the current setting (Kerberos), and click Edit (see Figure 14-26).

Change to Use a certificate from this certificate authority (CA) and select your certificate that you previously imported into Windows, and click OK three times until you end up in the Tunnel Properties window.

Alternatively, you can set up your system to use the PSK shared secret. To do so, simply select the Shared Key button and enter the shared secret in the box below.

Remember that you have to define rules for both incoming and outgoing traffic, so you have to add another IP Security rule. The process is similar to what we have been doing, except for in the Filter Properties, you need to swap the source with destination, and in the Tunnel Settings, you need to enter the IP of the other VPN peer.

Finally, in the properties of the tunnel, switch to the General tab and click Advanced (see Figure 14-27).

Now enable Master Key Perfect Forward Secrecy by selecting the check box, then click Methods and set the Security Method for IKE to use 3DES for encryption and MD5 for integrity checking (see Figure 14-28).

Now you have to go back to the Local Security Settings and right-click the tunnel we have just created. Select All Tasks and click Assign (see Figure 14-29).

Figure 14.29. Assign your new tunnel.

[View full size image]

Then in Administrative Tools, open Services, find IPSEC Policy Agent, and restart it (see Figure 14-30).

Figure 14.30. Restart the IPSEC service.

[View full size image]

Also check that IPSec is set to start up automatically at boot time.

To enable IPSec on a specific interface, go to Control Panel and open Network and Dial-up Connections. Right-click the Local Area Connection corresponding to your wireless link and select Properties. In the new window, highlight Internet Protocol (TCP/IP) and click Properties. In the Properties window, click Advanced. Now move to the Options tab, highlight IP Security, and select Properties (see Figure 14-31).

Now select the policy you created, click OK, and close all the preceding windows.

If you have followed the instructions precisely, your Windows system is configured to use IPSec.

The FreeS/WAN part of the configuration for the connection is shown next. Note that we specify that we want to use the shared secret by setting the authby parameter to secret:

conn pingo-winda

        left=192.168.77.6

        leftnexthop=%direct

        right=192.168.77.66

        rightnexthop=%direct

        esp=3des

        ike=3des-sha

        authby=secret

        auto=start

The Windows configuration example we provide uses 3DES symmetric block cipher because it is the best available choice in the default Windows IPSec implementation. If you want to go beyond the use of 3DES and employ more robust and secure ciphers, prepare to sacrifice some cash for higher-grade encryption commercial third-party software.