The VPN protocol should ideally be secure, functional, and fast. But there is another factor: popularity. An unpopular protocol is more difficult to implement and maintain: its software needs to be installed and configured, and users and administrators need to be trained.
Sometimes protocols become popular despite their technical shortcomings, simply because of aggressive promotion by a large company.
It happens, and vice versa, the protocol of independent developers solves such an urgent problem for some part of the users that it is quickly gaining popularity on its own. This happened with OpenVPN or WireGuard.
Some protocols are losing popularity. Some never become widely known, sometimes deservedly, sometimes not. In this article, we will talk about several of these protocols.
PPTP (Point to Point Tunneling Protocol) has been in the background quite rightly. I would like to believe that young readers have not come across him anymore, but ten years ago he was a textbook example of an undeservedly popular protocol.
Its popularity was ensured by the monopoly of its developer – Microsoft Corporation. From the mid-nineties to the late 2000s, the vast majority of client devices were Windows computers. Obviously, the presence of a built-in client in Windows automatically made the protocol at least common.
Microsoft wouldn’t be itself if it didn’t take advantage of this to maintain and strengthen its monopoly position. PPTP used standard PPP and GRE for data transfer, but a non-standard, proprietary set of protocols was used for authentication and encryption: MPPE (Microsoft Point-to-Point Encryption) and MS-CHAP.
Because of this, free implementations of both the client and the PPTP server were at one time as sore subject as GIF and MP3. Then the patents expired, poptop for Linux and MPD for FreeBSD became popular alternatives to proprietary products.
However, warnings about the security issues of homemade cryptography were not groundless. The strengths of MMPE and MS-CHAP have been declining several times, and in 2012 the protocol was finally discredited: researchers proved that the strength of MS-CHAP-v2 is no better than DES.
After that, it became impossible to perceive PPTP as a secure protocol, and it quickly lost its last remnants of popularity.
Should you use PPTP?
Obviously strongly discouraged.
SSTP (Secure Socket Tunneling Protocol) is Microsoft’s second attempt to create its own VPN protocol. This time they did not invent their own cryptographic algorithms but used standard SSL / TLS. They also no longer interfere with the creation of free implementations.
SSTP is PPP over HTTPS. The obvious advantage is that it perfectly passes through NAT and theoretically even through a proxy. The advantage is far from unique, OpenVPN was able to work on top of TCP / 443 long before that.
OpenVPN, however, does not just use UDP by default, not TCP. Tunnels over TCP have serious performance problems – they can be tens of times slower on the same hardware.
Windows obviously has a built-in client – starting with Windows Vista. For Linux, there are client implementations and plugins for NetworkManager. There are also third-party clients for macOS such as EasySSTP. For mobile devices, you will also have to search and install third-party applications.
If you need to deploy an SSTP server, accel-pppd and SoftEther support it from free projects.
Should you use SSTP?
Unless if forced by corporate policy.
SoftEther is a multi-protocol VPN server similar to MPD or accel-ppp. It supports L2TP / IPsec, PPTP, SSTP, OpenVPN and the non-standard SoftEther protocol of the same name. This is a fairly young project, its first version was released in 2014.
SoftEther protocol is Ethernet over HTTPS. Since standard SSL is responsible for encryption and authentication, security is not a big issue.
The authors claim performance is ten times higher than OpenVPN. It’s hard to believe, but I have no opportunity to verify their statements. The client is only for Linux and Windows, so other platforms will have to use different protocols.
Should you use SoftEther?
If the authors’ performance claims are correct, it might be worth it.
The term SSL VPN without context is a common term but completely meaningless. “Supports SSL VPN” can mean both SSTP and OpenVPN and many incompatible proprietary protocols.
Almost every vendor has its own protocol. For example, Cisco AnyConnect, Juniper Pulse Connect, Palo Alto GlobalProtect.
If an organization has the widespread use of a client for such a protocol, it can be very difficult to change the equipment of a VPN concentrator – which is what vendors are trying to achieve.
The free OpenConnect project provides server and client implementations for the Cisco, Juniper, and Palo Alto protocols. The OpenConnect client runs on Windows and a variety of UNIX-like systems: not only Linux and macOS but also BSD systems and even Solaris.
OCServ can save an organization a lot of money because proprietary implementations often license these protocols per user.
Should you use OpenConnect?
If your organization has implemented one of these protocols and is now itself not happy – absolutely. Since none of these protocols are protected by patents (and there is nothing much to patent in them), the only real risk to the project’s existence is the lawsuits over trademarks.
There are no registered trademarks in the name of the project, so the risk is low. In addition, the project has existed since 2009, and until now none of the vendors have sued the authors.
VARIATIONS ON THE IPSEC TOPIC
It would seem that IPsec is the most standardized protocol of all, and all network equipment vendors support it. But with a standardized protocol, you can’t lure users into the vendor lock-in trap, so proprietary variations of IPsec are regularly invented.
Sometimes they solve a very real problem that is difficult to solve with pure IPsec.
For example, Cisco GETVPN (Group Encrypted Transport) simplifies the deployment of a secure network for MPLS users, since MPLS itself does not provide any protection against traffic interception.
In other cases, as with EZVPN, vendors try to bribe users with the relative ease of configuration compared to “normal” IPsec.
Should you use proprietary IPsec variations?
If the prospect of forever remaining tied to one supplier does not scare you … In the case of EZVPN, for example, some devices support only the server, and some only support the client, so the choice may also be limited to a specific model.
Most VPN protocols are point-to-point or star-based. Mesh networks are still quite an exotic scenario. Nevertheless, protocols for these purposes exist and are being developed.
The TINC project has been in development since 1998. This means it is older than OpenVPN, which released its first version in 2001. It supports Windows and all UNIX-like operating systems but does not have a version for mobile operating systems.
The main feature is the automatic creation of a mesh network. Even if there are many nodes in the network, traffic between them will be transmitted directly, rather than through a central server.
This could make TINC a working alternative to Dynamic Multi-Point VPN and the mentioned GETVPN for corporate networks. Well, or it could if network equipment vendors and popular free network operating systems supported it.
Should you use TINC?
At least it will be interesting to experiment for sure.
There are a lot of VPN protocols in the world. Even if you prefer to use only the most popular, it is useful to know about others – the choice will be more informed.