Enterprise VPN offers secure Internet access between local and remote locations. Here’s a short history of Virtual Private Networks (VPN) and the protocols that are used to make them possible.

The term Virtual Private Network (VPN) has been around for some time, starting in wide scale around the implementation of Microsoft Windows 95. The basic idea was to provide a secure way of allowing employees to access the organization’s internal network, without opening up the network to awaiting hackers.

This article takes a brief look at the history of VPN, the various protocols that have been developed and used over the years, and their modern children, which are in wide scale use on today’s networks. As a follow up, we’ll take a look at the top five enterprise VPN options available today.

VPN Evolution

The next few sections will cover the various VPN protocols that have evolved over the last 20 years.

  • Point to Point Tunneling Protocol (PPTP)

The first widely supported and used VPN protocol was the Point to Point Tunneling Protocol. PPTP utilized some familiar protocols to perform its operations, including Generic Routing Encapsulation (GRE) and the Point to Point Protocol (PPP). PPTP first encapsulates the traffic into a PPP frame; this frame is then wrapped into a GRE (modified) datagram and then finally wrapped into an IP datagram. Encryption and compression was possible, but not directly from PPTP instead at the encapsulated PPP level using the Microsoft Point-To-Point Compression (MPPC) and Microsoft Point-to-Point Encryption (MPPE). While PPTP is certainly one of the easiest and most supported (across multiple platforms) VPN protocols, it is also one of the most insecure ones, especially on modern hardware.

  • Internet Protocol Security (IPsec)

At about the same time the PPTO protocol was starting to become popular, the Internet Protocol security (IPsec) protocol was being developed and then finally standardized in 1995 (RFC 1825). Other commonly used protocols used along with IPsec were finalized and standardized in the following years and IPsec was widely supported in common operating systems around 1999-2000. IPsec uses two unique IP protocols: the Encapsulating Security Payload (ESP) — IP protocol 50, or Authentication Header (AH) — IP protocol 51, which provide authentication, integrity and confidentially (ESP only). It also uses Internet Security Association and Key Management Protocol (ISAKMP) to set up Security Associations that exist between IPsec endpoints. ISAKMP in turn uses protocols like Internet Key Exchange (IKE) or Kerberized Internet Negotiation of Keys (KINK).

IPsec can operate in one of two modes: transport (default) or tunnel. When in transport mode, only the IP payload is protected using either AH, ESP or both, where AH provides integrity and authentication protection for the whole original IP packet (including the header) while ESP provides confidentiality (encryption) and authentication for only the ESP header and encrypted payload. When in tunnel mode, the whole original IP packet is encapsulated inside AH and/or ESP, allowing the entire packet to be protected instead of just the original IP payload.

  • IKEv2 Tunnels

A further evolution of IPsec tunnels was the introduction of IKE version 2 in 2005. With IKEv1 there were a number of open issues that quickly became problematic, depending on the specific implementation. The goal behind IKEv2 was to fix these issues, including:

  • NAT traversal is built-in;
  • Lowers protocol overhead;
  • Added traffic reliability;
  • Added authentication support;
  • Added support for the Mobility and Multihoming Protocol (MOBIKE).
  • Layer 2 Tunneling Protocol (L2TP)

The Layer 2 Tunneling Protocol (L2TP) came about in 1999. Its creation came from combining some of the attributes of PPTP and the Cisco Proprietary Layer 2 Forwarding Protocol (L2F). L2TP operates by encapsulating a PPP datagram inside of a L2TP packet; this L2TP packet (header and payload) is then encapsulated inside of a UDP datagram, and finally this UDP datagram is encapsulated inside of an IP packet.

L2TP by itself does not provide confidentiality or strong authentication so it is commonly combined with IPsec. When used in this way, the IP packet formed from the process discussed above is then wrapped in IPsec ESP (in transport mode) and is commonly referenced as L2TP/IPsec.

  • Secure Socket Tunneling Protocol (SSTP)

