Chapter 20. IPsec Remote-Access VPNs
This chapter covers the following topics:
Cisco IPsec remote-access VPN solution
Advanced Cisco IPsec VPN features
L2TP over IPsec remote-access VPN (IKEv1)
Monitoring and troubleshooting
Remote-access VPN services provide a way to connect home and mobile users to the corporate network. Until a decade ago, the only way to provide this service was through dialup connections using analog modems. Corporations had to maintain a huge pool of modems and access servers to accommodate remote users. Additionally, they were billed for providing toll-free and long-distance phone services. With the rapid growth of Internet technologies, most remote users have migrated from dialup connections to broadband DSL or cable-modem connections. In response, corporations have moved these users to remote-access VPNs for faster communication.
There are many remote-access VPN protocols available to provide secure network access. The commonly used ones include the following:
Point-to-Point Tunneling Protocol (PPTP)
Layer 2 Tunneling Protocol (L2TP)
Layer 2 Forwarding (L2F) Protocol
IPsec
L2TP over IPsec
Secure Sockets Layer (SSL) VPN
The Cisco ASA supports the native IPsec and L2TP over IPsec to provide VPN services in a secure manner. The Cisco IPsec VPN solution uses Cisco VPN Client while L2TP over IPsec uses the built-in VPN client on Microsoft Windows and Android operating systems. AnyConnect supports the Internet Key Exchange version 2 (IKEv2) protocol; it does not support IKE version 1. IKEv1 is supported by the former Cisco VPN client, which is now end-of-life (EoL).
Cisco ASA supports VPN connections from Android mobile devices when using the L2TP over IPsec protocol and the native Android VPN client. Mobile devices must be using the Android 2.1, or later, operating system. Android L2TP over IPsec support is available since Cisco ASA Software versions 8.2(5) and 8.4(1).
Both native IPsec and L2TP over IPsec VPN solutions are discussed in this chapter.
Cisco IPsec Remote Access VPN Solution
Cisco ASA allows mobile and remote users to establish an IPsec VPN tunnel by using the following:
Cisco AnyConnect Secure Mobility Client (SSL VPN or IKEv2)
Built-in clients in operating systems such as OS X, and Apple iOS products (iPhones, iPads, and iPods)
Cisco hardware VPN clients
Table 20-1 provides a high-level comparison between IKEv1 and IKEv2.
Cisco ASA IKEv2 support uses Cisco’s IKEv2 implementation toolkit, which is common in AnyConnect, Cisco ASA, and Cisco IOS devices. It includes a few extensions for fragmentation and client redirection support and uses a proprietary EAP method (AnyConnect EAP). However, it uses the same authentication methods supported previously with IPsec and SSL VPN.
The following features are not supported in IKEv2:
Windows 7 IKEv2 client or any other third-party IKEv2 clients
Hardware client support for IKEv2 (covered later in this chapter), except the ASA 5505 as a headend using IKEv2 is supported
Preshared-key authentication for client or server
IKEv2 encryption for load-balancing link to other ASAs (covered later in this chapter)
L2TP over IPsec
Reauthentication
Peer ID check
Compression/IPcomp
Network Admission Control (Posture)
Third-party firewalls
Table 20-2 provides a high-level comparison between Cisco ASA support for IPsec (IKEv1 and IKE v2) and L2TP over IPsec remote-access VPNs.
It is recommended to use main mode for IKEv1 authentication, which requires RSA signatures because of the known vulnerabilities in aggressive mode.
IPsec (IKEv1) Remote-Access Configuration Steps
Figure 20-1 illustrates SecureMeInc.org’s Chicago hub office, which is to be configured for the Cisco remote-access VPN solution. This topology is used in the following two sections to show the configuration steps required to establish a successful VPN tunnel.
There are several ways that you can configure an IPsec (IKEv1) remote-access VPN on the Cisco ASA:
Using the ASDM IPsec IKEv1 Remote Access VPN Wizard (the easiest way)
Manually configuring all the options in ASDM
Via the command-line interface (CLI)
Using the ASDM IPsec IKEv1 Remote Access VPN Wizard
The easiest way to configure IPsec Remote Access VPN in the Cisco ASA is by using the ASDM IPsec IKEv1 Remote Access VPN Wizard, as shown in the following steps. This wizard allows you to configure a remote-access VPN solution in minutes.
1. Launch the ASDM IPsec IKEv1 Remote Access VPN Wizard by choosing Wizards > VPN Wizards > IPsec (IKEv1) Remote Access VPN Wizard, as illustrated in Figure 20-2.
2. The first step of the IPsec IKEv1 Remote Access VPN Wizard appears, as shown in Figure 20-3. From the VPN Tunnel Interface drop-down list, choose the interface to which the VPN clients will connect. For the example topology shown in Figure 20-1, the clients connect to the Cisco ASA outside interface.
3. To enable inbound IPsec sessions to bypass interface access lists, check the Enable Inbound IPsec Sessions to Bypass Interface Access Lists check box. As the option indicates, group policy and per-user authorization access lists still apply to the traffic.
4. Click Next.
5. The Remote Access Client screen shown in Figure 20-4 is displayed. Remote-access users of various types can open VPN tunnels to this ASA. Choose the radio button corresponding to the type of VPN client for this tunnel.
In this case, the Cisco VPN Client, Release 3.x or Higher, or Other Easy VPN Remote Product radio button is selected to allow the legacy Cisco VPN clients or Easy VPN hardware clients to connect to the Cisco ASA. Because the legacy Cisco VPN client is not available for 64-bit OS X, Mac users employ the in-built Cisco VPN client.
6. Click Next.
7. For the third wizard step, shown in Figure 20-5, choose the authentication method. The VPN client authenticates either with a preshared key, a certificate, or a challenge/response authentication (CRACK). In this example, preshared key authentication is used.
8. Enter a name for the tunnel group. The tunnel group name is an arbitrary name for the record that contains tunnel connection policies for this IPsec connection. A connection policy specifies authentication, authorization, and accounting servers, a default group policy, and IKE attributes. In this example, the Tunnel Group Name is SecureMeIPSec.
9. Click Next.
10. On the Client Authentication screen, shown in Figure 20-6, configure the Cisco ASA to authenticate VPN connections either using a local user database or using an external AAA server such as RADIUS, LDAP, Active Directory, etc. In this case, the local user database is used for authentication.
11. Click Next.
12. On the User Accounts screen, shown in Figure 20-7, add a new user to the authentication database and, optionally, specify a password. In this example, a new user called user1 is being created and added to the local database.
13. Click Next.
14. The Address Pools screen is shown next. During the tunnel negotiations, an IP address is assigned to the VPN adapter of the IPsec VPN Client. The client uses this IP address to access resources on the protected side of the tunnel. To create a new IP address pool, click New. In the Add IPv4 Pool dialog box that opens, shown in Figure 20-8, enter the name, starting IP address, ending IP address, and subnet mask for the new pool. In this case, the IP pool name is IPPool, the starting IP address is 192.168.50.1, the ending IP address is 192.168.50.254, and the subnet mask is 255.255.255.0.
15. Click OK to close the dialog box, and then click Next to proceed to the next step of the wizard.
16. As indicated in Figure 20-9, the next step, Attributes Pushed to the Client, is an optional step. For the IPsec VPN clients, you can assign DNS and WINS server IP addresses so that they can browse and access internal sites after their tunnel has established. In this example, the primary DNS server is 192.168.10.10 and the secondary DNS server is 192.168.10.20. A primary WINS server with the IP address 192.168.10.20 is also configured. The default domain name is securemeinc.org.
17. Click Next.
18. The next step, IPsec Settings, is also optional. As indicated in Figure 20-10, if NAT is used, you can bypass NAT to expose the entire or part of the internal network to authenticated remote-access VPN clients. If you opt to complete this step, choose the interface on which your private network resides and for which you want NAT to be bypassed. In this example, the inside interface is selected and the NAT exempt network is the 192.168.10.0/24 network.
19. To enable split tunneling, check the top check box shown in Figure 20-10. With split tunneling, the security appliance can notify the IPsec VPN client about the secured subnets. The VPN client, using the secured routes, encrypts only those packets that are destined for the networks behind the security appliance. Split tunneling is covered in more detail later in this chapter.
20. Check the bottom check box in Figure 20-10 to enable PFS, and then specify the appropriate D-H group type in the drop-down list box. PFS is discussed in more detail in Chapter 19, “Site-to-Site IPsec VPNs.”
21. Click Next.
22. The VPN Wizard shows you a summary of all the features and configurations you have set, as illustrated in Figure 20-11. After you have verified the configuration, click Finish to push the configuration to the security appliance.
Manually Configuring IPsec (IKEv1) VPN Using ASDM and CLI
The following examples are based on the topology shown in Figure 20-1, illustrating SecureMeInc.org’s Chicago hub office. Many of the following steps are very similar to the steps discussed in the “Configuration Steps” section of Chapter 19. At the end of each configuration step, the equivalent CLI is shown in case you prefer to configure the security appliance through the command line.
1. Enable ISAKMP (IKEv1).
2. Create the IKEv1 (ISAKMP) Policy.
3. Set up tunnel and group policies.
4. Define the IPsec policy.
5. Configure user authentication.
6. Assign an IP address.
7. Create a crypto map.
8. Configure traffic filtering (optional).
9. Bypass NAT (optional).
10. Set up split tunneling (optional).
11. Define DNS and WINS addresses (optional).
Step 1: Enable ISAKMP (IKEv1)
IKEv1 Phase 1 configuration starts by enabling ISAKMP on the interface that terminates the VPN tunnels. Typically, it is enabled on the outside, Internet-facing interface. If ISAKMP is not enabled on an interface, the security appliance does not listen for the ISAKMP traffic on that interface. If you have a fully configured IPsec tunnel and ISAKMP is not enabled on the outside interface, the security appliance does not respond to a tunnel initialization request.
To enable ISAKMP on an interface by using ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec Connection Profiles and check the Allow Access check box next to the interface where you want to terminate the sessions. To terminate the IPsec sessions on the outside interface, check the Allow Access check box next to the outside interface. To push this configuration to the security appliance, click the Apply button.
Note
When ASDM delivers the commands to enable ISAKMP on an interface, it also configures a number of parameters, including
Two ISAKMP policies (policy numbers 5 and 10). They are discussed in the next section.
Ten IPsec policies. They are discussed in the “Step 4: Define the IPsec Policy” section.
A dynamic crypto map and a static crypto map. The static crypto map is applied to the VPN terminating interface. The crypto maps are discussed in the “Step 7: Create a Crypto Map” section.
Example 20-1 shows the CLI configuration to enable ISAKMP on the outside interface.
Note
IKEv2 was introduced in Cisco ASA Software version 8.4(1) and ASDM version 6.4(1). The ASA now supports IPsec with IKEv2 for the AnyConnect Secure Mobility Client, Version 3.0(1), for all client operating systems. As a result, Cisco modified the crypto isakmp commands for IKEv1 to crypto ikev1 policy, crypto ikev1 enable, and crypto ipsec ikev1. Example 20-1 shows use of the new version of the IKEv1 command.
Example 20-1 Enabling ISAKMP on the Outside Interface
Chicago# configure terminal
Chicago(config)# crypto ikev1 enable outside
Step 2: Create the IKEv1 (ISAKMP) Policy
After you enable IKEv1 on the interface, create a Phase 1 policy that matches a policy on the VPN client. The Phase 1 policy negotiates the encryption and other parameters that are useful in authenticating the remote peer as well as establishes a secure channel over which the VPN client and the security appliance entities can communicate.
To configure a new ISAKMP policy in the security appliance, navigate to Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > IKE Policies and click Add. ASDM launches an Add IKE Policy dialog box in which you can specify the following attributes:
Priority: Enter a number between 1 and 65535. By default, ASDM has priority numbers 5 and 10 preconfigured. If multiple ISAKMP policies are configured, the Cisco ASA checks the ISAKMP policy with the lowest number first. If there is no match, it checks the policy with the next highest priority number, and so on until all policies have been evaluated. A priority value of 1 is evaluated first, and a priority value of 65535 is evaluated last.
Authentication: Choose the appropriate authentication type from the drop-down list. The authentication mechanism establishes the identity of the remote IPsec peer. You can use preshared keys, CRACK, or RSA. Chapter 18, “Tuning and Monitoring IPS,” discusses RSA signatures in detail.
Encryption: Choose the appropriate encryption type from the drop-down list. Cisco ASA employs a dedicated hardware encryption accelerator to process IKE requests. It is recommended that you choose AES 256-bit encryption because the performance impact is pretty much the same as using a weaker encryption algorithm such as DES.
D-H Group: Choose the appropriate Diffie-Hellman (D-H) group from the drop-down list. The D-H group is used to derive a shared secret to be employed by the two VPN devices. The Cisco IPsec clients by default offer D-H groups 2 and 5 when proposing IKE policies.
Hash: Choose the appropriate hash type, either MD5 or SHA, from the drop-down list. A hashing algorithm provides data integrity by verifying that the packet has not been changed in transit. It is recommended to use SHA because it provides better security than MD5.
Lifetime: Specify the lifetime after which a new set of ISAKMP keys is negotiated. You can specify a finite lifetime between 120 and 2,147,483,647 seconds. You can also check Unlimited in case the remote peer does not propose a lifetime. Cisco recommends that you use the default lifetime of 86,400 seconds for IKE rekeys.
Figure 20-12 shows that an ISAKMP policy of priority 1 is being added. The authentication mechanism is preshared keys, the encryption method is AES-256, the D-H group is 2, the hashing algorithm is SHA, and the default lifetime of 86,400 seconds is specified.
Note
If the VPN-3DES-AES feature is not enabled, the security appliance allows DES encryption for only the ISAKMP and IPsec policies.
If you prefer the CLI, use the crypto ikev1 policy command to define a new policy. Example 20-2 illustrates how to configure an ISAKMP policy for AES-256 encryption, SHA hashing, DH group 2, and preshared keys for authentication, with 86,400 seconds as the lifetime.
Example 20-2 Creating an ISAKMP Policy
Chicago# configure terminal
Chicago(config)# crypto ikev1 policy 1
Chicago(config-isakmp-policy)# authentication pre-share
Chicago(config-isakmp-policy)# encryption aes-256
Chicago(config-isakmp-policy)# hash sha
Chicago(config-isakmp-policy)# group 2
Chicago(config-isakmp-policy)# lifetime 86400
Step 3: Set Up Tunnel and Group Policies
Cisco ASA uses an inheritance model when it pushes network and security policies to the end-user sessions. Using this model, you can configure policies at the following three locations:
Under the default group policy
Under the user’s assigned group policy
Under the specific user’s policy
In the inheritance model, a user inherits the attributes and policies from the user policy, which receives its attributes and policies from the user group policy, which in turn inherits its attributes and policies from the default group policy, as illustrated in Figure 20-13. A user, ciscouser, receives a traffic ACL and an 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.
After these policies are defined, they must be bound to a tunnel group where users terminate their sessions. This way, a user who establishes his VPN session to a tunnel group inherits all the policies mapped to that tunnel. The tunnel group defines a VPN connection profile, of which each user is a member.
Configuring Group Policies
Configure the user group and default group policies by choosing Configuration > Remote Access VPN > Network (Client) Access > Group Policies. Click Add to add a new group policy. As shown in Figure 20-14, a user group policy called IPSecGroupPolicy is being added. This group policy allows only IPsec tunnels to be established and strictly rejects all the other tunneling protocols. If you would rather assign attributes to the default group policy, modify DfltGrpPolicy (System Default). To modify DfltGrpPolicy, go to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select DfltGrpPolicy, and click Edit. Any attribute that is modified in DfltGrpPolicy is propagated to any user group policy that inherits that attribute. In other words, a group policy name other than DfltGrpPolicy is treated as a user group policy, and that user group policy can inherit the attributes configured in the default group policy.
Note
DfltGrpPolicy is a special group name that gets created by default and is used solely for the default group policy.
The user, group, and default group polices can be applied to clientless, AnyConnect, and IPsec-based remote-access VPN tunnels. The IPsec-specific attributes are discussed in detail in the next few sections of this chapter.
You can configure a user policy by choosing Configuration > Remote Access VPN > AAA/Local Users > Local Users.
Example 20-3 illustrates how to define a user group policy called IPSecGroupPolicy. This policy allows only IKEv1 IPsec tunnels to be terminated on the group.
Example 20-3 Group Policy Definition
Chicago(config)# group-policy IPSecGroupPolicy internal
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# vpn-tunnel-protocol ikev1
Configuring a Tunnel Group
A tunnel group, also known as a connection profile, is used to map the attributes that are assigned to remote-access clients. Configure a new tunnel group by choosing Configuration > Remote Access VPN > Network (Client) Access > IPsec (IKEv1) Connection Profiles and clicking Add under Connection Profiles. As shown in Figure 20-15, an IPsec remote access connection profile called SecureMeIPSec with a preshared key of C!$c0K3y (obfuscated) is defined. It is recommended that you configure a long alphanumeric key with special characters. It is hard to decode a complex preshared key even if someone tries to break it by brute force. Under Default Group Policy, choose IPSecGroupPolicy from the Group Policy drop-down menu and also check the Enable IPsec Protocol option.
Example 20-4 illustrates how to configure a remote-access tunnel group of SecureMeIPSec. The preshared key is defined under the ipsec-attributes of the tunnel group, using the pre-shared-key command.
Example 20-4 Tunnel Group Definition
Chicago(config)# tunnel-group SecureMeIPSec type remote-access
Chicago(config)# tunnel-group SecureMeIPSec general-attributes
Chicago(config-tunnel-general)# default-group-policy IPSecGroupPolicy
Chicago(config-tunnel-general)# tunnel-group SecureMeIPSec ipsec-attributes
Chicago(config-tunnel-ipsec)# pre-shared-key C!$c0K3y
Step 4: Define the IPsec Policy
An IPsec transform set specifies what type of encryption and hashing to use for the data packets after a secure connection has been established. This provides data authentication, confidentiality, and integrity. The IPsec transform set is negotiated during quick mode, discussed in Chapter 1, “Introduction to Security Technologies.” To configure a new transform set through ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > IPsec Proposals (Transform Sets) and click Add. A dialog box opens, enabling you to configure the following attributes:
Set Name: Specify the name for this transform set. This name has local significance and is not transmitted during IPsec tunnel negotiations.
Mode: Click the radio button for the appropriate encapsulation mode. You have the option to use either transport mode or tunnel mode. Transport mode is used to encrypt and authenticate the data packets that are originated by the VPN peers. Tunnel mode is used to encrypt and authenticate the IP packets when they are originated by the hosts connected behind the VPN device. In a remote-access connection, tunnel mode is always used.
ESP Encryption: Choose the appropriate encryption type from the drop-down list. It is recommended that you select AES 256-bit encryption because the performance impact is pretty much the same as using a weaker encryption algorithm such as DES.
ESP Authentication: Choose the appropriate hash type—SHA, MD5, or none—from the drop-down list. A hashing algorithm provides data integrity by verifying that the packet has not been changed in transit. It is recommended to use SHA because it provides better security than MD5.
Note
Cisco ASDM has ten predefined IPsec transform sets. You do not have to define a new transform set if you want to use a predefined transform set.
In Figure 20-16, a new transform set called RA-AES256SHA is being defined. It is set up to use AES-256 encryption and SHA authentication for data packets. The encapsulation mode is defined as tunnel, the default mode.
Example 20-5 shows how an IPsec transform set can be configured through the CLI.
Example 20-5 Transform Set Configuration
Chicago(config)# crypto ipsec transform-set RA-AES256SHA esp-aes-256 esp-sha-hmac
Step 5: Configure User Authentication
Cisco ASA supports a number of authentication servers, such as the following:
RADIUS
NT domain
Kerberos
SDI
LDAP
Digital certificates
Smart cards
Local database
For small organizations, a local database can be set up for user authentication. For medium to large remote-access IPsec VPN deployments, it is highly recommended that you use an external authentication server, such as RADIUS or Kerberos, as the user authentication database. If you are deploying a remote-access IPsec VPN for a few users, use the local database.
You define users in ASDM by choosing Configuration > Remote Access VPN > AAA/Local Users > Local Users and clicking Add. From the CLI, you define users as shown in Example 20-6, where two accounts, ciscouser and adminuser, are configured for user authentication. The ciscouser account, with a password of C1$c0123, is used for IPsec user authentication, whereas adminuser, with a password of @d1m123, is employed to manage the security appliance.
Example 20-6 Local User Accounts
Chicago(config)# username ciscouser password C1$c0123
Chicago(config)# username adminuser password @dmin123
Many enterprises use either a RADIUS server or a Kerberos server to leverage their existing Active Directory infrastructure for user authentication. Before configuring an external authentication server on Cisco ASA, you must specify authentication, authorization, and accounting (AAA) server groups by choosing Configuration > Remote Access VPN > AAA/Local Users> AAA Server Groups and clicking Add. Specify a server group name that can be referenced by the other AAA processes. Choose an authentication protocol for this server group name. For example, if you plan to use a RADIUS server for authentication, choose RADIUS from the drop-down menu. This option ensures that the security appliance requests the appropriate information from the end users and forwards it to the RADIUS server for authentication and verification.
After enabling RADIUS processing, define a list of the RADIUS servers. The Cisco security appliance checks their availability on a round-robin basis. If the first server is not reachable, it tries the second server, and so on. If a server is available, the security appliance keeps using that server until it fails to receive a response. Upon such a failure, it checks the availability of the next server. It is highly recommended that you set up more than one RADIUS server in case the first server is not reachable. You can define a RADIUS server entry by navigating to Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups. Select the correct AAA server group and click Add in the Servers in the Selected Group area. You can specify the IP address of the RADIUS server and the interface closest to the server. The security appliance authenticates itself to the RADIUS server by using a shared secret key. The security appliance, for security reasons, never sends this shared secret key over the network.
Figure 20-17 shows the Cisco ASA configured with an AAA server under the server group called Radius. The server is located toward the inside interface at 192.168.10.100 and uses a server secret key of C1$c0123 (obfuscated).
Note
You can optionally modify the authentication and accounting port numbers if your RADIUS server does not use the default ports. The security appliance uses UDP ports 1645 and 1646 as defaults for authentication and accounting, respectively. Most of the RADIUS servers use ports 1812 and 1813 as authentication and accounting ports, respectively.
After defining the authentication servers, you have to bind them to the IPsec process under a tunnel group. Figure 20-17 illustrates that the newly created Radius AAA server group is mapped to the SecureMeIPSec tunnel group.
Tip
For large VPN deployments (both IPsec and SSL VPNs), you can even control user access and policy mapping from an external authentication server. Pass the user group policy name as a RADIUS or LDAP attribute to the security appliance. By doing so, you guarantee that a user always gets the same policy, regardless of the tunnel group name to which the user connects. If you are using RADIUS as the authentication and authorization server, you can specify the user group policy name as attribute 25 (class attribute). Append the keyword OU= as the value of the class attribute. For example, if you define a user group policy called engineering, you can enable attribute 25 and specify OU=engineering as its value.
Example 20-7 shows how a radius server can be defined. The radius group name is Radius and it is located toward the inside interface at 192.168.10.100. The shared secret is C1$c0123.
Example 20-7 Defining RADIUS for IPsec Authentication
Chicago(config)# aaa-server Radius protocol radius
Chicago(config)# aaa-server Radius (inside) host 192.168.10.100
Chicago(config-aaa-server-host)# key C1$c0123
Chicago(config-aaa-server-host)# exit
Chicago(config) tunnel-group SecureMeIPSec general-attributes
Chicago(config-tunnel-general)# authentication-server-group Radius
For configuration of external servers, consult Chapter 7, “Authentication, Authorization, and Accounting (AAA) Services.”
Step 6: Assign an IP Address
During the tunnel negotiations, an IP address is assigned to the VPN adapter of the IPsec VPN Client. The client uses this IP address to access resources on the protected side of the tunnel. Cisco ASA supports three different methods to assign an IP address back to the client:
Local address pool
DHCP server
RADIUS server
Many organizations prefer to assign an IP address from the local pool of addresses, for flexibility. You can assign the IP address by configuring an address pool and then linking the pool to a group policy. You can either create a new pool of addresses or select a preconfigured address pool. You define a new pool of addresses by choosing Configuration > Remote Access VPN > Network (Client) Access > Address Assignment > Address Pools, clicking Add, and configuring the following attributes, as illustrated in Figure 20-8:
Name: An alphanumeric name to be assigned to this pool. A pool name of IPPool is assigned.
Starting IP Address: The first IP address to be assigned to a client. A starting IP address of 192.168.50.1 is assigned.
Ending IP Address: The last IP address to be assigned to a client. An ending IP address of 192.168.50.254 is assigned.
Subnet Mask: The associated subnet mask for this pool of addresses. A subnet mask of 255.255.255.0 is configured.
By default, all address assignment methods are allowed. If you want to disable a specific address assignment method, do so by navigating to Configuration > Remote Access VPN > Network (Client) Access > Address Assignment > Assignment Policy.
If all three methods are configured for address assignment, Cisco ASA prefers RADIUS over DHCP and internal address pools. 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.
After defining a pool of addresses, map the pool to a user group policy. Choose Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, and click Edit. Uncheck the Inherit check box to the right of Address Pools and then click Select to choose a predefined pool of addresses, as shown in Figure 20-18. A dialog box pops up with all the preconfigured address pools. Select the address pool you want to use and click Assign to map the pool to this policy. In Figure 20-18, the IPPool is assigned to IPSecGroupPolicy. Click OK when you are finished.
Note
A static IP address can be assigned to a user under the user policy. The VPN user receives the same IP address regardless of the number of times they connect to the Cisco ASA.
Example 20-8 shows how to assign an address from a pool called IPPool, which is mapped to a group policy called IPSecGroupPolicy.
Example 20-8 Defining Pool of Addresses
Chicago(config)# ip local pool IPPool 192.168.50.1-192.168.50.254 mask 255.255.255.0
Chicago(config) group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# address-pools value IPPool
You can also link a pool of addresses to the tunnel group. However, if a pool is mapped to a group policy and a different pool is mapped to a tunnel group, then the security appliance prefers the pool mapped to the group policy.
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. To configure the IP address of the DHCP server in ASDM, navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec Connection Profiles, select SecureMeIPSec, click Edit, and specify an address in the DHCP Servers field. Example 20-9 illustrates how the security appliance in Chicago can be configured from the CLI to use a DHCP server with an IP address of 192.168.10.10 for address assignment.
Example 20-9 Address Assignment from a DHCP Server
Chicago(config)# vpn-addr-assign dhcp
Chicago(config)# tunnel-group SecureMeIPSec general-attributes
Chicago(config-general)# dhcp-server 192.168.10.10
Step 7: Create a 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. When you enable ISAKMP on an interface, Cisco ASDM preconfigures a dynamic crypto map for you. If you want to change any parameters, navigate to Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > Crypto Maps, select the dynamic crypto map—that has a priority of 65535—and click Edit. Here you can define the crypto map configuration for an IPsec rule. The values you define here appear in the IPsec Rules table after you click OK. All rules are enabled by default as soon as they appear in the IPsec Rules table. Every tunnel policy must specify a transform set and identify the security appliance interface to which it applies. The transform set identifies the encryption and hash algorithms that perform IPsec encryption and decryption operations. Because not every IPsec peer supports the same algorithms, you might want to specify a number of policies and assign a priority to each. The security appliance then negotiates with the remote IPsec peer to agree on a transform set that both peers support.
A dynamic tunnel policy is used when you cannot or do not want to provide information about remote hosts that are permitted to initiate a connection with the security appliance. If you are only using your security appliance as a VPN client in relation to a remote VPN central-site device, you do not need to configure any dynamic tunnel policies. Dynamic tunnel policies are most useful for allowing remote access clients to initiate a connection to your network through a security appliance acting as the VPN central-site device. A dynamic tunnel policy is useful when the remote access clients have dynamically assigned IP addresses or when you do not want to configure separate policies for a large number of remote access clients. Additional information about IPsec crypto maps is covered in the “Create a Crypto Map” section in Chapter 19.
Example 20-10 demonstrates the configuration of the Cisco ASA to use the defined transform set ESP-AES-256-SHA with the default dynamic crypto map. The dynamic crypto map name is SYSTEM_DEFAULT_CRYPTO_MAP and it is configured with a sequence number of 65535. Assigning a transform set to a dynamic crypto map is a required configuration step.
Example 20-10 Defining Dynamic Crypto Map
Chicago(config)# crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set
transform-set ESP-AES-256-SHA
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 19 covers these attributes.
When a dynamic map is defined via Cisco ASDM, it also creates a crypto map entry that eventually gets applied to the interface terminating the IPsec tunnels. Example 20-11 shows the crypto map configuration when a dynamic map called SYSTEM_DEFAULT_CRYPTO_MAP is linked to a static map called outside_map.
Example 20-11 Defining Static Crypto Map
Chicago(config)# crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
The crypto map can have both static and dynamic crypto map entries, discussed later in the section “Load Balancing of Cisco IPsec Clients and Site-to-Site Integration.”
The Cisco ASA limits you to 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.
The next step in setting up a remote-access tunnel is to bind the crypto map to an interface. When ISAKMP is enabled on an interface, Cisco ASDM applies the crypto map on the interface dynamically. If you are configuring the IPsec tunnels via the CLI, use the crypto map command followed by the name of the crypto map and the interface terminating the tunnels. In Example 20-12, the crypto map outside_map is applied to the outside interface of the Chicago ASA.
Example 20-12 Applying a Crypto Map to the Outside Interface
Chicago(config)# crypto map outside_map interface outside
Step 8: Configure Traffic Filtering (Optional)
Like a traditional firewall, the Cisco ASA protects the trusted network from outside traffic, unless the ACLs explicitly permit traffic to pass through it. However, by default, the security appliance allows all IPsec traffic to pass through the interface ACLs. For instance, even if the outside interface ACL does not permit the decrypted traffic to pass through, the security appliance trusts the remote private network and permits the decrypted packets to pass through.
You can change this default behavior, if you want the outside interface ACL to inspect the IPsec protected traffic, by navigating to Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > System Options and unchecking the Enable Inbound IPsec Sessions to Bypass Interface Access Lists check box. If you prefer to use the CLI, issue the no sysopt connection permit-vpn command and define appropriate ACLs to allow VPN traffic to pass through. Example 20-13 shows that only the Telnet traffic from the VPN pool of addresses (192.168.50.0/24) to an inside host located at 192.168.10.10 is allowed to pass through the security appliance.
Example 20-13 Disabling Sysopt and Configuring ACLs
Chicago(config)# no sysopt connection permit-vpn
Chicago(config)# access-list outside_acl extended permit tcp 192.168.50.0
255.255.255.0 host 192.168.10.10 eq 23
Chicago(config)# access-group outside_acl in interface outside
If you do not want to disable sysopt connection permit-vpn and still want to filter VPN traffic for a specific user or group policy, define an access list to allow or deny specific traffic and map that access list to a user or group policy. Using ASDM, choose Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, click Edit, click the More Options button on the General screen, uncheck the Inherit box for the IPv4 Filter option, and choose an ACL from the drop-down menu.
Example 20-14 shows that only the Telnet traffic from the VPN pool of addresses (192.168.50.0/24) to an inside host located at 192.168.10.10 is allowed to pass through the IPSecGroupPolicy.
Chicago(config)# access-list FilterTelnet extended permit tcp 192.168.50.0
255.255.255.0 192.168.10.10 255.255.255.0 eq telnet
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group)# vpn-filter value FilterTelnet
Step 9: Bypass NAT (Optional)
In most cases, you do not want to change the IP addresses for the traffic going over the tunnel. If NAT is configured on the security appliance to change the source or destination IP addresses, you can set up the NAT exemption rules to bypass address translation, as discussed in Chapter 10, “Network Address Translation,” and Chapter 19.
Step 10: Set Up Split Tunneling (Optional)
After the tunnel is up, the default behavior of the Cisco IPsec VPN Client is to encrypt traffic to all destination IP addresses. This means that if an IPsec user wants to browse to http://www.cisco.com over the Internet, the packets get encrypted and are sent to Cisco ASA. After decrypting them, the security appliance looks at its routing table and forwards 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 SSL VPN client.
This behavior might not always be desirable for the following two reasons:
Traffic destined to the nonsecure networks traverses over the Internet twice: once encrypted and once in clear text.
Cisco ASA handles extra VPN traffic destined to the nonsecure subnet. The security appliance analyzes all traffic leaving and coming from the Internet, and that impacts overall device performance.
With split tunneling, the security appliance can notify the IPsec VPN client about 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 remote computer is susceptible to hackers potentially taking control over the computer and directing traffic over the tunnel. To mitigate this behavior, a personal firewall is highly recommended on the IPsec VPN clients’ workstations.
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)
In the third mode, tunnel all but specific networks, Cisco ASA tunnels all traffic except for a list of networks that require cleartext access. This feature is useful if users require cleartext access to their LAN and an encrypted tunnel for all other traffic.
Split tunneling can be configured under a user, user group policy, or default group policy. Choose Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, click Edit, and choose Advanced > Split Tunneling in the left pane. Next to Policy and Network List, uncheck the Inherit check box. Choose Tunnel Network List Below from the Policy drop-down menu. Additionally, choose a network list from the Network List drop-down menu. If you would rather define a new network list, click the Manage option, in which case Cisco ASDM launches the ACL Manager and prompts you to define a new list. Under the Standard ACL tab, click Add to add an ACL. A new ACL, called SplitTunnelList, has been added. Select the newly defined list, click Add again on the Standard ACL tab, and add an ACE. Two ACE entries for 192.168.10.0/24 and 192.168.20.0/24 have been added with a description of List to Allow Access to Inside Network.
Example 20-15 shows the CLI equivalent of the previous steps.
Example 20-15 Split Tunnel Configuration
Chicago(config)# access-list SplitTunnelList standard permit 192.168.10.0 255.255.255.0
Chicago(config)# access-list SplitTunnelList standard permit 192.168.20.0 255.255.255.0
Chicago(config)# access-list SplitTunnelList remark List to Allow Access to Inside Network
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# split-tunnel-policy tunnelspecified
Chicago(config-group-policy)# split-tunnel-network-list value SplitTunnelList
Step 11: Assign DNS and WINS (Optional)
For the IPsec VPN clients, you can assign DNS and WINS server IP addresses so that they can browse and access internal sites after their tunnel has established. To configure these attributes, choose Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, click Edit, and click Servers in the left pane. Uncheck the Inherit check box for DNS Servers, WINS Servers, and Default Domain. To add multiple DNS or WINS servers, use a comma (,) to separate the entries. In Figure 20-19, the primary DNS server is defined as 192.168.10.10, and the secondary DNS server is 192.168.10.20. The primary WINS server is 192.168.10.2. The default domain name to be pushed to the IPsec VPN Client is securemeinc.org.
Example 20-16 shows the CLI equivalent of Figure 20-19.
Example 20-16 Defining DNS and WINS Servers for IPsec VPN Clients
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# wins-server value 192.168.10.20 192.168.10.10
Chicago(config-group-policy)# dns-server value 192.168.10.10 192.168.10.20
Chicago(config-group-policy)# default-domain value securemeinc.org
IPsec (IKEv2) Remote-Access Configuration Steps
The Cisco AnyConnect Secure Mobility Client supports IKEv2. The Cisco ASA configuration steps that support IKEv2 connections from the Cisco AnyConnect Secure Mobility Client are very similar to IKEv1 with a few exceptions. Define a new IPsec remote-access connection by choosing Wizards > VPN Wizards > AnyConnect VPN Wizard. Proceed with the following wizard steps to define a remote-access IPsec IKEv2 tunnel.
Step 1: Introduction
After the AnyConnect VPN Connection Setup Wizard is launched, an introduction (summary) is displayed. Click Next to proceed with the wizard.
Step 2: Connection Profile Identification
The next step is to configure a connection profile and the interface that the remote-access users will retrieve for VPN connections. In the example shown in Figure 20-20, IKEv2Profile is entered in the Connection Profile Name field and the outside interface is selected in the VPN Access Interface field. Click Next after you have completed the fields.
Step 3: VPN Protocols
On the VPN Protocols screen, shown in Figure 20-21, the AnyConnect VPN Wizard prompts you to choose the protocol to be used to protect the data traffic (SSL or IPsec). In this case, IPsec is checked.
IKEv2 requires a valid device certificate on the Cisco ASA. You can configure a device certificate with RSA or ECDSA keys. Only IKEv2 connections support certificates with ECDSA keys. In this example, ECDSA is used, as described next.
Click Manage to open the Manage Identity Certificates dialog box. Then click Add to add an identity certificate and its details. To add a new identity certificate, click the Add a New Identity Certificate radio button, as illustrated in Figure 20-22.
The goal in this example is to use ECDSA, so click New to display the Add Key Pair dialog box.
Choose the ECDSA key type, as shown in Figure 20-23.
To use the default key pair name, click the Use Default Key Pair Name radio button. To use a new key pair name, click the Enter a New Key Pair Name radio button and type the new name. In this case, the default key pair name is used.
Choose the modulus size from the Size drop-down list.
Click Generate Now to create new key pairs, and then click Show to display the Key Pair Details dialog box. Click OK to go back to the Add Identity Certificate dialog box.
Choose a certificate subject DN to form the DN in the identity certificate and then click Select to display the Certificate Subject DN dialog box.
Choose one or more DN attributes that you want to add from the drop-down list, enter a value, and then click Add. Available X.500 attributes for the Certificate Subject DN are the following:
Common Name (CN)
Department (OU)
Company Name (O)
Country (C)
State/Province (ST)
Location (L)
E-mail Address (EA)
To create self-signed certificates, check the Generate Self-signed Certificate check box, as illustrated in Figure 20-22.
In this instance, the self-signed certificate generated by the Cisco ASA is used. However, to configure additional identity certificate settings or enroll to an external certificate authority (CA) server, click Advanced. Chapter 21, “Configuring and Troubleshooting PKI,” covers PKI and the use of external CA servers.
Click OK and then click Next to proceed to the next step of the AnyConnect VPN Wizard.
Step 4: Client Images
The Cisco AnyConnect software can be provisioned to users from the Cisco ASA. The only thing that the new user needs to do is point a web browser to the interface that is enabled to terminate VPN client connections.
You can upload the AnyConnect installation file on the ASA flash memory or to replace an image already listed in the table, by clicking Add or Replace respectively. You can also browse the flash memory to identify a file, or upload a file from a local computer.
You can use a regular expression to match the user agent of a browser to an image. You can also minimize connection setup time by moving the most commonly encountered operation system to the top of the list.
After adding the AnyConnect software versions you would like clients to use, click Next.
Step 5: Specify User Authentication Method
In the next window, the wizard prompts you to select a user authentication mechanism, either the local database or an external server. If you want to use an external server, such as RADIUS, click Authenticate Using an AAA Server Group and enter a predefined server group name. If a server is not defined, click New to define a new external authentication server. If you would rather use the local database, click Authenticate Using the Local User Database. After you click Next, ASDM prompts you to add any additional users that you want to declare. If you do not want to add any additional local users, click Next to specify a pool of addresses to be assigned to the VPN clients.
Step 6: Specify an Address Pool
The next wizard window prompts you to select a predefined pool of addresses from the Pool Name drop-down menu. This is the same procedure as the one followed in the IPsec IKEv1 Remote Access VPN Wizard described earlier in the chapter. If a pool of addresses is not currently defined, click New and specify a pool name of IPPool, a starting IP address of 192.168.50.1, an ending IP address of 192.168.50.254, and a subnet mask of 255.255.255.0 for the new pool of addresses. Click Next to continue.
Step 7: Network Name Resolution Servers
After defining the pool of addresses, the wizard prompts you to specify mode-config attributes such as the primary and secondary DNS and WINS servers and a default domain name. All these parameters are optional and sent to the VPN client during tunnel negotiations. Specify 192.168.10.10 and 192.168.10.20 as the DNS addresses and 192.168.10.20 as the WINS addresses. Also specify a domain name of securemeinc.org. Click Next to proceed with the wizard.
Step 8: NAT Exemption
If network translation is enabled on the ASA, the VPN traffic must be exempt from this translation. This is the same procedure as the one followed when configuring IKEv1 client connections, as described earlier in the chapter. Click Next to proceed with the wizard.
Step 9: AnyConnect Client Deployment
You can install the AnyConnect Client program to a client device via web launch or predeployment. When web launch is configured, the client installs automatically when a user accesses the ASA using a web browser. With predeployment, the client is manually installed on the user workstation. Click the Allow Web Launch option to enable web launch client installation. This is a global setting that affects all connections. Click Next to proceed.
The VPN Wizard shows you a summary of all the features and configurations you have set. After you have verified the configuration, click Finish to push the configuration to the security appliance.
Hardware-Based VPN Clients
The Cisco hardware-based VPN clients (also called Easy VPN hardware clients) can also provide the remote-access IPsec functionality by using the dedicated Cisco hardware devices. The Cisco hardware-based VPN client functionality is supported on the following platforms:
Cisco IOS routers
Cisco ASA 5505
A Cisco ASA 5505 can act as an IKEv1 VPN client and initiate a VPN tunnel on behalf of the hosts residing on the private subnet, as shown in Figure 20-24. When the ASA 5505 receives interesting traffic destined to pass over the VPN tunnel, it initiates an IPsec tunnel to the IP address of the headend security appliance. Hardware clients are only supported using IKEv1. IKEv2 is not supported in the Cisco ASA configured as a hardware client.
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-based Easy 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 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 when you use NEM VPN tunnels, 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 client configuration on the Cisco ASA 5505 requires the use of vpnclient commands. In Example 20-17, the Easy VPN client is configured on an ASA 5505 to connect to the headend ASA’s public IP address of 209.165.200.225. The group name that the Easy VPN client is using is SecureMeIPSec, with the group password of C!$c0K3y. The administrator has set up network extension mode for this connection. For X-Auth, a username of ciscouser with a password of C1$c0123 is being configured.
Example 20-17 Cisco 5505 Easy VPN Client Configuration
interface Vlan1
nameif inside
security-level 100
ip address 192.168.60.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 209.165.201.3 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
! Address Translation rules for the inside hosts to connect to the Internet
global (outside) 1 interface
nat (inside) 1 192.168.60.0 255.255.255.0
!—- Specify the IP address of the VPN server.
vpnclient server 209.168.200.225
!—- This example uses network extension mode.
vpnclient mode network-extension-mode
!—- Specify the group name and the pre-shared key.
vpnclient vpngroup SecureMeIPSec password C!$c0K3y
!—- Specify the authentication username and password.
vpnclient username ciscouser password C1$c0123
!—- In order to enable the device as hardware vpnclient, use this command.
vpnclient enable
Note
For Cisco IOS Easy VPN Client installation and configuration documents, refer to the following link:
http://www.cisco.com/go/easyvpn.
Advanced Cisco IPsec VPN Features
Cisco ASA provides many advanced features to suit your remote-access VPN implementations, including the following:
Hardware-based Easy VPN client features
Tunnel Default Gateway
A Layer 3 device typically has a default gateway that it uses to route packets when the destination address is not found in its routing table. The tunnel default gateway is used to route packets if they reach the security appliance over an IPsec tunnel and 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, or any Layer 3 device.
The tunnel default gateway feature is important if you do not want to define routes for your internal networks on the Cisco ASA, and instead prefer that all tunneled traffic be sent to the internal router for routing.
To set up a tunnel default gateway, navigate to Configuration > Device Setup > Routing > Static Routes and click Add. An Add Static Route dialog box appears in which you can add a default route with the gateway IP being the next-hop IP address of the inside router (Router1), as shown in the topology illustrated in Figure 20-24. Make sure that you select the Tunneled radio button, as shown in Figure 20-25.
If you prefer to use the CLI, make sure that you add the keyword tunneled to the statically configured default route. Example 20-18 shows the configuration of the appliance with the tunnel default gateway specified as 192.168.10.2, located on the inside interface.
Example 20-18 Tunnel Default Gateway Configuration
Chicago(config)# route inside 0.0.0.0 0.0.0.0 192.168.10.2 tunneled
Transparent Tunneling
In many network topologies, the VPN clients reside behind a NAT/PAT device that inspects the Layer 4 port information for address translation. Because IPsec uses ESP (IP protocol 50), which does not have Layer 4 information, the PAT device is usually incapable of translating the encrypted packets going over the VPN tunnel. To remedy this problem, Cisco ASA offers three solutions:
NAT Traversal (NAT-T)
IPsec over UDP
IPsec over TCP
NAT Traversal
NAT-T, defined in RFC 3947 (“Negotiation of NAT-Traversal in the IKE”), is a feature that encapsulates the ESP packets into UDP port 4500 packets. NAT-T is dynamically negotiated if the following two conditions are met:
Both VPN endpoints are NAT-T capable
A NAT or PAT device exists between VPN peers
If both conditions are true, the VPN client tries to connect to the security appliance, using UDP port 500 for IKE negotiations. As soon as the VPN peers discover that they are NAT-T capable and that a NAT/PAT device resides between them, they switch over to UDP port 4500 for the rest of tunnel negotiations and data encapsulation.
NAT-T is globally enabled on the security appliance by default, with a default keepalive timeout of 20 seconds. In many cases, the NAT/PAT devices time out the UDP port 4500 entries if no active traffic is passing through them. NAT-T keepalives are used so that the security appliance can send periodic keepalive messages to prevent the entries from timing out. You can specify a NAT-T keepalive range between 10 and 3600 seconds.
If NAT-T is not enabled for some reason, navigate to Configuration > Remote Access VPN > Network (Access) Client > Advanced > IPsec > IKE Parameters and check the Enable IPsec over NAT-T check box. Example 20-19 illustrates how NAT-T is globally enabled in the CLI, with keepalives sent every 30 seconds.
Example 20-19 Enabling NAT-T Globally
Chicago(config)# crypto isakmp nat-traversal 30
IPsec over UDP
IPsec over UDP, similar to NAT-T, is employed to encapsulate the ESP packets using a UDP wrapper. This is useful in scenarios where the VPN clients do not support NAT-T and are behind a firewall that does not allow ESP packets to pass through. In IPsec over UDP, the IKE negotiations still use UDP port 500. During the negotiations, Cisco ASA informs the VPN client to use IPsec over UDP for data transport. Additionally, Cisco ASA updates the VPN client about the UDP port that should be used.
To enable IPsec over UDP in a user group policy, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, click Edit, and choose Advanced > IPsec (IKEv1) Client in the left pane. Uncheck the Inherit check box for the IPsec over UDP and IPsec over UDP Port parameters. Click the Enable radio button for IPsec over UDP and specify port 10000 for IPsec over UDP Port.
Example 20-20 shows how Cisco ASA can be set up in the CLI to use IPsec over UDP for the remote-access group IPSecGroupPolicy. Cisco ASA pushes UDP port 10000 as the data encapsulation port to the VPN client.
Example 20-20 IPsec over UDP Configuration
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# ipsec-udp enable
Chicago(config-group-policy)# ipsec-udp-port 10000
IPsec over TCP
IPsec over TCP is an important feature used in scenarios such as
UDP port 500 is blocked, resulting in incomplete IKE negotiations.
ESP (IP protocol 50) is not allowed to pass, and as a result encrypted traffic does not traverse.
The network administrator prefers to use a connection-oriented protocol.
With IPsec over TCP, the security appliance negotiates the VPN tunnel, using TCP as the protocol over a preconfigured port. When the tunnel is up, both VPN devices (Cisco ASA and the VPN client) pass traffic through the same connection. Enable it by navigating to Configuration > Remote Access VPN > Network (Access) Client > Advanced > IPsec > IKE Parameters and then checking the Enable IPsec over TCP check box and specifying a port number. Example 20-21 illustrates how to configure IPsec over TCP on Cisco ASA. The administrator of the security device prefers to use TCP port 10000 for tunnel setup and data transport. Cisco ASA allows up to ten TCP ports to be used for this feature.
Example 20-21 IPsec over TCP Configuration
Chicago(config)# isakmp ipsec-over-tcp port 10000
To verify whether the VPN clients are using IPsec over TCP, use the show crypto ipsec sa | include settings command, as demonstrated in Example 20-22. The In Use Settings option indicates that the particular VPN connection is a remote-access tunnel using TCP encapsulation.
Example 20-22 Verifying VPN Client Use of IPsec over TCP
Chicago(config)# show crypto ipsec sa | include settings
in use settings ={ RA, Tunnel, TCP-Encaps, }
in use settings ={ RA, Tunnel, TCP-Encaps, }
IPsec Hairpinning
Cisco ASA, by default, does not allow a packet to leave the same interface on which it was originally received. Cisco ASA supports receiving the IPsec traffic from one VPN tunnel and then redirecting it into a different VPN tunnel, if both tunnels terminate on the same interface. This feature is known as IPsec hairpinning. Using this feature, you can implement a true hub-and-spoke scenario, as shown in Figure 20-26.
If Client1 needs to send traffic to Client2, it sends all traffic to the hub Cisco ASA. The hub Cisco ASA, after checking the routing table for the destination address, sends traffic to Client2 over the other VPN tunnel, and vice versa. However, this feature requires both remote VPN devices to be a part of the same crypto map and the crypto map to be applied to the same interface.
You can enable IPsec hairpinning by navigating to Configuration > Device Setup > Interfaces and checking the Enable Traffic Between Two or More Hosts Connected to the Same Interface check box. Using the CLI, you use the global same-security-traffic permit intra-interface command to permit VPN traffic to leave the same physical interface when traffic needs to go over the other VPN tunnel.
Cisco ASA also supports receiving traffic from an IPsec client and then redirecting it to the Internet in clear text. This feature, also known as Client U-turn, is useful if you
Are not using split tunneling and all traffic is sent to the security appliance.
Want to provide Internet access to your IPsec clients.
Do not want return traffic from the Internet that is destined to the VPN clients to enter the inside network of your organization.
Cisco ASA applies firewall rules (ACL checking, packet inspection, NAT, IDS, URL filtering) before sending traffic out to the same interface for both IPsec hairpinning and Client U-turn. As shown in Example 20-23, if the pool of addresses is 192.168.50.0/24, then you must configure the NAT and global commands to allow the VPN client traffic to access the Internet.
Example 20-23 Allowing VPN Clients for Internet Access
same-security-traffic permit intra-interface
ip local pool IPPool 192.168.50.1-192.168.50.254
object network vpn_local
subnet 192.168.50.0 255.255.255.0
nat (outside,outside) dynamic interface
object network inside_nw
subnet 192.168.10.0 255.255.255.0
nat (inside,outside) dynamic interface
! Use twice NAT to pass traffic between the inside network and the VPN client without
! address translation (identity NAT):
nat (inside,outside) source static inside_nw inside_nw destination static vpn_local vpn_local
VPN Load Balancing
VPN load balancing is a way to distribute remote-access IPsec and SSL VPN connections across multiple security appliances. When two or more Cisco ASA devices are deployed in load balancing, they form a virtual cluster, with one of the security appliances acting as the cluster master. All Cisco ASA devices in the cluster are configured with a virtual IP address, and the cluster master takes ownership of that IP address, as illustrated in Figure 20-27.
The VPN clients use this IP address to initiate the tunnel request. The master appliance, after receiving the request, looks at the load-balance database and determines which security appliance has the least load. The master appliance sends a redirect message back to the client with the IP address of the security appliance to which the client should connect. After receiving the IP address of the Cisco ASA, the client initiates a new request to the Cisco ASA and goes through the IKE negotiations.
The load-balancing feature is supported on the following remote-access client types:
Cisco AnyConnect Secure Mobility Client
Legacy Cisco IPsec VPN Client (Release 3.0 and later)
Cisco ASA 5505 as an Easy VPN client
Cisco IOS Easy VPN Client devices, such as 831/871 supporting IKE-redirect
Clientless SSL VPN
Note
Load balancing is not supported on L2TP over IPsec tunnels and IPsec site-to-site tunnels.
To set up VPN load balancing, navigate to Configuration > Remote Access VPN > Load Balancing and configure the following attributes:
Participate in Load Balancing Cluster: Check this box if you want this security appliance to participate in load balancing the remote-access sessions.
Cluster IP Address: The cluster IP address is the virtual IP address of the load-balancing cluster that the remote-access clients use to establish their initial connections. The Cluster IPv4 Address specifies the single IPv4 address that represents the entire IPv4 virtual cluster. Similarly, the Cluster IPv6 Address specifies the single IPv6 address that represents the entire IPv6 virtual cluster.
UDP Port: Specify a port that is used by the security appliance to send and receive the load-balancing information. By default, it uses UDP port 9023.
Enable IPsec Encryption: Check this box if you want the Cisco ASAs to optionally secure their communication when the Cisco ASAs that are members of the cluster exchange load-balancing information.
IPsec Shared Secret: Specify a shared secret to be used by the load-balancing process to encrypt communication. If there is a mismatch in the key, the security appliance fails to join the cluster.
Public Interface: Specify the interface that terminates the IPsec tunnels. By default, it is the outside interface.
Private Interface: Specify the interface that connects to the internal network. By default, it is the inside interface. You must enable ISAKMP processing on the inside interface if you choose to encrypt load-balancing information.
NAT Assigned IPv4 Address and NAT Assigned IPv6 Address: If the Cisco ASA devices sit behind a NAT device, then you can configure the security appliance’s translated address as the NAT assigned IPv4 or IPv6 address, respectively.
Priority: You can set the appropriate priority to indicate the likelihood of a Cisco ASA device becoming the cluster master, either during bootup or when the existing cluster master fails to respond. The default priority of Cisco ASA devices is determined based on the model number. If two Cisco ASA devices with the same priority are powered up simultaneously, then the security appliance with the lowest IP address becomes the cluster master. Otherwise, the security appliance with the highest priority assumes the role of master cluster. If the cluster master fails to respond during operation, the secondary appliance with the highest priority becomes the new cluster master. You can specify a priority between 1 and 10. When the original master appliance comes online, it does not preempt to regain control.
In Figure 20-28, a security appliance is configured to participate in VPN load balancing. The cluster IP address is 209.165.200.227 and the IPsec shared secret is C1$c0123 (masked). The device priority is 6.
Load balancing can be configured to redirect IKEv2 connections to another ASA during the security association (SA) authentication or during SA initialization. In Figure 20-28, Redirect During SA Authentication is selected.
If you prefer to configure VPN load balancing via the CLI, Example 20-24 shows the relevant configuration.
Example 20-24 VPN Load-Balancing Configuration with Encryption
Chicago(config)# vpn load-balancing
Chicago(config-load-balancing)# priority 6
Chicago(config-load-balancing)# cluster key C1$c0123
Chicago(config-load-balancing)# cluster ip address 209.165.200.227
Chicago(config-load-balancing)# cluster encryption
Chicago(config-load-balancing)# participate
Note
VPN load balancing requires you to enable ISAKMP on all the interfaces participating in load balancing. If you enable load balancing but ISAKMP is not enabled on an interface, you receive the following error message:
Chicago(config-load-balancing)# participate
ERROR: Need to enable isakmp on interface inside to use encryption.
Client Firewalling
The Cisco VPN client has an integrated personal firewall that protects a machine from the Internet by inspecting packets both inbound and outbound. When you have the firewall option enabled on the VPN client, the client provides extra security if the VPN tunnel group to which the user is connecting has split tunneling enabled. In this way, the VPN client firewall denies packets received from the unprotected networks, resulting in more secure corporate networks. Cisco ASA supports two different scenarios for client firewalling, discussed in the sections that follow.
Note
Only Windows VPN clients support the client firewalling feature.
Personal Firewall Check
The Cisco VPN client can check to see whether the firewall service on the machine is running by sending periodic keepalives, also known as Are you there (AYT) messages, to the specified VPN client firewall. If the firewall service on the client machine is not running, the VPN client fails to establish the secured connection. Additionally, if the VPN tunnel is up and the user manually turns off the firewall service, the keepalives time out and the Cisco VPN client drops the connection.
To configure the client firewall option, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, click Edit, and choose Advanced > IPsec (IKEv1) Client > Client Firewall. Uncheck the Inherit from Default Group Policy check box and choose a firewall type from the Firewall Setting drop-down list. An administrator can set up Cisco ASA for three firewall check types:
No Firewall: The personal firewall check is disabled. This mode is useful if non-Windows clients are connecting to a group.
Firewall Optional: Cisco ASA checks to see whether the firewall services on the VPN client are running. If they are disabled, Cisco ASA still allows the VPN connection to come up. This mode is useful if Windows and non-Windows clients connect to a group.
Firewall Required: If the firewall service is not running, Cisco ASA does not allow the VPN tunnel to be established. This mode is recommended if only Windows clients connect to a group.
For optional (opt) and required (req) modes, Cisco ASA provides a list of currently supported personal firewalls, including the built-in Cisco Integrated Client Firewall. As shown in Figure 20-29, Cisco Integrated Client Firewall is selected as a required firewall before the VPN sessions are allowed to connect. If the VPN clients don’t have this firewall running, Cisco ASA stops the tunnels from getting established.
Note
You can define a customized firewall, if you know the vendor ID and product ID, by using the settings in the Custom Firewall area. These settings are enabled when the Custom Firewall option is selected from the Firewall Type pull-down menu.
Central Protection Policy
When split tunneling is employed, Cisco ASA can additionally send security policies in the form of ACLs to the client machine and restrict its cleartext traffic capabilities. This deployment scenario, known as Centralized Protection Policy (CPP) or policy pushed, uses ACLs that can be pushed to the client firewall. This feature is extremely useful if you want your remote users to browse a limited set of IP addresses when they are sending traffic in clear text and you want to filter out all other traffic.
Note
CPP is supported in only those Windows VPN clients that have the integrated stateful firewall functionality. Microsoft Windows 2003 and Windows Vista do not support this feature.
To define a CPP, navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, select IPSecGroupPolicy, click Edit, and choose Advanced > IPsec (IKEv1) Client > Client Firewall. Uncheck Inherit from Default Group Policy and choose Firewall Required in the Firewall Setting drop-down list. Also choose Cisco Integrated Client Firewall (CIC) from the Firewall Type drop-down list. In the Firewall Policy area, make sure that Policy Pushed (CPP) is selected. ASDM enables you to choose an inbound policy and an outbound policy to be applied to the user connections. If you do not have an ACL defined, click the Manage button and, in the dialog box that opens, specify the ACLs to be pushed to the user connections.
Note
The CIC ACLs are defined from the VPN client’s perspective. That means the outbound ACL should have the pool of addresses as the source and the target network as the destination. Similarly, the inbound ACL should have the target network as the source and the pool of addresses as the destination.
If you are defining ACLs at the protocol level, make sure that you allow DNS queries and the responses in the policies. For instance, if the DNS server resides at 192.168.101.1, then allow port 53 for the DNS server’s IP address in your ACLs.
You can define a central protection policy via the CLI, as shown in Example 20-25.
Example 20-25 Configuration of Central Protection Policy
Chicago(config)# access-list FW-IN extended permit ip 192.168.100.0 255.255.255.0
192.168.50.0 255.255.255.0
Chicago(config)# access-list FW-IN extended permit udp host 192.168.101.1 eq 53
192.168.50.0 255.255.255.0
Chicago(config)# access-list FW-OUT extended permit ip 192.168.50.0 255.255.255.0
192.168.100.0 255.255.255.0
Chicago(config)# access-list FW-OUT extended permit udp 192.168.50.0 255.255.255.0
host 192.168.101.1 eq 53
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# client-firewall req cisco-integrated acl-in FW-IN acl-out FW-OUT
Hardware-Based Easy VPN Client Features
Cisco ASA provides further security for the Easy VPN hardware client if you enable specific features by navigating to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, selecting IPSecGroupPolicy, clicking Edit, and choosing Advanced > IPsec (IKEv1) Client > Hardware Client. Figure 20-30 displays these features and shows ASDM configuration when all these features are turned on.
Interactive Client Authentication
Cisco ASA can use the interactive hardware client authentication feature, also known as secure unit authentication, which ensures that the hardware-based Easy VPN client provides user credentials every time the tunnel is negotiated. That way, the security appliance does not allow user passwords to be saved on the hardware-based Easy VPN client, which provides additional security. If the user password is saved on the hardware-based Easy VPN client, Cisco ASA pushes down a policy during mode-config to delete the saved password from the hardware-based Easy VPN client configuration. Navigate to the screen shown in Figure 20-30 and click Enable for the Require Interactive Client Authentication option to enable this feature. Example 20-26 shows the configuration to set up Cisco ASA for interactive hardware client authentication for the IPSecGroupPolicy group.
Example 20-26 Configuration of Interactive Client Authentication
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# secure-unit-authentication enable
Individual User Authentication
Using the Individual User Authentication feature, Cisco ASA secures the VPN tunnel by making sure that users behind the hardware-based Easy VPN client are authenticated before they can access corporate resources. To be able to pass traffic over the tunnel, a user behind the hardware-based Easy VPN client must launch a web browser and present valid user credentials. The hardware-based Easy VPN client forwards the user information to the Cisco ASA, which in turn uses the configured authentication method to validate the user information.
Tip
Users do not have to manually point the web browser to the IP address of the hardware-based Easy VPN client. Instead, users can try to browse to any server behind the security appliance, and the hardware-based Easy VPN client will redirect them for user credentials.
Navigate to the screen shown in Figure 20-30 and click Enable for the Require Individual User Authentication option to enable this feature. Example 20-27 shows the Cisco ASA configuration for Individual User Authentication for the IPSecGroupPolicy group.
Example 20-27 Configuration of Individual User Authentication
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# user-authentication enable
You can also specify the idle-time period if there is no activity over a user’s connection. When the idle-time period expires, Cisco ASA terminates that particular connection. Specify the timeout in minutes or as unlimited for the User Authentication Idle Timeout option shown in Figure 20-30. In Example 20-28, group IPSecGroupPolicy is configured to time out inactive users after 60 minutes.
Example 20-28 Configuration of Individual User Idle Timeout
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# user-authentication-idle-timeout 60
LEAP Bypass
LEAP bypass is a feature in the security appliance that allows Lightweight Extensible Authentication Protocol (LEAP) packets to go over the VPN tunnel when individual hardware client authentication is configured. Enable LEAP bypass by navigating to the screen shown in Figure 20-30 and clicking Enable for the LEAP Bypass option. Example 20-29 shows the Cisco ASA configuration for LEAP bypass for the IPSecGroupPolicy group.
Example 20-29 Configuration of Cisco Aironet LEAP Bypass
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# leap-bypass enable
Note
This feature works only with Cisco Aironet access points using LEAP for authentication. It does not work if interactive hardware client authentication is enabled.
Cisco IP Phone Bypass
When individual hardware client authentication is enabled, Cisco ASA tries to authenticate Cisco IP phones if they send traffic to go over the tunnel. You can set up the security appliance to bypass authentication for Cisco IP phones by navigating to the screen shown in Figure 20-30 and clicking Enable for the Cisco IP Phone Bypass option. In Example 20-30, this feature is enabled for IPSecGroupPolicy group policy.
Example 20-30 Configuration of Cisco IP Phone Bypass
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# ip-phone-bypass enable
Note
For this feature to work, make sure that the hardware-based Easy VPN client is using network extension mode.
Hardware Client Network Extension Mode
You have the option to configure a group policy to disable network extension mode (NEM) on Cisco ASA. When you employ this option, the hardware-based Easy VPN clients are restricted to use client/PAT mode for VPN tunnels. If they try to use NEM, Cisco ASA blocks the tunnel from being established. You can enable NEM by navigating to the screen shown in Figure 20-30 and clicking Enable for the Allow Network Extension Mode option. Example 20-31 shows the Cisco ASA configuration to allow NEM for the IPSecGroupPolicy group.
Example 20-31 Configuration to Allow NEM
Chicago(config)# group-policy IPSecGroupPolicy attributes
Chicago(config-group-policy)# nem enable
L2TP over IPsec Remote-Access VPN (IKEv1)
Organizations that prefer to use a built-in remote-access client in the Windows-based operating systems can use L2TP. However, L2TP fails to provide strong data confidentiality. Therefore, most of the L2TP implementations employ IPsec to provide data security. This methodology is commonly referred to as L2TP over IPsec and is documented in RFC 3193, “Securing L2TP Using IPsec.”
Note
L2TP over IPsec is only supported with IKEv1. IKEv2 is not supported with L2TP over IPsec in the Cisco ASA.
In an L2TP over IPsec implementation, the client workstation and the security appliance go through seven steps, as depicted in Figure 20-31.
1. The user establishes a PPP session to the ISP access router and receives a dynamic public IP address. This step is optional if the workstation already has an IP address and can send traffic to the Internet.
2. The user launches the L2TP client that is configured to use IPsec (IKEv1) for data security.
3. The client workstation initiates a session and negotiates a secure channel for exchanging keys (IKEv1 Phase 1 negotiations of IPsec).
4. After successfully establishing Phase 1, the client establishes two secure channels for data encryption and authentication (IKEv1 Phase 2 negotiations of IPsec). The data channels are set up to encrypt L2TP traffic that is destined to UDP port 1701.
5. After IPsec is established, the client initiates an L2TP session within IPsec.
6. The user-specified authentication credentials are used to validate the L2TP session. Any PPP or L2TP attributes are negotiated after the user has been successfully authenticated.
7. After the L2TP session is established, the user workstation sends data traffic that is encapsulated within L2TP. The L2TP packets are encrypted by IPsec and then sent out to the other end of the tunnel over the Internet.
Note
If you have a firewall between the L2TP over IPsec client and the home gateway, you need to allow IP protocol 50 (ESP) and UDP port 500 to pass through. L2TP packets (UDP port 1701) are encapsulated within ESP. Some L2TP over IPsec vendors allow NAT Traversal (NAT-T) by encapsulating traffic into UDP port 4500.
Figure 20-32 shows an L2TP over IPsec packet format after all the headers and encapsulations have been added to the original packet.
Note
You can have multiple L2TP over IPsec clients behind a PAT device terminate their session on the security appliance using NAT-T. For more information about NAT-T on Windows platforms, refer to the Microsoft knowledge base article number 926179: http://support.microsoft.com/kb/926179.
L2TP over IPsec Remote-Access Configuration Steps
Figure 20-33 illustrates SecureMeInc.org’s Chicago hub office to be configured for the L2TP over IPsec solution. This topology is used to show the following configuration steps required to establish a successful tunnel. The best way to establish an L2TP over IPsec remote-access tunnel is through the use of the ASDM wizard. Many of these steps are identical to the steps discussed earlier in the chapter under the “IPsec (IKEv1) Remote-Access Configuration Steps” section.
Launch the IPsec IKEv1 Remote Access VPN Wizard by choosing Wizards > VPN Wizards > IPsec (IKEv1) Remote Access VPN Wizard (as shown earlier in Figure 20-2). ASDM launches the VPN Wizard with the option to choose a VPN tunnel interface. Proceed with the steps in the following sections to successfully define a L2TP over IPsec remote-access tunnel.
Step 1: Select Tunnel Interface
After the IPsec wizard is launched, the very first thing the ASDM wizard prompts you to do is to specify the tunnel interface. Choose outside from the VPN Tunnel Interface drop-down menu. Make sure that the Enable Inbound IPsec Sessions to Bypass Interface Access Lists check box is checked to bypass ACL checks for the decrypted traffic. Click Next to move to the Remote Site Peer window.
Step 2: Select Remote Access Client
In the next window, the VPN Wizard prompts you to select the IPsec remote-access client connection. You can choose either Cisco VPN Client, Release 3.x or Higher, or Other Easy VPN Remote Product or Microsoft Windows Client Using L2TP over IPsec. For the L2TP over IPsec connections, click Microsoft Windows Client Using L2TP over IPsec. Specify a PPP authentication protocol. Cisco ASA supports:
PAP: It is the most unsecure form of authentication because it sends the username and password in cleartext.
CHAP: It is considered more secure than PAP because the username is sent in cleartext but the password is sent as a response to a challenge by the server. The data, however, is sent in cleartext.
MS-CHAP-V1: It is an enhanced version of CHAP in which the client sends a response in MD4 hash to a challenge by the server.
MS-CHAP-V2: It offers additional security enhancements over MS-CHAP version 1, such as mutual authentication between peers.
EAP-Proxy: It allows the security appliance to proxy the PPP authentication process to an external RADIUS authentication server.
You can choose one or more authentication protocols. An authentication protocol is negotiated based on what is offered by the L2TP over IPsec client. Check MS-CHAP-V1 and MS-CHAP-V2 as the authentication protocols. Click Next.
Step 3: Select VPN Client Authentication Method
In the next window, the wizard prompts you to select an IKE authentication mechanism such as preshared keys or preinstalled certificates. Choose Pre-Shared Key as the authentication method and specify C!$c0K3y. For VPN clients using L2TP over IPsec, the DefaultRAGroup tunnel group must be used. This is why the VPN wizard shows the Tunnel Group section grayed out. Click Next to move to the user authentication window.
Step 4: Specify User Authentication Method
In the next window, the wizard prompts you to select a user authentication mechanism, either the local database or an external server. If you want to use an external server, such as RADIUS, click Authenticate Using an AAA Server Group and choose a predefined server group name from the drop-down list. If a server is not defined, click New and define a new external authentication server. If you would rather use the local database, click Authenticate Using the Local User Database.
Step 5: User Accounts
After you click Next, ASDM prompts you to add any additional users that you want to declare. If you do not want to add any additional local users, click Next.
Step 6: Specify an Address Pool
In the next window, the VPN Wizard prompts you to select a predefined pool of addresses from the Pool Name drop-down menu. If a pool of addresses is not currently defined, click New and specify a starting IP address of 192.168.50.1 and an ending IP address of 192.168.50.254 for the new pool of addresses. Click Next.
Step 7: Specify Attributes Pushed to Clients
After you define the pool of addresses, the VPN Wizard prompts you to specify mode-config attributes such as the primary and secondary DNS and WINS servers and a default domain name. All these parameters are optional and are sent to the VPN client during L2TP tunnel negotiations. Specify 192.168.10.10 as the DNS address and 192.168.10.20 as the WINS address. Define securemeinc.org as the default domain name. Click Next to specify an IKE policy.
Step 8: Select the IPsec Settings (Optional)
In the next window, the wizard prompts you to specify some of the optional IPsec parameters such as an address translation bypass mechanism, split tunneling, and Perfect Forward Secrecy (PFS). To identify local hosts/networks which do not require address translation, choose the name of the interface that connects to the hosts or networks you have selected and select the IP address of the host or network that you want to exempt from the chosen interface network. By default, the ASA hides the real IP addresses of internal hosts and networks from outside hosts by using dynamic or static NAT. If you specify a specific network, then traffic from that network to the pool of VPN traffic is bypassed for address translation.
Step 9: Verify the Configuration
The VPN Wizard shows a summary of all the features and configuration that have been completed. After you have verified the configuration, click Finish to push the configuration to the security appliance.
Windows L2TP over IPsec Client Configuration
On Microsoft Windows, you can configure the basic L2TP over IPsec parameters by following these steps:
1. Create a new connection by navigating to Start > Settings > Control Panel > Network Connections. Under Network Tasks in the left panel, click Create a New Connection. Windows launches the New Connection Wizard. Click Next to define a new connection entry.
2. Select Connect to the Network at My Workplace and click Next.
3. Under Network Connection, select Virtual Private Network Connection and click Next.
4. Specify a name for this connection, such as L2TPIPSecCorp, and click Next.
5. If the Public Network window comes up, select Do Not Dial the Initial Connection.
6. Specify the public IP address, such as 209.165.200.225, of the security appliance. Click Next to continue.
7. If the Smart Cards window is provided, select Do Not Use My Smart Card. Click Next to continue.
8. Under Connection Availability, specify whether you want to use this connection for everyone or only for the user who is currently logged in to the Windows workstation. Click Next and then Finish to complete the connection setup.
9. Windows launches the newly defined connection entry. Choose the Properties option and go to the Security tab. Under the Data Encryption drop-down menu, select Require Encryption (Disconnect if Server Declines). Select an authentication protocol by clicking Advanced and then Settings. Choose the MS-CHAP and MS-CHAP2 protocols. Click OK when you are finished.
10. Click the Click IPsec Settings, check Use Pre-Shared Key for Authentication, and type in the preshared key to set the preshared key. Click OK after specifying a key.
11. Click the Networking tab and select L2TP IPsec VPN under the Type of VPN drop-down menu. Click OK to complete this configuration.
12. Specify a username and password and then click Connect to start an L2TP over IPsec connection to the security appliance.
Deployment Scenarios
The ASA VPN solution can be deployed in many different ways. This section a common design scenario where the Cisco ASA is configured for load balancing of Cisco IPsec clients and site-to-site VPN.
Note
The design scenario discussed in this section should be used solely to reinforce learning. It should be used for reference purposes only.
Load Balancing of Cisco IPsec Clients and Site-to-Site Integration
SecureMeInc.org’s headquarters office in Chicago wants to deploy Cisco ASA to be used for remote-access VPN tunnels to support about 20,000 users. However, SecureMe wants to make sure that users do not overburden the system and therefore prefers to use two security appliances in load-balancing mode. SecureMe also wants to terminate a site-to-site tunnel on one of the security appliances. Figure 20-34 shows SecureMe’s network topology in Chicago.
The security requirements for SecureMe’s Chicago office are as follows:
Load-balance Cisco IPsec VPN connections across two Cisco ASA devices.
Use UDP encapsulation if a NAT device exists between the VPN devices.
Use a RADIUS server as the external database for user lookup.
Encrypt only the traffic destined for 192.168.0.0/16.
Configure a site-to-site VPN tunnel to the London ASA.
Assign the DNS and WINS server addresses as 192.168.10.10 and 192.168.10.20, respectively.
To meet these requirements, split tunneling is proposed for the Cisco VPN client so that traffic destined to 192.168.0.0/16 is encrypted. NAT-T, which is enabled by default, is to be used for UDP encapsulation.
Configuration Steps Through ASDM
The relevant configuration through ASDM is discussed in the steps that follow. These configuration steps assume that you have IP connectivity from the ASDM client to the management IP address of the security appliances. The management IP address of the Chicago ASA is 172.18.82.64.
1. Launch the IPsec IKEv1 Remote Access VPN Wizard by choosing Wizards > VPN Wizards > IPsec (IKEv1) Remote Access VPN Wizard (as shown earlier in Figure 20-2). ASDM launches the VPN Wizard with the option to choose a VPN tunnel interface. Select outside from the VPN Tunnel Interface drop-down menu. Make sure that the Enable Inbound IPsec Sessions to Bypass Interface Access Lists check box is checked to bypass ACL check for the decrypted traffic. Click Next.
2. In the next window, choose Cisco VPN Client, Release 3.x or Higher and click Next.
3. Choose Pre-Shared Key as the authentication method and specify C!$c0K3y. Under Tunnel Group, specify SecureMeIPSec as the tunnel name. Click Next.
4. In the next window, the wizard prompts you to select a user authentication mechanism. Use an external server such as RADIUS by clicking Authenticate Using an AAA Server Group. If a server is not defined, click New and define a new external authentication server group called Radius, located toward the inside interface at 192.168.10.100 with a shared secret of C1$c0123.
5. If a pool of addresses is not currently defined, click New and specify a name of IPPool with the starting IP address of 192.168.32.1 and the ending IP address of 192.168.64.254 with a subnet mask of 255.255.224.0. Click Next.
6. Configure the DNS and WINS server addresses of 192.168.10.10 and 192.168.10.20, respectively. Define securemeinc.org as the default domain name. Click Next to specify an IKE policy.
7. In the next IPsec Settings window, select the inside interface and specify 192.168.0.0/16 in the Exempt Networks field. Alternatively, you can click on th “...” button and then click Add to select the IP address of the host or network that you want to exempt from the chosen interface network. Check Enable Split Tunneling to Let Remote Users Have Simultaneous Encrypted Access to turn on split tunneling. Uncheck the Enable Perfect Forwarding Secrecy (PFS) box. Click Next to continue.
8. The VPN Wizard shows you a summary of all the features and configurations you have set. After you have verified the configuration, click Finish to push the configuration to the security appliance.
9. Before you configure load balancing, enable ISAKMP on the private (inside) interface so that the load-balancing packets can be encrypted. Navigate to Configuration > Remote Access VPN > Network (Client) Access > IPsec Connection Profiles and check the Allow Access check box for the inside interface.
10. Configure load balancing by navigating to Configuration > Remote Access VPN > Load Balancing and defining the following attributes to enable load balancing:
Participate in Load Balancing Cluster: Checked
Cluster IPv4 Address: 209.165.200.227
UDP Port: 9023
Enable IPsec Encryption: Checked
IPsec Shared Secret: C1$c0123
Private Interface: inside
Priority: 9
11. Launch the IPsec IKEv1 Remote Access VPN Wizard by choosing Wizards > VPN Wizards > Site-to-site VPN Wizard. An introduction screen is shown. Click Next.
12. Specify 209.165.201.1 as the Peer IP Address Choose outside from the VPN Access Interface drop-down menu. Click Next.
13. Enter the local and remote networks to protect using IPsec encryption. Click Next.
14. In the next window, configure the methods to authenticate with the peer device. You can either choose the simple configuration, and supply a pre-shared key. Or you can select Customized Configuration for more advanced options. In there, you can configure the IKE version, authentication methods, encryption algorithms, and perfect forward secrecy.
15. Under the Encryption Algorithms tab, select an IKE policy that uses AES-256 for encryption, SHA for authentication, and DH group 5 for key generation.
16. In this example, PFS will not be used. Please verify that PFS is not enabled under the Perfect Forward Secrecy tab and click Next.
17. Select Exempt ASA side host/network from address translation on the inside interface. Click Next to continue.
18. The VPN Wizard shows you a summary of all the features and configurations you have set. After you have verified the configuration, click Finish to push the configuration to the security appliance.
Configuration Steps Using the CLI
Example 20-32 shows the complete configuration of SecureMe’s Cisco ASA in Chicago to meet the design requirements.
Example 20-32 Configuration to Load-Balance Cisco IPsec Clients with Site-to-Site VPN
Chicago# show running-config
ASA Version 8.4(1)
! ip address on the outside interface
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 209.165.200.225 255.255.255.0
! ip address on the inside interface
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 192.168.10.1 255.255.255.0
! ip address on the mgmt interface
interface Management0/0
nameif mgmt
security-level 100
ip address 172.18.82.64 255.255.255.0
management-only
!
hostname Chicago
domain-name securemeinc.org
! Access-list entries to bypass NAT for the traffic going from Chicago to London
access-list inside_nat0_outbound extended permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0
! Access-list entries to bypass NAT for the traffic going from Chicago to
RA_clients
access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 192.168.32.0 255.255.224.0
! Encryption Access-list to encrypt the traffic from Chicago to London
access-list outside_1_cryptomap extended permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0
! ACL for Split-Tunneling
access-list SecureMeIPSec_splitTunnelAcl standard permit 192.168.0.0 255.255.0.0
! IP Pool used to assign IP address to the VPN client
ip local pool IPPool 192.168.32.1-192.168.64.254 mask 255.255.224.0
! NAT ACL is bound to NAT 0 statement to bypass address translation
nat (inside) 0 access-list inside_nat0_outbound
! Radius configuration to enable user authentication
aaa-server Radius protocol radius
aaa-server Radius (inside) host 192.168.10.100
key C1$c0123
! Configuration of ASDM for Appliance management
http server enable
http 0.0.0.0 0.0.0.0 mgmt
! Transform set to specify encryption and hashing algorithm
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
! Dynamic crypto-map for Remote-Access Clients and Static Crypto map for London ASA
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-
SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-
MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set peer 209.165.201.1
crypto map outside_map 1 set transform-set ESP-AES-256-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
! isakmp configuration- Enabled on the outside interface
isakmp enable outside
! isakmp configuration- Enabled on the inside interface for VPN LB
isakmp enable inside
! isakmp policy configuration
crypto ikev1 enable outside
crypto ikev1 enable inside
crypto ikev1 policy 10
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 86400
! NAT-T is enabled by default, so no additional configuration is required
! tunnel-group configuration for VPN client. The group-name is SecureMeIPSec
group-policy SecureMeIPSec internal
group-policy SecureMeIPSec attributes
wins-server value 192.168.10.20
dns-server value 192.168.10.10
domain-name securemeinc.org
vpn-tunnel-protocol IPSec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SecureMeIPSec_splitTunnelAcl
tunnel-group SecureMeIPSec type remote-access
tunnel-group SecureMeIPSec general-attributes
address-pool IPPool
authentication-server-group Radius
default-group-policy SecureMeIPSec
tunnel-group SecureMeIPSec ipsec-attributes
pre-shared-key *
! L2L tunnel-group configuration for London
tunnel-group 209.165.201.1 type ipsec-l2l
tunnel-group 209.165.201.1 ipsec-attributes
pre-shared-key *
! VPN Load-balancing. The virtual IP address is 209.165.200.227. Encryption is
enabled with using C1$c0123 as the key
vpn load-balancing
priority 9
cluster key C1$c0123
cluster ip address 209.165.200.227
cluster encryption
ms-chap-v2
Monitoring and Troubleshooting Cisco Remote-Access VPNs
Cisco ASA comes with a number of show commands to check the health and status of the IPsec tunnels. For troubleshooting purposes, Cisco ASA offers a rich set of debug commands to isolate the IPsec-related issues.
Monitoring Cisco Remote-Access IPsec VPNs
To monitor the IPsec sessions through ASDM, navigate to Monitoring > VPN > VPN Statistics > Sessions and check how many active IPsec tunnels are established on the security appliance. The security appliance shows you all the active VPN sessions, including the clientless and AnyConnect SSL VPN client connections. Should you prefer to get detailed information about a user’s connection, select that specific user session and then click the Details button. Using the CLI, you can find similar information by using the show vpn-sessiondb detail command, as shown in Example 20-33.
Example 20-33 show vpn-sessiondb detail Command Output
Chicago# show vpn-sessiondb detail
Active Session Summary
Sessions:
Active : Cumulative : Peak Concurrent : Inactive
SSL VPN : 0 : 6 : 1
Clientless only : 0 : 0 : 0
With client : 0 : 6 : 1 : 0
Email Proxy : 0 : 0 : 0
IPSec LAN-to-LAN : 0 : 0 : 0
IPSec Remote Access : 1 : 18 : 1
VPN Load Balancing : 0 : 0 : 0
Totals : 1 : 24
License Information:
IPSec : 750 Configured : 750 Active : 1 Load : 0%
SSL VPN : 2 Configured : 2 Active : 0 Load : 0%
Active : Cumulative : Peak Concurrent
IPSec : 1 : 24 : 1
SSL VPN : 0 : 6 : 1
AnyConnect Mobile : 0 : 0 : 0
Linksys Phone : 0 : 0 : 0
Totals : 1 : 30
Tunnels:
Active : Cumulative : Peak Concurrent
IKE : 1 : 18 : 1
IPSec : 1 : 18 : 1
Clientless : 0 : 6 : 1
SSL-Tunnel : 0 : 6 : 1
DTLS-Tunnel : 0 : 6 : 1
Totals : 2 : 54
<Some Output removed for Brevity>
To monitor specific information about the remote users, use the show vpn-sessiondb remote command. In Example 20-34, an IPsec session for user ciscouser is displayed. The public IP address of the client is 209.165.201.10, and the negotiated address is 192.168.50.1. The security appliance has received 18,279 bytes of traffic, while it has transmitted 19,876 bytes of data to the client. The security appliance has enforced policies from a user group called IPSecGroupPolicy. The user is connected for approximately 12 minutes and 20 seconds.
Example 20-34 show vpn-sessiondb remote Command Output
Chicago# show vpn-sessiondb remote
Session Type: IPSec
Username : ciscouser Index : 83
Assigned IP : 192.168.50.1 Public IP : 209.165.201.10
Protocol : IKE IPSec
License : IPSec
Encryption : 3DES AES128 Hashing : SHA1
Bytes Tx : 19876 Bytes Rx : 18279
Group Policy : IPSecGroupPolicy Tunnel Group : SecureMeIPSec
Login Time : 19:57:52 UTC Mon Jul 20 2009
Duration : 0h:12m:20s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
If you want to see if the IPsec tunnels are working and passing traffic, start by looking at the status of Phase 1 SA. Type show crypto ikev1 sa detail, as demonstrated in Example 20-35. If the ISAKMP negotiations are successful, you should see the state as AM_ACTIVE.
Example 20-35 show crypto ikev1 sa detail Command Output
Chicago# show crypto ikev1 sa detail
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 209.165.201.10
Type : user Role : responder
Rekey : no State : AM_ACTIVE
Encrypt : aes-256 Hash : SHA
Auth : preshared Lifetime : 86400
Lifetime Remaining: 86331
You can also check the status of the IPsec SA by using the show crypto ipsec sa command, as shown in Example 20-36. This command displays the negotiated proxy identities, along with the actual number of packets encrypted and decrypted by the IPsec engine.
Example 20-36 show crypto ipsec sa Command Output
Chicago# show crypto ipsec sa
interface: outside
Crypto map tag: outside_dyn_map, local addr: 209.165.200.225
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.50.60/255.255.255.255/0/0)
current_peer: 209.165.201.10
dynamic allocated peer ip: 192.168.50.60
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#send errors: 0, #recv errors: 0
You can check the status of a hardware encryption card with the show crypto accelerator statistics command. In Example 20-37, the important output from this command is shown, which displays the counter information, such as the number of packets going through the encryption card.
Example 20-37 show crypto accelerator statistics Command Output
Chicago# show crypto accelerator statistics
Crypto Accelerator Status
--------------------------
[Capability]
Supports hardware crypto: True
Supports modular hardware crypto: False
Max accelerators: 1
Max crypto throughput: 200 Mbps
Max crypto connections: 750
[Global Statistics]
Number of active accelerators: 1
Number of non-operational accelerators: 0
Input packets: 18
Input bytes: 5424
Output packets: 223
Output error packets: 0
Output bytes: 172405
[Accelerator 0]
Status: Active
! Output omitted for brevity.
Cisco ASA can display global IKE and IPsec counter information, which is helpful in isolating VPN connection problems. Information such as the number of total requests, the number of total SAs created, and the number of failed requests is useful to determine the failure rate for IKE and IPsec SAs in the security appliance. As shown in Example 20-38, view this information by using the show crypto protocol statistics ikev1 and show crypto protocol statistics ipsec command.
Example 20-38 Output of show crypto protocol statistics ikev1/ipsec Commands
Chicago# show crypto protocol statistics ikev1
[IKEv1 statistics]
Encrypt packet requests: 23
Encapsulate packet requests: 23
Decrypt packet requests: 23
Decapsulate packet requests: 23
HMAC calculation requests: 63
SA creation requests: 3
SA rekey requests: 0
SA deletion requests: 1
Next phase key allocation requests: 4
Random number generation requests: 0
Failed requests: 1
Chicago# show crypto protocol statistics ipsec
[IPSec statistics]
Encrypt packet requests: 0
Encapsulate packet requests: 0
Decrypt packet requests: 0
Decapsulate packet requests: 0
HMAC calculation requests: 0
SA creation requests: 4
SA rekey requests: 0
SA deletion requests: 2
Next phase key allocation requests: 0
Random number generation requests: 0
Failed requests: 1
Troubleshooting Cisco IPsec VPN Clients
If the IPsec tunnel is not working for some reason, make sure that you have the proper debug command turned on. For IKEv1 connections, the following are the two most important to look at:
debug crypto ikev1 [debug level 1–255]
debug crypto ipsec [debug level 1–255]
By default, the debug level is set to 1. You can increase the severity level up to 255 to get detailed logs. However, in most cases, setting this to 127 provides enough information to determine the root cause of an issue.
For IKEv2 connections, use the debug crypto ikev2 [debug level 1–255] command in combination with debug crypto ipsec.
You can also use the debug crypto ike-common [debug level 1–255] command to troubleshoot both IKEv1 and IKEv2 connections.
Refer to Figure 20-27 and look at the tunnel negotiation between the Cisco ASA and the VPN client located at 209.165.201.10. To enforce learning, the following debugs have been enabled:
debug crypto ikev1 127
debug crypto ipsec 127
As mentioned in Chapter 1, the tunnel negotiation opens with an exchange of IKE proposals. The security appliance shows the tunnel group, SecureMeIPSec in this case, to which the VPN client is trying to connect. If the proposal is acceptable, the Cisco ASA displays a message indicating that the IKEv1 SA proposal is acceptable, as shown in Example 20-39.
Example 20-39 debug Output to Show ISAKMP Proposal Is Acceptable
Chicago# debug crypto ikev1 127
Chicago# debug crypto ipsec 127
[IKEv1 DEBUG]: Group = , IP = 209.165.201.10, processing SA payload
[IKEv1 DEBUG]: Group = , IP = 209.165.201.10, processing ke payload
[IKEv1 DEBUG]: Group = , IP = 209.165.201.10,processing VID payload,
<snip>
[IKEv1]: IP = 209.165.201.10, Connection landed on tunnel_group SecureMeIPSec
[IKEv1 DEBUG]: Group = SecureMeIPSec, IP = 209.165.201.10, processing IKE SA
[IKEv1 DEBUG]: Group = SecureMeIPSec, IP = 209.165.201.10, IKE SA Proposal # 1,
Transform # 10
acceptable Matches global IKE entry # 1,
If the proposal is acceptable, the VPN devices try to discover whether they are NAT-T capable and if there is an address-translation device between them. If NAT-T is not negotiated or a NAT/PAT device is not detected, they display the message highlighted in Example 20-40.
Example 20-40 debug Output to Show NAT-T Discovery Process
[IKEv1 DEBUG]: Group = SecureMeIPSec, IP = 209.165.201.10, processing NAT-
Discovery payload
[IKEv1 DEBUG]: Group = SecureMeIPSec, IP = 209.165.201.10, computing NAT
Discovery hash
[IKEv1 DEBUG]: Group = SecureMeIPSec, IP = 209.165.201.10, processing NAT-
Discovery payload
[IKEv1]: Group = SecureMeIPSec, IP = 209.165.201.10, Automatic NAT Detection
Status: Remote end is NOT behind a NAT device. This end is NOT behind a NAT device
After NAT-T negotiations, Cisco ASA prompts the user to specify user credentials. Upon successful user authentication, the security appliance displays a message indicating that the user (ciscouser in this case) is authenticated, as shown in Example 20-41.
Example 20-41 debug Output to Show User Is Authenticated
[IKEv1]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10, User
(ciscouser) authenticated.,
[IKEv1 DEBUG]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10,
constructing blank hash
[IKEv1 DEBUG]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10,
constructing qm hash
The client requests mode-config attributes by sending a list of client-supported attributes, as shown in Example 20-43. Cisco ASA replies with all its supported attributes and the appropriate information.
Example 20-42 debug Output to Show Mode-Config Requests
[IKEv1 DEBUG]Processing cfg Request attributes,
[IKEv1 DEBUG]MODE_CFG: Received request for IPV4 address!,
[IKEv1 DEBUG]MODE_CFG: Received request for IPV4 net mask!,
[IKEv1 DEBUG]MODE_CFG: Received request for DNS server address!,
[IKEv1 DEBUG]MODE_CFG: Received request for WINS server address!,
After pushing down the attributes, Cisco ASA displays the PHASE 1 COMPLETED message, indicating that the IKEv1 SA is successfully negotiated, as demonstrated in Example 20-43.
Example 20-43 debug Output to Show Phase 1 Negotiations Are Completed
[IKEv1]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 PHASE 1
COMPLETED,
<snip>
[IKEv1 DEBUG]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10
Processing ID,
[IKEv1 DECODE]ID_IPV4_ADDR ID received 192.168.50.60,
[IKEv1]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 Received
remote Proxy Host data in ID Payload: Address 192.168.50.60, Protocol 0, Port 0,
After completing Phase 1 negotiations, the VPN peers try to negotiate Phase 2 SAs by exchanging the proxy identities and the IPsec Phase 2 proposal. If they are acceptable, Cisco ASA displays a message indicating that the IPsec SA proposal is acceptable, as shown in Example 20-44.
Example 20-44 debug Output to Show Proxy Identities and Phase 2 Proposal Are Accepted
[IKEv1 DEBUG]: Group = SecureMeIPSec, Username = ciscouser, IP =
209.165.201.10, IPSec SA Proposal # 12, Transform # 1 acceptable Matches
global IPSec SA entry # 10,
[IKEv1 DEBUG]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 ,
Transmitting Proxy Id:
Remote host: 192.168.50.60 Protocol 0 Port 0
Local subnet: 0.0.0.0 mask 0.0.0.0 Protocol 0 Port 0
After accepting the transform set values, both VPN devices agree on the inbound and outbound IPsec SAs, as shown in Example 20-45. After the IPsec SAs have been created, both VPN devices should be able to pass traffic bidirectionally across the tunnel.
Example 20-45 debug Output to Show IPsec SAs Are Activated
[IKEv1 DEBUG]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 ,
loading all IPSEC SAs
[IKEv1]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 Security
negotiation complete for User (ciscouser) Responder, Inbound SPI = 0x00c6bc19,
Outbound SPI = 0xa472f8c1,
[IKEv1]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 Adding
static route for client address: 192.168.50.60 ,
[IKEv1]: Group = SecureMeIPSec, Username = ciscouser, IP = 209.165.201.10 , PHASE
2 COMPLETED (msgid=8732f056)
Summary
Using the remote-access methods available with Cisco ASA, security administrators can deploy Cisco ASA into almost any network topology. The Cisco IPsec VPN solution is available for remote users who want to access their enterprise network over a secure VPN connection as if they were directly connected to it. The L2TP over IPsec solution is available for those customers who do not wish to install any IPsec client software on the end machines. To reinforce learning, a case study (deployment scenario) was discussed, along with the specific configurations. This chapter covered extensive show and debug commands to assist in troubleshooting complicated remote-access IPsec (IKEv1 and IKEv2) VPN deployments.