Linux Containers Authors: Yeshim Deniz, Liz McMillan, Zakia Bouachraoui, Elizabeth White, Pat Romanski

Related Topics: Linux Containers

Linux Containers: Article

Implementing IPSec on Linux

Build advanced VPN topology with FreeS/WAN

IPSec (Internet Protocol SECurity) is an extension to the Internet Protocol (IP) that provides authentication and encryption. IPSec uses strong cryptography to provide both authentication and encryption services intended for building Virtual Private Networks (VPN).

In fact, IPSec is a peer-to-peer protocol that allows you to build secure tunnels through untrusted networks like the Internet. Everything passing through this network is encrypted by the IPSec gateway machine and decrypted by the gateway at the other end. The result is a VPN because IPSec allows building networks that are effectively private, even though it includes machines at several different sites connected by the insecure Internet (or another network). IPSec is an industry standard described in a series of IETF's (Internet Engineering Task Force) RFC (Request For Comments) documents – RFC2402, RFC2406, and RFC2408 – and is also widely accepted by vendors and developers. Originally, IPSec was designed for IPv6, but it's currently being deployed mostly for IPv4. IPSec services (authentication and encryption) are implemented at the IP level of the protocol stack; therefore, IPSec can protect any protocol running above IP and any medium used below IP. Of course, IPSec provides security services in the background, with no visible impact on applications because the authentication and encryption occur at the IP level.

Most IPSec implementations are commercial products, but thanks to the FreeS/WAN package Linux administrators can build up VPN based on IPSec. FreeS/WAN is an open source implementation of IPSec for Linux that is compliant with the IETF's IPSec specification. It does not yet implement all of IPSec, but everything it does follows the IPSec RFCs. FreeS/WAN, including the full source code, is available under GPL license. Thanks to the FreeS/WAN package, Linux becomes an attractive platform for building IPSec-based VPN gateways.

Unfortunately, FreeS/WAN code cannot be distributed with standard Linux kernel source because the export laws of some countries (not only the U.S.) restrict the distribution of strong cryptography. However, there are a few Linux distributions that include FreeS/WAN support: SuSE Linux (www.suse.com), Connectiva Linux (www.connectiva.com.br), and Trustix Secure Linux (www.trustix.net). If your Linux distribution isn't on this list, you'll need to download and compile FreeS/WAN for yourself.

FreeS/WAN Services
IPSec– (and then FreeS/WAN) based VPNs are built upon two services: authentication and encryption. These can be used separately in theory, but in real life they're used together. Authentication allows you to be confident that a packet came from a particular machine and that its contents were not altered en route to you. Authentication service doesn't protect transmission of content.

Authentication can be provided separately using a special Authentication Header (AH), or it can be included as part of the service that offers encryption (this is called Encapsulated Security Payload [ESP], defined in RFC 2406). In most configurations authentication uses keys that are automatically negotiated (and periodically renegotiated) using the IKE (Internet Key Exchange) protocol.

