Cisco IPSec Remote Access VPN Solution

With the Cisco IPSec solution, Cisco ASA allows mobile and home users to establish a VPN tunnel by using the Cisco software and Cisco hardware VPN clients.

The Cisco VPN client uses aggressive mode if preshared keys are used, and uses main mode when public key infrastructure (PKI) is used during Phase 1 of the tunnel negotiations. After bringing up the ISAKMP SA for secure communication, Cisco ASA prompts the user to specify the user credentials. In this phase, also known as X-Auth or extended authentication, the security appliance validates the user against the configured authentication database. If the user authentication is successful, Cisco ASA sends a successful authentication message back to the client. After X-Auth, the Cisco VPN client requests configuration parameters such as the assigned IP address and the DNS and WINS server IP addresses, to name a few. During this phase, known as mode-config, the security appliance sends the configured parameters back to the client. The final step for a successful VPN tunnel is the negotiation of Phase 2 parameters, as illustrated in Figure 16-1. After completing the tunnel negotiations, the client can send or receive traffic over the connection.

Figure 16-1. Tunnel Negotiations for Cisco VPN Client

Note

It is recommended to use main mode for IKE authentication using RSA signatures because of the known vulnerabilities in aggressive mode.

Configuration Steps

Figure 16-2 illustrates SecureMe's Chicago hub office to be configured for the Cisco remote-access VPN solution. This topology will be used to show the following configuration steps required to establish a successful VPN tunnel. Many of these steps are identical to the steps discussed in Chapter 15, "Site-to-Site IPSec VPNs."

Figure 16-2. Remote-Access Network Topology for SecureMe

Step 1: Enable ISAKMP

By default, ISAKMP is disabled on all the interfaces. If the remote VPN device sends a tunnel initialization message, the security appliance drops it until ISAKMP is enabled on the interface terminating the VPN tunnels. Typically, it is enabled on the Internet-facing or outside interface, as demonstrated in Example 16-1.

Example 16-1. Enabling ISAKMP on the Outside Interface

Chicago# configure terminal Chicago(config)# isakmp enable outside

Step 2: Create the ISAKMP Policy

The isakmp policy commands define ISAKMP Phase 1 attributes that are exchanged between the VPN peers. Cisco ASA supports digital signature authentication using Digital Signature Algorithm (DSA) and Rivest-Shamir-Adleman (RSA), and preshared keys as the authentication method. For encryption, Cisco ASA uses both Advanced Encryption Standard (AES) and the aging Data Encryption Standard (DES).

Additionally, Cisco ASA supports Diffie-Hellman (DH) groups 1, 2, 5, and 7. The complete command syntax of the isakmp policy command is as follows:

isakmp policy priority authentication dsa-sig | pre-share | rsa-sig isakmp policy priority encryption 3des | aes | aes-192 | aes-256 | des isakmp policy priority group 1 | 2 | 5 | 7 isakmp policy priority hash md5 | sha isakmp policy priority lifetime 120-2147483647

If multiple ISAKMP policies are configured, the Cisco ASA checks the ISAKMP policy with the highest priority first. If there is no match, it checks the next higher priority policy, and so on until all policies have been evaluated. A priority value of 1 is the highest priority, while a priority value of 65535 is the lowest.

Example 16-2 shows an ISAKMP policy to negotiate preshared keys for authentication, AES-256 for encryption, SHA for hashing, group 2 for DH, and 86400 seconds for lifetime.

Example 16-2. Configuration of ISAKMP Policy

Chicago# configure terminal Chicago(config)# isakmp policy 10 authentication pre-share Chicago(config)# isakmp policy 10 encryption aes-256 Chicago(config)# isakmp policy 10 hash sha Chicago(config)# isakmp policy 10 group 2 Chicago(config)# isakmp policy 10 lifetime 86400

Step 3: Configure Remote-Access Attributes

Cisco ASA allows the configuration of most of the mode-config parameters in three different places:

• Under default group-policy
• Under user group-policy
• Under user policy

Cisco ASA implements the inheritance model, where a user inherits the mode-config attributes from the user policy, which inherits its attributes from the user group-policy, which in turn inherits its attributes from the default group-policy, as illustrated in Figure 16-3. A user, ciscouser, will receive traffic ACL and an assigned IP address from the user policy, the domain name from the user group-policy, and IP Compression along with the number of simultaneous logins from the default group-policy.