The Secure Socket Tunneling Protocol (SSTP) was developed by Microsoft and allows PPP (primarily) or L2TP traffic to be tunneled using SSL 3.0/TLS over TCP port 443. SSL is used in this case to provide key negotiation, encryption and integrity protection. SSTP was primarily designed to work between a VPN endpoint and a central VPN concentrating device; the site to site configurations that are possible with IPsec are generally not supported.

SSTP has been implemented into Microsoft Windows versions from Vista SP1 forward, but does not have a wide implementation base outside of Microsoft and a select few Microsoft partners.

Support for SSTP is limited compared to some of the other alternatives, but it is still considered a highly secure option. SSTP is also commonly compared against OpenVPN, which is an open source alternative.

  • TLS and DTLS

Many of the newest VPN platforms, including the open source OpenVPN and proprietary vendor options, like Cisco AnyConnect, utilize a combination of VPN types depending on the specific network conditions. Other than those discussed above, one of the most commonly used methods is using “raw” Transport Layer Security (TLS) (think web pages). When using a customized client and TLS, traffic can be encapsulated inside a TLS tunnel between a device and an endpoint, or from endpoint-to-endpoint, depending on the implementation. This way the amount of overhead is kept to a minimum and NAT becomes a non-issue, as it can be problematic with IPsec.

The only problem with this is that TLS is designed to work using a reliable transport method, mainly TCP. While this works for many different situations, there are several cases where it does not. Many evolving technologies require both the flexibility and speed of unreliable transport (UDP) and the security of a traditional TLS tunnel. For these situations, a new solution was required that took advantage of the characteristics of a “raw” TLS tunnel and provided a method of delivering traffic in a way traditionally related by UDP, also referred to as with “datagram semantics;” for this the new Datagram TLS (DTLS) was designed. DTLS offers the security advantages of a TLS tunnel along with the mechanisms that allow the tunnel to exist in the first place, including methods of dealing with packet loss, reliability, and reorders

Comparison of Various Enterprise VPN

here are a number of different solutions on the market today which offer Virtual Private Network (VPN) functionality. Sometimes these solutions are included as part of a comprehensive suite of solutions and other times, they are offered as standalone products. This article will take a look at the top five enterprise VPN solutions available today.

F5 Networks VPN Solutions

The F5 Networks VPN solution was once offered both as a standalone product and as a part of a comprehensive suite. However, following the recent reorganization, it seems that F5 is looking to push only the offering that is part of the BIG-IP and Viprion comprehensive products. Whether this is a problem or not depends on the specific implementation, but it seems that the standalone VPN appliance may be at the end of its deployment life.

F5’s specific software module that includes VPN functionality is the Access Policy Manager (APM). This module includes a lot of different functions, including the ability to connect through the deployed appliance using F5’s BIG-IP Edge Client. This client is offered for all common desktop and mobile platforms. The amount of performance offered depends on the specific platform that the module is deployed on.

The BIG-IP Edge VPN Client uses TLS (transport layer security) and DTLS (datagram TLS) for its connection from the client to the appliance, allowing for delay sensitive and delay insensitive appliances to run without problems.

F5’s BIG-IP and VIPRION offerings are quite wide in terms of range of available processing power. The BIG-IP appliances are individual appliances with static hardware specifications which can be sized depending on the specific implementation. F5’s Viprion is a blade based platform that offers options for very large implementations. Finding specific VPN statistics using F5 resources however, has proven to be challenging as none of these types of statistics are commonly promoted in their data sheets. Nevertheless, here are some of F5’s devices and the relevant information.

F5’s physical appliances start at the BIG-IP 1600 and go up to the BIG-IP 11050, which is their largest standalone appliance. F5’s largest blade option is the Viprion 4800 Chassis, which offers up to eight blades , each of which offer the following specifications:

