Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Advisory Watch: March 27th, 2015
Linux Security Week: March 23rd, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

OpenVPN: An Introduction and Interview with Founder, James Yonan Print E-mail
User Rating:      How can I rate this item?
Features In this article, Duane Dunston gives a brief introduction to OpenVPN and interviews its founder James Yonan.


OpenVPN is a newer generation VPN in that it is based on SSL as the underlying security mechanism. IPSEC is the current and most popular standard for VPN technology. SSL is already a standard for secure communication over the Internet for financial transactions, checking email, and ensuring sensitive information is not leaked to "people-in-the-middle". Many articles I've read speak of SSL VPN's as requiring a browser. I'm not sure why that gets under my skin. It just isn't true. The only time I use a browser over OpenVPN is to access an intranet web server on the remote side. Once an OpenVPN tunnel is established you can then use any application to access services on the remote end, provided the right access controls are in place. A browser is not needed to create an OpenVPN tunnel, it can be done from the commandline. Another nicety is that it runs on Windows 20000/XP, Linux, Solaris, FreeBSD, OpenBSD, NetBSD, and MacOS X.

Oh yes, and it is under the GNU Licenese. OpenVPN uses the protocols that are available with SSL and TLS 1.0 for authentication, encryption, and intergrity checking. I have personally tested and use OpenVPN on Windows and Linux systems. I've never had problems using any applications over OpenVPN. The only issue I've run into is a common or well-known issue with VPN's and that is the problem with packet fragmentation, which is easily remedied by a simple OpenVPN configuration option.

Don't let the SSL scare you because of creating public and private keys. OpenVPN comes with scripts to automate the process (If you ask nicely, I'll send you my scripts to automate the process even more.) You'll also want to ensure the client's key expires within a reasonable amount of time and require a password. Also, OpenVPN supports static keys which is good for LAN-to-LAN connections. It can be a bit scary letting remote users have a static key out in the wild, so a public/private key exchange is best for remote users. Static keys should be changed very often (Note: OpenVPN static keys that are created on Windows can be used on Linux and vice versa. Remember the dos newline issue if you are creating and sending keys between unix and windows systems.)

Interview with James Yonan, Creator of OpenVPN: What browser is required to run OpenVPN tunnels?

James Yonan: Talking about SSL VPNs doesn't necessarily mean that you are talking about a VPN which uses a web browser as the client. In a sense, browser-based VPNs are not VPNs at all -- they are really just web applications that provide enough services so that a true VPN is not actually required.

OpenVPN uses the underlying cryptographic mechanism of SSL/TLS to secure a VPN connection, but the web analogy stops there. OpenVPN can best be understood as a portable, user-space VPN implementation which uses SSL/TLS as its underlying cryptographic engine. OpenVPN is able to use the same public key infrastructure as Apache, but is otherwise not related to the secure web. What do you do in your spare time?

James Yonan: Open Source development, jazz dancing, and flying (without an engine). How did the idea to create OpenVPN come about?

James Yonan: Around the turn of the century, I finished up a large project for my company. As a kind of thank you, they decided to unchain me from my workstation, on the condition that I maintain an always-reachable telepresence. With this newfound freedom, I traveled all over the world, checking into the office from places like Hurghada Egypt, and Bishkek Kyrgyzstan. As one might imagine, I become very interested in the tools of telecommuting. I wanted a solution that was not only world-class from a security perspective, but that would also give me the ability to install and manage the remote end of the VPN, without needing to bother people back at the office. Traveling in Central Asia (pre 9/11), I was especially concerned about active attacks and connection hijacking, since my internet path crossed through Russia and other regions having an absurd number of very talented hackers who were also unemployed.

My initial foray into Linux VPNs showed that the various VPN camps had split into groups, based on the kind of tradeoffs they were willing to make. The "security-first" group consisted of the IPSec and FreeSwan people whose goal was to first get the security right, sometimes at the expense of robustness and usability. Then there were the non-IPSec camps (VTun, Cipe, etc) founded by people who probably needed a VPN right away and decided it would be easier to roll their own than figure out how to install IPSec. The non-IPSec camps were very focussed on the networking theory behind VPNs, and I think a major innovation that came out of this work was the concept of the "tun" or "tap" virtual network adapter as a means of moving the complexity of the VPN into userspace, logically separating the networking and crypto components, making the code portable, and giving an intuitive interface to the end-user (tun or tap drivers export a first-class network interface to the OS which can be routed from/to, firewalled, NATed, just like any other interface).

After some study of the open source VPN field, my conclusion was that the "usability-first" camp had the right ideas about networking and internetwork tunneling, and the SSH, SSL/TLS, and IPSec camps had the appropriate level of seriousness toward the deep crypto issues. This was the basic conceptual starting point for my work on OpenVPN. How did you choose the name OpenVPN?

