Mastering OpenVPN

Chapter 1. Introduction to OpenVPN

The Internet in modern society is as ubiquitous as any public utility. When someone buys a home or moves into a new apartment, or a business moves into a new space, an Internet service is the first utility on the list to be ordered, followed by power, heat, trash, and maybe (but not likely) a land line or telephone service. You could even argue that the modern qualifier isn't even necessary. With programs such as One Laptop per Child, coupled with efforts by the likes of Facebook and Google, so-called third-world nations have the Internet where there is no running water, sewers, or even telephone services.

When you have such a wide-reaching service with so many individuals, at a certain point it will be necessary to secure and protect the data transmitted on that network. With most crowds and heavy concentrations of people, there is a more nefarious element looking to take advantage of those with less knowledge. Virtual Private Networks (VPNs) were created out of a greater need for secured communication across an otherwise unprotected infrastructure. The original large-scale network, ARPANET, had very little (if any) protection and authentication and all other nodes were inherently trusted. The network landscapes today are very different and even many casual, nontechnical users are aware of the lack of security of their connections.

Government agencies have long been targets for intelligence. For thousands of years, methods and procedures have been slowly perfected and tuned to protect sensitive information from enemies and other prying eyes. Initially, wax-sealed letters carried by trusted individuals meant you and the receiver could trust a message had arrived safely and untampered. As time and technology have progressed, it became easier to intercept those messages, read or alter them, and send them along their way.

World War II saw some of the greatest advances in cryptography and secure communications. From devices such as the German Enigma machine to the Navajo Code Talkers, communicating securely between troops and command was a never-ending arms race. Today, governments and militaries aren't the only groups with a desire for privacy. Corporations want to maintain data integrity and protection for payment card industry (PCI) standards to protect consumers. Family members want to discuss family matters over private channels, where the community at large isn't able to eavesdrop. Others wish to break through the national firewalls meant to oversee the populous and restrict content deemed controversial or against party politics.

Every day, most people use a VPN or have a use for a VPN, whether they realize it at the time or not. Many different VPN technologies exist, both from commercial vendors and as open source projects. One of the most popular pieces of open source VPN software is OpenVPN. The goal of this book is to make you an OpenVPN master; you will learn not just the technology behind it, but the reasoning, logic, and logistics of everything involved. While this book will mention and touch on the commercial offering from OpenVPN Technologies, Inc., Access Server, the primary focus will be on the open source/community version of OpenVPN.

What is a VPN?

Put simply, a VPN allows an administrator to create a "local" network between multiple computers on varying network segments. In some instances, those machines can be on the same LAN, they can be distant from each other across the vast Internet, or they can even be connected across a multitude of connection media such as wireless uplinks, satellite, dial-up-networking, and so on. The P in VPN comes from the added protection to make that virtual network private. Network traffic that is flowing over a VPN is often referred to as inside the (VPN) tunnel, compared to all the other traffic that is outside the tunnel.

In the following figure, network traffic is shown as it traditionally traverses across multiple network segments and the general Internet. Here, this traffic is relatively open to inspection and analysis. Though protected protocols such as HTTPS and SSH are less vulnerable, they are still identifiable; if an attacker is snooping network traffic, they can still see what type of connection is made from which computer to which server.

When a VPN is used, the traffic inside the tunnel is no longer identifiable.

The traffic within a VPN can be anything you would send over a local or wide-area network: web traffic, e-mail, text, graphics, and so on. Examples of some applications include the following:

Automated Teller Machines: ATMs may use a VPN to connect more securely to banking systems.
Open / Free Wi-Fi: With the proliferation of free or open wireless networks, everyday users can utilize a VPN to protect the entirety of their Internet browsing.
Corporate networks: Corporations and other organizations may use a VPN to connect multiple office locations or even entire data centers.
GeoIP / Location-based services: Some websites serve data based on geographic location by using GeoIP databases and other records. A VPN can allow you to "bounce" through another machine in a location closer to the content you really want. Internet video services such as Hulu, YouTube, and Netflix are common examples of this.
Bypassing censorship / Political freedom: Some regimes, such as North Korea or China, have extraordinarily restrictive censorship rules. The "Great Firewall of China" is one extreme example. The lockdowns of Internet access during political uprisings such as the "Arab Spring" attempt to contain and control reports outside the conflict. VPNs can aid in getting outside those restrictive rules to the greater Internet.

Here is an example of the traffic within a VPN. While the VPN itself is routed across the Internet like in the preceding figure, devices along the network path only see VPN traffic; those devices are completely unaware of what is being transmitted inside the private tunnel. Protected protocols, such as HTTPS and SSH, will still be protected inside the tunnel from other VPN users, but will be additionally unidentifiable from outside the tunnel. A VPN not only encrypts the traffic within, it hides and protects individual data streams from those outside the tunnel.

