Building and Installing Openswan

Once you have configured your kernel, and run make dep if using a 2.4 kernel, you are ready to build your new kernel using the same commands as described earlier in this chapter. Depending on whether you build KLIPS as module or not, and whether you applied the NAT-T patch, you need to execute one or both of:

#make bzImage

#make modules modules_install

Verifying the Installation

You can see if Openswan is properly installed by issuing the following command:

# ipsec ––version

Linux Openswan 2.4.1 (klips)

See `ipsec --copyright' for copyright information.

If you did not install KLIPS, but plan to use NETKEY, the output will look slightly different:

Linux Openswan U2.4.1dr1/K2.6.11-1.27_FC3 (netkey)

See `ipsec --copyright' for copyright information.

If you just installed Openswan, you might not have an IPsec stack loaded yet, in which you will see the following:

Linux Openswan U2.4.1/K(no kernel code presently loaded)

See `ipsec --copyright' for copyright information.

You should further have a skeleton configuration file in /etc/ipsec.conf, and for most distributions there will also be a freshly generated /etc/ipsec.secrets. Some additional directories and configuration files can be found in /etc/ipsec.d. The programs, apart from the

ipsec command that will be installed in /usr/sbin or /usr/local/sbin, are all installed in

/usr/lib/ipsec and /usr/libexec/ipsec, or their equivalents in /usr/local. The startup script,

which is also called ipsec, is installed in the appropriate location within /etc, which depending upon your Linux distribution will be somewhere in /etc/init.d or /etc.rc.d.

Summary

In this chapter, we have looked at the features of each distribution and each IPsec stack, and we can now make the decision of which distribution to use. We can choose our IPsec stack, and we should be able to set up our build, compile, and install the Openswan userland, and if needed a new kernel with the features our system will need.

We are now ready to configure Openswan.

74

4

Configuring IPsec

This chapter will explain how to configure various kinds of IPsec tunnels. It will discuss:

•Automatic versus manual keying

•PSK versus RSA

•Basic IPsec tunnels

•Syntax and options in ipsec.conf

•Syntax and options in ipsec.secrets

•Basic ipsec commands

•Testing IPsec connections

The chapter addresses Openswan configuration for the most common types of VPN networks.

Manual versus Automatic

Often, the first kind of setup that is discussed is the so-called manual keying setup, since from a technological point of view, it is the easiest way to set up an IPsec tunnel. However, with Openswan, contrary to most other VPN software, automatic tunnels are actually easier to set up than manual tunnels. Manual keying—where one manually configures the encryption keys and the SPDs and SPIs used—is quite difficult to configure. With Openswan, it is much easier to configure automatic keying using the IKE protocol.

To understand the difference between manual and automatic keying, think of the gears of a car. No one can deny that using an automatic, where the car itself shifts the gears on your behalf, is easier to master than manually shifting the gears at the right time. You are busy enough as it is looking in the mirrors, steering the car to keep it on the road, checking the speedometer and keeping an eye on traffic. Of course, those who learned driving cars using manual gears will swear by it. They claim it will give them more control and that they can shift better than the machine. It's hard to let the control go.

Automatic keying is much easier and safer to set up than manual keying.

Configuring IPsec

PSK versus RSA

A similar discussion can be held regarding the type of authentication. Though using a Pre-Shared Key (PSK) might seem easier than using a full blown public/private key algorithm like RSA, it often causes more headaches than RSA. But regardless of which is the easier to set up, there is a much more important issue at hand here.

People believe a PSK is like a passphrase on their PGP key, but this is wrong. A PSK is not a password or passphrase. A pre-shared secret is used as the key! A short PSK means that the VPN tunnel becomes susceptible to a simple brute force attack.

Using a PSK like 'test' or even a line of random characters is just not good enough. It can be easily cracked on modern CPUs. Do not use PSK unless you have to, which usually only happens when you're stuck with some low-cost hardware appliance that has not implemented all parts of the IPsec specification.

Therefore, we will start our basic configuration with an example that uses both automatic keying and RSA authentication.

Pitfalls of Debugging IPsec

Before we start our first configuration, you need to understand the security provided with a properly (and even improperly!) configured IPsec tunnel. To protect against various types of attacks, such as spoofing attacks, an IPsec peer that has been configured to talk to a remote host using IPsec will not talk to that peer without encryption, except for those packets needed to set up the IPsec tunnel, such as IKE packets.

If you are configuring IPsec, you are normally working locally on one endpoint, and have one remote endpoint. A secure login, usually using SSH, is used to configure the remote endpoint from the local one. Once both ends are configured, the IPsec subsystem can be started on both sides.

So imagine what happens if you made a mistake on the remote endpoint. The IPsec tunnel will fail to establish. It will refuse all cleartext packets from the local endpoint except IKE. This means you can no longer log in to the remote endpoint using SSH to fix its configuration!

Always have an independent, non-IPsec, third machine from which you can log in to both IPsec endpoints. This machine should NOT appear in the IPsec configuration of either endpoint and should be able to use SSH to log in to both IPsec endpoints.

Even the most experienced IPsec guru has been bitten by this, current authors not excluded.

Here we are using the client at Sunset and use SSH to configure both, West and East to configure an IPsec tunnel between East and West. If we make an error, we can SSH from Sunset to South and from South to East to repair our configuration.

76