Client Configuration


The DHCP side of the client requires no specific additional changes, unless (like me) you want the client's name to appear in the local DNS server (which requires ISC's DHCP server V3 coupled to named). This being the case, you need to add a line to your interface configuration file. In my case, both eth interfaces use DHCP, so the file /etc/sysconfig/network-scripts/ifcfg-eth1 has the following contents:-


where the significant change for here is the line DHCP_HOSTNAME='sporty' line, indicating that this machine's name will be sporty and will appear in the local DNS server as

Conceptually one could use different names for each DHCP enabled interface. I haven't tried, and don't know what other problems it might introduce.


This section assumes the use of FreeS/WAN IPSEC implementation. Others will, of course, have different configurations.

I split my configuration file into two parts. The main file, /etc/ipsec.conf contains the general configuration for this end of the link. Then the directory /etc/ipsec contains per connection data for the remote end. This removes a great deal of redundant data from the main configuration file.

FreeS/WAN's installation generates a default configuration which is close to what is needed. The following only shows the critically different sections. The distribution includes a large amount of documentation, and is quite helpful to understand the configuration.

Firstly, the important parts of the file /etc/ipsec.conf are shown here:-

config setup
        # THIS SETTING MUST BE CORRECT or almost nothing will work;
        # %defaultroute is okay for most simple cases.

conn %default keyingtries=0

# Per destination details are dragged in with the following. include /etc/ipsec/remote.*.conn

# sample VPN connection conn home-net # Left security gateway, subnet behind it, next hop toward right. left=%defaultroute # Identify ourselves to the other end # Right security gateway, subnet behind it, next hop toward left. # Details are in the files included by the above include. # Our public key. leftrsasigkey=<our public key, from /etc/ipsec.secrets>

The interfaces line will use the default route, specifically the device for the default route. Setting the keyingtries to 0 means that connections attempts to the other end will be repeated ad infinitum. The include line will drag in all files matching remote.*.conn from the directory /etc/ipsec This directory contains the connection information for the remote end, including addresses and public key information.

Finally, the conn section contains little more than the definition of this end of the tunnel. There may be multiple entries here, such as one for work, one for home etc. The individually included files specify which of these to use.

A typical file from the /etc/ipsec directory is this one, remote.jackie.conn and is the file defining the connection to 'jackie', the internal IPSEC server. Its contents are:-

# Connections from 'sporty' to jackie over the wireless link
# Data in this file is specific to the remote machine.
conn jackie-sporty
        #  Limit keylife, just to make it harder.
        # Right security gateway, subnet behind it, next hop toward left.
        # Left is the wireless machine, defined in the main file.
        # Couple this data to the 'home-net' section in main config file.
        #  An identity string for the gateway.
        #  jackie's public key
        rightrsasigkey=<jackie's public key>
        # Authorize and start this connection at startup.

Note that the keylife parameter ensures the keys (used to encrypt traffic only) are changed about every hour - there is some random variation in the exact time. The rightnexthop parameter specifies a direct connection to the laptop from the server. The rightsubnet= line specifies that all traffic is directed over the link. This is almost correct; the changes that IPSEC makes to the routing table means that all traffic on the network of the underlying device are not sent via IPSEC, which is necessary to avoid an infinite loop.

The also=home-net adds in the "our end" definition included in the main configuration file above. And, obviously, you need the public key for the far end.

DHCP And IPSEC Together
Server Configuration I

Version: $Revision: 1.2 $; Updated at 15:47 EST on Tue Apr 11, 2006
Copyright (C) 2002 - 2006, Lindsay Harris