It should be noted that the preceding figure shows both the strengths and one of the greatest threats of VPN technologies. The VPN tunnel is dug through routers and firewalls on both sides. Thus, all the network traffic that is flowing via the VPN tunnel is bypassing the regular network defenses, unless special measures are taken to police the VPN traffic.

Most VPN implementations utilize some form of encryption and, additionally, authentication. The encryption of the VPN ensures that other parties that may be monitoring traffic between systems cannot decode and further analyze otherwise sensitive data. Authentication has two components, each in a different context.

First, there is user or system authentication that ensures those connecting to the service are authorized. This type of authentication may be in the form of per-user certificates, or a username/password combination. Further, rules specific to a given user can be negotiated such as specific routes, firewall rules, or other scripts and utilities. Typically, these are unique to a single instance, though even that can be configurable (when OpenVPN is used, see --duplicate-cn).

The second component of authentication is added protection to the communication stream. In this case, a method of signing each packet sent is established. Each system verifies the VPN packets it receives are properly signed before decrypting the payload. By authenticating packets that are already encrypted, a system can save processing time by not even decrypting packets that do not meet the authentication rules. In the end, this prevents a very real potential Denial of Service (DoS) attack, as well as thwarting Man in the Middle (MITM) attacks, assuming the signing keys are kept secure!

Types of VPNs

There are many VPN products available on the market, both commercial and open source. Almost all of these VPN products can be separated into the following four categories:

PPTP-protocol based VPNs
IPSec-protocol based VPNs
SSL-based VPNs
OpenVPN

Some people argue that OpenVPN is also an SSL-based VPN, as it uses an SSL or TLS-like protocol to establish a secure connection. However, we have created a separate category for OpenVPN, as it is different from almost every other SSL-based VPN solution.

We will now go into more detail about each of the four types of VPNs:

PPTP

