Encrypted Tunnels with FreeS/WAN's x509 Patch
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.
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.
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.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- Calling All Linux Nerds!