Building an OpenVPN binary RPM package requires these RPM prerequisites:

• openssl
• openssl-devel
• lzo
• lzo-devel

The openssl package is almost always installed by default on Linux distributions. The openssl-devel package is almost always available on Linux distributions, but is sometimes not installed by default. The lzo and lzo-devel packages are usually included in more recent Linux distributions but must be installed manually. See the Dag Wieers site for a comprehensive set of LZO RPMs for Red Hat and Fedora.

Once the prerequisite binary RPMs are in place, building an OpenVPN binary RPM is quite straightforward:

You will see a lot of lines of output as rpmbuild compiles OpenVPN, but check near the end of the output for a line which looks like this:

This tells you where rpmbuild wrote the binary RPM file. Now, use:

to do a fresh install of OpenVPN, or

to upgrade an existing installation

By default, OpenVPN uses the blowfish cipher for tunnel encryption. For some reason, some versions of Slackware have an OpenSSL library built without Blowfish cipher support.

The fix is either:

• Rebuild the OpenSSL library to include blowfish, or
• use the –cipher option to choose a different cipher. The command openvpn –show-ciphers will show the available ciphers. For example –cipher DES-EDE3-CBC will select Triple-DES encryption.

Not to our knowledge (as of 2004.12.08). The current OpenVPN security model matured by version 1.1.0, which was released in 4/2002. Since that time, there have been no confirmed reports on the OpenVPN lists or other security-related forums claiming any security vulnerabilities due to bugs in the software.

Having said that, there is always the potential for security vulnerabilities to be introduced by incorrect configurations. One such vulnerability is discussed here.

While OpenVPN has not as yet been subjected to a comprehensive security review, so far the security model has stood up well to analysis. In 9/2003, cryptography expert Peter Gutmann looked at the field of open source VPNs with a critical eye, and OpenVPN was singled out for some positive remarks.

OpenVPN’s security model can be summarized as such: Use the IPSec ESP protocol for tunnel packet security, but then drop IKE in favor of SSL/TLS for session authentication. This allows for a lightweight, portable VPN implementation that draws on IPSec’s strengths, without introducing the complexity of IKE.

See the article OpenVPN and the SSL VPN Revolution (PDF), by Charlie Hosner, for a more in-depth look at OpenVPN from a security perspective.

While it’s impossible to assure with certainty that no weaknesses exist, OpenVPN has multiple levels of security to protect against a single flaw causing a catastrophic security breach. For example, by using –user nobody –group nobody you can ensure that even if some kind of remote buffer overflow exploit were discovered, the exploit would be unable to elevate its privilege to root. Another example is using SSL/TLS security with –tls-auth. Using –tls-auth ensures that even if a remote buffer overflow is discovered and exploited in the SSL/TLS authentication code in the OpenSSL library, it could not be used to attack an OpenVPN session that is protected with a –tls-authpassword. In addition, if you use SSL/TLS authentication, you have the benefit of “perfect forward secrecy”.

Okay, here is a brief summary of the principle behind OpenVPN:

Imagine you had a direct physical wire (i.e. a long cable) connecting two computers (A and B) at different locations. On each computer there would be a /dev/longcable which would be a network device. You could route IP traffic over it, and do everything you could normally do with a network device.

Basically a tun device is like having a /dev/longcable except the OpenVPN daemon is the program that connects the /dev/longcable on computer A with the /dev/longcable on computer B so that you can use the internet rather than a real physical cable. But in this case it is called /dev/tun or whatever your OS prefers to call them.

Now the mechanism by which OpenVPN connects /dev/tun on computer A with /dev/tun on computer B is this: It simply creates an encrypted UDP connection over the internet between A and B and forwards traffic between /dev/tun on A with /dev/tun on B. Because of the clever way in which the tun and tap drivers were designed, it is possible for a program running entirely in user-space to effect this link, allowing OpenVPN to be a portable cross-platform daemon (like SSH), rather than an OS-specific kernel module (like IPSec).

The difference between a tun and tap device is this: a tun device is a virtual IP point-to-point device and a tap device is a virtual ethernet device. So getting back to the “long cable” analogy, using a tun device would be like having a T1 cable connecting the computers and using a tap device would be like having an ethernet network connecting the two computers. People who are running applications that need the special features of ethernet (which won’t work on an IP-only network) will often bridge their physical local ethernet with a tap device (using a utility such as brctl on Linux), then VPN the tap device to another similar setup at the other end. This allows OpenVPN to route ethernet broadcasts and non-IP protocols such as Windows NetBios over the VPN. If you don’t need the special features of ethernet (such as bridging capability), it’s better to use a tun device.

Tun and tap devices can be interconnected to create a complex routing topology. Some people have created multi-node WAN networks over tap devices and actually run DHCP over the VPN so that clients can log into the virtual ethernet and request an IP address. I’ve even heard of people using Linux advanced routing to run OSPF (a kind of dynamic routing protocol) over the VPN WAN to allow for dynamic, fault-tolerant routing. They sky is the limit as far as the complexity of network you can build, but the basic building block is a VPN daemon such as OpenVPN connecting tun or tap devices on two different machines.

Yes. See the –crl-verify option in OpenVPN 1.5 and higher.

While the OpenVPN protocol has been fairly stable since version 1.1.0, minor changes have occurred. See the Compatibility Notes for more information.

A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link.

You cannot mix –dev tun and –dev tap on different ends of the connection. Use one or the other consistently.

When a client connects via bridging to a remote network, it is assigned an IP address that is part of the remote physical ethernet subnet and is then able to interact with other machines on the remote subnet as if it were connected locally. Bridging setups require a special OS-specific tool to bridge a physical ethernet adapter with a virtual TAP style device. On Linux, for example, brctl is this tool. On Windows XP or higher, select your TAP-Win32 adapter and your ethernet adapter in Control Panel -> Network Connections, then right click and select Bridge Connections.

When a client connects via routing, it uses its own separate subnet, and routes are set up on both the client machine and remote gateway so that data packets will seamlessly traverse the VPN. The “client” is not necessarily a single machine. It could be a subnet of several machines.

Bridging and routing are functionally very similar, with the major difference being that a routed VPN will not pass IP broadcasts while a bridged VPN will.

When you are bridging, you must always use –dev tap on both ends of the connection. If you are routing you can use either –dev tap or –dev tun, but you must use the same on both ends of the connection. –dev tun tends to be slightly more efficient for the routing case.