Figure 16-3. Mode-Config Inheritance Model

You can use the group-policy attributes command to specify the default and user group-policy mode-config attributes. Example 16-3 shows how to configure the default group attributes on Cisco ASA by setting DfltGrpPolicy as the group name in the group-policy. The administrator has limited the simultaneous logins to 3, and has enabled IP Compression for data payload.

Example 16-3. Configuration of Default Group-Policy

Chicago(config)# group-policy DfltGrpPolicy attributes Chicago(config-group-policy)# vpn-simultaneous-logins 3 Chicago(config-group-policy)# ip-comp enable

Note

DfltGrpPolicy is a special group name, used solely for the default group-policy.

The user group-policy is set up similarly to a default group-policy, by configuring the attributes under the group-policy submenu. In Example 16-4, a group called SecureMeGrp is being set up to send the domain-name securemeinc.com attribute during mode-config exchange. One major difference between the default group-policy and the user group-policy is that you can define the latter as an internal or external group. Internal group means that all the policy attributes are defined locally on the security appliance, while external group means that all the attributes are stored on an external server such as RADIUS. In Example 16-4, SecureMeGrp is set up as an internal group, which is why the domain-name VPN attribute is defined locally.

Example 16-4. Configuration of Group-Specific Group Policy

Chicago(config)# group-policy SecureMeGrp internal Chicago(config)# group-policy SecureMeGrp attributes Chicago(config-group-policy)# default-domain value securemeinc.com

The user policy is defined by using the username attributes command. The user account is usually mapped to the user group-policy, discussed in the previous example. If an attribute is configured under both the user group-policy and under the user policy, then the user account attribute takes precedence over the group-policy attribute. In Example 16-5, a user account ciscouser is defined and mapped to the SecureMeGrp group. This user is configured to receive an IP address of 192.168.50.1 and a filtering ACL of 102 as the user attributes.

Example 16-5. Configuration of User Policy

Chicago(config)# username ciscouser password cisco123 Chicago(config)# username ciscouser attributes Chicago(config-username)# vpn-group-policy SecureMeGrp Chicago(config-username)# vpn-framed-ip-address 192.168.50.1 255.255.255.255 Chicago(config-username)# vpn-filter value 102

Table 16-1 lists all the mode-config attributes that you can set up under the default and user group-policies.

Step 4: Define the Tunnel Type

As briefly mentioned in Chapter 15, Cisco ASA can be configured for two different tunnel types, as shown in Example 16-6.

Example 16-6. Supported Tunnel Types

Chicago(config)# tunnel-group ciscovpn type ? ipsec-l2l IPSec Site to Site group ipsec-ra IPSec Remote Access group

In this example, the tunnel-group tag is named ciscovpn. The tunnel type ipsec-l2l is used for site-to-site VPN tunnels, while the tunnel type ipsec-ra is used for the Cisco IPSec VPN solution. In the ipsec-ra type, the security appliance expects the Cisco VPN clients to initiate a tunnel and send vendor identity as Cisco client during the ISAKMP negotiations. Example 16-7 shows the Cisco ASA in Chicago configured for remote-access tunnels.

Example 16-7. Configuration of Remote-Access Tunnels

Chicago(config)# tunnel-group ciscovpn type ipsec-ra

Note

The tunnel-group name, ciscovpn in the preceding example, is the group name that needs to be configured on the Cisco VPN clients.

Step 5: Configure ISAKMP Preshared Keys

If you want to use a preshared key as the authentication method, then you must configure a shared secret which is used to validate the identity of both VPN devices. The preshared key is configured under the ipsec-attributes submenu of the tunnel group, as shown in Example 16-8.

Example 16-8. Preshared Key Configuration

Chicago(config)# tunnel-group ciscovpn ipsec-attributes Chicago(config-ipsec)# pre-shared-key cisco123

In Example 16-8, all Cisco VPN clients configured for the ciscovpn group must use cisco123 as the preshared key. If there is a mismatch on the key, the security appliance denies group authentication for the client.

Note

Preshared key is also known as group password in the Cisco remote-access VPN.

