s SECURING CONNECTIONS AND REMOTE ADMINISTRATION in Font

Creator Data Matrix 2d barcode in Font s SECURING CONNECTIONS AND REMOTE ADMINISTRATION

Now you need to build the userland tools and the ipsec.o module. Listing 3-17 shows the required command. Listing 3-17. Building the Openswan Userland and the IPSec module for Kernel Version 2.4 puppy$ make KERNELSRC=/path/to/kernel/source programs module Again, replace /path/to/kernel/source with the location of your kernel source. Once this is compiled, the last step is to install the tools and your new IPSec module. Use the command in Listing 3-18 for this. Listing 3-18. Building the Userland Tools and IPSec Module puppy# make KERNELSRC=/path/to/kernel/source install minstall Remember to replace /path/to/kernel/source with the location of your kernel source. With version 2.6 kernels, Openswan relies on the built-in IPSec support and does not need to compile a module.

s Note This implies you have enabled the IPSec support in your 2.6 kernel. You also should be using at

least version 2.6.4 of the kernel because earlier versions have IPSec bugs that can result in system crashes.

From inside the Openswan source directory, use the commands in Listing 3-19 to compile and install Openswan for version 2.6 kernels. Listing 3-19. Compiling and Installing Openswan for Version 2.6 kernels puppy$ make programs puppy# make install Once you have installed Openswan, you need to start it. Openswan comes with an init script called ipsec that is installed with your other init scripts when you run the make install process. I will start this script first (see Listing 3-20). Listing 3-20. Starting the ipsec Script puppy$ /etc/rc.d/init.d/ipsec start ipsec_setup: Starting Openswan IPSec 2.1.3... Next you should verify that all the required components for Openswan are available using the verify function, which is run using the ipsec command. The ipsec command provides an interface to Openswan and allows you to control it. Listing 3-21 shows the ipsec verify function.

Listing 3-21. The ipsec verify Command puppy$ ipsec verify Checking your system to see if IPSec got installed and started correctly: Version check and ipsec on-path [OK] Linux Openswan U2.1.3/K2.4.21-4.EL (native) (native) Checking for IPSec support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK] Checking for 'ip' command [OK] Checking for 'iptables' command [OK] Checking for 'setkey' command for native IPSec stack support [OK] Opportunistic Encryption DNS checks: Looking for TXT in forward dns zone: puppy.yourdomain.net [MISSING] Does the machine have at least one non-private address [FAILED] The results of the command in Listing 3-21 show that all Openswan and IPSec options are installed and started correctly. The last two options relate to using the Opportunistic Encryption (OE) DNS checks that rely on DNS TXT records to authenticate VPN connections. I will not cover this, but if you are interested in looking at OE, then see this quick start guide at http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/quickstart.html. The guide is for Openswan s predecessor, FreeSWAN, but because Openswan is drawn from the FreeSWAN code base, configuration is nearly identical.

Openswan connections are controlled via the ipsec.conf file. You will need to have a copy of this file on both systems you want to connect with Openswan. Listing 3-22 shows an example of an ipsec.conf file. Listing 3-22. A Sample ipsec.conf File version 2.0 config setup interfaces="ipsec0=eth0" klipsdebug=none plutodebug=all conn puppy_to_kitten auth=rsasig left=203.28.11.1 leftsubnet=192.168.0.0/24 leftid=@puppy.yourdomain.net leftrsasigkey=key leftnexthop=%defaultroute

right=203.28.12.1 rightsubnet=192.168.1.0/24 rightid=@kitten.anotherdomain.com rightrsasigkey=key rightnexthop=%defaultroute #Disable Opportunistic Encryption include /etc/ipsec.d/examples/no_oe.conf

s The ipsec.conf file is occasionally highly temperamental when parsed. If you have issues with the Tip

ipsec init script failing to start or connections failing to start because of parse errors in your configuration

file, then make sure you have the file properly indented, no extra spaces or special characters are present, and all your sections starts in the first column. If all else fails, try to remove all comments and empty lines in your ipsec.conf file.

Let s go through the file line by line. The first option specifies the use of version 2.0 of Openswan. The rest of the ipsec.conf file is divided into sections. The sections currently available for Openswan are the config and conn sections. The config section handles the general configuration of Openswan, and the conn sections describe connections. You need to indent the parameters under each section with a tab; otherwise the configuration file will not be parsed correctly. The section config setup refers to configuration options related to the startup of Openswan. I have used three options on this section. The first specifies a matched pair of virtual and physical interfaces to be used by Openswan for IPSec connections, in this case the virtual interface ipsec0 matched with the physical interface eth0. You can specify more than one interface here. You can also use the variable %defaultroute, which finds the default route and uses the interface associated with that. Enter the following: interfaces=%defaultroute You will need at least two interfaces in both your systems for most VPN configurations. This is because you need one interface for each end of the VPN tunnel in addition to an interface or interfaces on each system for non-VPN tunnel traffic to use. For example, the simple system-to-system tunnel you are creating here requires two interfaces on each system: one to connect to the local internal network and the other to provide the interface for the VPN tunnel. The last two options are both related to the output of debugging data. The klipsdebug option handles the debugging output from the IPSec module of the kernel, which can be outputted to syslog as part of Openswan s operation. I have set it to none, which will produce no debug output. The plutodebug option handles the output from the Pluto IKE daemon, which is started when you run the ipsec init script. The Pluto IKE (or IPSec Key Exchange) daemon handles the low-level key negotiation daemon. You can read more about Pluto (and its related control interface whack) via man ipsec pluto. Table 3-6 describes some other useful options.