So different VPN. Analyzing VPN protocols

The content of the article

PPTP
SSTP
SoftEther
OpenConnect
Variations on IPsec
Client IPsec
TINC
Conclusion

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 a pressing problem for some part of 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’ll talk about several of these protocols.

PPTP

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 anymore, but ten years ago it 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 the built-in Windows client automatically made the report 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 the same sore subject as GIF and MP3. Then 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 were repeatedly reduced, 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

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 prevent free implementations from being created.

SSTP is PPP over HTTPS. The obvious advantage is that it passes perfectly 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, doesn’t just use UDP by default, not TCP. Tunnels over TCP have serious performance problems – they can be ten 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

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 available 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.

OPENCONNECT

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 such protocol. For example, Cisco AnyConnect, Juniper Pulse Connect, Palo Alto GlobalProtect. If an organization has a 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 special to patent in them), the only real risk to the project’s existence is lawsuits over trademarks. Registered trademarks do not appear in the project name, 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 IPSEC

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 on 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.

CLIENT IPSEC

Speaking of IPsec. It is typically used for fixed site-to-site tunnels or as a secure transport for another protocol like L2TP. The old IKEv1 protocol was indeed ill-suited for client connections. However, modern IKEv2 does a much better job. Moreover, built-in support for this kind of tunnels is present in all systems, including Windows, macOS and mobile devices.

There are also no problems with free server implementations, the same StrongSWAN officially supports client connections.

Should I use client-side IPsec?

If you are setting up a server from scratch and want built-in client support in all common operating systems, it is definitely worth considering this option along with L2TP / IPsec.

TINC

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.