Included/Maximum SSL Transactions per Section (TPS)
F5 BIG-IP 1600 500/1,000
F5 BIG-IP 11050 500/20,000
F5 Viprion 4800 Chassis
(4340N Blade)

F5 also offers virtual appliances which are able to run the same modules as the physical appliances including the APM used for VPN. Keep in mind as well that the pricing for these appliances is based on the customer using these devices not just for VPN, but also as Appliance Delivery Controllers (ADC)

Cisco VPN Solutions

Like F5, Cisco’s VPN solution is based on a number of products that offer more than VPN termination. The AnyConnect Secure Mobility Client is the main piece of software sitting in the middle of Cisco’s VPN solution. It is able to be run on all common desktop and mobile operating systems and offers not only support for VPNs, but also other security functionality. For Cisco’s VPN functionality, AnyConnect offers support for TLS, DTLS and IPsec IKEv2; these support the majority of traffic types that would typically be supported over remote connections.

The AnyConnect client must of course be supported by a backend VPN termination solution; for this it uses either a model from the ASA 5500-X series or a Cisco IOS device running version 15.1(2)T or higher (although limited in client functionality). This second group of devices allows the client to be used in an expansive number of reasonably priced devices providing the ability to support VPN termination on a very small scale.

On a smaller sized platform, Cisco’s 1941, 2900 and 3900 series platforms all support hardware acceleration for DES, 3DES and AES for both IPsec and SSL VPNs. As for performance metrics, the only thing Cisco provides is the IPsec performance:

Tunnels Supported Throughput
Cisco 1941
(using ISM-VPN module)
Up to 500 Up to 550 Mbps using 1400-bytes sized packets
Cisco 2900 series
(using ISM-VPN module)
Up to 2,000 Up to 900 Mbps using 1400-bytes sized packets
(highest series model – 2951)
Cisco 3900 series
(using ISM-VPN module)
Up to 3,000 Up to 1,200 Mbps using 1400-bytes sized packets
(highest series model – 3945)

From here there are a number of different IOS device options, including many IOS-based switches up to the 6500 series switch, which offers VPN specific hardware acceleration modules.

VPN concentration services are also available through Cisco’s ASA 5500-X series next generation firewall platforms.

Tunnels Supported Throughput
Cisco ASA 5512-X
(smallest option)
Up to 3,000 Up to 200 Mbps
Cisco ASA 5555-X
(middle option)
Up to 5,000 Up to 700 Mbps
Cisco ASA 5585-X w/SSP-60 Up to 10,000 Up to 5 Gbps

Citrix VPN Solutions

Citrix VPN access solution is integrated into the NetScaler Gateway product. The NetScaler gateway, like NetScaler itself, is highly customizable and integrated into many Citrix product lines. However, it is not limited to just Citrix shops. The NetScaler Gateway offers more than SSL VPN functionality, including secure access to Citrix XenDesktop, XenApp, and XenMobile sessions, as well as secure network access to any server, along with device analysis and determination. The Citrix Gateway has support for both TLS and DTLS sessions, depending on the traffic requirements.

The Citrix Gateway is included in some form in all editions of the NetScaler ADC appliance and is fully integrated into Citrix applications. It can be deployed as either a virtual appliance or as part of an appliance solution.

The licensing is a bit confusing depending on the specific platforms that are deployed, or are going to be deployed. It is my recommendation to go over the options available with a Citrix representative before making a final decision on which VPN solution to choose, especially if other Citrix applications are or are going to be deployed into the target environment. Generally there are two different types of licenses: Platform licenses and Universal licenses. Most of the SSL VPN functionality requires a universal license.

The following specifications are from some of the available NetScaler appliances that can be used to deploy the NetScaler gateway solution:

The lowest level MPX platform is the 5550 (upgradable to the 5650), and the latest is the 22120, both of which include the following specifications:

Included/Maximum SSL Transactions per Section (TPS)
Citrix NetScaler MPX 5550 1,500
Citrix NetScaler MPX 22120 560,000