Note

This step is not necessary if the security appliance is set up for RSA signatures. This will be discussed in Chapter 17, "Public Key Infrastructure (PKI)."

Step 6: Configure User Authentication

Cisco ASA supports a variety of authentication servers, such as RADIUS, Windows NT domain, Kerberos, SDI, and local database. For small organizations, a local database can be set up for user authentication. In Example 16-9, the Chicago ASA has two user accounts, ciscouser and adminuser, configured for IPSec authentication.

Example 16-9. Local User Accounts

Chicago# configure terminal Chicago(config)# username ciscouser password cisco1 Chicago(config)# username adminuser password cisco2

The tunnel group must be configured with the corresponding authentication server, under general attributes. The authentication-server-group subcommand specifies the authentication server. Example 16-10 illustrates how to configure the security appliance to use the local database for the ciscovpn group.

Example 16-10. Local Authentication Configuration

Chicago(config)# tunnel-group ciscovpn general-attributes Chicago((config-group-policy)# authentication-server-group LOCAL

For configuration of external servers, consult Chapter 7, "Authentication, Authorization, and Accounting (AAA)."

Caution

In the first few releases of the Cisco ASA image, if user authentication is not configured, you need the authorization server command to push the mode-config attributes.

Step 7: Assign an IP Address

During mode configuration, the Cisco VPN client requests an IP address to be assigned to the VPN adapter on the workstation. Cisco ASA supports three different methods to assign an IP address back to the client:

• Local address pool
• DHCP server
• RADIUS server

Example 16-11 shows the available address assignment methods in the vpn-addr-assign command. The security appliance uses the aaa option to use the RADIUS server for address assignment, the dhcp keyword to contact a DHCP server when it needs to assign an address to the VPN user, and the local option to use the local database.

Example 16-11. Available Address Assignment Methods

Chicago(config)# vpn-addr-assign ? aaa Allow AAA servers to specify an IP address dhcp Allow DHCP servers to specify an IP address local Allow local pools to specify an IP address Chicago(config)# vpn-addr-assign local

For small to midsize deployments, the preferred method for assigning an IP address is through the local database. When the client requests an IP address, Cisco ASA looks at the tunnel group configuration and checks the address assignment method. If local pool is the configured option, the security appliance checks the address assignment in the following order:

1. user policy configuration
2. group address pool

A static IP address can be assigned to a user under the user policy. The VPN user will receive the same IP address regardless of the number of times they connect to the Cisco ASA. In Example 16-12, a static IP address of 192.168.50.1 is assigned to ciscouser by using the vpn-frame-ip-address command.

Example 16-12. Address Assignment Under User Policy

Chicago(config)# username ciscouser attributes Chicago(config-username)# vpn-framed-ip-address 192.168.50.1

The second option of assigning an IP address is by configuring the address pool and then linking it to the VPN group under tunnel-group general attributes. Example 16-13 shows the necessary commands to configure an address pool called vpnpool, and map it for address assignment for a VPN group ciscovpn. The pool range starts from 192.168.50.2 and ends at 192.168.50.199.

Example 16-13. Address Assignment from Local Pool

Chicago(config)# ip local pool vpnpool 192.168.50.2-192.168.50.199 Chicago(config)# tunnel-group ciscovpn general-attributes Chicago(config-general)# address-pool vpnpool

For ease of management, the security appliance can contact a DHCP server when allocating an IP address. After the DHCP server assigns an address, Cisco ASA forwards that IP address to the client. Example 16-14 illustrates how the security appliance in Chicago can be configured to use a DHCP server with an IP address of 192.168.10.10 for address assignment.

Example 16-14. Address Assignment from a DHCP Server

Chicago(config)# vpn-addr-assign dhcp Chicago(config)# tunnel-group ciscovpn general-attributes Chicago(config-general)# dhcp-server 192.168.10.10

Many large enterprises prefer to authenticate users on the external RADIUS servers, which can assign IP addresses to the client after successfully authenticating the users. Example 16-15 shows the configuration of the Cisco ASA if RADIUS, set up as an authenticating device, is assigning the IP address.

Example 16-15. Address Assignment from an AAA Server

