Chapter 9: IPsec and SSL VPN Design (Part01)

Overview

After completing this chapter, you will be able to:

• Discuss design considerations for remote-access VPNs

• Discuss design considerations for site-to-site VPNs

• Discuss technologies for implementing VPNs

• Discuss managing and scaling VPNs

This chapter reviews virtual private network (VPN) design in the enterprise. VPNs are networks deployed on a public or private network infrastructure. VPNs are useful for telecommuters, mobile users, and remote offices, and for customers, suppliers, and partners.

For enterprises, VPNs are an alternative WAN infrastructure, replacing or augmenting existing private networks that use dedicated WANs based on leased-line, Frame Relay, ATM, or other technologies. Increasingly, enterprises are turning to their service providers for VPNs and other complete service solutions tailored to their particular business.

Designing Remote-Access VPNs

Remote-access VPNs permit secure, encrypted connections between mobile or remote users and their corporate networks through a third-party network, such as a service provider. Deploying a remote-access VPN enables enterprises to reduce communications expenses by leveraging the local packet-switching infrastructures of Internet service providers. Cisco remote-access VPN solutions deliver both IP Security (IPsec) and Secure Sockets Layer (SSL) technologies on a single platform with unified management.

Remote-Access VPN Overview

Remote-access VPNs using IPsec or SSL technologies permit secure, encrypted connections between mobile or remote users and their corporate network across public networks.

There are three remote-access VPN components:

• VPN termination device or headend supporting a high number of endpoints.

• End clients that can be mobile or fixed. The remote-access client can be built inside of operating system or application, or be installed as a Layer 3 software client such as the Cisco VPN Client.

• Technology that connects the VPN headend and the end clients. The two main protocols supporting remote-access VPNs are IPsec and SSL.

  • IPsec is used primarily for data confidentiality and device authentication, but extensions to the standard allow for user authentication and authorization to occur as part of the IPsec process.

  • The main role of SSL is to provide security for web traffic. With SSL, the browser client supports the VPN connection to a host. SSL is a default capability in leading browsers.

Both IPsec and SSL remote-access VPNs are mechanisms to provide secure communication:

• Authenticity identifies the trusted party by asking for username and password or a credential.

• Integrity checking verifies that packets were not altered or tampered with as they traveled across the network.

• Confidentiality is supported using encryption to ensure communications were not read by others.

Example—Cisco Easy VPN Client IPsec Implementation

Cisco Easy VPN provides simple IPsec VPN deployments for remote offices and teleworkers.

The Cisco Easy VPN Server allows Cisco routers and security appliances to act as IPsec VPN headend devices in remote-access and site-to-site VPNs.

Note

IPsec components and features are covered in the prerequisite Implementing Secure Converged Wide Area Networks course.

For remote-access VPNs, the Cisco Easy VPN Server terminates VPN tunnels initiated by remote workers running the Cisco VPN Client software on PCs. This capability allows mobile and remote workers to access critical data and applications on their corporate intranet. The Cisco Easy VPN Server pushes configurations and security policies defined at the central site to the remote client device, helping to ensure that those connections have appropriate information and current policies in place before the connection is established. Cisco Easy VPN Server can pass a variety of information to the client, including IP address and mask, information on the internal Domain Name System (DNS) and Windows Internet Naming Service (WINS) server, and organization policies.

Note

Cisco Easy VPN Server is discussed in more detail in the “Using IPsec VPN Technologies” section of this chapter.

SSL VPN Overview

SSL is a protocol designed to enable secure communications on an insecure network such as the Internet.

SSL is a technology developed by Netscape to provide encryption between a web browser and a web server. SSL supports integrity of communications along with strong authentication using digital certificates:

• Web server certificates are used to authenticate the identity of a website to visiting browsers. When a user wants to send confidential information to a web server, the browser accesses the digital certificate of the server. The certificate, which contains the public key of the web server, is used by the browser to authenticate the identity of the web server and to encrypt information for the server using SSL technology. Because the web server is the only entity with access to its private key, only the server can decrypt the information.

• Root certificates are self-signed digital certificates that are generated during the creation of a certificate authority (CA). “Trusted” root certificates refer to CA certificates that are stored in the trust lists that are natively embedded in the leading web browsers. There are a limited number of CA certificates, which come embedded in the web browsers from Microsoft and Netscape.

SSL for VPNs can be more than a basic web page supporting secure access to the applications available as static web pages on HTTP servers:

