VPN implementations and their peculiarities

We have previously discussed what VPN is. Now let’s review its implementations and their advantages and drawbacks.

In a previous post, we discussed the definition of VPN (Virtual Private Network), its purpose and various use cases. Today we will review its most prevalent implementations, and their advantages and drawbacks.

By definition, a VPN is a versatile concept and it’s hard to understand straight away whether some implementation is a VPN or not. To a certain extent, the Internet’s forerunner, ARPANET, could also be considered a VPN. Curiously, almost all of the networking concepts and, more evidently, protocols, started as corporate technologies and only later became used by average individuals.

Well, neither history nor corporate infrastructure are of interest for us today. In this post we’re going to analyse common VPN implementations, which a user with no technical acumen might come across.

First, we will see into those implementations which help to protect users when they are connecting to a public Wi-Fi network, or to bypass certain IP-based restrictions imposed by a service provider. As a rule, consumer-class VPN services leverage popular operating system capabilities and provide a step-by-step instructions necessary for establishing a secure connection.

Lately VPN has made a huge step forward in terms of simplifying this process: an average user does not have to go through all those techy gibberish and only needs to follow primitive instructions like ‘pay here, download app here, press here and enjoy.’ But in some cases it would make sense to at least know how VPN implementations differ from each other.


Caption: VPN settings in Android (left) and Windows (right)

<h3>Popular VPN implementations</h3>

PPTP (Point-to-Point Tunneling Protocol) was developed about 20 years go, which is both its advantage and major drawback. The most important benefit is its compatibility with almost all of operating systems, even legacy ones which makes the protocol highly universal and available. Also, it’s not demanding in terms of computing power, if compared to newer solutions.

But its major drawback is also explained by its old age: by today’s security realities it offers a considerably lower level of protection. Its encryption methods were absolutely fine in mid-90’s, but today are not secure enough — a problem which is amplified by a flawed architecture and a number of weaknesses in the most popular Microsoft implementation.

Moreover, with regard to PPTP, encryption is not offered by default, and it would take an adversary less than 24 hours to crack the password with the production hardware available today. However, in scenarios which don’t require a super secure connection or when other VPN connections are not available, it’s better to use PPTP with weak encryption rather that to go completely unprotected.

Once I found myself in a tricky situation: I was travelling to a country which is notorious for certain Internet regulations (if you know what I mean). I used our corporate PPTP server located in my home country to email, and my mails were delivered with a lag varying from two days to about two weeks. One can only guess where those emails were all that time. At the same time, the use of an alternative and thus more secure VPN connection was restricted. This story illustrates that PPTP by far isn’t strong enough to protect you from powerful guys like governments or corporations.

L2TP (Layer 2 Tunneling Protocol) is quite similar to PPTP. These two standards were developed and certified practically at the same time, yet L2TP is considered more efficient for virtual networks, but at the same time is a bit more demanding in terms of computing power. Usually it is preferred by ISPs and enterprise users. By the way, L2TP does not provide default encryption and is bundled with other protocols (usually IPSec).

IPSec (Internet Protocol Security) is a collection of protocols, standards and recommendations. This bundle is purpose-made for various types of secure connections. The first elaborations of IPSec date back to early 90’s, but the basis of its concept is constant improvement and updating in accordance with developments in tech, so it’s not a static specification.

It’s obvious what type of entities it was developed for. IPSec included a dozen of standards (each of them having more than one implementation), which could be used for facilitating secure connections at all levels. It’s admittedly good in terms of architecture, reliability of its encryption algorithms, and capabilities.

With all due respect, IPSec has its downsides as well. First, it’s not easy to configure for an average PC user, and if it’s configured improperly, its security can be compromised. Also, as was noted before, it’s used in a bundle with several other protocols.

Second, it’s demanding in terms of computing power. Partially, this drawback is compensated by the use of hardware acceleration of AES encryption algorithms (which are usually offered in today’s implementations of IPSec, among other algorithms). This AES hardware acceleration feature is deployed in current processors for both mobile and desktop devices, as well as in Wi-Fi routers and so on.

To our dismay, technologies created by theoreticians (mainly, math think tanks), are brought to life by practical minds which at times lack knowledge and understanding of science. Research published in October 2015 states that up to 66% IPSec connections are crackable with quite moderate effort, and NSA is likely to possess suitable hardware resources to compromise encryption.

The issue here is the incorrect use of protocols which are used to initiate a secure connection. This problem is applicable not only to IPSec, but to TLS (which we’ll discuss below) and SSH, as well as TOR and OTR. In other words, there is likelihood of compromise for both VPN connection and other types of secure connection for certain websites, mail servers, messengers and the likes of those.

Of course, long lead-in times and significant computing resources are required to carry out such an attack, but in this very case the researchers used Amazon’s common cloud technologies and, evidently, spent a realistic amount of money, technically available for a private actor.

With such resources at hand, the prep time for an attack can be a minute in the best case scenario and up to a month in a worst-case scenario. At the same time, some experts were sceptical about this Proof-of-Concept: as they say, in real life the number of vulnerable systems is much lower. Anyway, certain aspects of the research should be taken seriously; meanwhile the developers of potentially vulnerable software are preparing or have already developed patches and have alerted their users.

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) VPNs, as their names suggest, belong to a class of solutions based on corresponding SSL and TLS protocols, which are at times complemented by other means of protection. All of you should have come across SSL/TLS when surfing the Internet; for example, this very website uses it as well: the ‘https’ prefix and the green lock header confirm that the website uses these protocols for secure connection.

The first implementations of the protocol date back to as early as last century, yet the technology gained traction only in 2000’s. The proliferation of the protocols allowed to study them thoroughly and find a number of vulnerabilities, both in the architecture itself and in different implementations. SSL 3.0 was phased out in June 2015; the most up-to-date version is TLS 1.2, yet it is hardly totally secure: a lot really depends on configuration (see IPSec). Besides, both protocols are burdened by a need to offer backward compatibility.

What can definitely be considered an advantage of this type of VPN is the prevalence of SSL/TLS in the Internet, which means that most public networks let it pass through freely. In terms of drawbacks, these VPNs have low performance, are hard to configure and require additional software.

Among the most popular SSL/TLS VPN implementations are OpenVPN (SSL 3.0 / TLS 1.2) and Microsoft’s SSTP (SSL 3.0). In fact, SSTP is integrated with Windows. OpenVPN, due to its open nature, has a lot of implementations for most platforms and is considered the most reliable VPN implementation to date.


We have reviewed the most popular VPN implementations known to date. However, as this technology evolved over the years, it saw a huge number of iterations. Think of all solutions developed for the enterprise and telecommunication sectors!

As for average users, I would recommend sticking to OpenVPN due to its open nature, reliability and security. However, this and other VPN implementations have a number of tricky technical and legal peculiarities I’m going to cover in a later instalment in this series.