Encryption service prevents the unauthorized reading of packet contents. In IPSec this is done using a block cipher (3DES and MD5 in FreeS/WAN). FreeS/WAN also supports ESP encryption service. ESP provides encryption and/or authentication. It may be used with or without AH authentication. FreeS/WAN can work in the following IPSec modes:

  • AH: Authentication only, no content encryption.
  • ESP: Encryption only, no authentication.
  • ESP: Authentication and encryption together; this is the recommended and most commonly used configuration.
  • AH + ESP: Double authentication.

    Technically, FreeS/WAN contains two modules:

  • KLIPS (KerneL IPSec): Implements AH, ESP, and packet handling within the Linux kernel.
  • Pluto daemon: Implements IKE, negotiating connections with other gateways and performing other high-level tasks. Pluto calls KLIPS kernel code.

    FreeS/WAN Configuration
    The three most common VPN configurations with FreeS/WAN (and IPSec in general) are:

  • End-to-end VPN: Two end hosts communicate through an IPSec connection. This is the simplest configuration and is used often.
  • Node-to-end VPN: The client machine is connected to the intranet through an IPSec gateway, e.g., mobile VPN clients (see Figure 1).


  • Node-to-node VPN: The two private networks communicate through an IPSec gateway using an unsecure network (i.e., the Internet); VPN gateways decrypt communication on the intranet side.

    Depending on your local network configuration, additional scenarios are possible:

  • "Road Warrior" configuration: When the remote host doesn't have fixed IP address.
  • Opportunistic encryption: This doesn't rely on any prearranged connection and doesn't require that the administrators of the gateways involved communicate with each other. Each gateway checks the destinations of outgoing packets to see if an encrypted connection is possible, and if so, takes the opportunity to encrypt.

    There are some network configuration prerequisites that you must check before installing FreeS/WAN. First, enable TCP/IP forwarding on all FreeS/WAN gateway servers. Second, the IPSec gateway should have packet filters rules in the firewall script file permitting the following protocols to traverse three kinds of packets (if you use firewalling, of course):

  • UDP port 500 for IKE implemented by the Pluto daemon
  • Non-IP protocol 50 for ESP encryption and/or authentication (see "etc/protocols")
  • Non-IP protocol 51 for AH packet-level authentication (see "/etc/protocols")


    Install FreeS/WAN source code and integrate it with your kernel source code. It adds an "IP Security Protocol (FreeS/WAN IPSEC)" section under the "Networking Options" section of the kernel configuration interface (see Figure 2). FreeS/WAN documentation includes step-by-step instructions for compiling and installing tools. When installation is complete, check to see whether FreeS/WAN code is properly integrated into kernel. You can do this with the "dmesg" command:

    zeus# dmesg | grep ipsec
    klips_info:ipsec_init: KLIPS startup, FreeS/WAN
    IPSec version: 2.00

    All FreeS/WAN configuration parameters are in "/etc/ipsec.conf". You need to change the default values to fit your configuration and topology. "ipsec.conf" contains two sections that apply to all connections: "conn setup", which describes FreeS/WAN machine configuration, and "conn %default", which defines default parameters that apply to all connections. The "ipsec.conf" example shown in Listing 1 defines an end-to-end VPN.

    The "conn" sections that will define connections to be made using FreeS/WAN follow. The connection definition takes precedence over the "%default" section. Listing 2 shows an example connection section definition between two gateways (named "zeus" and "athena").

    When you have a connection definition ready, the next step is to define a secret to be used for authentication between gateways.

    Authentication Issues
    FreeS/WAN (like all IPSec implementations) supports two types of connection authentication: manually keyed and automatically keyed (also called perfect forward secrecy or PFS). Manually keyed connections use keys stored in the "/etc/ipsec.conf" file. Automatically keyed connections use keys automatically generated by the Pluto key negotiation daemon. The key negotiation protocol used by default, IKE, authenticates the other system using shared secrets stored in "/etc/ipsec.secrets" file. The better (more secure) solution is to use automatically keyed connections, of course.

    The "ipsec.secrets"file stores the secrets used by the Pluto daemon to authenticate communication between both gateways. Several kinds of secrets can be configured in this file: pre-shared key, RSA private keys, and X.509 certificates, which require patching FreeS/WAN sources. An example for pre-shared keys is included in the "ipsec.secrets" file that comes with FreeS/WAN source code.

    Pre-Shared Key (PSK)
    The pre-shared keys are simply predefined byte strings used for authentication. Of course, both gateways must utilize this same PSK. FreeS/WAN uses PSK for authentication by default, and you can always revert to PSK at any time by adding the following option to your connection definition in "ipsec.conf":


    You also need to change the default PSK line in the "ipsec.secrets" file to add the IP addresses for VPN gateways. Last, add preshared keys; the most to use is "ipsec ranbits" command that generates random keys. The result (in "ipsec.secrets") may look something like: PSK

    RSA Private Keys
    The most useful authentication in FreeS/WAN uses RSA keys that can be used by the Pluto daemon on FreeS/WAN gateways. Authentication by RSA signatures requires that each host have its own private key and export its public key. You need to create a separate RSA key for each gateway. Each holds its own private key in the "ipsec.secrets" file, and the public key goes to the "leftrsasigkey" and "rightrsasigkey" parameters in the connection description section in the "ipsec.conf" file. You can generate RSA keys for host with the following command:

    zeus# ipsec rsasigkey --verbose 1024 > zebra-RSAkeys

    The "rsasigkey" utility generates an RSA public and private key pair of a 1024- bit signature and puts it in the file "zeus- RSA-keys". The file includes both keys with appropriate comments so you can easily separate the private key from the public key. The private key should be inserted into the "ipsec.secrets" file, and the public key into the "ipsec.conf" file. Don't forget to delete temporary files (from the "/tmp" directory) after key generation. Now add the RSA secret definition to your connection definition section in "ipsec.conf":


    Insert the RSA public keys for both gateways into the connection definition in "ipsec.conf":

    leftrsasigkey=<Public key of zeus>
    rightrsasigkey=<Public key of athena>

    Next, modify "ipsec.secrets" on each gateway to include its RSA private key. The "/etc/ipsec.secrets" file should have permissions set to 600 and be owned by root user. The "/etc/ipsec.conf" file is installed with permissions mask 644 and must be also owned by root. The other question is how to deliver public keys to gateways that you want to establish secure communication with. There are three ways to do this:
    1.  Put public keys in the connection descriptions in the "/etc/ipsec.conf" file (use "ipsec showhostkey --left" [or "-- right"] to extract the public key prepared for "ipsec.conf" insertion).
    2.  Place the public key in DNS records (if you use "ipsec showhostkey" you'll get the public key in a format suitable for KEY and TXT records in DNS).
    3.  Use X.509 certificates or PGP keys for storing public (and also private) keys and implement a third-party patch on FreeS/WAN (see resources). Using X.509 certificates is most useful if your organization utilizes PKI (Public Key Infrastructure) and you can use it for generating trusted certificates for FreeS/WAN authentication. The MS Certificate Authority and Domino built-in Certificate Authority are examples of inexpensive CA servers that you may use with FreeS/WAN. If you don't have PKI or at least CA server, you can always generate self-signed certificates with the OpenSSL package.

    FreeS/WAN Interoperability
    IPSec has been designed to work in heterogeneous VPN environments and is supported by major firewall software and hardware vendors, including Apple, Microsoft, Sun, Cisco Systems, Check Point, Nortel Networks, Lucent, IBM, and Alcatel. Unfortunately, interoperability between IPSec products is still the problem. You must realize that many third-party products will require some tweaking to work with FreeS/WAN because it's not completely compliant with the IPSec IETF RFC specification.

    FreeS/WAN works out of the box with Cisco routers (IOS 12.0 or later), Nortel Switches, OpenBSD, Check Point FW-1/NG, SSH Sentinel VPN, F-Secure VPN, Xedia Access Point, PGPnet, IRE SafeNet/SoftPK, Freegate, Borderware, Intel Shiva LANRover, Windows 2000/XP, and Sun Solaris. When you try to connect FreeS/WAN products other than those listed with IPSec, first check whether your product supports 3DES. Detailed instructions can be found on the FreeS/WAN Web site, and documentation is included with the FreeS/WAN distribution.

    Thanks to FreeS/WAN you can set up an IPSec VPN connection in a short time. FreeS/WAN is stable solution developed over many years, and commercial IPSeccompatible products will cooperate with it. FreeS/WAN is a cheap and flexible solution for building advanced VPN topology. Best of all, it's open source, so you can even improve the way it works.


  • FreeS/WAN VPN: www.freeswan.org
  • IPSec white papers: www.vpnc.org/white-papers.html
  • Patches for X.509 certificate support: www.strongsec.com/freeswan/
  • Patch for IPv6 support: www.ipv6.iabg.de/downloadframe/index.html
  • Hardware acceleration for FreeS/WAN: http://sources.colubris.com/en/projects/FreeSWAN/
  • All standards and official documents regarding IPSec collected by IPSec Working Group: www.ietf.org/html.charters/ipsec-charter.html
  • Configuring FreeS/WAN with X.509 certificates: www.natecarlson.com/linux/ipsecx509.php
  • Using Windows 2000/XP as VPN client for FreeS/WAN: http://vpn.ebootis.de
  • Setting IPSec on Mac OS X for connecting FreeS/WAN: www.slackwerks.com/thecrew/arete/soekris/macosx-ipsec.html

    Source Code

    Listing 1

    config setup
    # specifies network interfaces for IPSec to use.
    #Two above lines specifies the debugging output for KLIPS and for the Pluto.
    # The value %search loads all defined connections with auto=add or auto=start parameters.
    conn %default
    # We use RSA keys for authentication. See below
    # This option specifies whether authentication should be done separately using AH (Authentication Header), or be included as part of the ESP - Encapsulated Security Payload service.
    # This option specifies whether automatic startup operations should be done at IPSec startup.

    Listing 2

    conn zeus-athena
    # left host - this is 'zeus'. 'ipsec.conf' uses left-right notation for more intuitive
    gateways distinction
    # next hop to reach right - this should ge used if
    # right host - this is 'athena'
    # manual encryption/authentication algorithm and parameters to it
    # here we use ESP with 3DES and MD5
    espenckey=[192 bits]
    espauthkey=[128 bits]

  • More Stories By Pawel Leszek

    Pawel Leszek, a contributing editor of Linux.SYS-CON.com, has been a Linux administrator and consultant since 1996. He currently provides consulting expertise in the areas of corporate groupware software and Mac OS X and Linux.

    Comments (1)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...