Understanding VPN Remote Access Mechanism
What is a Virtual Private Network (VPN)?
A VPN, or Virtual Private Network, is a group of two or more computer systems, typically connected to a private network, that communicates securely over a public network (typically the Internet). VPNs may exist between an individual machine and a private network (client-to-server or remote access) or a remote LAN and a private network (site-to-site).
Site to site VPNs involve the use of dedicated VPN hardware at each remote site. Remote access VPNs however, utilize a central site VPN concentrator and a software VPN client. The client is installed on the users’ desktop or laptop computers and enables the users to establish a secure, encrypted tunnel to the office network.
A VPN connection extends the boundaries of the physical network. Computers that gain access to a VPN can potentially access all the resources of the private network as if they were physically connected to it. This allows for workers, consultants, external vendors and offshore support to connect to the corporate network from any spot on earth, and perform their job remotely. The number of concurrent VPN connections is only limited by the public network bandwidth and the performance capabilities of the VPN server/appliance.
VPNs provide encryption and additional security measures to ensure that only authorized users have access to the network and its data. Traffic is encrypted in both directions while it travels the public network.
Since VPN is a secure method for allowing remote users access to a private network (and in most cases – cheaper and faster than old dial-up connections), VPNs are usually used in cases where remote users require secure access to network resources that could not be accessed in any other way. For example, VPNs enable administrators to remotely diagnose and solve problems and perform management tasks while away from the physical network. Remote users can also benefit from a VPN that allows access to their shared network or fax printers.
Some of the popular protocols applied for VPN security are:
- IPsec (IP Security)
- L2TP (Layer 2 Tunneling Protocol)
- PPTP (Point to Point Tunneling Protocol)
- SSL/TLS (Secure Socket Layer/Transport Layer Security)
The first 3 are considered as “traditional” VPN connections.
Traditional VPN connections most commonly use encryption protocols such as IPsec, L2TP or PPTP. Discussing the exact details and differences of each VPN-type is beyond the scope of this article, but it’s worth noting that the usually, the configuration of PPTP and L2TP remote access is much simpler than that of IPsec.
Traditional VPN connections have some drawbacks. First, they require the deployment of a special client or agent software. This can be a major headache to deploy, only works for a subset of devices and platforms, and is impractical for non-employees and un-managed devices.
The second issue is that traditional VPNs work by enabling a full network-layer connection. Because VPN traffic is trusted, it effectively bypasses the firewall. A VPN connection is considered as an entry point for security threats to enter the network. This raises the concern of controlling what type of traffic can be passed through these VPN connections, and what type of remote computers can actually connect to the corporate network. Often, these un-managed computers might not be fully patched against security vulnerabilities, not have an up-to-date anti-virus product, or not have their personal firewall turned on. Furthermore, after successfully connecting to the corporate network, these computers might initiate a type of connection to internal resources that is out of scope for the type of required connection.
In order to mitigate these risks there is need to implement a mechanism that will quarantine these computers until they provide proof of being fully patched and up-to-date. These types of quarantine systems can be achieved by using 3rd-party Network Admission Control (NAC) capabilities of VPN appliances such as those provided by Juniper, Check Point or Cisco, or by implementing the built-in Network Access Protection (NAP) found in Microsoft Windows Server 2008.
In order to control exactly what type of traffic is passed through the VPN connection, there is need to either deploy smart appliances such as those provided by Check Point, Cisco, Juniper or Microsoft (with their IAG product), or to place an additional firewall behind the VPN server that will scan the un-encrypted inbound traffic.
While traditional VPN solutions are also used by individual users that need access to their corporate network, since the introduction of SSL VPN, more organizations turn to SSL VPN for their end user connectivity solutions, and retain IPsec-based VPN tunnels for use principally for site-to-site communications (rather than individual client remote access). I.e. in scenarios where there is need to connect remote branch offices between themselves and to the main head office they will use IPsec-based VPN tunnels, and for mobile users travelling with their laptops, or for personnel working away from office they use SSL-based VPN.
What is a SSL VPN?
Like traditional VPN, SSL VPN extends the boundaries of the physical network over the public Internet, enabling remote users to securely access corporate resources as if they were located on the corporate network. However, SSL VPN provide this remote access over SSL (Secure Sockets Layer), also known as TLS.
In addition, when compared to IPSec, SSL is an application level transport protocol that transmits data over a standard TCP port (typically TCP port 443) while the IPSec uses its own Internet protocol which required firewall rules modifications. Instead of opening ports and protocols on the incoming firewall, and on the outgoing connection side, SSL VPN uses an industry-standard port that is usually open on most corporate firewalls, without the need to configure specific ports or protocol numbers. SSL VPN traffic is able to traverse a network to reach the end-point server even when the client is behind a Network Address Translation (NAT)-enabled network, Web proxy, or a corporate firewall.
What makes the implementation of SSL VPN easier than traditional VPN, is that the connections are initiated from a web-based portal, accessed by the client through a common web browser such as Internet Explorer. In most situations, this is much simpler to accomplish, does not need any client or agent installation and does not require special permissions. This makes such connections ideal for usage on un-managed and public computers such as the ones found in hotel lobbies and conference centers. Therefore, virtually any client with a network connection can use SSL VPN without needing additional VPN client software or a complex configuration and setup.
The definition of SSL VPN has evolved significantly since the first web-based VPN products were originally introduced. The original objective was to allow mobile users to access the growing number of web-based applications, including corporate mailbox access or “webified” database applications. However, the reality was that many organizations have many traditional client-server applications that cannot be “webified”, thus there’s need for more than just a Web-based VPN. In addition, many web applications where not SSL-enabled, and cannot be used over a standard web VPN. It’s also worth noting that as a performance factor, this type of connection places the most stress on the devices because of the need to re-write the web content that is presented to the client.
This is where the original intention of SSL VPN had to be changed, with new access methods introduced to provide the organizations’ needs. Many SSL VPN vendors quickly realized the shortcomings of this solution and began adding functionality that would extend support to non-web applications. Many SSL VPN products began to include web or Java based clients that provide access to pre-defined services such as Microsoft Terminal Services or Citrix, file shares, Telnet, and so on. Some SSL VPN vendors have Java or ActiveX applications that listen on the client machine and then encrypt traffic and send it to the SSL VPN gateway. In such a scenario, a small applet such as an ActiveX control is downloaded and installed on the user’s computer after the user signs on to the SSL VPN portal. The applet then intercepts the user’s web request and sends it off to the established SSL VPN connection. These applet transactions can take place in a manner that is fairly transparent to the end user so that the user does not even realize that he or she is dealing with a client.
Currently, SSL VPN resource access methods include:
- Reverse-proxy – This is the original intention of SSL VPN. The reverse-proxy-based method is the most common access method and is good for almost all users. Only a limited number of applications that can be made suitable for web use are supported in this case. These are normally web-based e-mail applications such as Microsoft OWA (Outlook Web Access). As mentioned above, up to recent years this was the predominant reason for using SSL VPN.
- Port forwarding – The port-forwarding clients can be used to support business partners or contractors who need to access a very limited number of client/server applications that cannot be adapted to the web. However, most of these solutions only support TCP data and cannot support applications that use other protocol types such as UDP or ICMP. In addition, most cannot support network applications that use dynamic TCP port address ranges, such as VoIP, Instant Messaging and NetMeeting.
- Tunnel client – Also known as a Full SSL VPN client. This is similar to a standard IPSec VPN client, however all data is sent over SSL, and unlike traditional VPN, establishing a connection is done without the need to deploy a client application or agent on the remote computer. Tunnel clients can be used to support power users that need full resource access. Because of their requirement of user privilege and their nature of full network access, tunnel clients should only be deployed on corporate-owned user systems, such as work laptops.
As mentioned, in most scenarios, SSL VPN is preferred for remote access to those applications that are browser-based (i.e., have a web-based user interface), while IPsec VPN will be used principally for site-to-site communications (rather than individual client remote access). As for security comparison, there’s really no difference between IPsec VPN and SSL VPN. Both are equally secure.
Because remote users can access the network from any location, not just from dedicated laptops or remote VPN sites, companies can easily setup secure Extranets for business partners and customers. SSL VPNs can provide fine-grained application level filtering, which allows easier usage and deployment. In addition, remote users do not need to remember the names or IP addresses of machines on the corporate network to access corporate servers and applications, because all resources can be made available to remote users in form of bookmarks, favorites or web links.
SSL VPNs are evolving to meet the industry’s requirements. They started as a dedicated VPN solution and slowly became integrated with other network and security services. Generally speaking, there are 2 types of SSL VPN solutions currently on the market: pure SSL VPN appliances, and the more sophisticated solutions that integrate with other network devices such as routers and firewalls. The second type provides enterprises with the option to deploy a single security device that offers multiple security services such as a firewall, a VPN, anti-virus, anti-spam, and other content security services.
While many vendors has SSL VPN solutions available (Cisco, 3COM, Check Point, Nortel and many others), Juniper Networks’ Secure Access SSL VPN appliances are mostly considered as the leading brand with this type of remote access mechanism.
It’s worth mentioning the Windows Server 2008 SSL VPN implementation called Secure Socket Tunneling Protocol (or SSTP). SSTP is an SSL-based client-to-server VPN tunneling protocol designed to make connectivity much easier. By using SSTP you can reduce the overall cost associated with a remote access solution because the SSTP component is an integral part of the Windows Server 2008 Routing and Remote Access Server role. Connecting to SSTP-based VPN servers requires that the clients run Windows Vista SP1 or higher, and that the RRAS server runs Windows Server 2008 SP1 or higher.
Do I need VPN?
The security issues involved with granting remote access capabilities for users, vendors, partners and external consultants are obvious. Unless taken into consideration, these security issues might pose a real threat to the company’s data integrity. Therefore, if VPN is the only remote access method of to a network, it is essential that the right measures will be taken in order that VPN users be granted only the minimum access necessary to do their jobs.
In some cases, it may not be wise to grant VPN access at all. Many client/server applications can now be deployed with alternatives to giving the user full remote access capabilities.
For example, users who require only email access to their corporate mailbox should not be given access through a VPN. Instead, they can access their email through Outlook Web Access (OWA) feature that allows them to access their email through a Web browser without having to logon the entire network, or even better, by using the RPC over HTTP capabilities of Exchange Server 2003/2007 and the Outlook 2003/2007 client.
Another example is Remote Desktop/Terminal Server access. Users that require access to their desktops, to terminal Servers, or to published applications used to need a VPN connection to the computer that was running TS/RDP. Nowadays, the capabilities of Microsoft Windows Server 2008 TS Gateway provide further protection of RDP traffic by encapsulating it into SSL packets – much like SSL VPN, but without the need to deploy special VPN servers.
VPNs are changing the way that businesses communicate. Traditionally, in order to deploy a wide area network, organizations would need to procure expensive leased line technology to connect their offices. Nowadays, VPN can run over public networks (like the Internet) whilst providing data security and integrity. SSL VPN has taken its position as the leading remote access mechanism for many organizations, allowing clientless access to web applications and, with some limitations, to client/server applications inside the corporate network. When taking security measures to prevent malicious code from entering the network from un-managed clients, VPN is a formidable way to extend the physical boundaries of the corporate network.
Recent Cisco Routers & Switches How-to Forum threads
Got a question? Post it on our Cisco Routers & Switches How-to Forum!
More in Windows Server 2008
Microsoft Acknowledges New Netlogon Issues On Windows Server Machines
Feb 25, 2022 | Rabia Noureen
How to Fully Patch the PrintNightmare Vulnerability
Jul 9, 2021 | Brad Sams
Everything You Need to Know About Windows – January 2020
Feb 3, 2020 | Russell Smith
Paul Thurrott's Short Takes: Microsoft Earnings Special Edition
Jan 31, 2020 | Paul Thurrott
SCARY: “Atom Bomb” Windows Security Hole said to be Unfixable
Oct 31, 2016 | Richi Jennings
Microsoft’s New Patching Philosophy Sacrifices A Few For The Many
Aug 19, 2016 | Brad Sams
Most popular on petri