The modular structure of OpenVPN can not only be found in its security model, but also in the networking scheme. James Yonan chose the Universal TUN/TAP driver for the networking layer of OpenVPN.
The TUN/TAP driver is an open source project that is included in all modern Linux/Unix distributions, as well as Windows, Solaris, and Mac OS X. Like SSL/TLS, it is used in many projects, and therefore it is steadily being improved, and new features are being added. Using the TUN/TAP devices takes away a lot of complexity from the structure of OpenVPN. Its simple structure brings increased security when compared to other VPN solutions. Complexity is always the main enemy of security. For example, IPsec has a complex structure with complex modifications in the kernel and the IP stack, thereby creating many possible security loopholes.
The Universal TUN/TAP driver was developed to provide Linux kernel support for tunneling IP traffic. It is a virtual network interface, which appears as authentic to all applications and users. Only the name tunX or tapX distinguishes it from other devices. Every application that is capable of using a network interface can use the tunnel interface. Every technology that you are running in your network can be run on a TUN or TAP interface too.
This driver is one of the main factors that makes OpenVPN very easy to understand, easy to configure, and at the same time, very secure.
The following figure depicts OpenVPN using standard interfaces:
A TUN device can be used like a virtual point-to-point interface, like a modem or DSL link. This is called routed mode because routes are set up to the VPN partner.
However, a TAP device can be used like a virtual Ethernet adapter. This enables the daemon listening on the interface to capture Ethernet frames, which is not possible with TUN devices. This mode is called bridging mode because the networks are connected as if over a hardware bridge. Applications can read/write to this interface. Software (the tunnel driver) will take all the data and use the cryptographic libraries of SSL/TLS to encrypt them. The data is packaged and sent to the other end of the tunnel. This packaging is done with standardized UDP or optional TCP packets. UDP should be the first choice, but TCP can be helpful in some cases. You are almost completely free to choose the configuration parameters such as protocol or port numbers, as long as both tunnel ends agree on the same figures.
OpenVPN listens on TUN/TAP devices, takes the traffic, encrypts it, and sends it to the other VPN partner, where another OpenVPN process receives the data, decrypts it, and hands it over to the virtual network device, where the application might already be waiting for the data.
As far as I know, there are only few other VPN software applications that enable VPN partners to transmit. This concept offers the following exciting possibilities:
- Broadcasts are needed for browsing Windows networks or for LAN games
- Non-IP packets like IPX be used and almost anything is possible in your LAN that is sent over the VPN to the other side
As OpenVPN uses standard network packets, NAT is no problem either. A host in the local net in Sydney with a local IP can start a tunnel to another host in the local net in London, if it is also equipped with a local IP.
But there's more. As the network interface is a standardized Linux network interface (either TUN or TAP), anything possible on an Ethernet NIC can also be done on VPN tunnels. Consider the following:
- Firewalls can restrict and control traffic
- Traffic shaping is not only possible, but it is also a feature incorporated in OpenVPN
Also, if you want to use DSL lines with frequent reconnects and dynamically assigned IPs, OpenVPN will be your first choice. The reconnect is much faster than that of any other VPN software that we have tested. A Windows terminal server or SSH session does not terminate when one of the VPN partners changes its IP. The session just freezes for a few seconds and then you can continue. Can your VPN accomplish that?
OpenVPN and firewalls
OpenVPN works perfectly with firewalls. There are a few VPN solutions that can claim to have similar firewall support, but none can offer the same level of security.
What is a firewall? There is a famous and simple definition. A firewall is a router that does not route. If you consider this to be not very helpful, then here is a more refined definition:
A firewall is a router that routes only selected Internet data. Firewall rules define how to handle specific data and traffic.
Firewalls can be devices or software on PCs, servers, or on other devices. A firewall takes care of the data that has been received and has a closer look at it. Modern firewalls are so-called packet filtering, stateful inspection firewalls. Depending on the OSI layer it is operating in, the firewall can pass decisions based on the data that is found in the headers of the packets or application data. Packet filtering firewalls usually operate by reading the IP data header. Stateful inspection is a mechanism to remember the connection states. In this way, internal networks can be protected from external networks. While Internet connections initiated from the inside can be allowed, all unwanted unauthorized connections from the outside can be rejected. At the same time, incoming data requested by a member of the local net is passed through (because the firewall remembers the state of the request).
Under Linux, most firewalls are based on the program iptables. This is a user-space interface to the Linux kernel's netfilter firewall functionality, and offers everything that modern firewalls should. Probably the best way to protect your LAN is by writing a set of iptables rules with a shell script. However, the usability of such a script is not perfect. Most administrators want a Graphical User Interface (GUI) for firewall control and all the hardware firewalls offer this. Enterprise Distributions, such as RHEL or SLES come with sophisticated firewall tools, but there are also several open source projects. Outstanding tools for this purpose and Linux (iptables) firewalls are as follows:
- The Shorewall (Shoreline Firewall) project that integrates into the Webmin suite—a web-based frontend to administer Linux systems from a browser. People from the Shorewall project, namely, Simon Matter and Tom Eastep, have written a very useful guideline for the integration of OpenVPN tunnels into Shorewall and more at http://www.shorewall.net/OPENVPN.html.
- IPCop (http://www.ipcop.org) is a promising standalone, easy-to-configure Linux firewall system that is also equipped with a professional GUI. It has had great success in third-world projects like Linux4africa (http://www.linux4africa.de) and in other medium-size professional setups. Standardized installation, simple structures, and modular add-ons make this a fast-growing project, and with the help of OpenVPN, the IPCop firewall becomes a true VPN server.
- Tools like Fwbuilder (http://www.fwbuilder.org) help you build, manage, and distribute your iptables scripts on your own. Fwbuilder does even more. It can work independently from your platform and is able to translate Linux rules into Cisco, BSD, or other firewall languages. This is really worth a look.
Up till now, you have seen that OpenVPN has a secure and easy-to-use security approach and a flexible networking model. Consequently, very simple configuration syntax and good documentation characterize the user interface of OpenVPN. Configuration is done by editing a simple text file. The syntax is the same on every operating system. Here is an example of a simple configuration file with 13 lines.
ifconfig 10.79.10.1 10.79.10.2
route 10.94.0.0 255.255.0.0 10.79.10.2
keepalive 120 600
route-up "/sbin/firewall restart"
A command-line interface allows you to start temporary tunnels at will, which is very useful when testing setups. The same parameters as in the configuration file are added to the command line, and the tunnels are started.
In the so called server mode, OpenVPN can push various configuration data to the clients through the tunnel. Multiple tunnels can be run on one singular port, either UDP or TCP. OpenVPN can be tunneled through firewalls and proxies, if they allow HTTPS connections, and the server can tell the client to use the tunnel as the default route to the Internet.
This offers a huge variety of possibilities. You can have your field workers open only one port to whatever network they are connected to. This is the port OpenVPN uses to connect to your company's VPN server. Once connected, all Internet traffic from this laptop is routed through the network of the company to which the VPN tunnel is connected. In this way, your company's firewall can also protect the road warriors. A road warrior is a member of a company (or a company's network), who is working outside the company's walls and connects to the network frequently through different connections. A typical road warrior may be a salesman with his or her laptop, who needs to access the company's resources using his or her customer's network.
Problems with OpenVPN
OpenVPN has a few weaknesses:
- It is not IPsec compatible, and IPsec is the standard VPN solution. Lots of devices such as Cisco or Bintec routers use IPsec and can connect to applications of other manufacturers or software IPsec clients. At least they should be able to, because in practice many manufacturers tend to develop their own proprietary extensions to IPsec, which make their implementations practically incompatible with other IPsec devices.
- OpenVPN is not defined by any RFC. But for the future, Yonan has posted several times that RFC 4347 (DTLS—Datagram Transport Layer Security) offers a very promising specification with compatible modules taken into account.
- There are still relatively few people who know how to use OpenVPN, especially in difficult scenarios (though those tend to be rare). So if you read on, you can acquire a valuable qualification.
- There is no enterprise class GUI for administration, but there are some promising projects.
- Today you can only connect to other computers. But this is changing, there are companies working on devices with integrated OpenVPN clients.
- OpenVPN runs in user space and all network traffic needs to go from kernel space to user space and back.
As you can see, the main weaknesses of OpenVPN are incompatibility to IPsec and lack of public knowledge about its features and hardware manufacturers. The first will probably never change because the architectures differ too much, but the latter is already changing.
OpenVPN compared to IPsec VPN
Even though IPsec is the de facto standard, there are many arguments for using OpenVPN. If you want to convince your management about why your branches should be connected through OpenVPN instead of IPsec VPN, then the following table can help your argument (points that are preceded by '+' are advantages and points that are preceded by '-' are disadvantages):
Probably the best argument is that you can use both VPN solutions in parallel, as long as you're using Linux or a Linux-based application. Due to the different approaches to networking, there are no conflicts between the two systems. Moreover, you can tunnel IPsec over OpenVPN.
User space versus kernel space
How do the two solutions compare when it comes to speed and latency? Latency is a parameter that defines the responsiveness of a line. The less latency, the faster the roundtrip for IP packets, and communication gets faster. A very interesting study by Nejc Skoberne from Ljubliana University (http://stuff.skoberne.net/IPSec_and_OpenVPN_Performance.pdf) demonstrates the expected. OpenVPN runs in user space, whereas IPsec runs in kernel space. That's why many Linux systems need specially patched kernels or add-ons for IPsec. As the technology of this VPN is very close to the network stack and is implemented directly in or at least close to the kernel, it will be faster than OpenVPN in most setups. With any VPN solution running in user space, the operating system's kernel has to perform significantly more context switches than with a technology running in kernel space, which results in a higher latency of the connection. As the OpenVPN server has to do slightly more work than the IPsec variant, its latency will always be a little higher.
Here comes the interesting part. OpenVPN beats IPsec when the number of connected clients rises. Although the author has no explanation for this phenomenon, he documents very well how ten OpenVPN clients are able to draw more bandwidth from the server than a single client or ten IPsec clients. Thus, from the perspective of performance, IPsec may be the better choice, if there are protocols involved that need small latencies such as Samba. However, as the number of clients rises, OpenVPN becomes better and better.
Sources for help and documentation
If you want to learn more about OpenVPN, there are numerous resources on the Internet. Web sites, mailing lists, forums, and private pages of OpenVPN fans can be found in abundance. Google finds more than seven million hits for 'open vpn'. This list of course cannot be complete, but here you will find links to web sites that were helpful to me when I started using OpenVPN and where I still look for help today.
The project community
OpenVPN project has its own web site, including downloads of new versions and updates, documentation, how-to's, mailing lists, and links to various VPN-related pages. The OpenVPN project page could not be bettered. You'll find it at http://www.openvpn.net.
The most important source of help is the mailing list: http://www.openvpn.net/index.php/documentation/miscellaneous/mailing-lists.html.
As we are using SSL/TLS for encryption purposes, you will certainly want to understand this toolkit. The SSL/TLS Cryptographic library's web site provides detailed documentation and mailing lists, which can be found at http://www.openssl.org.
The website of the TLS Charter by the TLS Working Group provides a list with many related RFCs and Internet drafts you might consider helpful at http://www.ietf.org/html.charters/tls-charter.html. The promising DTLS RFC 4347 can be found at http://www.ietf.org/rfc/rfc4347.txt
The Universal TUN/TAP driver can be downloaded from the following page: http://vtun.sourceforge.net/tun. Nevertheless, this should not be necessary, as every modern distribution (and kernel) should have this feature built-in. However, the FAQ of this project may be helpful for various questions.
Documentation in the software packages
If you install OpenVPN from the binary packages for your distribution, then you will have the standard documentation in the following directories:
Path to Documentation
online documentation only
Other distributions may have different locations. Check your package management system for details. RPM-based systems give a list of all the files belonging to a specific package when you type rpm -ql openvpn as the super user. Debian-based systems (like Ubuntu) should give the same information when root enters dpkg -L openvpn. Other systems that use ipkg as a manager will respond to ipkg files openvpn. Replace openvpn with the name of the package you had installed.
The source code package (tarball) contains several READMEs and documentation files. Just browse through the directories from which you had extracted OpenVPN. If you're interested, have a look at some of the source code files. The developer's comments can be of great help to understand the depths of the software.
OpenVPN offers great possibilities. The networking concept allows very transparent setups with firewalls or in road warrior configurations. James Yonan, the founder, has made very good decisions when trusting the TUN/TAP network drivers and the SSL/TLS libraries. OpenVPN was first published in 2001, version 2 came out in 2005 and offers many more advanced features than the versions before. The current stable version is 2.0.9, but there are already 15 release candidates for 2.1, and a commercial version 3 is on the way. Multi-client support, Vista support, the push/pull options, a management interface, and the advanced port sharing are only some of the features. OpenVPN is easy to configure and has only a few weaknesses, the most serious of which is its incompatibility with IPsec by design. But to name this as a weakness is harsh if it is compared to IPsec, as was done earlier in this article. IPsec is still the standard, but OpenVPN has many more features at a much better security level.
If you have read this article you may be interested to view :