Ideally, the VPN Protocol should be secure, functional, and fast. But there is another factor: popularity. An unpopular Protocol is harder 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. Sometimes, on the other hand, the Protocol of independent developers solves such a pressing problem of some part of users that it quickly gains popularity by itself. This is what 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 such protocols.
PPTP
The Point-to-Point Tunneling Protocol (PPTP) is quite rightly on the back burner. I would like to believe that young readers have not encountered it yet, 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 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. The PPTP Protocol used standard PPP and GRE for data transmission, 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 PPTP servers were once as much a sore subject as GIF and MP3. Then the patents expired, and poptop for Linux and MPD for FreeBSD became popular alternatives to proprietary products.
However, warnings about the security issues of homemade cryptography were not unfounded. THE mmpe and MS-CHAP durability ratings were repeatedly lowered, and in 2012 the Protocol was finally discredited: researchers proved that the MS-CHAP-v2 durability is no better than DES. After that, it became impossible to perceive PPTP as a secure Protocol, and it quickly lost the last remnants of popularity.
Should I use PPTP?
Obviously, it is 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 the creation of free implementations.
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, does not just use UDP by default, not TCP. TCP tunnels have serious performance problems - they can be dozens 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 for and install third-party apps.
If you need to deploy an SSTP server, some of the free projects support it accel-pppd and SoftEther.
Should I use SSTP?
Unless it is forced by corporate policy.
SOFTETHER
SoftEther - Multiprotocol 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.
The SoftEther Protocol is Ethernet over HTTPS. Since standard SSL is responsible for encryption and authentication, security does not raise any special questions.
The authors claim performance ten times higher than OpenVPN. It's hard to believe, but I don't have the opportunity to verify their statements. The client is available only for Linux and Windows, so you will have to use other protocols on other platforms.
Should I use SoftEther?
If the authors claims about performance are correct, maybe you should.
OPENCONNECT
The term SSL VPN without context is often used, but completely meaningless. "Supports SSL VPN" can mean both SSTP and OpenVPN, and many incompatible proprietary protocols.
Almost every vendor has its own Protocol. Например, Cisco AnyConnect, Juniper Pulse Connect, Palo Alto GlobalProtect. If your organization has a widely used client for this Protocol, it can be very difficult to change the VPN hub hardware - which is exactly what vendors are trying to achieve.
Free project OpenConnect provides server and client implementations for the Cisco, Juniper, and Palo Alto protocols. The OpenConnect client runs on Windows and many UNIX-like systems: not only Linux and macOS, but also BSD systems and even Solaris.
An OCServ server can save an organization a lot of money, since proprietary implementations often license these protocols per user.
Should I use OpenConnect?
If your organization has implemented one of these protocols and is now not happy about it, then it should definitely do so. Since none of these protocols are protected by patents (and there is not much to patent in them), the only real risk to the project's existence is trademark lawsuits. Registered trademarks do not appear in the project name, so the risk is low. In addition, the project has existed since 2009, and so far none of the vendors have sued the authors.
VARIATIONS ON THE IPSEC THEME
It would seem that IPsec is the most standardized Protocol of all, and it is supported by all network equipment vendors. But with a standardized Protocol, you can't lure users into the vendor lock-in trap, so proprietary variations are regularly invented on the topic of IPsec.
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 I use proprietary variations of IPsec?
If the prospect of being permanently tied to one vendor doesn't scare you... In the case of EZVPN, for example, some devices support only the server, and some only the client, so the choice may also be limited to a specific model.
CLIENT-SIDE IPSEC
Speaking of IPsec. It is usually used for fixed site-to-site tunnels, or as a secure transport for another Protocol like L2TP. The old IKEv1 Protocol was indeed poorly adapted for client connections. However, the modern IKEv2 copes much better. Moreover, native support for this type of tunnel is available on all systems, including Windows, macOS, and mobile devices.
There are no problems with free server implementations either, and 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, at least consider this option along with L2TP/IPsec is definitely worth it.
TINC
Most VPN protocols rely on point - to-point or star topologies. Mesh networks are still quite an exotic scenario. Nevertheless, protocols for these purposes exist and are being developed. The TINC project has been developed since 1998. This means that it is older than OpenVPN, which released its first version in 2001. It supports Windows and all UNIX-like operating systems, but it doesn't have mobile OS versions.
The main feature is the automatic construction of a mesh network. Even if there are many nodes in the network, traffic between them will be transmitted directly, and not through a Central server. This can make TINC a working alternative to Dynamic Multi-Point VPN and the aforementioned GETVPN for enterprise networks. Well, or it could, if network hardware vendors and popular free network operating systems supported it.
Should I use TINC?
At the very least, it will definitely be interesting to experiment.
CONCLUSION
There are a great many VPN protocols in the world. Even if you prefer to use only the most popular ones, knowing about others is not useless the choice will be more informed
Sometimes protocols become popular despite their technical shortcomings, simply because of aggressive promotion by a large company. Sometimes, on the other hand, the Protocol of independent developers solves such a pressing problem of some part of users that it quickly gains popularity by itself. This is what 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 such protocols.
PPTP
The Point-to-Point Tunneling Protocol (PPTP) is quite rightly on the back burner. I would like to believe that young readers have not encountered it yet, 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 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. The PPTP Protocol used standard PPP and GRE for data transmission, 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 PPTP servers were once as much a sore subject as GIF and MP3. Then the patents expired, and poptop for Linux and MPD for FreeBSD became popular alternatives to proprietary products.
However, warnings about the security issues of homemade cryptography were not unfounded. THE mmpe and MS-CHAP durability ratings were repeatedly lowered, and in 2012 the Protocol was finally discredited: researchers proved that the MS-CHAP-v2 durability is no better than DES. After that, it became impossible to perceive PPTP as a secure Protocol, and it quickly lost the last remnants of popularity.
Should I use PPTP?
Obviously, it is 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 the creation of free implementations.
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, does not just use UDP by default, not TCP. TCP tunnels have serious performance problems - they can be dozens 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 for and install third-party apps.
If you need to deploy an SSTP server, some of the free projects support it accel-pppd and SoftEther.
Should I use SSTP?
Unless it is forced by corporate policy.
SOFTETHER
SoftEther - Multiprotocol 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.
The SoftEther Protocol is Ethernet over HTTPS. Since standard SSL is responsible for encryption and authentication, security does not raise any special questions.
The authors claim performance ten times higher than OpenVPN. It's hard to believe, but I don't have the opportunity to verify their statements. The client is available only for Linux and Windows, so you will have to use other protocols on other platforms.
Should I use SoftEther?
If the authors claims about performance are correct, maybe you should.
OPENCONNECT
The term SSL VPN without context is often used, but completely meaningless. "Supports SSL VPN" can mean both SSTP and OpenVPN, and many incompatible proprietary protocols.
Almost every vendor has its own Protocol. Например, Cisco AnyConnect, Juniper Pulse Connect, Palo Alto GlobalProtect. If your organization has a widely used client for this Protocol, it can be very difficult to change the VPN hub hardware - which is exactly what vendors are trying to achieve.
Free project OpenConnect provides server and client implementations for the Cisco, Juniper, and Palo Alto protocols. The OpenConnect client runs on Windows and many UNIX-like systems: not only Linux and macOS, but also BSD systems and even Solaris.
An OCServ server can save an organization a lot of money, since proprietary implementations often license these protocols per user.
Should I use OpenConnect?
If your organization has implemented one of these protocols and is now not happy about it, then it should definitely do so. Since none of these protocols are protected by patents (and there is not much to patent in them), the only real risk to the project's existence is trademark lawsuits. Registered trademarks do not appear in the project name, so the risk is low. In addition, the project has existed since 2009, and so far none of the vendors have sued the authors.
VARIATIONS ON THE IPSEC THEME
It would seem that IPsec is the most standardized Protocol of all, and it is supported by all network equipment vendors. But with a standardized Protocol, you can't lure users into the vendor lock-in trap, so proprietary variations are regularly invented on the topic of IPsec.
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 I use proprietary variations of IPsec?
If the prospect of being permanently tied to one vendor doesn't scare you... In the case of EZVPN, for example, some devices support only the server, and some only the client, so the choice may also be limited to a specific model.
CLIENT-SIDE IPSEC
Speaking of IPsec. It is usually used for fixed site-to-site tunnels, or as a secure transport for another Protocol like L2TP. The old IKEv1 Protocol was indeed poorly adapted for client connections. However, the modern IKEv2 copes much better. Moreover, native support for this type of tunnel is available on all systems, including Windows, macOS, and mobile devices.
There are no problems with free server implementations either, and 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, at least consider this option along with L2TP/IPsec is definitely worth it.
TINC
Most VPN protocols rely on point - to-point or star topologies. Mesh networks are still quite an exotic scenario. Nevertheless, protocols for these purposes exist and are being developed. The TINC project has been developed since 1998. This means that it is older than OpenVPN, which released its first version in 2001. It supports Windows and all UNIX-like operating systems, but it doesn't have mobile OS versions.
The main feature is the automatic construction of a mesh network. Even if there are many nodes in the network, traffic between them will be transmitted directly, and not through a Central server. This can make TINC a working alternative to Dynamic Multi-Point VPN and the aforementioned GETVPN for enterprise networks. Well, or it could, if network hardware vendors and popular free network operating systems supported it.
Should I use TINC?
At the very least, it will definitely be interesting to experiment.
CONCLUSION
There are a great many VPN protocols in the world. Even if you prefer to use only the most popular ones, knowing about others is not useless the choice will be more informed
