Encrypted Tunnels with FreeS/WAN's x509 Patch

FreeS/WAN can be a bit hard to set up, but with a few start up tips, it also can be a great tool.

In countries where a private or semi-public WAN is something not every company can afford, the Internet is the only option available to connect all of those remote offices. The obvious problems are this is a public network and, in most cases, we don't get a static IP address. We know that sending data through the Internet is like talking to somebody in an elevator--everybody just can't help hearing what you're saying. So, not encrypting the data is not an option.

Many types of tunnels can be used and VPNs can be put together in many ways, but the IPsec implementation of Linux (FreeS/WAN) is by far the most secure and compatible way to do it. In this article, I explain how to establish LAN-to-LAN tunnels using the x509 patch and only one static IP address. I also tell you two ways to get around the four tunnel inconvenience.

Installation

FreeS/WAN has two main parts: the IPsec patch for the kernel (KLIPS) that implements AH (authentication header), ESP (encapsulating security payload) and packet handling within the kernel; and the userland tools (pluto). Pluto implements IKE (internet key exchange), which negotiates the many connections with other systems.

The first thing to do is make the kernel understand IPsec, which can be done by applying the IPsec patch to the kernel's source tree and compiling it. People at the FreeS/WAN project have done a great job documenting the whole process, but for the impatient users (like myself), shortcuts are lifesavers. So, the most recommended way of doing this is not doing it all; instead, install the packages ready to be downloaded from the FreeS/WAN web site. Because I'm going to talk about the x509 FreeS/WAN patch here, download the x509 "already patched" packages.

The installation of these RPM packages is no different from any other .rpm package:

# rpm -ivh freeswan-version-module.rpm
# rpm -ivh freeswan-version.rpm

A word of advice: if you install the packages this way, do not try to compile the sources in the .tgz packages. Doing so will overwrite the FreeS/WAN binaries (pluto's tools) before you know it, and get you into trouble.

Once the installation is done, you're ready to link your offices with encrypted tunnels.

Configuring FreeS/WAN

Two files play a major role in configuring FreeS/WAN, the /etc/ipsec.conf file and the /etc/ipsec.secrets file. Things always can get more difficult, but because we want to keep this simple, let's play with only these two guys. The ipsec.conf file contains all the information about how the tunnels are established, and the ipsec.secrets file contains all the passwords and things we want to keep, well, secret.

The ipsec.conf file consists of two sections, the config and the conn section. Right now the only config section recognized by FreeS/WAN is "setup config". The config setup section contains all the information the software needs to know at the time it starts up. Here's an example from this section:

config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        uniqueids=yes

The most important value here is the interfaces parameter; the %defaultroute special value means the interface that pluto uses to establish an encrypted tunnel is the one that has the system's default route. The debug parameters, klipsdebug and plutodebug, need changing only when you have strange problems. The default messages receive get in the logs (messages and auth/secure) are, in most cases, enough to understand where the problem is.

The conn sections tell what type of tunnels pluto can accept or establish. Let's start with an example of what I'm going to call "the concentrator", which is the secure gateway (sgw) in front of the LAN to which everybody wants to connect. This concentrator is the only gateway (gw) that needs a static IP address in my example, and it also is the center of the star network topology used in this case.

conn %default
        keyingtries=0
        authby=rsasig
        leftrsasig=%cert
        leftcert=hostBobcert.pem
        leftsubnet=192.168.1.0/24
        leftnexthop=the Concentrator's default gateway
        rightrsasig=%cert

As this is the default conn section, the parameters set here apply to all the conn sections. The keyingtries line states how many times pluto tries to establish a specific tunnel; a zero value means keep trying. The authby parameter can have one of two values, secret, for pre-shared secret keys authentication and rsasig, which is used to authenticate the sgw using a RSA digital signature. leftrsasig tells pluto how to get the RSA signature from the left side of the tunnel. %cert is an x509-specific value that says the public key should be extracted from an X.509 certificate sent by the peer. leftcert is an x509-specific parameter that informs pluto which file has the x509 certificate on the left side of the tunnel. In this example, the concentrator's certificate is Bob.

The FreeS/WAN people did a great job of naming things. Instead of using the local or remote names, they chose left and right; thus, the same names can be used in any peer's ipsec.conf file. The left name is always used to point to the same sgw; that is, left is always left and right is always right, no matter which sgw you're configuring. In this example, left is the concentrator.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Encrypted Tunnels with FreeS/WAN's x509 Patch

Anonymous's picture

While this all looks interesting, the author just jumps in, while obviously assuming a ton of background knowledge on the part of his readers. Every sentence contains typically several undefined terms, and the whole tone is that "you obviously already know all this background".

I think in a case like this, and it is so often the case in technical writing, and particularly in writing about linux, that an author should recognize the prerequisites that he is assuming of his readers, and give them at least a couple references of where to go to get the necessary background before they try to make sense out of his article.

Two or three URLs, for background, would probably make all the difference.

Inter-operating with MS ISA

Anonymous's picture

I've gone even futheur by inter-operating with MS ISA server.
As I speak I have 4 offices all interconnected through VPN, 2 offices using MS ISA and 2 using Linux. The Linux boxes supporting as well incoming "dial in" MS client running L2TP over IPSec.

Where's the HowTo ? you may ask. Well am in the process of writting it.
The current limitation is that for LAN to LAN we can only initiate the connection from the MS ISA side.

Drop me an email if you're interested
dom.cressatti@aurora.uklinuxDOTnet (anti-spam relplace dot by .)

Re: Encrypted Tunnels with FreeS/WAN's x509 Patch

Anonymous's picture

ip route change net/netmask via yourgw dev ipsec0 src yourlocalip

is enough to make gateway host visible from remote network

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