Configuring a Linux FreeSWAN Server

Configuring a Linux FreeS /WAN Server

FreeS/WAN is a more Linux-centric VPN solution than is PPTP, but considered broadly, both serve a similar function: linking two or more computers or networks in a secure way over an insecure network, such as the Internet. As with PPTP, the first step in running a FreeS/WAN VPN is obtaining and installing the software. You can then begin configuring the system and establishing a link between FreeS/WAN systems.

FreeS/WAN is actually a very sophisticated package, with more options than can be covered in this chapter. For more information, consult the FreeS/WAN documentation, and particularly the configuration manual, http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html.

Obtaining and Installing FreeS/WAN

In early 2002, few Linux distributions ship with FreeS/WAN, but there are exceptions. Most notably, SuSE comes with the package, and a Mandrake package is also readily available. You should check your distribution to be sure it doesn't come with FreeS/WAN before obtaining it from the main FreeS/WAN Web site, http://www.freeswan.org. This site (or more precisely, the FTP site to which it links, ftp://ftp.xs4all.nl/pub/crypto/freeswan/) holds the software in source code form. FreeS/WAN requires explicit kernel support that's not standard in the Linux kernel, so to use it, you must recompile your kernel, as described shortly. If you install a FreeS/WAN package that came with your distribution, chances are these kernel changes are part of the kernel that came with the distribution, so your configuration task is simpler. The rest of this section assumes you're installing FreeS/WAN using its source code.

If you compile FreeS/WAN from source code, you must have several components installed on your system:

• Standard development tools You must have typical development tools, such as GCC, make , and normal libraries and library headers. Such tools are installed on most Linux systems by default.

• Kernel source code The FreeS/WAN compilation tools automatically change your Linux kernel source tree, in /usr/src/linux . This tree should therefore contain your current kernel source code. If you're using your distribution's standard kernel, you should be able to install a matching source code package. You'll later have to recompile the kernel and reboot. If you plan to change your kernel's configuration, you should do this (with make menuconfig , make xconfig , or a similar command) prior to compiling FreeS/WAN. You may want to make the kernel and test it before proceeding further.

