Businesses often need to give their road warriors access to the enterprise IT, and some private users also appreciate the ability to "phone home." With an increasing numbers of households depositing their personal documents on large networked drives, it's little wonder that many people need to be able to access their data at home via VPN when they are on the road. However, what should be your tool of choice for this task?

At one time, IPsec was more or less the standard in all things VPN; however, in the course of many years, OpenVPN has built up an excellent reputation for security and ease of use. When you finish installing Ubuntu 14.04, for example, all you need to do is add the openvpn package to operate an OpenVPN server. Moreover, OpenVPN is very easy to set up on the client side: Android comes with an OpenVPN client out of the box, and if you use iOS, you will find a matching tool in the App Store. Clients for Windows, Linux, and OS X are naturally also available. Ideally, establishing a working client-server setup with OpenVPN will take you just a few minutes.

Pritunl

Pritunl, built on the OpenVPN protocol, is sounding the attack: Pritunl simply promises to be the perfect VPN solution for practically any implementation and to exceed the functionality and convenience of OpenVPN alone. Can the program really offer more? Is it really as easy to install as OpenVPN? And, what about the Pritunl Enterprise products [1]?

Installing Pritunl is simple. The vendor offers its own software repositories for popular distributions, such as the current stable version of Debian and the current LTS release of Ubuntu, 14.04. The vendor also has something for RPM-based systems such as CentOS 7 or the current Fedora release. Installing is not difficult with these repositories: many of the guides [2] focus on enabling the repository locally and then using the package manager to install the Pritunl package.

When you install Pritunl, MongoDB is also installed as a mandatory requirement. Why does a VPN server need a database? As it turns out, Pritunl uses MongoDB to store and manage its own settings in the background. In scale-out environments with multiple Pritunl instances at multiple locations, the Pritunl servers exchange data about their configurations, and they use MongoDB to do so. The configuration back end for this kind of construct is easy to implement, thanks to the database – in particular because the database comes with its own cluster functionality.

Keeping configuration data in a database also is far more flexible than maintaining static configuration files, which you will not find with Pritunl: a fixed part of Pritunl is a web interface for handling the user-facing configuration. The settings configured in the web interface end up directly in MongoDB. Only a simple pritunl.conf file specifies the port on which to access the web interface and how Pritunl reaches its MongoDB data.

Directly after launching the program for the first time, Pritunl welcomes users with a wizard that walks them through the basic configuration. The tool asks for the MongoDB database name that you want to use. If you are installing on a single server, the defaults are fine. At the end, Pritunl writes its own pritunl.conf based on your details. All told, the entire Pritunl setup takes less than five minutes.

User Management

The Pritunl web interface also lets you handle user management, which only exists locally. However, it has another trick up its sleeve: Pritunl supports single sign-on (SSO) authentication based on the Google authorization system.

If you have a Google account, you use the same approach for Pritunl as for logging into other web services with your account. In the login window, you choose to use SSO to authenticate against Google. In the next step, you let Pritunl receive the Google registration confirmation. Once the user has logged in to Google, they are also viewed as logged in to Pritunl.

When the administrator then assigns the users created in this way to one of the "organizations" (I'll come back to that later), the VPN connection is opened. This removes the annoyance of separate VPN access data, but only – and this is the unfriendly bit – if you decide to go for the Enterprise subscription.

Summoning a Server

The web interface not only lets you manage users, but also the VPN instances that you want to launch. Installing and configuring Pritunl does not automatically run a VPN server, as is the case with OpenVPN. Instead, the admin needs to start the VPN connection. Admins assign existing users to organizations (Figure 1), which allows an arbitrary number of servers in the Free Edition; however, the number of VPN servers per host is restricted to one.

Figure 1: Pritunl thinks in terms of users and organizations. For each Pritunl instance, you can manage several of each.

Compared with OpenVPN, this is extremely convenient: If you want to operate multiple OpenVPN instances on a single host, you are forced to manage the configuration files manually. Moreover, launching multiple VPN connections per host at the same time requires some tinkering with the configuration. Pritunl hides the complete configuration overhead behind the scenes of the web interface.

By default, individual VPN servers are isolated at the host's interface level. On the one hand, this gives enterprises the option of managing multiple VPN servers for different departments. On the other hand, the operator of a Pritunl instance can rest assured that multiple customers on the server do not see each other's traffic.