James Yonan: OpenVPN is tightly coupled with the OpenSSL library, and given OpenVPN's tendency to inherit stuff from its dependencies, sharing 4 out of 7 name characters seems appropriate.

The other thing I like about "OpenVPN", is that the name makes it immediately clear what the whole production is about. Why use SSL?

James Yonan: Establishing a cryptographic handshake over an insecure network, in a way that is resistant to connection hijacking, is one of the most challenging problems in cryptography.

The fact that we have 3 versions of SSL + TLS 1.0 should clue you in to the fact that cryptographers seem to take delight in attempting to outsmart themselves by devising ever-better protocols and then smashing them in their spare time. Ever heard of of SSL 1? It was apparently cracked in real-time as it was being presented at a cryptographic conference. Who knows how many other cryptographic schemes would be similarly broken, were they exposed to any real scrutiny?

TLS fits the bill rather nicely. It is a high-quality piece of cryptographic work, designed, attacked, and ultimately endorsed by some of the brightest cryptographers today.

It is also easily accessible in userspace library implementations, such as OpenSSL. Many VPN appliances and software applications are billed as "IPSEC-compliant", yet many aren't compliant. Can SSL-VPN's be made compliant eg. for example with Amrita VPN? ( )

James Yonan: Ever since Peter Gutmann published his critique on open source VPNs, there has been growing interest in putting together an RFC to describe a TLS-based, user-space VPN standard.

I expect that this process will take time, more so because of usability and management issues than security issues. User-space VPNs have already reached the point where they are stable, secure, and well-documented. What is still needed is to make them easier to configure both at the low end (new users, small business, home offices) and higher end (larger organizations with potentially hundreds or thousands of VPN users).

While we know today the kinds of cryptography technology a VPN needs to be secure, we don't really know yet what the optimal VPN experience should look like, from a usability perspective. How do we minimize the amount of manual configuration required? How do we streamline the key management process? I would argue that it would be premature to codify the user-space VPN model into a standard until we have a better handle on the usability and management issues. What kind of security problems do "compliant" VPN's introduce?

James Yonan: One of my major gripes with IPSec is that it adds a lot of complexity to the kernel. Complexity is really the enemy of security. The problem with putting complex security software in the kernel is that you ignore an important security principle: never design secure systems so that the failure of one component results in a catastrophic security breach. A single buffer overflow exploit in kernel space results in total system compromise -- why not move the complexity into user space where the code might run in an empty chroot jail as user "nobody"? At least with this approach, a code insertion exploit can be more readily contained. How do we spread the word on SSL-VPN's?

James Yonan: The best thing you can do is try one, and report your experiences (good or bad) back to the community. James, thank your for your time. We appreciate the interview!

Duane Dunston is a Senior Computer Security Analyst at STG Inc. for the National Climatic Data Center in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS. He writes poetry. He hangs out at Anntony's, Early Girl Eatery (tell'em Duane sent you), The New French Bar, and still wakes up every morning ready to go to work. <

Great interviewWritten by Dell on 2006-10-11 00:14:46
OpenVPN is for people who really want to get things done as opposed to some academic exercise in crypto, 
Thanks for this great tunnelizer!
Managing DirectorWritten by Gerhard on 2007-05-23 09:20:38
My company is in the process of rolling out a web application linked to a back-end information source that will span many thousands of remote clients (fixed, pos-type clients collecting data and statistics from many hundreds of devices connected to the client via proprietary radio communication). This enterprise-strength solution requires a globally scalable architecture, which lead to an exhaustive research into candidate VPN solutions. Given the fact that I was, until a few years ago, dead set against the adoption of open-source products, for all the right reasons at the time (big corporate philosophy based on big spend = big miracles...), it took more than a reasonable amount of convicing when I was finally presented with OpenVPN. 
Finally, I agreed on a proof-of-concept deployment pilot and within ONE WEEK, and at NO COST, not only was the proof-of-concept successfully demonstrated, but I had personally gained an insight into the (previously) laymans labarynth of VPN, IPSec, SSL, etc. 
I now know more about VPN than the avarage IT Executive out there and, what's more, I'm totally convinced that OpenVPN will carry the tourch high with our system. 
What can I say - Well done James Jonan and his Team (I did make a donation...:). 
I am finally a believer in-, and my company will in due cource contribute to-, the open-source phenomina. 
Gerhard Janse van Rensburg
General ManagerWritten by Damien on 2009-01-09 04:15:27
I had tested all major VPN (IPSec, PPTP, Web browser SSL, RSA) but non can do for my project as good as OpenVPN. I love its NAT friendly and easy portability to different platforms, yet secure enough.

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

< Prev   Next >


Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
FBI Quietly Removes Recommendation To Encrypt Your Phone
And the prize for LEAST SECURE BROWSER goes to ... Chrome!
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.