An Introduction to FreeS/WAN, Part I

VPN tunnels for secure wireless and WAN connections, Part I of II.
Preparing ipsec.conf

FreeS/WAN is configured via two files: /etc/ipsec.conf is its main configuration file, and /etc/ipsec.secrets is its key repository. Both files should have restrictive permissions; 0600 is a safe choice. /etc/ipsec.secrets, in particular, must be carefully protected. If you need to copy any data out of this file, say, your host's public RSA key, copy out only the data you need into a separate file. Never allow ipsec.secrets itself to leave your system. We'll discuss this file in greater depth next month.

Listing 1 shows the ipsec.conf file from an example wireless VPN client. /etc/ipsec.conf consists of three parts: basic setup parameters (config setup); default tunnel parameters (conn %default); and tunnel definitions (conn george-gracie in Listing 1, where george-gracie is the name I chose for this tunnel).

Listing 1. /etc/ipsec.conf on a Wireless Client

The default settings for the config setup section can be safely left alone on single-interfaced systems. The most important parameter there is interfaces. This tells FreeS/WAN which interface to use as the local end point of IPSec tunnels. Its default, the magic string %defaultroute, expands to ipsec0=[interface] (where [interface] is the network interface name indicated in the system's default route, e.g., eth0). Similarly, the default tunnel settings usually can be left alone.

This brings us to the heart of ipsec.conf: the tunnel definition. In the tunnel george-gracie from Listing 1, we begin by setting authby, which determines how the IPSec hosts authenticate themselves to each other. The default is “secret”, which is short for preshared secret. This setting allows you to define a secret string used in a transparent challenge-response authentication transaction. The secret itself never traverses the network, so this isn't as sloppy an authentication method as you might think.

But that doesn't matter right now, because in Listing 1 authby is set to rsasig, so that RSA authentication is used instead. RSA authentication isn't necessarily that much more secure, but it's more convenient. Whereas a shared secret must be exchanged beforehand via some secure means such as PGP e-mail or SSH, the public keys used in RSA authentication may be exchanged openly (or even published on a web page).

The idea of left and right is important in FreeS/WAN configuration; they are used in parameters and commands to designate the end points of an IPSec tunnel. Which side is which doesn't matter, so long as you're consistent. The same host should be right on both systems' tunnel definition, and one system should not reverse the right/left designations defined on the other.

For sanity's sake, whenever one host acts as a server to another, you're encouraged to designate that host as left. In our example, George is acting as a server for wireless clients, so George is left, and Gracie, a client system, is right.

The tunnel-configuration parameter left indicates the IP address of the tunnel's left end point, George, whose IP address is 10.0.54.2. Right, of course, specifies the right end point's IP address. In our scenario, however, Gracie and other wireless clients have dynamic IP addresses. Instead of specifying an IP, then, we'll use the magic string %defaultroute, which expands to the IP address of the interface specified in the host's default route.

The tunnel parameter leftid may seem redundant, as we just identified the left IP address with left, but it's slightly different. leftid and rightid specify each tunnel end point's authentication ID. This can be an IP address, or it can be an FQDN preceded by an @ sign. Because Gracie's IP address is dynamic, @gracie.wiremonkeys.org is the only viable value for leftid. But in this example, @george.wiremonkeys.org and 10.0.54.2 are interchangeable values for rightid.

The next tunnel parameter in Listing 1 to consider is leftsubnet. This defines which destination IPs can receive packets from the right side, and therefore for which destinations the right-hand end point will use the tunnel. Because Gracie and other wireless clients will use George as their sole gateway to the corporate LAN and to the world at large, we've set this to 0.0.0.0/0, which signifies all destinations. (There's also a rightsubnet parameter, but you need to set both subnet parameters only in site-to-site scenarios. In remote-access and other client/server setups, only one or the other is needed.)

leftrsasigkey and rightrsasigkey both are required when you've specified RSA authentication for a tunnel. The values for these are stored in each host's ipsec.secrets file, in the line beginning #pubkey=. Alternatively, you can use these commands:

ipsec showhostkey --left

or

ipsec showhostkey --left
The --left and --right options (which work on FreeS/WAN versions 1.9 and later) are optional but convenient. They cause the output to take the form of a leftrsasigkey or rsasigkey statement (respectively) that can be copied and pasted verbatim into ipsec.conf. For example, running ipsec showhostkey --left on George would return the leftrsasigkey statement in Listing 1. Running ipsec showhostkey --right on Gracie would return the rightrsasigkey statement. Note that although RSA keys are long, each must occupy a single line, that is, without line breaks.

The last parameter in Listing 1's tunnel statement is auto, which tells FreeS/WAN what, if anything, to do about the tunnel when IPSec is started. A value of start causes the tunnel to be initialized and started automatically. “add” causes it to be added to the IPSec dæmon's (called pluto) connection specification, and “ignore” causes the tunnel to be ignored. In Listing 1, auto is set to start. Therefore, whenever IPSec is started on Gracie, we want the tunnel to George to be brought up immediately. The config setup parameters plutoload and plutostart must be defined properly for auto to have any relevance—see the ipsec.conf(5) man page for more information.

Okay, that's it for the client-side ipsec.conf. But what about George? As it happens, in this scenario the configuration is nearly the same on both sides. Listing 2 shows most of George's /etc/ipsec.conf file.

Listing 2. /etc/ipsec.conf on Gateway

The first difference is that unlike Gracie, George has multiple interfaces, so it's necessary to give an explicit value to the interfaces parameter. The interface in George's default route faces the corporate LAN, not the wireless LAN, so a value of %defaultroute won't work. Next, we have a new config setup parameter, forwardcontrol. When set to yes, it tells IPSec to turn on IP forwarding when needed and to turn it off when IPSec is shut down.

Next, in the tunnel section itself, right is now set to %any rather than %defaultroute (because %defaultroute would return George's local IP, not Gracie/right's). And, auto is set to add rather than start, because George is acting as a server; it only needs to be ready for Gracie to start the tunnel.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState