Scalable Public Key Infrastructure for both OpenSWAN and OpenVPN

Posted by ElizabethBevilacqua on Thu 15 Nov 2007 at 14:26

Tags: ,

User management and the related cryptographic authentication infrastructure is a major hurdle in deploying scalable, manageable VPNs (Virtual Private Networks). After introducing VPNs and Public Key Infrastructure (PKI) and discussing some of the benefits and challenges of two popular VPN implementations, we'll document how to build a scalable PKI to simplify VPN authentication management.

Two major pieces of FOSS (Free and Open Source Software) for VPNs are OpenSWAN and OpenVPN. Generally speaking, OpenSWAN is lighter weight, faster, and largely interoperable with other IPSec (IP Security) implementations. For example, if you need to connect to a Cisco or a Linksys, OpenSWAN is recommended. OpenVPN, on the other hand, provides free client software for Linux, Windows and Mac OS, better server-side management of the client-side network configuration (e.g., when they are non-technical users and need some networking tweaks), you can change the port to bypass non-standard firewall configurations, and even change the MTU (Maximum Transmission Unit) easily in case an intermediate gateway is acting funny.

Frequently it is necessary to support both implementations on a VPN server because of the advantages that each confers. But then one can quickly get an unscalable nightmare with a PKI per software and per client. This article will document a simple, single PKI infrastructure to manage all your users and their VPN connections with support for both OpenSWAN and OpenVPN.

An Introduction to VPNs and a Public Key Infrastructure

A VPN provides a cryptographically protected "private" network layered over IP (Internet Protocol). In a VPN, the server provides authentication and access to the VPN and a client is a system or network requesting access to the VPN. Both OpenSWAN and OpenVPN can use X.509 certificates to manage authentication. X.509 is a standard that defines cryptographic certificates which are "trusted" based on preconfiguration with a hierarchical chain of certificate authorities (CAs) known as a Public Key Infrastructure or PKI. Building an X.509 PKI is the only way we have found to manage an integrated, scalable client/user authentication database for both OpenSWAN and OpenVPN.

A PKI has a Certificate Authority (CA) at its root. This is a public/private cryptographic key pair whose signatures can be "trusted" (by configuring software to "trust" the CA's public key). Once the CA is "trusted", certificates (public/private key pairs) signed by it for each server and each client need to be generated. Server certificates are similar to the client's except they have the extra attribute 'Netscape Cert Type' set to 'SSL Server' to allow an additional sanity check. Once these certificates are signed, the clients and servers only need to exchange their public keys to establish their identity to each other (note: the signature of the CA can be checked by each side, enabling two way trust). If a certificate is ever compromised, it can be revoked and this information made available to the VPN servers and clients in the form of a Certificate Revocation List (CRL). In this way the CA controls authentication.

OpenSWAN

OpenSWAN is a VPN implementation based on the industry standard IPSec protocol (RFC 2401). In Debian Etch, it uses the in-kernel IPSec implementation, and the userspace tools are just frontends to the kernel. Due to kernel-level support, IPSec is very, very fast. For most workloads, you shouldn't notice a difference between IPSec protected traffic and normal unencrypted traffic. We have successfully set up VPNs between OpenSWAN and routers of various makes (Cisco, Linksys, Netgear) and with Windows and MacOS X clients using a variety of third party software. OpenSWAN implements most of the IPSec draft extensions such as NAT-T (detecting that a peer is behind a NAT (Network Address Translation) firewall and acting appropriately), X.509 based authentication, Dead Peer Detection (dropping disconnected clients) and many others.

OpenSWAN also implements several other nice features such as MTU control, changing the source address of the connection (so that a multihomed host can use the correct IP when sending traffic over a tunnel which is useful on a gateway), and many others. However, it is not always trivial to make IPSec interoperability actually work. Vendors are free to implement various subsets of the extensions, and there are many parts of the RFCs that are 'may's or 'might's that are not universally implemented. Not all clients support the IPSec extensions that OpenSWAN does. Moreover, OpenSWAN uses a highly baroque configuration syntax, some features are poorly documented, and it sports cryptic error and debug messages (in debugging something simple like client authentication, you typically have to wade through hundreds of lines of messages largely devoted to OpenSWAN internals).

OpenVPN

OpenVPN is an SSL-based VPN, that, unlike OpenSWAN, is entirely userspace. If you want to connect to an OpenVPN server, you must be running an OpenVPN client (no interoperability here). Being in user space also means some additional workload over an in kernel implementation, but the decision to create a new VPN communication protocol has given the OpenVPN developers the freedom to add an extraordinarily rich feature set. For just about every internetworking need we have faced, there has been an OpenVPN option to address the problem.

OpenVPN is highly configurable and well-documented (including a 3300 line manpage). Obviously, that's a wider feature set than we can cover here. Some of the very nice things that openvpn can do trivially that would be difficult to configure for OpenSWAN are:

  • Giving the client an address on the local subnet using a software bridge
  • changing the client's default route to go through the VPN server
  • Adding additional static routes to the client
  • PAM (Pluggable Authentication Module) based password authentication.

The main disadvantage of OpenVPN is interoperability. You will not be able to connect an OpenVPN server and a Netgear client. However, OpenVPN provides binaries for most OS's that you would need on the client side (Windows of various ages, MacOS X), so if you can use OpenVPN as a server, most roaming users will be able to connect.

Another disadvantage is speed. OpenVPN works by creating a tun/tap device and listening on it. All VPN traffic traffic goes kernel -> application -> kernel, so it is much more expensive than an in kernel implementation. But, similar tun/tap applications are capable of 50MB/s which exceeds the capacity of most WAN (Wide Area Networking) links. An underpowered system may experience an excessively high load. Otherwise, performance is not likely to be much of an issue (modestly higher latency could affect some applications).

PKI Configuration

So, to begin, make sure you have both pieces of software installed (apt-get install openvpn openswan). openswan setup tries to be very helpful and gives you a default config file and a default rsa key. You can safely remove both ipsec.conf and ipsec.secrets now, as we'll be recreating them momentarily. The method we use is wrapped around the pkitool script that comes with openvpn, namely, /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool.

$ mkdir -p /etc/pki/keys
$ cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars /etc/pki/

Create a file named /etc/pki/vars and fill in your information like this:

export EASY_RSA="/etc/pki/"
export OPENSSL="openssl"
export PKCS11TOOL="pkcs11-tool"
export GREP="grep"
export KEY_CONFIG="$EASY_RSA/openssl.cnf"
export KEY_DIR="$EASY_RSA/keys"
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY="US"
export KEY_PROVINCE="PA"
export KEY_CITY="Philadelphia"
export KEY_ORG="My company"
export KEY_EMAIL="vpn.server@mycompany.com"

Build PKI

$ . /etc/pki/vars
$ /usr/share/doc/openvpn/examples/easy-rsa/2.0/clean-all
$ /usr/share/doc/openvpn/examples/easy-rsa/2.0/build-dh

$ /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --pass --initca

(put this password somewhere safe - you'll need it for future keys)

$ /usr/sbin/openvpn --genkey --secret ta.key
$ /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --pass --server my.server

the password for this one is PASSWORD, more below.

$ cp /etc/pki/keys/ca.crt /etc/ipsec.d/cacerts
$ cp /etc/pki/keys/my.server.key /etc/ipsec.d/private
$ cp /etc/pki/keys/my.server.crt /etc/ipsec.d/certs

$ echo 'PASSWORD' > /etc/openvpn/my.server.password
$ chmod 0600 /etc/openvpn/my.server.password

Now that we've done this, both OpenSWAN and OpenVPN use a single PKI, and adding new clients is as easy as:

$ . /etc/pki/vars

$ /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --pass user@domain

The openvpn client will need the files user@domain.key, user@domain.crt, ca.crt, and ta.key. An openswan client will only need the first 3 of those files.

Software Configuration

OpenSWAN Server Configuration details:

ipsec.conf:
version 2.0   

config setup
     nat_traversal=yes
     uniqueids=no

conn %default
    compress=yes
    disablearrivalcheck=no
    authby=rsasig
    leftrsasigkey=%cert
    rightrsasigkey=%cert
    keyingtries=3

conn sslvpn
    type=tunnel
    left=%defaultroute
    leftsendcert=yes
    leftsubnet=192.168.1.0/24
    leftid=my.server
    leftcert=my.server.crt
    dpdaction=clear
    pfs=yes
    right=%any
    rightsubnetwithin=0.0.0.0/0
    rightca=%same
    auto=add

ispec.secrets:

: RSA /etc/ipsec.d/private/my.server.key "PASSWORD"

OpenVPN Server Configuration details:

/etc/openvpn/vpn.conf:

dev tap
tls-server
dh /etc/pki/keys/dh1024
ca /etc/ipsec.d/cacerts/ca.crt
cert /etc/ipsec.d/certs/my.server.crt
key /etc/ipsec.d/private/my.server.key
askpass /etc/openvpn/my.server.password
tls-auth /etc/pki/keys/ta.key 0
server-bridge 192.168.1.1 255.255.255.0 192.168.1.50 192.168.1.60
port 1194
comp-lzo
up /etc/openvpn/up.sh
down /etc/openvpn/down.sh
keepalive 10 120

/etc/openvpn/up.sh:

#!/bin/sh

DEV=$1
MTU=$2
/sbin/ifconfig $DEV mtu $MTU up
/usr/sbin/brctl addif br0 $DEV

/etc/openvpn/down.sh:

#!/bin/sh
# Intentionally empty script, the OS removes the interface 
# from the bridge when the connection terminates

OpenSWAN client configuration:

ipsec.conf:

version 2.0 

config setup
    nat_traversal=yes
    uniqueids=yes

conn %default
    compress=yes
    disablearrivalcheck=no
    authby=rsasig
    leftrsasigkey=%cert
    rightrsasigkey=%cert
    keyingtries=3

conn vpn 
    type=tunnel
    left=%defaultroute
    leftsendcert=yes
    leftcert=user@domain.crt
    dpdaction=clear
    compress=yes
    right=my.server
    rightid=my.server
    rightca=%same
    rightsubnet=192.168.1.0/24
    pfs=yes
    auto=start

ispec.secrets:

: RSA /etc/ipsec.d/private/user@domain.key "mypassword"

Put the certs in place:

$ cp ca.crt /etc/ipsec.d/cacerts
$ cp user@domain.key /etc/ipsec.d/private
$ cp user@domain.crt /etc/ipsec.d/certs

OpenVPN client configuration:

$ echo "mypassword" > /etc/openvpn/password
$ chmod 0600 /etc/openvpn/password

/etc/openvpn/client.conf:

dev tap
client
remote my.server
ca /etc/openvpn/ssl/ca.crt
cert /etc/openvpn/ssl/user@domain.crt
key /etc/openvpn/ssl/user@domain.key
tls-auth /etc/openvpn/ssl/ta.key 1
askpass /etc/openvpn/password
port 1194
comp-lzo
keepalive 10 120

Put the certs in place for this as well - the full paths are listed above.

Certificate Revocation

To revoke a compromised or otherwise no longer valid certificate, you can use another script distributed with openvpn. We will for purposes of this demonstration say that we are revoking a certificate for baduser@domain, who has previously had a key pair generated for them. There will be 3 files in /etc/pki/keys associated with this certificate - the private key (baduser@domain.key), the certificate signing request (baduser@domain.csr), and the signed certificate issued by our CA (baduser@domain.crt). It is important to remember that we are only revoking our signature on the public certificate - the private key is still a useable key, but it will no longer be part of our PKI.

So, the details:

$ . /etc/pki/vars

# Notice that we don't use the file extension - the script appends .crt

$ /usr/share/doc/openvpn/examples/easy-rsa/2.0/revoke-full baduser@domain

$ cp /etc/pki/keys/ca.crl /etc/ipsec.d/crls/

$ cp /etc/pki/keys/ca.crl /etc/openvpn/ssl/

Add this to the server's openvpn configuration:

crl-verify /etc/openvpn/ssl/ca.crl

OpenSWAN will do the check automatically, but will need to be restarted.

Acknowledgements:

Stephen Gran, System Administrator at LinuxForce; Primary Author

Elizabeth Bevilacqua, System Administrator at LinuxForce; Tester, Editor

CJ Fearnley, President of LinuxForce; Editor

 

 


Posted by Anonymous (193.110.xx.xx) on Fri 16 Nov 2007 at 16:33
Disclaimer: I am Paul Wouters, an Openswan developer...

Some comments to your article

> largely interoperable with other IPSec (IP Security) implementations.

We implement the RFC's, and even have a lot of workarounds for buggy implementations of IPsec. Openswan is probably the most compatible piece of IPsec software out there.

> OpenVPN, on the other hand, provides free client software for Linux, Windows and > Mac OS

If use use xl2tpd with Openswan, you can use the built-in IPsec/l2tp VPN client software of Windows and OSX. No need for third party software on the client.

> OpenSWAN uses a highly baroque configuration syntax

I thought it followed pretty closely commonly used [ini file] type syntax :P

> some features are poorly documented

Such as? All options have been added to the man page in openswan 2.4.x

> and it sports cryptic error and debug messages (in debugging something simple
> like client authentication, you typically have to wade through hundreds of lines
> of messages largely devoted to OpenSWAN internals).

That is because you are not supposed to enable plutodebug= or klipsdebug= to debug configuration errors. With NO DEBUG enabled, you get to see all the log messages required for setting up a connection or finding out why it fails. The debug options are for developers to find code bugs. It is extremely rare that we need to ask a user to enable any of these for debugging. For every time we ask a user this, we ask 250 users to DISABLE their debugging so we can see their configuration problem.

> [openvpn offers] Giving the client an address on the local subnet using a
> software bridge

Use xl2tpd with IPsec to accomplish this too, but using the Windows/OSX standards

> OpenSWAN Server Configuration details:

your configuration is missing "rekey=no" on the server end.

rightsubnetwithin= is obsoleted and should be written as: rightsubnet=vhost:%no,%priv

Thanks for the article though, the rest looks very useful for people to run an openswan/openvpn based dual gateway.

[ Parent | Reply to this comment ]

Posted by Anonymous (193.110.xx.xx) on Fri 16 Nov 2007 at 16:37
And I forgot:

In config setup, there is a missing line:

virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/ 12,%v4:!192.168.1.0/24

That line specifies the allowed behind-NAT IP's of the roadwarrior. It excludes the IP range you use behind your server (note the !)

[ Parent | Reply to this comment ]

Posted by Anonymous (193.90.xx.xx) on Tue 20 Nov 2007 at 17:34
>> OpenSWAN uses a highly baroque configuration syntax
> I thought it followed pretty closely commonly used [ini file] type syntax :P
....
>virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16. 0.0/12,%v4:!192.168.1.0/24

While this might be standard ini-file _syntax_, I agree with the author that it is baroque/hard to read.

[ Parent | Reply to this comment ]

Posted by Anonymous (66.151.xx.xx) on Tue 20 Nov 2007 at 22:26
Once you try OpenVPN, there's no going back. It's so much easier to setup / maintain. And it's pretty much functionally equivalent to an IPSec-based VPN, minus the interoperability with IPSec devices.

[ Parent | Reply to this comment ]

Posted by ElizabethBevilacqua (72.94.xx.xx) on Tue 4 Dec 2007 at 14:18
Thank you for your comment. It's excellent to hear from an OpenSwan developer.

> We implement the RFC's, and even have a lot of workarounds for buggy
> implementations of IPsec. Openswan is probably the most compatible piece
> of IPsec software out there.

I certainly didn't mean to single out OpenSwan as being particularly bad with interoperability. IPSec implementations industry-wide vary greatly and lead to issues, I don't doubt your assertion that OpenSwan is one of the most compatible pieces of software out there.

>> some features are poorly documented
>
> Such as? All options have been added to the man page in openswan 2.4.x

One example we bumped into was rightca not being documented in the ipsec.conf man page. Please correct me if I'm looking in the wrong place.

> That is because you are not supposed to enable plutodebug= or klipsdebug=
> to debug configuration errors.

It wasn't precisely configuration errors, but rather connection debugging of things like discovering that openswan thinks that a client certificate is failing because the crl is expired or discovering the details about what the proposal mismatch between the two sides is.

> Use xl2tpd with IPsec to accomplish this too, but using the Windows/OSX
> standards

The last time we investigated l2tpd it wasn't quite ready for prime time, upon review it does seem like this could be quite useful for some users now.

Finally, thank you for your configuration improvements. We started this project on sarge systems where the configurations were slightly different, and quite a bit older.

[ Parent | Reply to this comment ]

Posted by Anonymous (85.2.xx.xx) on Tue 20 Nov 2007 at 18:48
What about the excellent package at

/usr/share/doc/openvpn/examples/easy-rsa/

I found it very easy to use. There is even an "ugly" script that let's you create new signed keys at once. Very useful in a more local setup!

[ Parent | Reply to this comment ]

Posted by Anonymous (216.158.xx.xx) on Wed 5 Dec 2007 at 14:36
If you read the article carefully, you will notice that extensive use of tools from easy-rsa are used and explained.

[ Parent | Reply to this comment ]

Posted by borthner (142.165.xx.xx) on Tue 27 Nov 2007 at 00:07
Another great package for handling certificates is TinyCA (tinyca.sm-zone.net) - which adds a simple-to-use GUI for certificate and key creation and management.

[ Parent | Reply to this comment ]

Posted by rayk_sland (216.232.xx.xx) on Wed 11 Jun 2008 at 23:47
I was wondering if you could elaborate on connecting to various routers you mentioned. For example I have some netgear 318v2's I'd really like to connect to openswan with x509 certs and all that good stuff.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 494 votes ~ 5 comments )

 

 

Related Links