Unsurprisingly, this blog/forum has delivered the “Proprietary = Evil, Open = Good” message in many different formats. Often times, we tend to forget to actually backup this message with any specific stories. Everyone loves stories, so for today's post I intend to give a first-hand account of proprietary vs. open story. Even if the story isn't directly related to systems/event/service management, the lessons apply universally.
Zenoss has grown quite dramatically over the last several years, as a result the number of “remote” workers has increased as well. Anyone from sales to support has people working remotely on a 24/7 basis. It was time to provide a VPN gateway, so everyone could still access internal resources (VMware cluster, internal test systems, etc.). After some terrible experiences with IPSec and all its complexities, we settled on a SSL VPN appliance from Juniper.
SSL VPNs are pretty reliable and easy to use, so establishing a VPN connection could be done reliably and easily by simply visiting the gateway via the web. This certainly was a big step forward. After a while, however, remote users started raising concerns:
- The VPN would cut connections 24h after they were first established. This can be extremely annoying especially if a current customer Webex support session dies as a result. Not to mentioned the various SSH sessions one might have open.
- A lack of platform support left people on Linux and our VoIP phones on the outside. As an alternative we had to have phones connect directly via IPSec. Linux users had to patch/trick the client into running on their platform.
- It was impossible to connect from multiple systems at the same time, using the same credentials. This was especially inconvenient for remote users, since they might have multiple workstations from which they worked during the day. To connect an entire remote network expensive hardware devices had to be purchased and painfully configured.
- During a hardware failure of the VPN appliance we were left without VPN access for the time it took the replacement to arrive and be racked. Further, we lost all configuration, and therefore had to recreate all user accounts.
To address the above failures, I took it upon myself to create an alternative VPN solution based on OpenVPN. OpenVPN is an open source VPN solution build to adapt to any requirement one might have. Specifically, the following requirements have been addressed:
- Connections are no longer cut for anyone, unless they disconnect explicitly. As a matter of fact OpenVPN provides an endless number of keep alive options.
- OpenVPN has clients for every platform imaginable. Support goes well beyond Desktop platforms (Windows, Mac and Linux), but even for embedded systems such as off the shelf consumer routers.
- Expensive hardware appliances are a thing of the past. Since OpenVPN can be run on anything, backups and failover scenarios are easy. Also, users can configure their consumer routers to transparently connect their entire network (including VoIP phones)
Again, the strengths of Open Source allowed me to circumvent the limitations of the closed and proprietary SSL VPN. The lack of configuration options, lack of platform support, and lack of availability were completely addressed by OpenVPN. In the end, we now have a solution that is more reliable, more available, almost as easy to use, more portable and less expensive. All of this goodness springing directly from the principles of Open Source.
Image credit: OpenClipart.org