Chicago(config)# aaa-server Radius protocol radius Chicago(config-aaa-server-group)# exit Chicago(config)# aaa-server Radius (inside) host 192.168.10.10 Chicago(config-aaa-server-host)# key cisco123 Chicago(config-aaa-server-host)# exit Chicago(config)# vpn-addr-assign aaa

Note

If all three methods are configured for address assignment, Cisco ASA prefers RADIUS over DHCP and address pool. If Cisco ASA is not able to get an address from the RADIUS server, it contacts the DHCP server for address allocation. If that method fails as well, Cisco ASA checks the local address pool as the last resort.

Step 8: Define the IPSec Policy

An IPSec transform set specifies the encryption and hashing method to be used on the data packets once the tunnel is up. To configure the transform set, use the following command syntax:

crypto ipsec transform-set transform-set tag {esp-3des | esp-aes | esp-aes-192 | esp-aes-256 | esp-des | esp-md5-hmac | esp-null | esp-none | esp-sha-hmac}

Table 16-2 lists the encryption and hashing algorithms that can be used in a transform set.

Note

If the VPN-3DES-AES feature is not enabled, the security appliance allows DES encryption only for ISAKMP and IPSec policies.

In Example 16-16, the Chicago ASA is set up for AES-256 encryption and SHA hashing. The transform set name is myset.

Example 16-16. Transform Set Configuration

Chicago(config)# crypto ipsec transform-set myset esp-aes-256 esp-sha-hmac

Step 9: Set Up a Dynamic Crypto Map

VPN clients often get dynamic IP addresses from their ISPs. In a crypto map, which requires a static IP address for the VPN peer, there is no way to map those dynamic IP addresses. Cisco ASA solves this problem by allowing configuration of a dynamic crypto map. Example 16-17 demonstrates the configuration of the Cisco ASA in Chicago to use the defined transform set. The dynamic crypto map name is dynmap and it is configured with a sequence number of 10. Setting up a transform set in a dynamic crypto map is a required attribute. The dynamic crypto map becomes incomplete if there is no transform set applied to it.

Example 16-17. Dynamic Crypto Map Configuration

Chicago(config)# crypto dynamic-map dynmap 10 set transform-set myset

You can optionally configure many IPSec attributes in the dynamic crypto map. They include disabling NAT-T, configuring PFS and reverse-route injection (RRI), and setting security association (SA) lifetimes. Chapter 15, "Site-to-Site IPSec VPNs," covers these attributes.

Step 10: Configure the Crypto Map

The dynamic map is associated to a crypto map entry, which eventually gets applied to the interface terminating the IPSec tunnels. The crypto map can have both static and dynamic crypto map entries, discussed later in the deployment section "Load-Balancing and Site-to-Site Integration."

Example 16-18 shows crypto map configuration on the Chicago ASA. The crypto map name is IPSec_map and the sequence number is 65535.

Example 16-18. Crypto Map Configuration

Chicago(config)# crypto map IPSec_map 65535 ipsec-isakmp dynamic dynmap

The Cisco ASA limits one crypto map per interface. If there is a need to configure multiple VPN tunnels, use the same crypto map name with a different sequence number. However, the security appliance evaluates a VPN tunnel with the lowest sequence number first.

Step 11: Apply the Crypto Map to an Interface

The next step in setting up a remote-access tunnel is to bind the crypto map to an interface, using the following command syntax:

crypto map map-name interface interface-name

In Example 16-19, the crypto map, IPSec_map, is applied to the outside interface of the Chicago ASA.

Example 16-19. Applying a Crypto Map to the Outside Interface

Chicago# configure terminal Chicago(config)# crypto map IPSec_map interface outside

Step 12: Configure Traffic Filtering

In its default firewall role, the Cisco ASA blocks decrypted traffic and protects the trusted network, unless the ACLs explicitly permit traffic to pass through it. In Figure 16-2, the VPN clients are being assigned an IP address from the 192.168.50.0 address pool. They are allowed to send traffic to a Telnet server located at 192.168.10.20 on TCP port 23 across the VPN tunnel. The Chicago ASA has an inbound access list called outside_acl applied to its outside interface which only allows the telnet traffic to pass through it, as shown in Example 16-20.

Example 16-20. Access List to Allow Decrypted Traffic to Pass Through the Cisco ASA