• SSL VPNs can fit into existing networks and application environments and provide support for complex applications such as corporate directory and calendar systems, e-commerce applications, file sharing, and remote system management.

• SSL VPNs can support the same authentication mechanisms and often extensive application lists as those available for IPsec.

SSL VPNs have multiple access mechanisms:

• Content rewriting and application translation using embedded clientless access and Layer 7 features. Clientless access is where a user can connect with little requirements beyond a basic web browser.

• Port forwarding, which is known as a thin client. With a thin client, a small applet or application, generally less than 100 KB in size, provides access to a subset of resources.

• Dynamic VPN client with full network access, which is known as a thick client. With a thick client, a larger client, generally around 500 KB, is delivered to the end user. The applications that can be reached through the thick client are similar to those available via IPsec VPNs. This client is delivered via a web page and never needs to be manually distributed or installed.

Clientless Access

The SSL VPN system supports clientless access by proxying web pages. The system connects to a web server, downloads and translates a web page, and then transfers it over an SSL connection to the browser of the end user. The SSL VPN system rewrites or translates content so that the internal addresses and names on a web page are accessible to the end users.

Only web-enabled and some client/server applications (such as intranets, applications with web interfaces, email, calendaring, and file servers) can be accessed using a clientless connection. This limited access is suitable for partners or contractors that need access to a limited set of resources on the network.

Several content-rewriting functions are involved in proxying the remote applications:

• Translating protocol to HTTP

• Delivering HTML user interface

• Supporting file sharing

Clientless access for SSL VPNs does not require specialized VPN software on the user desktop, because all VPN traffic is transmitted and delivered through a standard web browser, which minimizes provisioning and support concerns.

Thin Client

Organizations that have not implemented web-based applications can often rely on the thin clients, shown here in Figure 9-1, that support port forwarding. Port forwarding requires a small application, often in the form of Java or Microsoft ActiveX that runs on the end-user system. The port forwarder acts as a local proxy server. The client application listens for connections on a port defined for an application on a local host address. It tunnels packets that arrive on this port inside of an SSL connection to the SSL VPN device, which unpacks them and forwards them to the real application server. Port forwarding maintains the native application look and feel for the end user.

Figure 9-1: Thin Client (Port Forwarding)

Port forwarding is an effective technique, but it also has some limitations. For port forwarding to work, the applications need to be well behaved and predictable in their network connectivity ports, patterns, and needs. Examples of applications that are not web enabled but can be addressed with port forwarding are common mail protocols, including Simple Mail Transfer Protocol (SMTP), Post Office Protocol Version 3 (POP3), Messaging Application Programming Interface (MAPI), and remote shell programs, such as Telnet. ActiveX or Java applet support may also be required on the client machine, along with the permissions in the browser to run them.

Thick Client

SSL VPN network extension connects the end-user system to the corporate network with access controls based only on network-layer information, such as destination IP address and port number. Network extension uses a thick client that provides authorized users with secure access to the entire corporate LAN.

The thick client, shown here in Figure 9-2, is automatically delivered through the web page and does not need to be manually distributed or installed. The thick client requires administrative access to the local system. The Layer 3 thick client provides a virtual adapter for the end user, typically using ActiveX and Java. The applications that can be accessed with the thick client are similar to those available through an IPsec VPN. The Cisco SSL VPN Client for WebVPN is a Cisco implementation of the thick client.

Figure 9-2: Thick Client (Port Forwarding)

Because the SSL VPN network extension runs on top of the SSL protocol, it is simpler to manage and has greater robustness with different network topologies such as firewalls and Network Address Translation (NAT) than the higher security of IPsec. The thick client is typically a smaller installation than the IPsec client.

Thick mode should be used when users need full application access and IT wants tighter integration with the operating system for additional security and ease of use.

Remote-Access VPN Design Considerations

When deploying remote-access VPNs, it is important to determine where to terminate the service. The decision is impacted by the originations firewall architecture, routing and addressing schema, and authentication policy. The following section examines these elements and their impact on Remote Access VPN design.

VPN Termination Device and Firewall Placement

The VPN termination device can be deployed in parallel with a firewall, inline with a firewall, or in a demilitarized zone (DMZ). For best security, the recommended practice is to place the public side of the VPN termination device in a DMZ behind a firewall.

Note

The firewall could be the VPN termination device.

The firewall policies should limit traffic coming in to the VPN termination device to IPsec and SSL. Any IPsec tunnels should terminate on the VPN appliance. For extra security, send traffic through another firewall for additional inspection after it passes through the VPN appliance.

