Understanding VPN Remote Access Mechanism
Understanding VPN Remote Access Mechanism
Understanding VPN Remote Access Mechanism
com/understanding-vpn-remote-access-mechanism
Shareon Facebook
Tweeton Twitter
Shareon LinkedIn
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:
Traditional VPN
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.
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.
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.
Conclusion
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.
Links
Virtual private network – Wikipedia, the free encyclopedia