Chicago(config)# access-list outside_acl extended permit tcp 192.168.50.0 255.255.255.0 host 192.168.10.20 eq 23 Chicago(config)# access-group outside_acl in interface outside

If you trust all of your private networks, including all of your remote VPN clients, Cisco ASA can be configured to permit all decrypted IPSec packets to pass through it without inspecting them against the configured ACL. This is done with the use of the sysopt connection permit-ipsec command, as shown in Example 16-21.

Example 16-21. Sysopt Configuration to Bypass Traffic Filtering

Chicago(config)# sysopt connection permit-ipsec

Step 13: Set Up a Tunnel Default Gateway (Optional)

A Layer 3 device typically has a default gateway that is used to route packets when the destination address is not found in the routing table. Tunnel default gateway, a concept first introduced in the VPN 3000 Series Concentrators, is used to route the packets if they reach the security appliance over an IPSec tunnel and if their destination IP address is not found in the routing table. The tunneled traffic can be either remote-access or site-to-site VPN traffic. The tunnel default gateway next-hop address is generally the IP address of the inside router, Router1 (illustrated in Figure 16-2), or any Layer 3 device.

The tunnel default gateway feature is important if you do not want to define routes about your internal networks to the Cisco ASA and instead want the tunneled traffic to be sent to the internal router for routing. To set up a tunnel default gateway, add the keyword tunneled to the statically configured default route. Example 16-22 shows the configuration of the security appliance with the tunnel default gateway specified as 192.168.10.2, located on the inside interface.

Example 16-22. Tunnel Default Gateway Configuration

Chicago(config)# route inside 0.0.0.0 0.0.0.0 192.168.10.2 tunneled

Step 14: Bypass NAT (Optional)

If NAT is configured on the security appliance but you do not want to change the source IP address of traffic going over the VPN tunnel, you need to configure the NAT exempt rules, as discussed in Chapter 5, "Network Access Control."

You need to create an access list to specify what traffic needs to be bypassed by the NAT engine. Example 16-23 shows an access list that is permitting the VPN traffic from 192.168.10.0/24 to the pool of addresses in 192.168.50.0/24.

Example 16-23. Access List to Bypass NAT

Chicago(config)# access-list nonat extended permit ip 192.168.10.0 255.255.255.0 192.168.50.0 255.255.255.0

After defining the access list, the next step is to configure the nat 0 command. Example 16-24 demonstrates how to configure the nat 0 statement if the private LAN that is being protected is toward the inside interface.

Example 16-24. Configuration of nat 0 access-list

Chicago(config)# nat (inside) 0 access-list nonat

Step 15: Set Up Split Tunneling (Optional)

Once the tunnel is up, the default behavior of the Cisco VPN client is to encrypt traffic destined to all the IP addresses. This means that if a VPN user wants to browse www.cisco.com over the Internet as illustrated in Figure 16-4, the packets will get encrypted and sent to the Cisco ASA. After decrypting them, Cisco ASA will look at its routing table and forward the packet to the appropriate next-hop IP address in clear-text. These steps are reversed when traffic returns from the web server and is destined to the VPN client.

Figure 16-4. Traffic with No Split Tunneling

This behavior might not always be desirable, for the following two reasons:

• Traffic destined to the nonsecured networks traverses over the Internet twiceonce encrypted and once in clear text.
• Cisco ASA handles extra VPN traffic destined to the nonsecured subnet.

With split tunneling, Cisco ASA can notify the VPN client for the secured subnets. The VPN client, using the secured routes, encrypts only those packets that are destined for the networks behind the security appliance.

Caution

With split tunneling, the VPN client is susceptible to a hacker, who can potentially take control over the computer and direct traffic over the IPSec tunnel. To mitigate this behavior, a personal firewall is highly recommended on the Cisco VPN clients.

Additionally, Cisco ASA also supports tunneling all traffic except for a list of networks that require clear-text access. This feature is useful if users require clear-text access to their local LAN and an encrypted tunnel to the corporate network.

As mentioned earlier, the security appliance provides three modes for split tunneling:

• Tunnel all traffic (no split tunneling)
• Tunnel specific networks (split tunneling)
• Tunnel all but specific networks (exclude split tunneling)

