Image via Wikipedia
Actually, I was first introduced to the concept of virtual private network (VPN) in 2000. An associate of mine was administering a Free Swan installation. Honestly, I had no idea what he was talking about because knowledge of networking was rather weak. For instance, I didn't know the difference between IPSec or PPTP tunneling protocols. Suffice to say that there are several ways to implement a VPN strategy. It is also worth noting that some tunneling strategies are inherently more secure than others.
So I figured that I'd better learn about VPN tunneling protocols and also deploy a solution that is fairly
idiot proof turn-key. As it turns out, the IPSec tunneling protocol has been around for quite awhile. It is fairly complicated to setup, but IPSec is an order of magnitude more robust when compared to Microsoft PPTP. The OpenSwan project (formerly FreeSwan) deploys the more robust IPSec tunneling protocol. The encryption algorithm strategy of PPTP is very inferior, in fact PPTP was designed on top of the very old PPP (Point-to-Point Protocol) from dialup modems. I mention PPTP here because it often is a readily available strategy on several modern commercial grade VPN routers. My Cisco RV082 VPN router provides PPTP out of the box as a VPN solution. This protocol is advertised as an easy means of creating a VPN tunnel between to M$ clients. I have often found that _easy_ is often quite dangerous too ;-) IPSec is also baked into the Linux kernel, so it can be deployed via iptables filtering at the kernel layer. In fairness to M$, it also deploys IPSec client on its more modern OSes; however, in true Redmond fashion they have "embraced and extended" IPSec in a way that puzzles most. Basically you have no idea what you're running, so is it really IPSec?
There is however a snag with the free IPsec clients from Microsoft. You can use IPsec only in combination with another protocol called L2TP. It is fairly difficult (2000/XP/Vista) or probably even impossible (MSL2TP, Pocket PC) to get rid of this L2TP requirement. One might say that Microsoft "embraced and extended" the IPsec standard, in true Microsoft fashion. To be fair though, L2TP is currently a 'Proposed Internet Standard' (RFC 2661 ) and so is 'L2TP over IPsec' (RFC 3193). PPTP, on the other hand, is another widely used VPN protocol but it is not an official standard.The excerpt above came from this very good FreeSwan article
Perhaps it would be helpful to understand why I have begun to utilize a VPN. When I am traveling or working in Panera Bread or Barnes and Nobles, I like to take advantage of the public Wi-Fi. Typically what I do is fire up a terminal and ssh into my Linux box at home and port forward TOR and SOCKS5 to the local ports on my notebook computer. For the curious, check some of my earlier entries on that subject. This strategy works quite well, but when I ask staff members who are less computer savvy to open a terminal window and then run ssh.. Their eyes get glazed over and they begin to complain about it not being a "pretty" solution.
So a more elegant solution was required to provide wider adoption within our organization. Furthermore, you can't sell what you don't own. That is if you're going to propose an alternate solution for accessing data securely, you must be willing to use it yourself. Some people call it "dog fooding".. Besides, I'm always excited about learning something new.
As I stated earlier I looked at OpenSwan (FreeSwan fork) or more generally IPSec and it did look rather confusing to me. Moreover, I wasn't quite sure how active the developer community was around that project.
Let's take a quick look at what makes OpenVPN a quite viable VPN solution.
- Private Key Infrastructure
- Multiple Encryption Algorithms
- UDP instead of TCP
- Pseudo Two-Factor Authentication
The PKI is the heart of OpenVPN, as it empowers the sysadmin to authenticate a host of clients through self-signed certificate/key pair which are generated on your own server. This approach is helpful, as it mitigates the need for a central signing authority. It works very much like creating SSL certificate for an apache webserver and associated client web browsers. Though OpenVPN is not overly complicated to setup, the PKI process is the area that will likely cause problems for many people. In fact, I scraped my knuckles during this process too. For instance, an incorrectly generated key may not show up until you try to authenticate a client. The error logs will reveal important messages, but are somewhat generic if not cryptic.
SSL/TLS are venerable and well understood IETF encryption standards that are deployed for many web and email servers. MD5 and SHA-1 are common place digest algorithms. No surprises here. Arguably TLS has its own faults and vulnerabilities, but because these are "standards" unlike L2TP the holes get discovered easily. Hence the community resolves problems fairly quickly.
All Linux distributions are equipped with Openssl and the means to generate certificate authorities. 'pkitool' is the front end for the openssl tool. pkitool does all of the certificates/key builds. You just have to remember to run "./clean-all" in the appropriate openvpn setup directory to wipe all previous keys otherwise your OpenVPN setup will fail silently but very consistently :-)
Regarding UDP... Many people prefer TCP over UDP, as the latter doesn't make any guarantees about the arrival of datagram packets. UDP is now exclusively used with openvpn, as UDP seems to play nicer with firewalls due in large part because packets are not resent upon failure.
The process of re-checking at the packet layer increases the overhead of TCP significantly. Hence the reason that UDP is preferred, as it is much faster albeit not as accurate. So you have a trade-off. My knowledge of packet inspection is limited, so if anyone has a better explanation, I'm very interested.
I'm running openvpn on a Debian/Stable box. It runs quite well. After I resolved my PKI issue, the only other gotchas occurred when I didn't explicitly set the packet routing for my server. More specifically, I had to echo 1 > /proc/sys/net/ipv4/ip_forward to enable packet routing on the server. Failing to do this will also break your openvpn setup.
Lastly, I had to pick the correct virtual IP address to push to both sides of the tunnel. In this case I was not able to ping either side of the tunnel. Using tcpdump I was able to ascertain that the packets arriving from the M$ windows clients were being dropped.. Once I enabled routing and changed the virtual IP addresses, the problem went away.
Originally, I had chosen 10.0.0/24 but realized that places like Panera Bread and others have the same IP addressing scheme, which played havoc resources located on the target server.
Lastly, the idea of pseudo two-factor authentication.. By definition, two-factor authentication is something you know (ie password) and something you have (ie secure token or passport). So openvpn PKI and a passphrase to verify ownership of the certificate authority and client key really isn't the same, but it sure feels very robust to me.
OpenVPN is a very robust solution for my needs. SSL/TLS is a fairly simple means of leveraging free software and well understood standards/protocols to securely encapsulate data packets on both sides of a VPN tunnel. However, I am not sure that enterprise networks would admire it the same. In fact, I know that my employer blocks the UDP ports which openvpn servers typically listen.
Hopefully, this sheds a bit of light on the various VPN strategies and also some of the virtues of OpenVPN.