VIRTUAL PRIVATE NETWORK (VPN) is a general industry term that actually covers a many different technologies. Ask anyone who works in a large company and needs to access a corporate network remotely and he or she will probably confirm using a VPN to connect to the network and get to his or her e-mail, intranet, and other corporate applications. Ask him or her how that VPN works, however, and you will almost always get a blank stare. End users are typically interested only in the result of a solution, not in how it works. For you the information security practitioner, however, just how a VPN works is as important as what benefits aVPN provides your organization.
VPNs deploy in a number of different ways, leveraging a variety of technologies, platforms and protocols. Determining which VPN is the right fit for your organization requires successfully gathering and interpreting your business requirements. Once you've documented those requirements, it's up to you as the security practitioner to understand those different options and capabilities to fit the VPN technology to the appropriate business requirements.
A variety of technical factors affect the selection and installation a VPN solution. Some VPNs are available as software installed on a workstation or a server. Other VPNs are software components of other devices, like a router or a firewall. Finally, dedicated VPN hardware appliances provide secure remote connectivity.
You need to know that a variety of underlying protocols can provide different functions, features, and levels of encryption. When a vendor starts talking about L2TP, IPv6, SSL and SSH, or IPSec, you'll need to speak the lingo and make the right technology decision for your organization.
Finally, other infrastructure considerations you need to take into account when working with VPN technologies include how things like network address translation (NAT), Internet Protocol version, and the use of virtualization can affect how you deploy, maintain, and troubleshoot a VPN.
A key topic in discussing VPN technologies is the differences between software and hardware solutions. The following definitions help reveal those differences:
Note
In the early days of VPNs, VPN software commonly ran on a Windows or UNIX server. Today, server-based implementations show up mostly in small environments because of the poor scalability and reliability of the operating system. Most software VPNs act as a component of a firewall or router, not as an add-on to a server.
Software VPN—Software-based VPNs are sold either as part of a server operating system, as part of an appliance operating system, or as a third-party add-on software solution.
Hardware VPN—A hardware VPN is a standalone device, dedicated to managing VPN functions such as authentication, encapsulation, encryption, and filtering.
While the functionality of software and hardware VPN solutions are essentially the same, providing a secure remote connection on demand points out some important differences.
When evaluating whether or not to deploy a software VPN, consider two types of software VPNs:
Operating System-based VPN—An operating system-based VPN solution is an application that runs on a Windows or UNIX operating system. These are generally used in smaller companies, as they tend to be less scalable and less stable than other VPN solutions. They are generally less expensive, especially as they are running on a shared server, which may be running other applications. Many of these solutions are open source, which further reduces the cost, although it can increase the complexity of the solution.
One potential security issue with this solution is that the server communicates with the public network (generally the Internet) for the connections to occur. Any time you connect a server and the associated operating system to a public network, you increase the security risk, since you are exposing it to a much larger pool of attackers. You can mitigate this risk by limiting the ports open to the server, and, if you are doing just site-to-site VPN connections, you can sometimes restrict the connections to specified IP addresses. You can also add a firewall to the VPN server, which adds to the overhead on the server, but will provide additional protection to offset the increased exposure.
Module-based VPN—A module-based VPN runs as a component on a larger system. These are sometimes included as part of the overall feature set, or in other cases may require the purchase of additional licenses to use the VPN. An example of this would be the VPN capability included with many firewalls. Many routers also offer this type of capability, which permits the easy encryption of WAN links for security-conscious companies. The benefit of this type of VPN solution is reduced complexity of the environment, since you have fewer discrete devices to manage. VPN modules are also typically less expensive than hardware VPN solutions. Some vendors also offer hardware accelerators for improving overall performance of this solution.
Hardware VPNs are dedicated appliance-based solutions, generally based on a router-type platform. Hardware VPNs are the most common type of VPN deployed in corporations today. While hardware VPNs can be complex to deploy, they are typically more scalable than their software counterparts, and can be easily deployed in a redundant manner. Hardware VPNs can increase the complexity of an environment, because you are deploying additional equipment. The good news is that you can usually manage this additional hardware with the same types of network management tools you use to manage the routers and switches in an environment.
Hardware VPNs can create some security issues, largely related to potential vulnerabilities in the VPN software code on the appliance itself. A number of security alerts related to VPN vulnerabilities have appeared in recent years. Fortunately, you can manage this issue fairly easily by keeping current on your vendor's security alerts and by upgrading VPN code in a timely fashion. A good rule of thumb is to run the N-1 version of code, where N is the current version of code, unless a known issue with that previous version of the code has been published.
Note
You must make a risk-based decision on whether to accept the possibility of undiscovered bugs in a new version of hardware or to live with the known bugs in a previous version. If an upgrade is issued primarily for fixing security flaws, you may be better off with the new version, surprises and all.
Ultimately, the requirements of your business will drive your selection of a software or hardware VPN. The good news is many options are available to you in your search for the best solution.
One facile component of current VPNs is that they use a variety of transport protocols to establish their connections. This is helpful not only because the protocols have different capabilities, encryption strengths, and authentication mechanisms, but they also can run at different layers of the OSI (open systems interconnection) model. The OSI model is the standard seven-layer conceptual tool that describes protocols and their functions. Each layer communicates with its peer layer on the other end of a communication session. While the OSI model is helpful in discussing protocols, most protocols are not in full compliance with it.
In the case of VPNs, the protocols used by the vast majority of solutions work at Layers 2 and 3 of the OSI model.
Layer 2 of the OSI model is the Data Link layer. The Data Link layer is the protocol layer that transfers data between adjacent network nodes. In the case of a VPN, this protocol transfers data from one VPN endpoint to the other.
An example of a protocol that communicates using Layer 2 would be Layer 2 Transport Protocol (L2TP).
Layer 3 of the OSI model is the Network layer. The Network layer is responsible for end-to-end packet delivery and includes the ability to route packets through intermediate hosts.
An example of a VPN protocol that communicates at Layer 3 is IPSec.
Internet Protocol Security (IPSec) is a standards-based protocol suite designed specifically for securing Internet Protocol (IP) communications. IPSec authenticates and encrypts each IP packet in an IP data stream. In addition, IPSec has protocols that can establish mutual authentication and cryptographic key negotiation during a session. IPSec operates at the Network layer of the OSI model.
The IPSec standard utilizes three major components:
According to the National Institute for Standards and Technology (NIST), authentication header (AH) provides integrity protection for packet headers and data, as well as user authentication. It can optionally provide replay protection and access protection. AH cannot encrypt any portion of a packet. In the initial version of IPSec, the ESP protocol could provide only encryption, not authentication, so AH and ESP were often used together to provide both confidentiality and integrity protection for communications. Because authentication capabilities were added to ESP in the second version of IPSec, AH has become less significant; in fact, some IPSec software no longer supports AH. However, AH is still of value because AH can authenticate portions of packets that ESP cannot. Also, many existing IPSec implementations use AH.
Encapsulating Security Payload (ESP) is the second core IPSec security protocol, NIST's Guide to IPsec VPNs notes. In the initial version of IPSec, ESP provided only encryption for packet payload data. Integrity protection was provided by the AH protocol if needed. In the second version of IPSec, ESP became more flexible. It can perform authentication to provide integrity protection, although not for the outermost IP header. Therefore, in all but the oldest IPSec implementations, ESP can provide encryption only, encryption and integrity protection, or integrity protection only. This chapter mainly addresses the features and characteristics of the second version of ESP.
Internet key exchange (IKE) negotiates, creates, and manages security associations. Security association (SA) is a generic term for a set of values that define the IPSec features and protections applied to a connection. You can also create SAs manually, using values agreed upon in advance by both parties, but because these SAs cannot be updated, this method does not scale for real-life large-scale VPNs. In IPSec, IKE provides a secure mechanism for establishing IPSec-protected connections. IPSec supports two different modes:
Note
IPSec supports the Data Encryption Standard (DES), a 56-bit encryption protocol and 3DES (data is encrypted three times using DES), which effectively yields a 168-bit encryption protocol.
Transport mode (host-to-host)—In transport mode, only the data packet payload is encapsulated, while the packet header is left intact. In this mode, the destination host decapsulates the packet. This is the mode used in a Microsoft Windows environment to secure a client-to-server connection using IPSec.
Tunnel Mode (gateway-to-gateway or gateway-to-host)—In the tunnel mode, the IP packet is entirely encapsulated and given a new header. The host/gateway specified in the new IP header, decapsulates the packet. This is the mode used to secure traffic for a remote access VPN connection from the remote host to the VPN concentrator on the internal network.
IPSec is a little different from some of the other protocols. It provides high-quality interoperable, cryptographically based security for IPv4 and IPv6. As a result, the protocol supports a comprehensive set of security services, including:
Access control
Connectionless data integrity checking
Data origin authentication
Replay detection and rejection
Confidentiality using encryption
Traffic flow confidentiality
IPSec-based VPNs have been the dominant VPN platform for many years, although in recent years SSL-based VPNs have been making significant inroads. IPSec is so popular for three reasons:
It supports all operating system platforms.
It provides secure, node-on-the-network connectivity.
It offers a standards-based solution, permitting easier interoperability between different devices and vendors.
For more information on IPSec, see http://tools.ietf.org/html/rfc4301. While RFC4301 provides the main IPSec standard definitions, separate RFCs exist for some IPSec features. The full set of RFCs defines the entire standard.
Layer 2 Tunneling Protocol (L2TP) is an older protocol largely replaced by IPSec and SSL/TLS-based VPNs in production environments. You will still encounter references to the protocol in current VPN literature, and it may still be in use in some older environments, where backwards compatibility could still be an issue. L2TP was used extensively in the early VPN solutions, but lost its popularity as other protocols proved to be more usable as industry standards developed.
L2TP is a combination of the best features of Point-to-Point Tunneling Protocol (PPTP), a Microsoft proprietary protocol and the Layer 2 Forwarding (L2F) protocol, which was an early competing protocol for PPTP, developed by Cisco Systems. Like PPTP, L2TP was an extension of Point-to-Point Protocol (PPP) to allow PPP to be tunneled through an IP network. L2TP support was first included in a Microsoft server product with the release of Windows 2000 Server. Prior to Windows 2000, PPTP was the only supported protocol. A number of hardware VPN vendors, including Cisco, also supported it.
One of the challenges with L2TP is that it only provides a mechanism for creating tunnels through an IP network. It doesn't provide a mechanism for encrypting the data being tunneled. As a result, L2TP was typically used in conjunction with IPSec protocol's ESP (Encapsulating Security Payload) for encryption. For this reason, you may sometimes see L2TP referred to as L2TP/IPSec.
RFC 3193 defines the use of IPSec to secure an L2TP implementation.
For more information on IPSec, see http://tools.ietf.org/html/rfc2661. While RFC2661 provides the main L2TP standard definitions, separate RFCs for some other implementations and features exist. The full set of RFCs defines the entire standard.
Remember that you may never encounter L2TP in a production environment, but you should know the basic aspects of this protocol when looking at tunneling and VPN protocols in general.
One of the key VPN protocols today is SSL/TLS, which is the main alternative for a VPN solution if you don't want to leverage an IPSec solution. However, before you consider this protocol in conjunction with VPNs, it's important to understand the origin of this protocol.
If you have ever surfed the World Wide Web, you have used the Hypertext Transfer Protocol (HTTP) to connect to a Web site. One of the drawbacks of HTTP is that is does not include the ability to encrypt or otherwise protect the data stream between the client and server. This wasn't an issue until the early 1990s, when the need to protect against eavesdropping on communications became critical to the ultimate success of the World Wide Web. While several technologies have addressed this need, one solution has rapidly become the industry standard: Secure Sockets Layer (SSL).
Note
SSL supports 128-bit encryption, while TLS will support the Advanced Encryption Standard (AES) with keys up to 256 bits.
HTTPS is the Web protocol that utilizes SSL to encrypt HTTP, and is used worldwide today for secure Web communications. (See Figure 12.1)
SSL was originally proposed as a standard by Netscape. Version 1.0 had serious security flaws, which were corrected in versions 2.0 and 3.0. As this protocol has become more widely used, it has been formalized in the IETF standard known as Transport Layer Security (TLS). The SSL/TLS protocol provides a method for secure client/server communications across a network. SSL/TLS prevents eavesdropping and tampering with data in transit. SSL/TLS also provides endpoint authentication and communications confidentiality through encryption.
In typical end-user/browser usage, SSL/TLS authentication is one-way. Only the server is authenticated when the client compares the information entered to access a server to information on the SSL certificate on the server. The client knows the server's identity, but not vice versa; the client remains unauthenticated or anonymous. See Figure 12-2 for an example of the information in a server certificate.
SSL/TLS can also perform bidirectional authentication by using client-based certificates. This is particularly helpful when using this protocol to access a protected network, as it adds an additional layer of authentication to the access.
As you learned in the section on IPSec, a VPN creates a secure tunnel through a public network like the Internet. While SSL VPNs still leverage the concept of tunneling, they create their tunnels differently than IPSec. An SSL VPN establishes connectivity using the SSL protocol. IPSec works at the Layer 3 of the OSI model, while SSH functions at Layers 4 and 5. SSL VPNs can also encapsulate information at Layers 6 and 7, which makes SSL VPNs some of the most flexible available.
On additional function of an SSL VPN is that it usually connects using a Web browser, whereas an IPSec VPN generally requires client software on the remote system.
SSL VPNs create predominantly remote access VPN connections, where a client connects to applications on an internal network. This is different from a site-to-site connection, where two gateways connect disparate private networks across the Internet.
SSL/TLS VPNs benefits over IPSec VPNs include:
Less expensive—Since an SSL VPN is typically clientless, you don't have the costs of rolling out, supporting, and updating client software.
Platform independent—Since the access to an SSL VPN comes through the standard SSL interface, which is a component of virtually every Web browser, virtually any OS that runs a browser is supported. While the operating system (OS) support for VPN clients is good for common OSs, a significant lag can exist in client development following the release of a new OS or the release of a new client version. You may see a Windows client 90 to 180 days earlier than the Mac version.
Client flexibility—As a general rule, IPSec clients are generally installed only on corporate systems, as you learned in Chapter 11, VPN Management. Due to the additional configuration flexibility, SSL VPNs allow access from a variety of clients including corporate systems, home systems, customer or supplier systems or even a kiosk machine in a library or an Internet cafe. This wider accessibility tends to increase employee satisfaction with the technology.
Network Address Translation (NAT) is not a problem—Historically, NAT caused issues with IPSec VPNs. As a result, virtually all IPSec vendors have created workarounds for this issue. With an SSL VPN, you don't have these issues because SSL works at a higher layer than IPSec, and, as a result, is not affected by NAT.
Granular access control—A benefit or a drawback, depending on your environment. SSL VPNs require a greater granularity of access than a typical IPSec VPN because instead of creating a tunnel from the host to the internal network, SSL VPNs require explicit definition of each resource accessed. The upside is that, unless you have defined it explicitly, an SSL VPN user cannot access the resource. Although this barrier has significant security benefits, in a complex environment this could add significant overhead to your VPN support.
Fewer firewall rules required—To access an IPSec gateway across a firewall, you need to open several ports to support the individual protocols for authentication and the tunnel. With an SSL VPN, you need to open only port 443, which is easy because of the prevalence of the HTTPS protocol.
For more information on TLS, see http://tools.ietf.org/html/rfc5246.
The Secure Shell (SSH) protocol is a method for secure remote login and other secure network services over a public network such as the Internet. SSH service a number of applications across multiple platforms including UNIX, Microsoft Windows, Apple Mac, and Linux.
You can use SSH:
For login to a shell on a remote host (replacing Telnet and rlogin) (See Figure 12.3 for an example of an application that uses SSH for this application)
For executing a single command on a remote host (replacing rsh)
For file transfers to a remote host
In combination with rsync to back up, copy, and mirror files securely
In conjunction with the OpenSSH server and client to create a full VPN connection.
The SSH protocol consists of three major components:
For more information on SSH, see http://tools.ietf.org/html/rfc4251.
Now that you have an in-depth understanding of the many options available to you for both VPN as well as other secure access protocols, it's time to discuss some of the challenges you might encounter when supporting your VPN. For your VPN rollout to be successful, consider two factors: performance and stability.
Some critical factors can affect the performance of your VPN:
VPN type—When considering the performance of your VPN, consider the type of VPN you've chosen. The performance characteristics of a VPN supporting remote clients can be very different from the performance characteristics of a VPN supporting site-to-site connections, or even a mixed remote client and site-to-site connections.
Protocol—The performance characteristics associated with an IPSec VPN can be very different from what you may find with an SSL VPN implementation. How you apply IPSec and SSL/TLS in a VPN solution can affect your VPN's performance. Validating the performance specifications of the solution before you rollout should allow you to address any performance issues associated with the protocol start-up.
Load—The number of remote access or site-to-site VPNs will affect the overall performance of your VPN rollout. The challenge in addressing this issue, particularly in an environment supporting a large pool of remote clients, is that the performance issues will tend to crop up during peak use. To appropriately diagnose these issues, you'll need to be able to report on use in a way that tracks the peaks. Many of the current reporting tools available for VPNs tend to show averages over time, which can hide peaks and valleys in your use numbers. Be sure you fully understand these performance reports.
Client Configuration—In a remote VPN connection, much of the performance is actually related to the client's capabilities. If the remote client is running on old hardware with limited memory and an underpowered processor, the overhead associated with encrypting the traffic will affect performance of the VPN connection. Another factor contributing to overhead is: what else is being done with the remote PC? If the user is running a memory-intensive application such a photo editing suite, you may find that this resource impact reduces the performance of the VPN.
Note
Don't forget time-of-day considerations when investigating load-related performance issues. You will generally find your peak times for VPN use will be first thing in the morning, as employees get started for the day; after lunch, when everyone comes back from the break; and at the end of the business day. Be sure to note the times of day if performance issues arise, to help correlate the data and identify root causes or at least a common factors.
Bandwidth—The bandwidth available to your VPN can have a significant impact on its performance and can vary widely among the remote hosts and gateways. If your VPN is supporting site-to-site VPNs connecting two locations, the bandwidth allocated at either (or both) ends of the connection may affect performance. You may find, for example, that an unreliable DSL connection at a remote client location creates unacceptable delays for the user.
Topology—Depending on the location of your VPN endpoints, the topology may affect performance. For example, if your VPN connection has to traverse a firewall or a proxy server you may find reduced performance, depending on how well those devices handle the VPN traffic.
Encryption Level—The higher the encryption level, the greater impact on the memory and processor of the endpoint devices. That being said, you should always run the highest available encryption available. If you suspect encryption is causing performance issues, you can look into either a dedicated processor for handling encryption or upgrading the processing capabilities of the central processor.
Traffic—An issue related to bandwidth is traffic loads. If, for example, the Sales Department likes to watch streaming video baseball games on Wednesday afternoon, and you have VPN performance issues during that time, increasing bandwidth may fix the problem, but does not really address the root cause, which is a traffic spike rather than too little bandwidth. To diagnose a performance issue related to traffic, devise some way to look at the traffic on your network. Another facet of this issue is: what does the traffic load look like across the VPN? Do your remote users store their documents on servers in the core network? Since you are running your VPN with split tunneling disabled, are remote users doing Web browsing through the VPN connection? Optimizing traffic both within the VPN as well as outside network traffic can go a long way to ensuring you don't encounter performance issues.
Client version—Sometimes the version of the client can impact the performance. Managing older versions on remote devices can be very difficult, depending on how your organization manages those devices. Keep your clients up-to-date and you should be able to avoid any performance issues related to client versions.
To ensure a successful VPN deployment, the implementation must be stable. Some factors that can affect VPN stability include:
Configuration—Ultimately how you configure your VPN will have an major impact on your VPN deployment. Not only should you check your internal VPN configuration, but also factor stability into your initial design. If access to the network through the VPN is mission-critical, you should ensure you use a configuration that includes some level of high availability or failover.
Location—Consider where you have placed your VPN in the network. If the VPN connection has to traverse three firewalls, multiple local routers, and a proxy server, you may find that the connections are not as stable as you need them to be.
Software version—The version of VPN software (or in the case of a hardware VPN, the concentrator code) can have a significant impact on the stability of your rollout. Be sure to keep your VPN software up to date. Updating too quickly can also be a source of stability issues, so a good rule of thumb is to keep your software version one less than the latest version number of the VPN software. That model allows you to keep your VPN relatively current, so you avoid any issues contained in older versions of code, but also keeps you from being the vendor's beta tester for new code, which is never a good idea in a production environment.
Underlying OS—The OS on which you run your VPN can definitely impact the stability of your VPN implementation. A VPN running on an old Windows operating system might have issues with the dreaded "Blue Screen of Death." A hardware-based VPN could run into challenges if there are firmware or OS issues, although those problems are typically less common than an OS-based solution. The number of lines of software code needed to run a hardware VPN are quite a bit less than the current OS coding. The leaner the software, the less risk you run of issues with the OS.
While these lists contains many of the most common sources of performance issues you may encounter, be sure to reference your troubleshooting processes and procedures when diagnosing VPN performance and stability issues.
VPNs and network address translation (NAT) have historically suffered from some conflicts when used together. NAT is an Internet standard that allows you to use one set of IP addresses on your internal LAN, and a second set of IP addresses for the Internet connection. A device (usually a router or firewall) stands in between the two connections that provides NAT services, managing the translation of internal addresses to external addresses. This allows companies to use large numbers of unregistered internal addresses while needing only a fraction of that number of addresses on the Internet, thus conserving the addresses. This is similar to a company that may have hundreds of phones in a building, but only pays for a small number of connections to the phone switch, as it is unlikely that every employee would pick up the phone at the exact same time.
NAT was created as a workaround to IP addressing issues. Since the Internet relies on the TCP/IP protocol for communications, it also relies on the IPv4 addressing that is an integral part of the TCP/IP protocol suite. The explosive growth of the Internet threatened to exhaust the pool of IPv4 IP addresses. Without unique addresses, the Internet would be unable to successfully route TCP/IP traffic. This was clearly unacceptable because the Internet was fueling the explosive growth of many businesses. As a result, NAT was proposed and adopted widely as a way to conserve critical IPv4 addresses.
In the early days of the Internet, when IP addressing was being created, developers believed the 32-bit addressing scheme (known as IPv4) to be more than adequate for any potential network growth. Theoretically 4,294,967,296 unique addresses were available using 32-bit addressing, and, even discounting the reserved ranges, more than 3 billion addresses were possible. At the time, that was enough addresses to provide one for every person on the planet.
Unfortunately, the designers of the addressing scheme dramatically underestimated the explosive growth of the Internet, as well as the popularity of TCP/IP in business and home networks. There are no longer enough addresses to go around. IPv6 is contains an addressing scheme that allows for a dramatically larger pool of addresses, but is receiving very limited deployment in corporate networks or on the Internet today. This is due in large part to the use of NAT. For more information on NAT, see RFC 3022, Traditional IP Network Address Translator (traditional NAT), at http://tools.ietf.org/html/rfc3022.
Two main types of NAT are available:
Static NAT—This version of NAT maps an unregistered IP address on the private network to a registered IP address on the public network on a one-to-one basis. This is used when the translated device needs to be accessible from the public network. For example, a Web server on your private network might have an unregistered address of 10.10.10.10, but a NAT address of 12.2.2.123. A user trying to connect to that Web site can enter 12.2.2.123, and the router or firewall at the other end will translate that address to 10.10.10.10 when the packet reaches it.
Dynamic NAT—This version of NAT maps an unregistered IP address to a registered IP address from a group of registered IP addresses. This is more commonly used when large pools of systems on the internal network need to access the Internet and don't have a requirement for a static address. The workstation's address is translated to the next available registered address as soon as it initiates a connection to the public network.
The critical thing to remember about NAT is that due to limitations in the IPSec standard, IPSec has issues traversing a translated network. VPN vendors have addressed this issue, but the workaround they have put in place can create challenges when troubleshooting issues. If possible, run your IPSec VPNs on untranslated addresses. Or deploy an SSL VPN. Because SSL runs at a higher level in the OSI model, it's not affected by NAT.
NAT traversal is a general term for techniques that establish and maintain TCP/IP network and/or UDP connections traversing NAT gateways.
For IPSec to work through NAT, configure the firewall to permit the following protocols and ports:
A number of definitions and types of virtualization are available to businesses today. Operating system virtualization is the emulation of an operating system environment hosted on another operating system. A virtual machine exists logically, but does not have an associated, dedicated physical device. Thus, a single physical machine can host multiple virtual machines. Virtualization of storage allows a storage manager to abstract the underlying physical storage technologies and manage storage at a logical level. Network virtualization allows you to run multiple logical switches within a single physical switch chassis. Some SSL VPNs support VPN virtualization.
All of these technologies can potentially affect your VPN environment.
Desktop virtualization (sometimes called client virtualization) is a concept that separates the personal computer desktop environment from the physical desktop machine by using a client-server model of computing. This model is reminiscent of the thin client client-server architectures of years ago, where the operating system was run centrally. This generation of the model offers significantly more business benefits. A virtualized desktop is hosted on a remote central server instead of on the local hardware of the remote client. This allows users to work from their remote desktop client, while all of the programs, applications, processes, and data used are kept and run centrally.
Where this has an immediate impact on your VPN is ensuring the compatibility of your VPN client with the virtualized desktop. The possibility always exists that the virtualization of the client might cause issues with the client or complicate troubleshooting any issues with the VPN. The best approach to working in a virtualized desktop environment is to test your VPN applications carefully before the virtual implementation goes into production.
Another issue that can come up in conjunction with the VPN is how you publish the virtual desktop to a remote client that is not connected to the network. One model would be to make the VPN connection first, then publish the virtual desktop across the VPN connection. This is an environment that lends itself well to SSL VPNs, due to the lack of dedicated client software. With an IPSec VPN deployment, you need to get a working VPN client on the remote desktops before publishing the virtual desktop, adding to the complexity of your VPN environment. The other model is to publish the virtual desktops natively from a DMZ environment across the Internet, and then connect back to the network via VPN, publishing the VPN client (if using IPSec) as part of the virtual desktop image.
Some limitations of desktop virtualization include:
Additional security risks associated with the complex network and desktop image environments used when working with remote virtual desktops.
Loss of employee privacy as all storage and processing is centralized.
Maintaining your VPN clients in the virtual images.
Increased downtime in the event of network failures. Outages can also affect a greater number of employees.
The concept of virtualization is becoming more popular among enterprise customers. For SSL VPNs, the need for virtualization is natural. Enterprises like to provide different remote access VPN presences to different user groups, such as partners and different departments of employees. The following section covers some of the basic capabilities you should consider for a "virtualized" SSL VPN deployment.
Virtualized SSL VPNs provide a unique virtual VPN configuration for each individual user group. Much like other types of virtualization, a virtualized SSL VPN allows you to separate the physical and logical sides of the VPN.
Some benefits of a virtualized SSL VPN environment include:
Greater flexibility—The ability to create custom authentication methods and VPN group policies for different user groups.
Delegation of management—Virtual VPNs allows the delegation of management roles for each virtual instance. If one virtual VPN instance allows a business partner to connect to an internal application, the management of that virtual VPN can go to someone supporting that business partner.
Added security when working in a multi-group environment—Virtual VPNs provide a total logical separation of the VPNs instances in terms of system resources, routing tables, user databases, and policy management interfaces.
The use of virtualized VPNs is especially attractive to companies that provide VPNs as a service. Being able to create completely separate environments and resource pools is critical to a successful service provider. Setting up dedicated hardware environments for each customer does not allow a service provider to take advantage of the economies of scale offered by a single implementation.
One of the critical topics associated with today's VPN implementations has to do with IPv4 vs. IPv6. A quick look at the history of the Internet Protocol (IP) will be helpful first.
The Internet has driven the development of the TCP/IP protocol suite, and the two remain tightly coupled. TCP/IP has always been at the root of the Internet; today you are using TCP/IP in your corporate network because of the success of both the Internet and the TCP/IP protocol. In the early days of computing, multiple protocols ran on corporate networks, and you had to worry about how to tunnel other protocols across the VPN. Today, most networks run TCP/IP exclusively.
The TCP/IP suite comprises a large number of protocols, defined in a series of RFCs. Each of the protocols in the TCP/IP suite provides a different function, and together they provide the functionality known as TCP/IP.
Tip
IANA—The assignment of both IPv4 and IPv6 addresses is the domain of suborganizations of a global organization called the Internet Assigned Numbers Authority (IANA). To find out more about IANA, go to www.iana.org In the U.S., the suborganization is ARIN (the American Registry for Internet Numbers)—www.arin.net.
The TCP/IP protocol suite got its name from the two main protocols in the suite: TCP (Transmission Control Protocol) and IP (Internet Protocol). TCP is responsible for providing reliable transmissions from one system to another, and IP is responsible for addressing and route selection. IP defines how computers communicate over a network. IP version 4 (IPv4), the currently prevalent version (defined at http://tools.ietf.org/html/rfc791), contains just over four billion unique IP addresses. IPv6 offers a newer numbering system that provides a much larger address pool than IPv4, among other features.
The largest challenge with IPv4 is address exhaustion. While the IPv4 addressing has kept the Internet and corporate networks running since the early years of the Internet, the industry is running out of addresses. The judicious use of NAT has extended the life of IPv4 far beyond its expected lifespan, however currently less than 10 percent of total IPv4 address space remains. Organizations will soon need to start adopting IPv6 to support applications that require ongoing availability of contiguous IP addresses.
IPv6 is the next-generation IP version and has been designated as the successor to IPv4, the first implementation used in the Internet. The main driving force for the redesign of Internet Protocol is the foreseeable IPv4 address exhaustion. IPv6 was defined in December 1998 by the IETF with the publication RFC 2460. IPv6 is documented in several requests for comment (RFCs) starting from RFC 2460.
While IPv6 is a relatively mature protocol, having been defined in 1998, adoption has been very slow thus far. According to ARIN, users requested only 395 IPv6 address blocks during 2009.
Based on the latest statistics, Europe has been requesting the highest percentage of IPv6 addresses, at 45.9 percent in the past 18 months, followed by Asia Pacific at 33.2 percent and the United States trailing with just 20.4 percent of the requests.
Some benefits of IPv6 include:
Increased address space—IPv6 supports 340 undecillion (3.40282E38) IP addresses for network devices.
More efficient routing—The routing functionality of IPv6 has been enhanced.
Reduced management requirement—more robust protocol requires less management. Original IPv4 required significant add-on management capabilities due to new requirements after introduction of the protocol.
Better Quality of Service (QoS) support for all types of applications— Support for QoS is built into the protocol, whereas it was an add-on in IPv4.
Security—IPv6 includes a native information security framework (IPSec) that provides for both data and control packets.
Plug and Play configuration with or without DHCP—IPv6 permits hosts to automatically configure themselves when they connect to an IPv6 network by querying the local routers with a multicast message. If the routers are configured correctly, they will respond with the appropriate configuration information. If this mechanism is not appropriate for a specific environment or application, support is available for an IPv6 version of DHCP. It also supports static configurations.
Three mechanisms currently exist for the transition from IPv4 to IPv6. It's important to understand that when the IPv6 standard appeared, the expectation was that the two protocols would need to co-exist in the network for 20 to 30 years, allowing for a gradual transition period. Three of the proposed migration strategies are:
Dual-stack—A transition solution where both IPv4 and IPv6 protocol stacks coexist in the same terminal or network equipment. This would allow the network to communicate using both protocols, but adds significant overhead to the network infrastructure.
Tunneling—Allows two IPv6 hosts to create a tunnel for traffic between two IPv6 hosts through an IPv4 network, or vice-versa, as IPv4 starts to phase out. This could add significant configuration overhead.
Translation—Enables an IPv4 host to talk to an IPv6 host. This solution will require additional development, as currently IPv6 does not include this capability.
IPSec is a mandatory component for IPv6, and is used to natively protect IPv6 data as it is sent over the network. The components of IPSec in IPv6 are not dramatically different from the IPSec that industry has been using since the 1990s. In IPv6, IPSec uses the AH authentication header and the ESP extension header.
The IPv6 IPSec is a set of Internet standards that uses cryptographic security services to provide the following:
Confidentiality—IPSec traffic is encrypted and cannot be deciphered without the appropriate encryption key. This should be easier to use in conjunction with IPv6, since it's a native component of the protocol.
Data origin authentication—Ipv6 IPSec uses a cryptographic checksum that incorporates a shared encryption key so that the receiver can verify that it was actually sent by the apparent sender. This prevents spoofing of transactions.
Data integrity—The cryptographic checksum can also be used by the receiver to verify that the packet was not modified in transit.
You can find more information about IPv6 in RFC2460 at http://tools.ietf.org/html/rfc2460.
You should now be familiar with the different VPN and related protocols and their uses, such as IPSec, Layer 2 Tunneling Protocol (L2TP), Secure Sockets Layer (SSL)/Transport Layer Security (TLS) and SSH. You should also understand the advantages and disadvantages of hardware and software solutions, and be able to determine which solution would be appropriate in your environment.
You learned how some of the challenges associated with establishing performance and stability for VPNs can impact the performance and stability of your VPN.
You learned about the issues network address translation (NAT) can present when rolling out a VPN, as well as the impact of both client and VPN virtualization on your VPN.
You took a detailed look at Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), including challenges and benefits associated with the rapidly approaching migration to IPv6.
Authentication Header (AH)
Encapsulating Security Payload (ESP)
Internet Engineering Task Force (IETF)
Internet Key Exchange (IKE)
Request for Comment (RFC)
Layer 2 Forwarding (L2F)
Layer 2 Tunneling Protocol (L2TP)
Point-to-Point Protocol (PPP)
Point-to-Point Tunneling Protocol (PPTP)
Secure Shell (SSH)
What are the two modes supported by IPSec? (Multiple answers are correct.)
Transition
Tunnel
Encrypted
Transport
Internally connected
All of the following are considered IPSec services (multiple answers may be correct) except:
Access Control
Encryption
NAT interoperability
Replay rejection
Support for AES encryption
The strongest encryption protocol currently supported by IPSec is _______.
The two different protocols commonly used for remote access VPN are _______ and _______.
Pick two advantages of using an IPSec-based VPN solution instead of an SSL-based solution. (Multiple answers are correct.)
Provides direct connection to the network.
Since IPSec works at Layer 3, it can support virtually all network applications.
Requires configuration of each application being accessed via the VPN.
Clientless solution.
A solution that permitted industry to extend the life of IPv4 addresses is _______.
Which of the following are benefits of using an SSL VPN? (Multiple answers may be correct.)
More costly
Less flexible
Support for NAT
Fewer firewall rules required
Used for secure logins
SSL VPNs are considered _______ because access is granted through SSL, which is supported by Web browsers on virtually all platforms.
Which of the following are areas that can impact the stability of your VPN? (Multiple answers may be correct.)
Number of users
VPN Configuration
Code Revision Level
Operating System
Encryption Level
Which of the following are types of Network Address Translation? (Multiple answers may be correct.)
On Demand
Dynamic
Secure
Static
Encrypted
The mechanism used by the IETF to document Internet standards is the _______.
Separating the physical devices from the logical devices is known as _______.
Which of the following are uses for the SSH protocol? (Multiple answers may be correct.)
Secure Remote Login
Secure File Transfers
Secure access to a Web site
Encrypting data on backup tapes
Creating a VPN connection
The L2TP protocol was created by the combination of these two protocols: _______ and _______
When you need to securely connect to a router for remote login,_would be the recommended protocol.
Which of the following are protocols that can be used for a VPN connection? (Multiple answers may be correct.)
IPSec
3DES
SSH
IETF
SSL
When working with IPSec in an environment using network address translation, which protocols and ports need to be open for IPSec to communicate? (Multiple answers may be correct.)
(IKE)—User Datagram Protocol (UDP) port 500
Internet Key Exchange—UDP port 500
Encapsulating Security Payload—IP port 50
Secure Sockets Layer—TCP port 443
Authentication Header—IP protocol number 51
When designing a VPN solution, which of the following areas could impact VPN performance? (Multiple answers may be correct.)
Available bandwidth
Client configuration
Client patch level
Traffic
Topology
Which of the following are benefits of IPv6? (Multiple answers may be correct.)
IPSec is defined as a native protocol.
Support for SSL included in the standard.
Ability to address a limit of 4.3 billion hosts
Plug and Play configuration with or without DHCP
Define how to respond to incidents.
The ability to traverse a firewall using Network Address Translation on port 443 is a component of which VPN protocol _______?