These modes can be configured under the group and user policy by using the split-tunnel-policy command followed by the split-tunneling mode. If split-tunneling and exclude split-tunneling modes are used, you need to configure a standard access list to specify all the destination networks to be included or excluded. Example 16-25 shows the configuration for the SecureMeGrp user group-policy to tunnel specific networks. Additionally, this configuration defines a standard ACL called Spt_tnl to include the 192.168.0.0/16 network for split tunneling. The ACL is then linked to the group-policy by using the split-tunnel-network-list value command followed by the name of the ACL, Spt_tnl.

Example 16-25. Split-Tunnel Configuration

Chicago(config)# access-list Spt_tnl standard permit 192.168.0.0 255.255.0.0 Chicago(config)# group-policy SecureMeGrp attributes Chicago(config-group-policy))# split-tunnel-policy tunnelspecified Chicago(config-group-policy))# split-tunnel-network-list value Spt_tnl

Cisco VPN Client Configuration

The Cisco VPN Client, also known as the Cisco Easy VPN Client, initiates the IPSec tunnel to the security appliance. If the configuration and user credentials are valid, the tunnel is established and traffic is processed over it. The Cisco VPN clients come in two different flavors, which are discussed in the sections that follow:

• Software-based VPN clients
• Hardware-based VPN clients

Software-Based VPN Clients

The software-based VPN client runs on a variety of operating systems, such as Windows, Solaris, Linux, and Mac OS/X. It can be downloaded from Cisco.com free of charge as long as the Cisco ASA is under a valid service contract.

Before you configure the Cisco VPN client, it needs to be installed on the host machine. Please refer to http://www.cisco.com/go/vpnclient for the installation instructions. Cisco ASA supports version 3.x or higher VPN clients.

Note

The installation of Cisco VPN Client requires administrative privileges on the workstation.

In the Windows-based operating systems, the Cisco VPN client can be launched by running the VPN client executable found under Start > Program files > Cisco Systems VPN Client once it is installed. The operating system runs the executable and displays the VPN Client utility, as depicted in Figure 16-5.

Figure 16-5. Initial VPN Client Window

The configuration of a Windows-based VPN client requires five parameters:

• Name of the connection entry
• Public IP address of the Cisco ASA
• Group name that the VPN client will be connecting to
• Group preshared key
• Tunnel encapsulation

You can configure these parameters on the Cisco VPN client by clicking the New icon. The Cisco VPN client shows a different window in which you can enter the necessary information. In Figure 16-6, the user has specified the Connection Entry as Chicago ASA. You can name this entry any name you like. It only has local significance and is not forwarded to the security appliance. You can optionally enter the description for this connection entry. In this example, the connection description is Connection to Chicago ASA. The VPN client requires you to input the IP or the hostname of the security appliance. Because the public IP address of the security appliance in Chicago is 209.165.200.225, the VPN client is set up to use this address. The group name that the VPN client is configured to use is ciscovpn, and the group password is cisco123, displayed as asterisks. The group password on the client is the preshared key configured on the security appliance.

Figure 16-6. VPN Client Configuration

You can specify what type of data encapsulation the Cisco VPN client should be using. This is set up under the Transport tab, as shown in Figure 16-7. If IPSec over UDP or NAT-T is the encapsulation mode, then check the Enable Transparent Tunneling box with IPSec over UDP (NAT/PAT) as the selected option. If IPSec over TCP is the required encapsulation, then select IPSec over TCP and specify the appropriate port number. In this example, IPSec over UDP is the selected transport protocol.

Figure 16-7. Transparent Tunneling Configuration

Note

The headend side needs to be set up for transparent tunneling as well. Consult the upcoming section "Transparent Tunneling" for a detailed explanation and configuration.

Note

If the Enable Transparent Tunneling box is disabled, the VPN client uses only the native IPSec encapsulation mode using ESP.

After configuring the VPN client, the user can click the Connect icon to establish the connection to the security appliance. This is shown in Figure 16-8.

Figure 16-8. VPN Connection Establishment

Hardware-Based VPN Clients

The Cisco hardware-based VPN clients implement the same functionality as discussed in the earlier section using the dedicated Cisco hardware devices. Easy VPN is supported on the following platforms:

