This chapter covers the following topics:
Architectural overview of NAC on Cisco security appliances
Configuration steps of NAC on Cisco security appliances
Testing, monitoring, and troubleshooting NAC on Cisco security appliances
Similar to the Cisco VPN 3000 series concentrators discussed in Chapter 6, "Configuring NAC on Cisco VPN 3000 Series Concentrators," the Cisco security appliances provide a complete solution for the site-to-site as well as remote-access VPN tunnels. Cisco security appliances consist of Cisco Adaptive Security Appliances (ASA) and the Cisco PIX Security Appliance. The NAC functionality on the Cisco security appliances enhances security of the IPSec tunnels. This chapter focuses on NAC implementation of the security appliances by providing a brief architectural overview of the solution and step-by-step configuration examples.
The NAC implementation on the security appliances is identical to the implementation on Cisco VPN 3000 series concentrators. Refer to Chapter 6 for detailed information about the NAC architectural design on the security appliance. This section covers some of the significant changes from the VPN 3000 concentrator NAC implementation.
The security appliances support stateful failover for the traffic passing through the device. This includes Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), and IPSec, to name a few protocols. However, the current implementation of NAC supports only stateless failover. This means that the NAC commands are replicated from the active appliance to the standby appliance; however, none of the active NAC connections will fail over to the standby appliance if the standby appliance becomes active. In a failover, all NAC postures that are validated by active appliance are disconnected, and the new NAC sessions are created on the newly active security appliance.
If you are using the stateful failover, the IPSec connections are switched over seamlessly after a failover. However, the remote-access VPN clients go through the posture-validation process. During this time, the security appliance applies a NAC default Access Control List (ACL), if defined, on the remote-access VPN clients.
Unlike a VPN 3000 concentrator, a security appliance supports multiple NAC exception lists that are configured under user group-policy. Each NAC exception list can be set up with the reported operating system from the VPN client and an ACL. This list excludes the configured operating systems from going through the posture-validation process. The Cisco VPN client also provides the name of the operating system the host is using, and this string is compared with entries in the NAC Exception List.
Note - The security appliances support NAC for Cisco software clients and Microsoft L2TP over IPSec clients. Plans are underway to support NAC for the SSL-based VPN tunnels in future releases.
Figure 7-1 illustrates a network topology in which a Cisco ASA 5500 appliance is terminating VPN client sessions from Cisco VPN clients. The public IP address of the appliance is 209.165.202.130; the private IP address is 10.10.0.2. The security appliance leverages a Cisco Secure ACS server for user authentication. The Cisco Secure ACS also participates in the client's posture validation and applies appropriate policies. The appliance is set up with a pool of addresses from the 10.10.200.0/24 subnet. During the mode-config phase of the VPN tunnel negotiations, the Cisco ASA 5500 appliance assigns an IP address from this pool to the VPN client.
Note - For more information about the mode-config phase, refer to Chapter 6.
Figure 7-1
ASA 5500 Topology to Terminate IPSec Connections
Note - You need to run Version 7.2 or later on the security appliances to enable NAC.
The implementation of NAC on a security appliance can be divided into three stages:
VPN configuration on the security appliances
VPN configuration on the Cisco VPN client
NAC configuration on the security appliances
Note - This chapter focuses on the configuration of the security appliances and how they interact with the Cisco VPN clients.
Note - The operating system used by Cisco ASA and PIX is the same. Consequently, the configuration of NAC on the two security appliances is identical.
This section discusses the configuration of remote-access IPSec tunnels on the security appliances that can be used to accept connections from the Cisco VPN clients. The following 12 steps set up a basic remote-access IPSec tunnel.
Step 1 Enable ISAKMP.
Step 2 Create the ISAKMP policy.
Step 3 Configure remote-access attributes.
Step 4 Define the tunnel type.
Step 5 Configure preshared keys.
Step 6 Configure user authentication.
Step 7 Assign an IP address.
Step 8 Define the IPSec policy.
Step 9 Set up a dynamic crypto map.
Step 10 Configure the crypto map.
Step 11 Apply the crypto map on the interface.
Step 12 Configure traffic filtering.
Note - This chapter assumes that you have basic familiarity with the security appliance command-line interface (CLI) and that you have administrative rights to set up different functions and features. For more information about the security appliances, visit http://www.cisco.com/go/asa and http://www.cisco.com/go/pix.
By default, ISAKMP is disabled on all the interfaces. If the remote VPN device sends a tunnel-initialization message, the security appliance drops it until ISAKMP is enabled on the interface terminating the IPSec tunnels. Typically, it is enabled on the Internet-facing or the outside interface, as demonstrated in Example 7-1.
CiscoASA# configure terminalCiscoASA(config)# isakmp enable outside
The isakmp policy commands define ISAKMP Phase 1 attributes that are exchanged between the VPN peers. Example 7-2 shows an ISAKMP policy to negotiate preshared keys for authentication, Advanced Encryption Standard-256 (AES-256) for encryption, Secure Hash Algorithm (SHA) for hashing, group 2 for Diffie-Hellman (DH), and 86400 seconds for lifetime.
CiscoASA# configure terminalCiscoASA(config)# isakmp policy 10 authentication pre-shareCiscoASA(config)# isakmp policy 10 encryption aes-256CiscoASA(config)# isakmp policy 10 hash shaCiscoASA(config)# isakmp policy 10 group 2CiscoASA(config)# isakmp policy 10 lifetime 86400
The security appliance allows the configuration of the mode-config parameters in three different places:
Under default group-policy
Under user group-policy
ω Under user policy
The security appliance implements an inheritance model in which a user inherits the mode-config attributes from the user policy, which inherits its attributes from the user group-policy, which, in turn, inherits its attributes from the default group-policy, as illustrated in Figure 7-2. A user, ciscouser, receives traffic filtering ACL and an assigned IP address from the user policy, the domain name from the user group-policy, and IP Compression, along with the number of simultaneous logins from the default group-policy.
Figure 7-2
Mode-Config Inheritance Model
You can use the group-policy attributes command to specify the default and user group-policy mode-config attributes. Example 7-3 shows how to configure the default group attributes on the security appliances by setting DfltGrpPolicy as the group name in the group-policy. The administrator has limited the simultaneous logins to three and has enabled IP Compression for data payload.
CiscoASA(config)# group-policy DfltGrpPolicy attributesCiscoASA(config-group-policy)# vpn-simultaneous-logins 3CiscoASA(config-group-policy)# ip-comp enable
Note - DfltGrpPolicy is a special group name, used solely for the default group-policy.
The user group-policy is set up similarly to a default group-policy, by configuring the attributes under the group-policy submenu. In Example 7-4, a group called SecureMeGrp is being set up to send the domain-name securemeinc.com attribute during mode-config exchange. One major difference between the default group-policy and the user group-policy is that you can define the latter as an internal or external group. In an internal group, all the policy attributes are defined locally on the security appliance. In an external group, all the attributes are stored on an external server such as RADIUS. In Example 7-4, SecureMeGrp is set up as an internal group, which is why the domain-name attribute is defined locally.