Dell SonicWALL VPN Solutions

With the acquisition of SonicWALL, Dell now offers a line of appliances that are dedicated to secure mobile and remote access, including the SRA appliances and the E-Class SRA appliances. The SRA appliances are focused on SMB environments with less than 500 employees; they are more limited in the extra functionality than their bigger E-Class brothers. The E-Class SRA appliances are not limited to being only used for VPN concentrators, but include mobility management as well as protection from malware and rogue device access protection, and bring your own device (BYOD) registration and policy management, to name a few.

The SRA appliances are split into three main offerings: SRA 1600, SRA 4600 and SRA virtual appliance. The following tables lists their relevant specifications:

Included/Maximum Users
Dell SonicWALL SRA 1600 5/50 (no more than 25 recommended)
Dell SonicWALL SRA 4600 25/500 (no more than 100 recommended)
Dell SonicWALL SRA Virtual Appliance 5/500
Dell SonicWALL EX6000 25/250
Dell SonicWALL EX7000 50/5,000
Dell SonicWALL EX9000 100/20,000
Dell SonicWALL EX Virtual Appliance 5/5,000

Pulse Secure (Formerly Juniper) VPN Solutions

Pulse Secure’s solution to the problem of mobile and remote access is a suite of applications which includes Pulse Secure MAG Gateway, Pulse Connect Secure and Plus Policy Secure. The Pulse Connect Secure product offers end user connectivity and security from any off-premises device via SSL VPN using either clientless access via a browser or via the Pulse Secure client. Pulse Policy Secure offers an advanced network access control solution with tight integration with Pulse Connect Secure.

The Pulse Secure MAG gateway platform includes four different physical appliance options along with a virtual appliance; the following tables lists their relevant specifications:

Maximum Concurrent SSL Sessions Maximum Concurrent Policy Secure Users
MAG 2600
(Connect Secure OR Pulse Secure)
100 250
MAG 4610
(Connect Secure OR Pulse Secure)
1,000 5,000
(per chassis – 2 SM) (per chassis – 2 SM)
MAG 6610
(Connect Secure And/Or Pulse Secure depending on secure module installed (2))
20,000 30,000
(per chassis – 4 SM) (per chassis – 4 SM)
MAG 6611
(Connect Secure And/Or Pulse Secure depending on secure module installed (4))
40,000 60,000


Along with the evolution of networks in general has come the need to maintain mechanisms to keep traffic safe from outside intrusions. VPNs provide one of the pieces in this puzzle that offer organizations the ability to maintain a flexible and possibly mobile workforce, along with high levels of security. As with other technologies, VPN has seen considerable changes as the need and requirements of enterprises have changed.

It does seem that the wind is certainly pushing the individual standalone VPN concentrator to be a thing of the past, as it is integrated further into Application Delivery Controllers (ADC), Next Generation Firewalls (NGFW) and Unified Threat Management (UTM) appliances. Even the two relatively standalone options discussed in this article (like SonicWALL and Pulse Secure) are full of integrated and optional features that fill the void with other similarly placed features.

It’s now much more difficult to separate a unified appliance into its component parts, in order to pull out the information that is just relevant to the VPN functionality. Some vendors, especially those that take the unified approach (like Citrix), are particularly weak in offering information on the application of a specific feature, without actually having to review configuration articles and getting rather deep into their support information. This is something to be aware of when looking for a VPN solution; know that the information is available somewhere, even if that means calling the vendor to get it.

On most modern networks, a remote access solution is something that most companies already have in place. It is also likely that if you’re reading this article, you’re looking to upgrade your current VPN solution with a modern equivalent. With BYOD becoming increasingly common and with threats continuing to build on a day to day basis, or more correctly minute by minute pace, these newer solutions offer both flexibility and additional security that meets the demands of modern networks. Hopefully the material covered in this article will give you some assistance in how to begin this journey.

Credit: TomITPro