• GMP library FreeS/WAN relies upon the GNU Multi-Precision (GMP) library (http://www.swox.com/gmp/). This package is available on most distributions, so try to find it and install it from your installation CD-ROM or your distribution's main FTP or Web site.

• Ncurses library Some configuration options use the ncurses library. This isn't strictly required, but it's very helpful. It's also very common, so it may already be installed.

To make and install the FreeS/WAN package, follow these steps:

1. Make sure you've got all the components described earlier, such as your kernel source code and the GMP library.

2. Uncompress the FreeS/WAN package in some convenient location, such as /usr/src . ( Do not copy or move the freeswan- version directory after uncompressing it; the directory contains symbolic links that are sensitive to changes.)

3. Change into the FreeS/WAN source code directory and type a command to configure the package, patch the Linux kernel, and make the FreeS/WAN package. You can use make oldgo to use your existing Linux kernel configuration and default FreeS/WAN settings, make ogo to use the kernel's make config configure utility, make menugo to use the kernel's make menuconfig , or make xgo to use the kernel's make xconfig . The last three of these options run you through the specified kernel configuration routine so that you can change kernel options. In any event, the last line of output should report that the system was calling an errcheck script. If you don't see this line, it means that something went wrong. You can check the out.kpatch and out.kbuild files for information on the patching and building process for clues to what went wrong.

4. Type make kinstall to rebuild your kernel. This process builds the kernel and its modules, and uses the kernel's make modules_install process to install the new kernel modules. If there are any errors, they should appear in the out.kinstall file.

5. Reconfigure LILO, GRUB, or whatever method you're using to boot your Linux kernel to handle the new kernel. You may need to copy your new kernel file from /usr/src/linux/arch/ architecture-code / boot , edit /etc/lilo.conf or some other configuration file, and type lilo or some other boot loader command.

6. Reboot the computer. Be sure to specify the correct new FreeS/WAN-enabled kernel if you have a choice.

At this point, your system should be working with a kernel that's capable of supporting FreeS/WAN. As part of the process, FreeS/WAN should have created a file called /etc/ipsec.secrets , which contains encryption keys. You'll need to deal with this file later, so for now you should check that it exists and contains some keys (which resemble hexadecimal gibberish).

In order to be useful, you must configure FreeS/WAN on at least two computers, presumably on different networks. The installation process is the same on both. In many cases, both systems will be configured as routers, although you can install FreeS/WAN on a single system that's to connect to a remote network.

Editing Configuration Files

FreeS/WAN uses two configuration files: /etc/ipsec.secrets and /etc/ipsec.conf . Each is important and plays a different role. The first contains encryption keys, which the servers use to identify themselves to each other. The second controls general-purpose configuration options.

Setting Up Keys

As noted earlier, the FreeS/WAN build process should have created an /etc/ipsec.secrets file that contains encryption keys. If this file isn't present, or if it doesn't contain a key you want to use, you can generate a new key with the following command:

 #  ipsec rsasigkey 128 > /root/rsa.key  

This command creates a 128-bit key and places it in the /root/rsa.key file. You can generate a key of some other length by specifying the desired length instead of 128 in the preceding example. The output of this command isn't quite what's needed, though. Specifically, you must add the following line to the start of the file:

 : RSA { 

Be sure to include the spaces around RSA . You must also add a line containing at least one space followed by a single right curly brace ( } ) to the end of the file. You can then copy the result into the existing /etc/ipsec.secrets file, replacing the current : RSA { block in that file. You should perform this step on both the FreeS/WAN VPN routers.

NOTE

The output of the ipsec rsasigkey command includes a comment to the effect that the key is only useful for authentication, not for encryption. This is fine; FreeS/WAN uses the key in precisely this way, and uses other algorithms for encryption.

The output of the ipsec rsasigkey command includes a commented-out line that begins #pubkey= . This sets the public key that you must give to other systems with which this system must communicate. You should make note of it now, because you'll need to enter it into the /etc/ ipsec.conf file of your other systems.

Editing the IPSec Settings

Most FreeS/WAN installations create a default /etc/ipsec.conf file. This file isn't terribly useful as is, but it can be used as a good template for configuring your system. The file has three basic types of setup sections: config setup , conn %default and conn remotename .

Adjusting Local Options

The config setup section specifies local settings. The default example section resembles the following:

 config setup   # THIS SETTING MUST BE CORRECT or almost nothing will work;   # %defaultroute is okay for most simple cases.   interfaces=%defaultroute   # Debug-logging controls:  "none" for (almost) none, "all" for \ lots.   klipsdebug=none   plutodebug=none   # Use auto= parameters in conn descriptions to control startup \ actions.   plutoload=%search   plutostart=%search   # Close down old connection when new one using same ID shows up.   uniqueids=yes 

The most important setting in this section is the interfaces line, which tells FreeS/WAN which interfaces to use for VPN connections (that is, where it can find VPN partners ). The default value of %defaultroute tells FreeS/WAN to use your default route, which normally connects to all non local IP addresses. You might want to specify particular interfaces, though. For instance, the following option tells the system to use eth0 and ppp1 :

 interfaces="ipsec0=eth0 ipsec1=ppp1" 

The klipsdebug and plutodebug options set the logging options for the Kernel IP Security (KLIPS) kernel features and for the Pluto daemon, which is a part of the FreeS/WAN package that handles key exchange. You can set these to all if you're having problems.

Pluto can load connections into memory or start them automatically when FreeS/WAN starts up. The plutoload and plutostart options tell the system with which connections it should do this. The default value works well in most cases, but if you want to specify just some connections, you can name them instead. The drawback to listing individual FreeS/WAN servers is that if one crashes, it may not come back up into the VPN automatically after restarting.

Adjusting Default Remote Options

Individual connections are defined through sections that begin with the keyword conn . FreeS/WAN supports a %default connection name for setting default connection options. Options you're likely to see in this section include the following:

• keyingtries In the event of a connection failure, FreeS/WAN normally retries the connection. A default value of for this option makes FreeS/WAN infinitely persistent, but if you want to limit the number of times it retries its connections, set this value lower. You might want to do this when you're first testing your setup.

• authby The usual authentication method uses authby=rsasig , which causes the system to use RSA keys. Another method uses shared secrets, but this chapter only covers RSA key authentication.

In addition to these options, it's possible for various other options described in the next section, "Adjusting System-Specific Remote Options," to appear in a default connection section. If you find yourself entering the same options for several connections, you might move them all to the default configuration to reduce the chance of a typo causing problems and to shorten the configuration file.

Adjusting System-Specific Remote Options

Each connection requires some customization, which is done in a conn section. The connection name follows conn , and that connection's options follow on subsequent lines, all of which are indented at least one space. Many of the options in this section relate to network interfaces. To help understand this, consider Figure 26.6. This shows a typical FreeS/WAN network. The configuration is described from the top ("left") VPN router. You must tell FreeS/WAN about various IP addresses used in this configuration. You do so with several options:

Figure 26.6. A FreeS/WAN configuration requires you to identify several computer and network addresses involved in creating the VPN.

• leftsubnet This is the local subnet to which the FreeS/WAN router is connected172.16.0.0/16 in the case of Figure 26.6.

• left This is the address associated with the VPN server's external interface. This can be set to %defaultroute in most cases, or you may want to provide an exact IP address, such as 10.0.0.1 in Figure 26.6

• leftnexthop This is the IP address of the conventional router to which the VPN system connects, such as 10.0.0.10 in Figure 26.6. This information is required because KLIPS bypasses the normal kernel routing machinery and sends the data directly to the next router.

• leftfirewall If the subnet that the VPN router serves uses nonroutable IP addresses with NAT, or if the VPN router also functions as a firewall, set leftfirewall=yes . This adjusts the way FreeS/WAN treats packets to support firewall functionality.

• rightnexthop This is the mirror of the leftnexthop entry; it's the IP address of the conventional router that delivers packets to the remote network. Note that this is the IP address of this router as seen by the remote FreeS/WAN system.

• right This entry corresponds to the remote VPN router's external network interface. Unlike left , you can't leave this entry set at a default.

• rightsubnet This is the IP address block of the remote network, such as 192.168.1.0/24 in Figure 26.6.

• leftid This is an identifier for the left system. This can be an IP address, a domain name, a hostname preceded by an at-sign (such as @vpn.threeroomco.com ) or a username and hostname (much like an e-mail address, such as [e-mail] ). The hostname preceded by the at-sign indicates that the system shouldn't try to resolve the name into an IP address. As a general rule, this is the best form to use because it's reasonably memorable and won't cause problems if DNS is down.

• rightid This is just like leftid , but it identifies the other side of the VPN link.

• leftrsasigkey This is the RSA public key value from the /etc/ ipsec.secrets file on the left VPN server. You should cut and paste this value if you're configuring the left system, or transfer the file and then copy and paste it if you're configuring the right system.

• rightrsasigkey This is the RSA public key value from the /etc/ ipsec.secrets file on the right VPN server.

• auto This option, in conjunction with the plutoload and plutostart options in the conn setup section, controls which networks are loaded or started when FreeS/WAN starts up. Specifically, if plutoload= %search and auto=add , then the configuration is loaded; if plutstart=%search and auto=start , then the configuration is started. For initial setup and testing, auto=add is a good configuration because this allows you to manually start connections. Once you set up a production system, auto=start usually works better because it requires no manual intervention to start the connections.

The labeling of a system or network as left or right is arbitrary. One useful mnemonic may be to give the link a name that includes both ends, such as boscinci for a VPN linking Boston and Cincinnati offices. You can then call the Boston side left and the Cincinnati end right , reflecting their positions in the name. You use the same configuration on both sides of the link; FreeS/WAN figures out which end it is by examining the system's existing network connections.

Establishing a Link

The basic procedure for establishing a link between two FreeS/WAN routers is to start the ipsec program as a daemon on one and to use the same program to initiate a connection from the other computer. Once you've tested the connection, it should be started automatically whenever you start the computers and run ipsec on both. It doesn't matter which system you use in daemon mode and which you use to manually start the connection when you do this stage of the testing; unlike PPTP, FreeS/WAN makes little distinction between clients and servers.

To start FreeS/WAN in daemon mode, type the following command:

 #  ipsec setup start  

This starts the server and, depending upon the configuration of the plutoload , plutostart , and auto options described earlier, the system loads a configuration and waits for a connection or tries to initiate a connection. If you configured your systems as described earlier, with auto=add on both ends of the connection, you can start the server on one end and it will wait for a connection request from the other system. This will occur when you type the following command on the system that's not yet running the program:

 #  ipsec auto --up   name  

In this example, name should be the name of a connection link, such as boscinci . The system should attempt to start up that link. You can check to see if it was successful by typing ipsec look . If you receive a set of encryption information and a VPN routing table as output, then the connection was successful. You can also try using normal networking commands, like ping , traceroute , and telnet , to see if you can establish connections with systems on the remote network, and to verify that they're being routed via the VPN. Remember that, if the remote network is publicly accessible from the Internet at large, tools like ping won't verify that the connection is via the VPN. You should use protocols that are blocked from scrutiny by the general public, or from your local public addresses, to test your VPN functionality.

Once you've gotten your network up and running, you can change the configuration of auto in /etc/ipsec.conf . If you set this to start on both ends, the startup will be automatic whenever the ipsec setup start command is issued. You can start FreeS/WAN in this way by starting it in a SysV or local startup script, as described in Chapter 4.