One of the oldest VPN protocols is the Point-to-Point Tunneling Protocol (PPTP) developed by Microsoft and Ascend in 1999. It is officially registered as RFC2637 (see https://www.ietf.org/rfc/rfc2637.txt for the full standard). The PPTP client has been included in Windows ever since 1995 and is still included in most operating systems.

Nowadays, the PPTP protocol is considered fundamentally insecure, as the strength of the security of the connection is directly related to the strength of the authentication mechanism chosen (for example, the password). Thus, an insecure password leads to an insecure VPN connection. Most PPTP setups use the MS-CHAPv2 protocol for encrypting passwords, and it is this protocol which is fundamentally broken. The security of the PPTP protocol, including the Microsoft MS-CHAPv2 extensions, has been discussed in the article available at https://www.schneier.com/paper-pptpv2.html.

It is also possible to use X.509 certificates for securing a PPTP connection, which does lead to a fairly secure connection. However, not all PPTP clients support EAP-TLS, which is needed to allow the use of X.509 certificates.

PPTP uses two channels, a control channel for setting up the connection and another channel for data transport. The control channel is initiated over TCP port 1723. The data channel uses the General Routing Encapsulation (GRE) protocol, which is IP protocol 47. For comparison, "regular" TCP/IP traffic is done using IP protocol 6 (TCP) and 17 (UDP).

PPTP clients are available on almost all operating systems, ranging from Windows to Linux and Unix derivatives to iOS and Android devices.

IPSec

The IPSec standard is the official IEEE/IETF standard for IP security. It is officially registered as RFC2411 (see https://www.ietf.org/rfc/rfc2411.txt for the full standard). IPSec is also built into the IPv6 standard.

IPSec operates at layer 2 and 3 of the OSI model of the network stack. It introduces the concept of security policies, which makes it extremely flexible and powerful, but also notoriously hard to configure and troubleshoot. Security policies allow an administrator to encrypt traffic between two endpoints based on many parameters, such as the source and destination IP address, as well as the source and destination TCP or UDP ports.

IPSec can be configured to use pre-shared keys or X.509 certificates to secure the VPN connection. Additionally, it uses either X.509 certificates, one-time passwords, or username/password protocols to authenticate the VPN connection.

There are two modes of operation in IPSec: tunneling mode and transport mode. Transport mode is used most often in combination with the Level 2 Tunneling Protocol (L2TP). This L2TP protocol performs the user authentication as described in the preceding section. The IPSec clients built into most operating systems usually perform IPSec+L2TP, although it is also possible to set up an IPSec-only connection. The IPSec VPN client built into Microsoft Windows uses IPSec+L2TP by default, but it is possible to disable or bypass it. However, this involves cryptic commands and security policy changes.

Like PPTP, IPSec also uses two channels: a control channel for setting up the connection and one for data transport. The control channel is initiated over UDP port 500 or 4500. The data channel uses the Encapsulated Security Payload (ESP) protocol, which is IP protocol 50. For comparison, "regular" TCP/IP traffic is done using IP protocol 6 (TCP) and 17 (UDP). The integrity of IPSec packets is ensured using Hash-based Message Authentication Code (HMAC), which is the same method that OpenVPN uses.

One of the main disadvantages of IPSec is that many vendors have implemented extensions to the standard, which makes it hard (if not impossible) to connect two IPSec endpoints from different vendors.

IPSec software is included in almost all operating systems, as well as firewall, router, and switch firmware.

SSL-based VPNs

The most commonly used VPNs nowadays are SSL-based VPNs, which are based on the SSL/TLS protocol. SSL-based VPNs are often called client-less VPNs or web-based VPNs, although there are some vendors that provide separate client software, such as Cisco AnyConnect and Microsoft SSTP. Most SSL-based VPNs use the same network protocol as is used for secure website (HTTPS), while OpenVPN uses a custom format for encrypting and signing data traffic. This is the main reason why OpenVPN is listed as a separate VPN category.

There is no well-defined standard for SSL-based VPNs, but most use the SSL/TLS protocol to set up and secure the connection. The connection is secured in most cases by using X.509 certificates, with one-time password or username/password protocols for authenticating the connection. SSL-based VPNs are very similar to the connections used to secure websites (HTTPS) and the same protocol and channel (TCP and port 443) is often used.

Even though SSL-based VPNs are often called web-based or client-less, there are quite a few vendors that use a browser plugin or ActiveX control to "enhance" the VPN connection. This makes the VPN noninteroperable with unsupported browsers or operating systems.

OpenVPN

OpenVPN is often called an SSL-based VPN, as it uses the SSL/TLS protocol to secure the connection. However, OpenVPN also uses HMAC in combination with a digest (or hashing) algorithm for ensuring the integrity of the packets delivered. It can be configured to use pre-shared keys as well as X.509 certificates. These features are not typically offered by other SSL-based VPNs.

Furthermore, OpenVPN uses a virtual network adapter (a tun or tap device) as an interface between the user-level OpenVPN software and the operating system. In general, any operating system that has support for a tun/tap device can run OpenVPN. This currently includes Linux, Free/Open/NetBSD, Solaris, AIX, Windows, and Mac OS, as well as iOS/Android devices. For all these platforms, client software needs to be installed, which sets OpenVPN apart from client-less or web-based VPNs.

The OpenVPN protocol is not defined in an RFC standard, but the protocol is publicly available because OpenVPN is a piece of open source software. The fact that it is open source actually makes OpenVPN more secure than closed-source VPNs, as the code is continually inspected by different people. Also, there is very little chance of secret backdoors being built into OpenVPN.

OpenVPN has the notion of a control channel and a data channel, both of which are encrypted and secured differently. However, all traffic passes over a single UDP or TCP connection. The control channel is encrypted and secured using SSL/TLS, the data channel is encrypted using a custom encryption protocol.

The default protocol and port for OpenVPN is UDP and port 1194. Before IANA granted OpenVPN an official port assignment, older clients (2.0-beta16 and older) defaulted to port 5000.

Comparison of VPNs

Each of the different VPN technologies has its own characteristics, advantages, and disadvantages. Even though this book is about OpenVPN, there are use-cases where, for example, an IPSec-based VPN is more suitable, depending on the requirement of the users.

Advantages and disadvantages of PPTP

The main advantage of PPTP-based VPNs is that the VPN client software is built into most operating systems. Also, the startup time for configuring and initializing a PPTP VPN connection is quite short.

Disadvantages of PPTP-based VPNs are the lack of security and the lack of configuration options on both the client and server side. Furthermore, the EAP-TLS extension that enables the use of X.509 certificates is fully supported only on Microsoft Windows, although a patch exists for the open source pppd package to enable EAP-TLS support. The pppd package is included in almost every Linux distribution. Also, if one must resort to using EAP-TLS, then the ease of setting up a PPTP VPN is greatly diminished. This is because EAP-TLS requires setting up a public key infrastructure, just like IPSec and OpenVPN.

Another major disadvantage of PPTP is the use of the GRE protocol, which does not integrate well with NAT'ing devices.

Advantages and disadvantages of IPSec

Advantages of the IPSec protocol are its strong security, good support from different vendors and platforms, including xDSL and Wi-Fi routers, as well as the ability to use fine-grained security policies to control the flow of traffic.

The downsides of IPSec are that it is notoriously difficult to configure and troubleshoot, different IPSec implementations from different vendors do not play nicely together, and IPSec does not integrate well with NAT'ted networks. Most notably, it is not recommended, and sometimes not even possible, to run an IPSec server that is on a NAT'ted network.

Advantages and disadvantages of SSL-based VPNs

SSL-based VPNs, or web-based VPNs, have the advantage of there being no or very little client software involved. This makes installation and initialization on the client side very easy.

The disadvantage of a web-based VPN is that it is often not a full-blown VPN and allows access to a single server or set of servers. Also, it is harder to share local data with the remote site or server.

Advantages and disadvantages of OpenVPN

Advantages of OpenVPN are its ease of deployment, its configurability, and the ability to deploy OpenVPN in restricted networks, including NAT'ted networks. Also, OpenVPN includes security features that are as strong as IPSec-based solutions, including hardware token security and support for different user authentication mechanisms.

Disadvantages of OpenVPN are its current lack of scalability and its dependence on the installation of client-side software. Another disadvantage is the lack of a GUI for configuration and management. Notably the tap interface driver for Microsoft Windows has often caused deployment issues when a new version of Windows is released.

History of OpenVPN

OpenVPN was originally written by James Yonan with an initial release, Version 0.90, in 2001 under the GPL. The initial release allowed users to create a simple point-to-point VPN over UDP using the Blowfish cipher and, optionally, the SHA1 HMAC signature. With Version 1.0, TLS-based authentication and key exchange was added along with a man page.

Improvements for OpenVPN 1.x included better TLS support, replay protection, and porting to other operating systems. Some ports included OpenBSD, Mac OS, and better packaging for RedHat. Prior to Version 1.1.1, the tun device had to be configured manually outside OpenVPN. This release added the --ifconfig option, which automatically configured the tun device, greatly simplifying the overall configuration.

The 1.x series was relatively crude compared to the current OpenVPN Version, 2.3.8, as would be expected of a new project. One primary hurdle was the integration of OpenSSL. As OpenSSL was notorious for its poor or completely absent documentation, the developer had to go directly to the source code to integrate the project with OpenVPN. License changes were also required early on to allow the more-specific GNU Public Licensed code to link against the non-GPL OpenSSL library. Those issues were worked out and feature additions were prominently present in the change log throughout the 1.x series.

Some notable updates in the 1.x series include:

2001.05.13 (0.90): This was the initial release
2002.03.23 (1.0): This allowed TLS authentication and key exchange
2002.04.09 (1.1.0): This had a OpenBSD port and OpenSSL linking
2002.04.22 (1.1.1): This had the --ifconfig option
2002.05.22 (1.2.0): This had configuration files (instead of just command-line options, pthread support, and a Solaris port)
2002.07.10 (1.3.0): This had better FreeBSD support and logging improvements
2002.10.23 (1.3.2): This had initial IPv6 support and more FreeBSD improvements
2003.05.07 (1.4.0): This included MTU features
2003.07.24 (1.5-beta1): This had TCP support
2003.11.03 (1.5-beta13): This had support for configuration parameters --http-proxy, --redirect-gateway, and --crl-verify
2004.02.01 (1.6-beta5): This had the SOCKS5 proxy and IPv6 on FreeBSD
2004.05.09 (1.6.0): This is the final 1.x release

OpenVPN 2.0 has seen great advances from the 1.x releases. With 2.0, effort was put in to provide multiclient server instances, improved threading, and a better Windows tun/tap adapter. Development for 2.0 overlapped 1.x for over a year, with initial test releases for 2.0 dating back to November 2003 and the final 1.x release not arriving until May 9, 2004. When it was finally released, 2.0 saw 29 test releases, 20 beta releases, and 21 release candidates over a year and a half of effort (November 2003 to April 2005).

Some key features of the 2.0 release, in comparison to 1.6.0, are as follows:

It allows a server instance to accept connections from multiple clients
It enables the server-side config option push to clients (--push/--pull)
It allows username/password authentication
It supports chroot and the downgrading of daemon privileges (--user/--group/--chroot)
It supports client connect scripts
It has a management interface
The inception of Easy-RSA

Development from 2.0 to 2.0.9 mostly consisted of bug fixes and corrections for a few security vulnerabilities. Apart from some sporadic contributions from a few others, OpenVPN was primarily developed by James up to and into the 2.1 release. 2.0.9 remained a stagnant official release from October 2006 until Version 2.1.0 in December 2009.

OpenVPN 2.1 was the first major release with a notable amount of code written by someone other than James Yonan. Alon Bar-Lev has many significant contributions dating back to 2.1-beta3 with many patches for cryptography support and corrections. Considered the first real community release, 2.1 saw much work in the core code base involving the management interface and network addressing. Some notable release notes include the following:

2005.11.12 (2.1-beta7): The ca, cert, key, and dh files could be specified inline in the configuration file.
2006.01.03 (2.1-beta8): The --topology subnet was added.
2006.02.16 (2.1-beta9): Port sharing was allowed so that OpenVPN and HTTPS could share a port.
2008.09.10 (2.1_rc10): Warn if the common 192.168.0.0/24 or 192.168.1.0/24 subnets are used. --server-bridge was added for DHCP proxy support.
2010.08.09 (2.1.2): It had a Python-based Windows build system, with improved handling of AUTH_FAIL for the management interface.
2010.11.09 (2.1.4): This was the final release of the 2.1 series.

In August 2008, there had been no official release since 2.0.9. Additionally, there was very little community support apart from the mailing list. There was interest in building a community and Krzee King and Eric Crist pushed to build one around the project. Initially, all effort was directed at supporting users.

As the group of individuals supporting OpenVPN grew, it attracted folks who could write good code. Contact was made with OpenVPN Inc., with the goal to not only provide better levels of support for OpenVPN, but to also build and extend the software James had written, but the efforts of the cooperation were rebuffed.

Talks began on Internet Relay Chat (IRC) which is a communication tool preferred by many developers for porting the project so that advancements could be made. Development began; some members managed IRC and helped on the mailing lists. Others built a source repository, wiki, and a web forum. The average usage was roughly 2 posts per day on the forum and about 8 users on IRC.

In early 2009, OpenVPN technologies hired Samuli Seppänen to help build and interact with the open source community. Samuli has been instrumental in forging a solid relationship between the corporation and the enthusiasts and volunteers. A strong community has been built around the project. Today, the forum averages 16 posts per day (more than 35,000 messages in total), and IRC fluctuates between 150 and 250 users on any given day.

OpenVPN 2.2 was the first release after the switch to a more community-oriented development model. After hashing out a development model and a direction, the community wanted to move with the project and work started right away.

Initially, for OpenVPN 2.2, James was still in overall control of what was merged into the main source tree, as the tree was still managed using subversion at OpenVPN Technologies. Later, the source tree was migrated to GIT and the roles reversed, where James' changes were accepted and merged into the open source project tree.

The notable changes in OpenVPN 2.2 were:

SOCKS plaintext authentication
Improved platform support for --topology subnet
The tap mode on Solaris
Windows build compiled with ENABLE_PASSWORD_SAVE enabled
Windows IPv6 tun support
Client certificates could be omitted with behavior similar to a web browser (--client-cert-not-required)
Client certificates could now indicate a separate username instead of using the certificate common name (--x509-username-field)
Support was removed for Windows 2000 and earlier
2011.04.26 Version 2.2.0 was released
2011.07.06 Version 2.2.1 was released with minor changes, mostly build/install related
2011.12.22 Version 2.2.2 was released with Windows tap driver changes

OpenVPN 2.3 is the beginning of a major turn in build structure within OpenVPN. The end goal, in a nutshell, is to create a more extensible and plugin-friendly source. With the build for mobile platforms such as Android and iOS already requiring a ground-up rewrite, James and other developers cleaned up older code in favor of more compact and normalized functions. Those rewrites are done in C++, as opposed to the current C language used.

While listed in the change log of past revisions, IPv6 support, both as a payload as well as for transit in OpenVPN, did not really mature until the 2.3 release. The vast majority of the IPv6 contributions were a result of hard work by Gert Döring.

Another important feature of the 2.3 release was the addition of PolarSSL support. PolarSSL is an alternative cryptographic library to OpenSSL and OpenVPN can now be built against either library. This topic is discussed in greater detail later in this chapter.

The list of improvements and additions for the 2.3 release is vast, but the highlights are as follows (the full change log is at https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23):

Cross-platform IPv6 support (transit AND payload)
New plugin API
Support for building against PolarSSL, and ground work for other potential alternatives
Clients can now inform the server of LZO support, and the server can automatically disable LZO for that client
Workaround for local routing conflicts (--client-nat)
A new --crl-verify directory mode, files named as common names disable certificates as if they were revoked
Certificate UTF-8 support for certificate fields
Project split for various subprojects:
- OpenVPN core project
- tap-windows
- Easy-RSA
- OpenVPN build system
Kill client connections from the management interface

Version 2.3.8 was most recent release at the time of writing.

OpenVPN packages

There are several OpenVPN packages available on the Internet:

The open source or community version of OpenVPN
OpenVPN Access Server, the closed-source commercial offering by OpenVPN Inc.
The mobile platform versions of OpenVPN for both Android and iOS (part of the code is closed-source, as a requirement of Apple)

The open source (community) version

Open source versions of OpenVPN are made available as each release is published. The community has resources to build binary packages for multiple platforms, including both 32-bit and 64-bit Windows clients. The currently available download options are available at http://openvpn.net/index.php/download/community-downloads.html.

Some operating system package maintainers track development and make snapshot releases available. FreeBSD, for example, has a security/openvpn-devel port that tracks weekly tarball snapshots from OpenVPN development. If you'd like to run the latest and greatest bleeding-edge version of OpenVPN, look at your package maintainer first. Otherwise, you can always build directly from source.

The community version of OpenVPN can act both as a VPN server and as a VPN client. There is no separate client-only version.

The closed source (commercial) Access Server

OpenVPN Technologies, Inc. offers a commercial version of OpenVPN called Access Server. Compared to the open source project, Access Server offers many features and deployment options that may appeal to some organizations. Access Server is a paid product, but a trial with two license keys enabled is available from the website.

Software packages, virtual appliances, and cloud services are all available from OpenVPN Technologies, Inc. at https://openvpn.net/index.php/access-server/overview.html.

OpenVPN Access Server includes its own OpenVPN client, OpenVPN Connect, for both Windows and Mac OS. This client software generally works only with OpenVPN Access Server. It is also possible to use the community version of OpenVPN as a client for an OpenVPN Access Server.

The mobile platform (mixed) OpenVPN/OpenVPN Connect

For mobile devices, such as iPhones/iPads and Android devices, OpenVPN Technologies, Inc., provides a special OpenVPN Connect Client. OpenVPN Technologies, Inc., and James specifically put a lot of effort and legal wrangling with the likes of Google and Apple to get access to a usable VPN API on each platform.

Due to the nature of Apple's NDA, currently, the source for OpenVPN Connect is unavailable and cannot be shared publicly. The iOS OpenVPN Connection client can be downloaded from the Apple App Store at https://itunes.apple.com/us/app/openvpn-connect/id590379981?mt=8.

There are Android clients written by a few developers, but the officially supported version is OpenVPN for Android, written by Arne Schwabe, which can be found at https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en.

OpenVPN Connect, written by OpenVPN Technologies, Inc., is also available. You can download the Android OpenVPN Connect client at https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=en.

One serious advantage of OpenVPN Connect is that it supports / is supported by both the community version of OpenVPN, as well as the closed-source OpenVPN Access Server. If you have a need to access both types of servers, OpenVPN Connect is recommended.

Other platforms

There are some hardware vendors attempting to integrate support for OpenVPN within their devices. Some offer firmware versions for the VoIP phones that include an older version of OpenVPN. Other firmware projects, such as DD-WRT for Linksys routers, as well as other projects such as FreeNAS, pfSense, and others, also integrate OpenVPN.

OpenVPN internals

The design of OpenVPN is not extensively documented, but most of the internals of OpenVPN can be discovered by looking at the source code.

The tun/tap driver

One of the basic building blocks of OpenVPN is the tun/tap driver. The concept of the tun/tap driver comes from the Unix/Linux world, where it is often natively available as part of the operating system. This is a virtual network adapter that is treated by the operating system as either a point-to-point adapter (tun-style) for IP-only traffic or as a full virtual Ethernet adapter for all types of traffic (tap-style). At the backend of this adapter is an application, such as OpenVPN, to process the incoming and outgoing traffic. Linux, Free/Open/NetBSD, Solaris and Mac OS include a tun kernel driver, which is capable of both tun-style and tap-style operations. Recently, a similar driver was added to AIX, which is IBM's Unix derivative.

For Microsoft Windows, a special NDIS driver was written by James Yonan, called the TAP-WIN32 adapter. At the moment, the NDIS5 and NDIS6 versions of the driver are available, supporting Windows XP through Windows 8.1. The development of this adapter is now officially separated from the main OpenVPN development, but OpenVPN continues to rely heavily on it.

The flow of traffic from a user application via OpenVPN is depicted in the preceding diagram. In the diagram, the application is sending traffic to an address that is reachable via the OpenVPN tunnel. The steps are as follows:

The application hands over the packet to the operating system.
The OS decides using normal routing rules that the packet needs to be routed via the VPN.
The packet is then forwarded to the kernel tun device.
The kernel tun device forwards the packets to the (user-space) OpenVPN process.
The OpenVPN process encrypts and signs the packet, fragments it if necessary, and then hands it over to the kernel again to send it to the address of the remote VPN endpoint.
The kernel picks up the encrypted packet and forwards it to the remote VPN endpoint, where the same process is reversed.

It can also be seen in this diagram that the performance of OpenVPN will always be less than that of a regular network connection. For most applications, the performance loss is minimal and/or acceptable. However, for speeds greater than 1GBps, there is a performance bottleneck, both in terms of bandwidth and latency.

It should be noted that the performance of the Windows driver is much lower than the performance of the native tun/tap adapters found in other operating systems. This is true even with the most recent NDIS6 implementation of the TAP-Win32 driver. For a single OpenVPN client, the impact is fairly small. For a large-scale OpenVPN server that serves many clients, this can easily cause performance issues. This is one of the main reasons that the open source community normally recommends the use of a Unix- or Linux-based host as the OpenVPN server.

The UDP and TCP modes

OpenVPN currently supports two ways to communicate between endpoints: using UDP packets or using TCP packets. UDP is a connectionless or lossy protocol; if a packet is dropped in transit, then the network stack does not transparently correct this. TCP packets are a connection-oriented protocol; packets are sent and delivered using a handshake protocol, ensuring the delivery of each packet to the other side.

Both modes of communication have their advantages and disadvantages. It actually depends on the type of traffic that is sent over the VPN tunnel to determine which mode of communication is best. Using a TCP-based application over a TCP-based VPN can result in double performance loss, especially if the underlying network connection is bad. In that case, a re-transmittance of lost packets is done for packets lost both inside and outside the tunnel, leading to a double performance hit. This is explained nicely in the article Why TCP over TCP is a Bad Idea at http://sites.inka.de/~W1011/devel/tcp-tcp.html.

However, it can be similarly argued that sending UDP over UDP is also not a good idea. If an application using UDP for its traffic is susceptible to message deletion or packet reordering attacks, then an underlying encrypted TCP connection will enhance the security of such applications even more than an underlying UDP-based VPN. If the bulk of traffic over the VPN is UDP-based then it is sometimes better to use a TCP connection between VPN endpoints.

When choosing between UDP or TCP transport, the general rule of thumb is as follows: if UDP (mode udp) works for you, then use it; if not, then try TCP (mode tcp-server and mode tcp-client). Some switches and routers do not forward UDP traffic correctly, which can be an issue especially if multiple OpenVPN clients are connected to the same switch or router. Similarly, the performance of OpenVPN over TCP can be severely affected by the choice of Internet Service Providers (ISPs): some ISPs use odd MTU sizes or packet fragmenting rules, resulting in extremely poor performance of OpenVPN-over-TCP compared to nonencrypted TCP traffic.

The encryption protocol

It has been said that OpenVPN implements TLS over UDP. This is more or less true, but the way OpenVPN uses TLS is different from the way a web browser uses it. Thus, when OpenVPN is run over TCP (using port 443 is a common method to duck firewalls), the traffic is distinguishable from normal TLS traffic. A firewall that uses Deep Packet Inspection (DPI) can easily filter out OpenVPN traffic.

The main difference between OpenVPN-TLS and browser-TLS is the way packets are signed. OpenVPN offers features to protect against DoS attacks by signing the control channel packets using a special static key (--tls-auth ta.key 0|1). Data channel packets, which are sent over the same UDP or TCP connection, are signed completely differently and are very readily distinguished from HTTPS traffic. The OpenVPN website (http://openvpn.net) depicts how packets are encrypted for UDP transport, which is illustrated below.

The same mechanism is used for TCP transport (http://openvpn.net/index.php/open-source/documentation/security-overview.html).

This is also the main reason why port-sharing, where OpenVPN and a secure web server share the same IP address and port number, can actually work.

The control and data channels

OpenVPN uses two virtual channels to communicate between the client and server:

A TLS control channel to exchange configuration information and cipher material between the client and server. This channel is used mostly when the VPN connection is started, as well as for exchanging new encryption keying material. This keying material is renewed after a certain period (based on the --reneg-sec, --reneg-bytes, or --reneg-pkts options).
A data channel over which the encrypted payload is exchanged.

The exception to this is the older pre-shared key point-to-point mode, in which only the data channel is used.

Encryption and authentication (signing) for the control channel and the data channel are determined differently. The control channel is initiated using a TLS-style protocol, similar to how a secure website connection is initiated. During control channel initialization, the encryption cipher and hashing algorithm are negotiated between the client and server.

Encryption and authentication algorithms for the data channel are not negotiable, but they are set in both the client and server configuration files for OpenVPN. The current default settings are Blowfish as the encryption cipher and SHA1 as the hashing algorithm. The ability to also negotiate cipher and hashing algorithms for the data channel are high on the wish list of the development team, but this requires an extensive change to the code.

Ciphers and hashing algorithms

OpenVPN supports a wide range of encryption ciphers and hashing algorithms. The ciphers are used to encrypt the payload, while the HMAC function makes use of a digest or hashing algorithm to authenticate incoming packets. As OpenVPN uses a control channel and a data channel, there are two sets of ciphers and hashing algorithms that can be configured.

The control channel cipher and hashing algorithms are normally negotiated at startup. The list of available combinations of ciphers and hashing algorithms can be displayed using the following command:

$ openvpn --show-tls

The available TLS Ciphers listed in order of preference:

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384
[…]

This output was retrieved on a CentOS 6 host using the OpenSSL 1.0.1e library.

The available combinations depend largely on the exact version of the SSL library used. You can specify a list of tls-ciphers in the OpenVPN configuration file in a manner that is very similar to configuring the Apache mod_ssl module:

tls-cipher  TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-       
            WITH-AES-256-CBC-SHA384
:TLS-ECDH-RSA-WITH-AES-256-GCM-
            SHA384

List all ciphers on a single line; the preceding output was modified for readability.

For the data channel, the encryption cipher and hashing algorithm are controlled using the --cipher and --auth options. If the cipher and authentication algorithm are not specified, then the default values of bf-cbc and sha1 are used, respectively.

To retrieve the list of available encryption ciphers, use the following command:

$ openvpn --show-ciphers

The following ciphers and cipher modes are available for use with OpenVPN. Each cipher shown here may be used as a parameter to the --cipher option. The default key size is shown regardless of, whether or not it can be changed with the --keysize directive. Using a CBC mode is recommended. In a static key mode, only a CBC mode is allowed:

[…]
BF-CBC 128 bit default key (variable)
BF-CFB 128 bit default key (variable) (TLS client/server mode)
BF-OFB 128 bit default key (variable) (TLS client/server mode)
[…]
AES-128-CBC 128 bit default key (fixed)
AES-128-OFB 128 bit default key (fixed) (TLS client/server mode)
AES-128-CFB 128 bit default key (fixed) (TLS client/server mode)
AES-192-CBC 192 bit default key (fixed)
AES-192-OFB 192 bit default key (fixed) (TLS client/server mode)
AES-192-CFB 192 bit default key (fixed) (TLS client/server mode)
AES-256-CBC 256 bit default key (fixed)
AES-256-OFB 256 bit default key (fixed) (TLS client/server mode)
AES-256-CFB 256 bit default key (fixed) (TLS client/server mode)
[…]

In this output, only the most commonly-used ciphers are shown. The list of available ciphers again depends on the exact version of the underlying crypto library. However, in most cases, the Blowfish (BF-*) and AES (AES-*) ciphers should be available.

Similarly, for the authentication (HMAC-signing) algorithms, we use the following command to list all the available options:

$ openvpn --show-digests

The following message digests are available for use with OpenVPN. A message digest is used in conjunction with the HMAC function to authenticate received packets. You can specify a message digest as a parameter to the --auth option:

[…]
SHA 160 bit digest size
SHA1 160 bit digest size
[…]
ecdsa-with-SHA1 160 bit digest size
[…]
SHA256 256 bit digest size
SHA384 384 bit digest size
SHA512 512 bit digest size
SHA224 224 bit digest size

In this output, only the most commonly-used digests or hashing algorithms are shown. The list of available digests depends on the exact version of the underlying crypto library. In most cases, the SHA-1 and SHA-2 family of hashing algorithms should be available.

OpenSSL versus PolarSSL

Starting with OpenVPN 2.3, support for a new SSL library has been added. The PolarSSL library (http://polarssl.org) can be compiled in instead of the default OpenSSL library. The main reason for adding a second library was to ensure the independence of the underlying encryption libraries and to ensure that no copyright issues would arise, as the OpenSSL copyright license is different from the one that OpenVPN uses.

Filter reviews by

All

Amazon verified reviews

Hugo Nov 16, 2015

VPN is an exciting topic for me, but I've had difficult to use it, I was searching for this but some information that I've found aren't for beginners, or are just bad resources, this book explain since the basic concepts, throughout the differences between VPN's, the new features and we know that when we deal with security we have to use the most updated resource, this book gives me a handfull knowledge about OpenVPN, I am not a professional yet, but all the things this book show makes me understand and feel confortable about its configurations, I know that real life projects must be more problematic, but I enjoyed every chapter, I don't had used BSD in the past so I just tried on my Linux and Windows house machines network, I liked the usage in mobile devices and home routers since this is my actual needs, and the part of the log files, even following the book I've missed few details during the configuration, and this log files are hard to me before.

Amazon Verified review

flying_phoenix Sep 19, 2015

Love reading the book. Learned a lot about configuring OpenVPN

Totempole Oct 18, 2015

This is the go-to book for going from learning everything about OpenVPN. Not only that, but it walks you through the basics, it tells you what a VPN is, the types of VPNs, their pros and cons. This is the book for everyone looking into mastering OpenVPN, from the home user (setting it up in your own router, and using your mobile devices as clients) to the network admin (client/server setup).

Matteo Guglielmi Oct 10, 2015

Finally a comprehensive and up-to-date book (Aug. 2015) on OpenVPN. The concepts and available options behind the implementation of virtual private networks using OpenVPN are well explained and worked out with several examples. The book is complete and self-contained. No previous knowledge on OpenVPN is required. Personally, I found Chapter 7 (Scripting and Plugins) extremely helpful: understanding the exact order in which all different scripts are executed is what helped me the most with the implementation of (powerful!) vpn solutions. The book has few typos in some of the worked out examples but they can easily be spotted out.

Carles Oct 14, 2015

This book is targeted to system administrators willing to deploy an extra layer of security for his users or customers which need to access private infraestructures from the internet using OpenVPN software. This book it's written in plain language and goes straight to the point but a good knowledge on networking is advised to get the most out of the book. The book can be used as a complete guide to deploy the service from the ground or to strengthen security or fine tune already existing VPN scenarios. The book also gives recommendations on how to scale in the future and be aware of possible weaknesses of the system. In overall it's a very good source of information on this matter and I recommend it without any doubt.