Paranoid Penguin - Linux VPNs with OpenVPN, Part II

Last month, I began a new series on how to build a Linux-based Virtual
Private Network (VPN) solution using OpenVPN. I described what VPNs are,
what they're used for, and I listed some popular ways of building VPNs
with Linux. That column ended with some pointers for obtaining
and installing OpenVPN.

This month, I continue with detailed instructions on how to build a quick-and-dirty single-user VPN connection that allows you to connect securely
from some untrusted remote site, like a coffee shop wireless hotspot,
back to your home network.

Quick Review

If you missed last month's column, here's a two-paragraph primer on
VPNs. First, they're generally used for two things: connecting different
networks together over the Internet and connecting mobile/remote
users to some corporate or home network from over the Internet. In the
first case, a VPN connection is usually “nailed”—that is, it stays
up regardless of whether individual users actually are sending traffic
over it. In the latter case, end users each create their own tunnels,
bringing them up only as needed.

Several protocols are in common use for VPNs. The two most important
of which are probably IPsec and SSL. IPsec is nearly always used to
create an “encrypted route” between two networks or between one system
and a network. In contrast, SSL, whether in the context of SSL-VPN
(which uses a Web browser as client software) or in other SSL-based
VPNs (like OpenVPN), can be used either to tunnel specific applications
or entire network streams.

IPsec and SSL-VPN are out of the scope of this series of articles,
which mainly concern OpenVPN. However, I will cover at least two
different remote-access usage scenarios: single-user and multiuser. A
later installment in this series may include site-to-site VPNs, which actually
are simpler than remote-access solutions and which use a lot of the same
building blocks. If I don't cover site-to-site VPNs, or if you need
to build one sooner than I get around to it here, you'll have little
trouble figuring it out yourself even after just this month's column!

The Scenario

Let's get busy with a simple scenario: setting up a single tunnel to
reach your home network from the local coffee shop (Figure 1).

Figure 1. Remote-Access Scenario

In this simple example, a laptop is connected to a wireless
hotspot in a coffee shop (Coffee Shop WLAN), which in turn is connected
to the Internet. The laptop has an OpenVPN established with a server on
the home network; all traffic between the laptop and the home network
is sent through the encrypted OpenVPN tunnel.

What, you may wonder, is the difference between the hardware and software
comprising the OpenVPN “server” versus that of the
“client”? As it
happens, the command openvpn can serve as either a
server dæmon or
client dæmon, depending on how you configure and run it. What hardware
you run it on is totally up to you, although obviously if you're going
to terminate more than a few tunnels on one server, you'll want an
appropriately powerful hardware platform.

In fact, if you need to support a lot of concurrent tunnels, you
may want to equip your server with one of the crypto-accelerator hardware
cards (“engines”) supported by OpenSSL (on which OpenVPN depends for
its cryptographic functions). To see which are supported by your local
OpenSSL installation, issue the command openvpn
--show-engines. See
the documentation at www.openssl.org for more information on its
support for crypto engines.

For this simple example scenario, let's assume both client and server
systems are generic laptop or desktop PCs running current versions of some
flavor of Linux with their respective distributions' standard OpenVPN and
OpenSSL packages. The example OpenVPN configurations I'm about to walk
through, however, should work with little if any tweaking on any of
OpenVPN's supported platforms, including Windows, Mac OS X and so forth.

Although this scenario implies a single user connecting back to the
home server, the configurations I'm about to describe can just
as easily support many users by changing only one server-side setting
(max-clients) and by generating additional client certificates. Have I
mentioned certificates yet? You'll need to create a Certificate Authority
(CA) key, server certificate and at least one client certificate. But
have no fear, OpenVPN includes scripts that make it quick and easy to
create a homegrown Public Key Infrastructure.

Comment viewing options

I wonder about security if I use a certificate on the server and username/password authentication as the only form of client authentication. As far as I understand this still should be much better than PSK because still authentication is done and changing session keys are used afterwards.
But of course a secure password should be chosen (16-32 random chars).

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.