Remote Access Overview

IPSec remote access is used to connect remote-access clients, such as a PC or small office, home office (SOHO) device (a small-end router or firewall appliance) to a corporate network. Figure 20-1 shows a simple example. In a remote-access VPN connection, the client has two IP addresses: one assigned to the NIC and one assigned by the VPN corporate device.

Figure 20-1. Remote-Access VPN Example

[View full size image]

In Figure 20-1, the remote-access PC has an IP address that the ISP assigned to its NIC, by either DHCP, PPPoE, or PPP (dialup), and one that the corporate office VPN router assigned it internally. The client uses ESP tunnel mode to send packets to the corporate office network. The original IP packet has a source address that internally was assigned (192.168.1.100) and a destination address of the corporate network (192.168.1.0/24) when sent to the corporate network. ESP tunnel mode encapsulates this packet and adds a new IP header, where the source address is the ISP-assigned address for the source (200.1.1.1) and the destination address is (192.1.1.1), the corporate office VPN router. However, when the client sends packets to other destinations, such as Internet sites, it uses normal IP packets with its ISP-assigned address as the source.

You have a lot of management and policy flexibility in this design. Typically, access policies are defined on the corporate side and are pushed down to the client. Information that the corporate device can assign to the client includes the internal IP address, DNS and WINS server addresses, the domain name, filtering and split tunneling policies, and many other items. In addition, when it comes to authentication, you can have the VPN corporate device perform authentication of the client or pass off the authentication to a AAA server, like the one shown in Figure 20-1.

EasyVPN Introduction

EasyVPN is a feature that Cisco developed to make the deployment of remote-access VPNs a simple process. It provides for consistent policies and key management, centralizing your administration and simplifying your configuration. EasyVPN has two components:

• EasyVPN server (EVS)

• EasyVPN client (EVC) or remote (EVR)

The EVS component is responsible for terminating the remote-access VPN connection at the corporate site. This can be an IOS-based router (12.2[8]T and later), a PIX firewall (FOS 6.0 and later), or the 3000 series concentrators (version 3.0 and later). For large numbers of remote-access client connections, both Cisco and I recommend the use of a VPN concentrator. Typically, routers are used for site-to-site connections. VPN concentrators support many more VPN features than IOS routers or PIX firewalls; however, for site-to-site connections and a small number of remote-access connections, an IOS router is an ideal solution, especially if you already have a router in place that can perform this process.

The EVC component is responsible for initiating the VPN connection. Cisco devices that can perform the function of a client include the VPN 3002 hardware client; the 800, 900, and 1700 series routers (IOS 12.2[15]T for Phase 2 support); and the PIX 501 firewall (FOS 6.2). The Cisco Secure and Unity 3.x and 4.x software clients also can perform the role of a client. One of the interesting things about the EVC is that some of Cisco's smaller-end routers can perform the function of a client. This provides more flexibility on your part because you can define access policies on your EVS and have these pushed down to your EVC router.

EasyVPN IPSec Support

EasyVPN uses IPSec to establish remote-access connections. Here are the IPSec components that EasyVPN supports:

• ISAKMP/IKE? Only dynamic support for ISAKMP/IKE is supported. Manual configuration is not.

• Authentication methods? Only RSA signatures and preshared keys are supported.

• Encryption algorithms? DES, 3DES, AES, AES-192, AES-256, and null (for data connections only) are supported.

• Hashing functions? MD5 and SHA are supported.

• Diffie-Hellman (DH) key groups? Groups 2 and 5 are supported.

• Data-connection parameters? ESP in tunnel mode and LZS compression are supported.

The following items are not supported:

• Digital Signature Standard (DSS) authentication

• Diffie-Hellman (DH) group 1 keys

• Authentication Header (AH) protocol

• Encapsulation Security Payload (ESP) transport mode

• Manual keying with ISAKMP/IKE

• Perfect forward secrecy (PFS)

EasyVPN Features

EasyVPN features include the following:

• Policy push? As I already mentioned, you can define policies on your EVS and have these pushed down to your EVCs.

• Group and user policies? You can implement group and user policies. Group policies apply to a group of devices or users, and user policies apply to a single device or user. With groups, you can more easily segregate your clients into appropriate categories and then apply policies on a group-by-group basis.

• XAUTH authentication? Remote access supports two types of authentication: device and user. I discussed the three different methods of performing device authentication in Chapter 19, "IPSec Site-to-Site Connections": preshared keys, RSA encrypted nonces, and RSA signatures (digital certificates). Remote access supports a second type of authentication, called user, or XAUTH, authentication, which enables you to give each user a username and password. This has an advantage over device authentication because the authentication information is stored on the device. As an example, if a user's laptop is stolen and you were using only device authentication, the thief who stole the laptop would have access to your network because he would not have to enter manually the authentication information?it is already stored on the device. XAUTH adds another layer of protection. With policy push, you can prevent the user from storing the user's password on the user device. Therefore, even if the user's device was compromised or stolen, the perpetrator still cannot access your corporate network using a VPN unless that hacker also knows the user's personal username and password.

• Split tunneling? Split tunneling is the capability to assign a policy that defines what is and is not tunneled through the remote-access VPN connection. The default policy is to force the client to send all traffic to the central site, through the VPN, and then have the central site forward the traffic. However, in certain cases, this does not make sense, especially if the information that the remote client wants is located at the local ISP or on a local LAN segment. Split tunneling enables you to assign tunneling policies on the EVS and push these policies down to the client.

• Split DNS? Split DNS is similar to split tunneling, and the two typically are used together. Split DNS allows a client to have two sets of DNS servers: one set for accessing services through the VPN connection, and another set for accessing services outside the VPN connection (the Internet).

• IKE mode config? IKE mode config allows the EVS to assign configuration information to the client. This configuration information includes the client's internal IP address, DNS server addresses, WINS server addresses, a domain name, filtering policies and restrictions, split tunneling, and other configuration and policy components.

• IKE dead peer detection (DPD)? DPD allows an EVS or EVC to detect a device failure at the other end of the VPN connection. Basically, IKE DPD is a remote-access VPN keepalive function. This is very useful for dialup clients that are prone to connection drops. In this situation, an EVS quickly can detect that a client is no longer there and can remove its connection information. Likewise, this feature provides redundancy for clients. If the client detects that its current EVS is no longer reachable, the client can initiate a connection to a secondary EVS. Note that DPD also can be used for LAN-to-LAN (L2L) connections.

• Initial contact? Initial contact is used when an EVC unexpectedly becomes disconnected from an EVS, and the EVC attempts to reconnect to the EVS. Without this feature, the EVS would not allow the new connection because the EVS assumes that the client already is connected (by a dead connection). Initial contact allows the EVS to remove the old security associations (SAs) for the EVC and build new ones.

• NAT transparency (NAT-T)? NAT-T, introduced in IOS 12.2(13)T, is an IPSec component that allows remote-access connections to be established through an address-translation device, specifically one that uses Port Address Translation. It accomplishes this by encapsulating the IPSec (ESP) packets in a UDP segment, using destination port 4500. To detect whether an address-translation device exists between the two IPSec devices, the two peers send a payload of hashes to each other: If both ends can verify the payload hashes, no translation was performed and the IPSec connection is set up normally; otherwise, if the payload hashes are invalidated, the peers automatically use NAT-T. The address-translation detection process takes place during IKE Phase 1; the use of NAT-T takes place in IKE Phase 2. NAT keepalives are generated by the two peers to ensure that the address-translation entry for the devices remains in the address-translation table on the address-translation device.