• Cisco IOS router
• Cisco PIX Firewall
• Cisco VPN 3002 Hardware Client

A Cisco small office, home office (SOHO) router can act as a VPN client and initiate a VPN tunnel on behalf of the hosts residing on the private subnet, as shown in Figure 16-9. When the Cisco IOS router receives interesting traffic destined to pass over the VPN tunnel, it determines the IP address of the security appliance by checking the configuration.

Figure 16-9. Cisco IOS based Easy VPN Client Connecting to Cisco ASA

Note

For a list of Cisco IOS routers supported for Easy VPN deployment, refer to the following Cisco.com page:

http://www.cisco.com/go/easyvpn

Two connection modes are supported by the hardware based Easy VPN devices:

• Client mode Also called Port Address Translation (PAT) mode, isolates all hosts on the private side of the hardware VPN client from those on the corporate network. The hardware based Easy VPN client translates all traffic initiated by the hosts on the private side to a single source IP address before sending it over the tunnel. This source IP address is assigned to the client by the security appliance during the mode-config exchange. The client translates the original source IP address by assigning a random source port. The client keeps and maintains a port translation table to identify where to send responses on the private network.

  Using the client mode, the hosts on the private network can initiate traffic destined to the corporate network. However, the hosts on the corporate network cannot initiate traffic back to the private network of the Easy VPN client.

• Network Extension Mode (NEM) Acts similarly to a site-to-site tunnel in that hosts behind the corporate network can initiate traffic destined to the network behind the Easy VPN client, and vice versa. Thus, hosts on either side know each other by their actual addresses. The major difference between the site-to-site and NEM VPN tunnels is that the IPSec connection has to be initiated by the Easy VPN client.

  Using NEM, there is no need for the security appliance to assign an IP address to the client. Therefore, the client does not participate in PAT for traffic destined over the VPN tunnel.

The Easy VPN configuration on the Cisco IOS routers requires the use of crypto ipsec client ezvpn followed by the name of the Easy VPN profile. The profile name has only local significance and is not used for tunnel negotiation. Under the EZVPN subconfiguration mode, you can specify the IP address of the security appliance, the group name, and the group password. In Example 16-26, an Easy VPN profile called EZVPN_Client is set up to automatically connect to the security appliance public IP address of 209.165.200.225, as soon as the Easy VPN interface configuration is done. The group name that the Cisco IOS Easy VPN client is using is ciscovpn with the group password of cisco123. The administrator has set up NEM for this connection. For X-Auth, a username of ciscouser with a password of cisco1 is being configured.

Example 16-26. Easy VPN Client Configuration

EZVPN-client(config)# crypto ipsec client ezvpn EZVPN_Client EZVPN-client(config-crypto-ezvpn)# connect auto EZVPN-client(config-crypto-ezvpn)# group ciscovpn key cisco123 EZVPN-client(config-crypto-ezvpn)# mode network-extension EZVPN-client(config-crypto-ezvpn)# peer 209.165.200.225 EZVPN-client(config-crypto-ezvpn)# username ciscouser password cisco1

After configuring the profile, the next step is to identify the inside and outside Easy VPN interfaces. This is achieved by using the crypto ipsec client ezvpn inside and crypto ipsec client ezvpn outside commands on the correct interfaces. Example 16-27 shows how to bind the configured EZVPN_Client profile on the inside and outside interfaces.

Example 16-27. Configuring the Inside and Outside Cisco IOS Easy VPN Interfaces

EZVPN-client(config)# interface Ethernet0 EZVPN-client(config-if)# ip address 192.168.60.1 255.255.255.0 EZVPN-client(config-if)# crypto ipsec client ezvpn EZVPN_Client inside EZVPN-client(config-if)# exit EZVPN-client(config)# interface Ethernet1 EZVPN-client(config-if)# ip address 209.165.201.3 255.255.255.248 EZVPN-client(config-if)# crypto ipsec client ezvpn EZVPN_Client outside

Note

For Cisco PIX and VPN 3002 Hardware Client installation and configuration documents, refer to the following links.

PIX Easy VPN Client:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/config/pixclnt.htm#wp1032561

VPN 3002 Hardware Client:

http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3002/4-1/referenc/tunnel.htm