You should also enforce endpoint security compliance on the remote system.

Routing Design Considerations

Routing design considerations are mainly a VPN headend consideration for remote-access VPNs.

For nonlocal subnet IP addresses, the most common configuration is that the internal routers use static routes for the address blocks pointing to the private interfaces of the headend device.

If a large number of networks exist behind each headend device, the configuration of static routes becomes difficult to maintain. Instead, it is recommended that you use Reverse Route Injection (RRI). RRI automatically inserts static routes into the routing table of the gateway router for those networks and hosts protected by a remote tunnel endpoint. These static routes can then be redistributed to the other routers in the network.

Note

Smaller organizations typically configure a few static routes to point to the VPN device and do not need RRI. The RRI function is usually of more benefit to larger organizations that have more complex requirements (for example, organizations that do not have a dedicated scope of DHCP addresses that are associated to a specific VPN headend).

The Firewall Services Module (FWSM) uses the administrative context for network management connectivity. Each context may also be managed individually as if they were distinct and separate firewalls. This granularity enables different groups to administer their own firewall. The system context is used to add VLANs, create contexts, and assign VLANs to contexts. With the default FWSM software, up to two security contexts are provided: the administrative and system context.

Address Assignment Considerations

For IPsec, thin, and thick clients, there are three common addressing techniques.

• The most simple and common address assignment design is to use internal address pools per VPN headend and to implement a static route for this subnet to the VPN headend. With this approach, ACLs on an internal firewall can support group-based address pools for incoming user policies.

• Another popular choice is to use DHCP to assign addresses. A recommended practice is to associate a dedicated scope of DHCP addresses to a specific VPN headend.

• For situations where the remote user needs a static IP address assignment to support a specific application, organizations will need to deploy RADIUS or Lightweight Directory Access Protocol (LDAP) with an attribute to assign the user the same IP. In this case, RRI may be needed.

An IP address is not assigned for clientless end-user devices:

• The headend device will proxy Address Resolution Protocol (ARP) on behalf of all local subnet IP addresses.

• Because the clientless users do not receive a unique IP address, their traffic will originate from the headend interface IP. This is good for scalability, but harder to monitor.

Other Design Considerations

Two other design considerations are authentication and access control.

Authentication

Although the SSL protocol does not support client authentication methods other than digital certificates, it is possible to use other authentication methods in conjunction with SSL. The simplest approach is to use a username and password, but security-conscious organizations use stronger authentication methods, such as security tokens and one-time password (OTP).

Customers who are focused on convenience sometimes authenticate to an internal Network Termination (NT) domain controller or static RADIUS password database. Any type of static password configuration leaves the organization vulnerable to brute-force password attacks.

Access Control

Access control rules allow organizations to restrict network access. Some companies choose to maintain all access rules on an internal firewall based on the source IP of the client. This scenario supports addresses that are assigned to a specific pool based on group assignment.

Access control rules can be defined at a per-group basis on the VPN headend device. This approach is easy to deploy, but can be more difficult to maintain with large numbers of policies or across multiple devices. Access control rules can also be defined on the headend RADIUS server, although generic RADIUS has a 4-KB packet size limit. The Cisco Secure Access Control Server (ACS) offers a downloadable access control list (ACL) feature that can be used with Cisco headend devices to support large policies.

Tunnel-based VPNs (IPsec and SSL VPN clients) provide Layer 3 control at the protocol, port, and destination IP level. Clientless SSL VPNs can provide more granular Layer 7 access control, including URL-based access or file server directory-level access control.

Example: VPN Architecture

Figure 9-3 shows an example of a VPN design architecture that supports employees and partners. The employees connect across the Internet using an IPsec VPN client. The noncorporate users connect using SSL. The IPsec or SSL clients are authenticated using the authentication, authorization, and accounting (AAA) server. Both IPsec and SSL VPNs come in on the public interface of the VPN cluster and are terminated. Load balancing is used for resiliency, stateless failover, and capacity growth on the VPN cluster. The private interface of the VPN headend connects through routers to the internal corporate network. Inbound ACLs on the internal edge routers provide access control rules to permit traffic to specific internal resources.

Figure 9-3: Example: VPN Architecture

Users are organized into various groups with appropriate security policy profiles and user authentication and authorization information. Both Cisco IPsec VPN and SSL VPN clients are supported, as is clientless SSL VPN with an optional port-forwarding feature.