Chapter 7: Configuring NAC on Cisco ASA and PIX Security Appliances

Cisco Press

1 2 3 4 Page 3
Page 3 of 4
  • Status query timer—This timer ensures that the security appliance periodically checks the posture state of the VPN client, in case it has changed from the last time. The default status query timer is 300 seconds. In Example 7-24, the status query timer is changed to 600 seconds, which is recommended if the number of concurrent sessions is high. If this value is set too low, the security appliance will use a lot of system resources in sending status queries to the remote-access VPN clients.

  • Revalidation timer—This timer initiates a complete posture-validation process on the remote-access VPN client. The default timer is set to 36,000 seconds (10 hours). You can lower this timer to 18,000 seconds (5 hours) if your organization requires you to revalidate the VPN clients more often. This is helpful when new antivirus patches are continuously updated on the servers and you want the VPN clients to update them as soon as they go through a new posture-validation process.

Example 7-24 Status Query and Revalidation Timers

CiscoASA(config)# group-policy SecureMeGrp attributesCiscoASA(config-group-policy)# nac-sq-period 600CiscoASA(config-group-policy)# nac-reval-period 18000

When all the parameters are set up, the last step is to enable NAC on the user group-policy. This is shown in Example 7-25 for a user group-policy called SecureMeGrp.

Example 7-25   Enable NAC on a User Group-Policy

CiscoASA(config)# group-policy SecureMeGrp attributesCiscoASA(config-group-policy)# nac enable

Note - You can revalidate all the active NAC sessions by using the eou revalidate all command. To revalidate a specific host, you can use the eou revalidate ip command followed by the IP address of the host to be revalidated.

To configure these parameters in ASDM, navigate to Configuration > VPN > General > Group Policy and click the NAC tab, as shown in Figure 7-5.

Figure 7-5

NAC Configuration of User Group-Policy Parameters in ASDM

Step 4: Configuring the NAC Exception List

A number of operating systems support the Cisco VPN client, including Solaris, Mac OS X, Windows, and Linux. However, Cisco CTA is currently supported only on Windows, Linux, and Mac OS X. During the tunnel-negotiation process, the VPN client reports its version information, such as Windows 2000, Windows XP, or Mac OS X, to name a few. You can specify an exception list based on the reported version of the VPN client. This list excludes the configured operating systems to go through the posture-validation process. After the IPSec tunnel is negotiated, the VPN clients that are in the exception list can be subject to an ACL to restrict their activities on the network. For example, if you want only Solaris-based VPN clients to access an internal mainframe system, the exception list ACL should allow only traffic destined for the mainframe server in the ACL and should deny all other traffic.

In Example 7-26, an ACL called Solaris-ACL is being set up. This ACL will allow all bidirectional traffic to pass through if

  • It is sourced from the mainframe server with an IP address of

  • It is destined to the Solaris VPN clients. Thus, the VPN client pool of with a subnet mask of is specified as the destination address.

Example 7-26   ACL for NAC Exception List

CiscoASA(config)# access-list Solaris-ACL extended permit ip host CiscoASA(config)# access-list Solaris-ACL extended permit ip host

When both the inbound and outbound entries are configured, the next step is to apply this ACL either globally or to a specific group. This is achieved by using the vpn-nac-exempt command followed by the operating system name and the ACL name to filter traffic. In Example 7-27, Solaris-ACL is mapped to the SecureMeGrp user group-policy for the Solaris operating system.

Example 7-27   NAC Exception List

CiscoASA(config-group-policy)# group-policy SecureMeGrp attributesCiscoASA(config-group-policy)# vpn-nac-exempt os Solaris filter Solaris-ACL

If instead you want to define the NAC exception policies globally, specify the vpn-nac-exempt command under the default group policy, DfltGrpPolicy.

To define or manage an exception list in ASDM, navigate to Configuration > VPN > General > Group Policy and select the NAC tab, as shown in Figure 7-6. Under Posture Validation Exception List, click Add and specify the operating system and the NAC exception ACL.

Figure 7-6

NAC Exception List in ASDM

Testing, Monitoring, and Troubleshooting NAC on Cisco Security Appliances

This section discusses the different test scenarios that are useful in implementing the NAC solution on the security appliances. Each test scenario helps in gathering the statistical information about a connection. These scenarios also discuss the related debugs that are helpful in troubleshooting any IPSec or NAC deployments. The following test scenarios are discussed:

  1. Remote-access IPSec tunnel without NAC

  2. Remote-access IPSec tunnel from an agentless client

  3. Remote-access IPSec tunnel from a CTA client

Remote-Access IPSec Tunnel Without NAC

If you are setting up a new group on the security appliance that will validate the posture on the VPN clients, follow the first two configuration stages, discussed earlier in the section "Configuration Steps of NAC on Cisco Security Appliances." The next step is to make a VPN tunnel from a test VPN client machine to ensure that you do not run into any misconfigurations. If the IPSec tunnel is not working for some reason, make sure that you have the proper debug turned on. The following are the two most important debugs to look at:

debug crypto isakmp [debug-level]debug crypto ipsec [debug-level]

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 level to 127 provides enough information to determine the root cause of an issue.

In Example 7-28, the debug crypto isakmp 127 and debug crypto ipsec 127 commands have been enabled.

Example 7-28   Enabling Crypto Debugs

CiscoASA# debug crypto isakmp 127CiscoASA# debug crypto ipsec 127

The tunnel negotiations begin by exchanging the ISAKMP proposals. If ISAKMP debugs are enabled, the security appliance shows the tunnel group—NAC-Group, in this case—that the VPN client is trying to connect to. If the proposal is acceptable, the debugs display a message indicating that the IKE SA proposal is acceptable, as shown in Example 7-29. Also displayed are the chosen IKE SA proposal number and the public IP address of the VPN client, which is

Example 7-29   debug Output to Show ISAKMP Proposal Is Acceptable

Mar 22 19:31:50 [IKEv1]: IP =, Connection landed on tunnel_group NAC-GroupMar 22 19:31:50 [IKEv1 DEBUG]: Group = NAC-Group, IP =, processing IKE SA payloadMar 22 19:31:50 [IKEv1 DEBUG]: Group = NAC-Group, IP =, 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 whether an address-translation device lies between them. If NAT-Traversal (NAT-T) is not negotiated or a NAT/PAT device is not detected, the ISAKMP debugs display the "Remote end is NOT behind a NAT device. This end is NOT behind a NAT device" message, as shown in Example 7-30.

Example 7-30 debug Output to Show NAT-T Discovery Process

[IKEv1 DEBUG]: Group = NAC-Group, IP =, processing NAT-Discovery payload[IKEv1 DEBUG]: Group = NAC-Group, IP =, computing NAT Discovery hash[IKEv1 DEBUG]: Group = NAC-Group, IP =, processing NAT-Discovery payload[IKEv1]: Group = NAC-Group, IP =, Automatic NAT Detection Status:

Remote end is NOT behind a NAT device. This end is NOT behind a NAT device

After NAT-T negotiations, the Cisco security appliance prompts the user to specify user credentials. Upon successful user authentication, the ISAKMP debugs display a message indicating that the user (ciscouser, in this example) is authenticated, as shown in Example 7-31.

Example 7-31 debug Output to Show User Is Authenticated

[IKEv1]: Group = NAC-Group, Username = ciscouser, IP =, User (ciscouser) authenticated.,[IKEv1 DEBUG]: Group = NAC-Group, Username = ciscouser, IP =, constructing blank hash[IKEv1 DEBUG]: Group = NAC-Group, Username = ciscouser, IP =, constructing qm hash

The client requests mode-config attributes by sending a list of client-supported attributes, as shown in Example 7-32. The security appliance replies with all its supported attributes and the appropriate information.

Example 7-32   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, the security appliance displays a message indicating that the ISAKMP SA was successfully negotiated, as demonstrated in Example 7-33.

Example 7-33   debug Output to Show Phase 1 Negotiations Are Completed

[IKEv1]: Group = NAC-Group, Username = ciscouser, IP = PHASE 1 COMPLETED

After completing Phase 1 negotiations, the VPN client and the security appliance try to negotiate Phase 2 SA by exchanging the proxy identities and the IPSec Phase 2 proposal. The remote host is the IP address that the security appliance assigned to the VPN client. If the proxy identities are acceptable, the ISAKMP debugs display a message indicating that the IPSec SA proposal is acceptable, as shown in Example 7-34.

Example 7-34  debug Output to Show Proxy Identities and Phase 2 Proposal Are Accepted

[IKEv1 DEBUG]: Group = NAC-Group, Username = ciscouser, IP =,

IPSec SA Proposal # 12, Transform # 1 acceptable Matches global IPSec SA entry # 10, [IKEv1 DEBUG]: Group = NAC-Group, Username = ciscouser, IP =, Transmitting Proxy Id: Remote host: Protocol 0 Port 0 Local subnet: mask 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 7-35. After the IPSec SAs have been created, both VPN devices should be capable of passing traffic bidirectionally across the tunnel.

Example 7-35 debug Output to Show IPSec SAs Are Activated

IKEv1 DEBUG]: Group = NAC-Group, Username = ciscouser, IP =, loading all IPSEC SAs[IKEv1]: Group = NAC-Group, Username = ciscouser, IP =

Security negotiation complete for User (ciscouser) Responder,

Inbound SPI = 0x00c6bc19, Outbound SPI = 0xa472f8c1,[IKEv1]: Group = NAC-Group, Username = ciscouser, IP =

Adding static route for client address: ,[IKEv1]: Group = NAC-Group, Username = ciscouser, IP =, PHASE 2 COMPLETED (msgid=8732f056)

Remote-Access IPSec Tunnel from an Agentless Client

After successfully testing the VPN tunnel, the next step is to configure NAC on the security appliance and then connect from the same test VPN client without installing the CTA agent. This emulates an agentless VPN client scenario. The security appliance enables you to set up NAC logging and/or NAC debugging. NAC logging enables you to capture EAPoUDP, EAP, and NAC events such as EAP status query, posture-validation initializations and revalidations, exception list matches, ACS transactions, clientless authentications, and default ACL applications.

NAC debugging is useful if you want to gather detailed NAC-specific events such as the hexadecimal dump of EAP header and packet contents, EAPoUDP header and packet contents, EAPoUDP session-state changes, and timer events.

Example 7-36 illustrates how to enable NAC logging on a security appliance. An event list, called NAC, is defined to log the nac, eapoudp, and eap classes. The logging level is set as debugging. The NAC logs are sent to the internal buffer of the security appliance.

Example 7-36   Enabling NAC Logging on a Security Appliance

CiscoASA(config)# logging enableCiscoASA(config)# logging list NAC level debugging class nacCiscoASA(config)# logging list NAC level debugging class eapoudpCiscoASA(config)# logging list NAC level debugging class eapCiscoASA(config)# logging buffered NAC

Note - It is a best practice to send the log messages to an external syslog server for forensics and later analysis.

When NAC logging is turned on, establish an IPSec session from the VPN client that is clientless. As shown in Example 7-37, as soon as IKE Phase 2 negotiations are completed, the security appliance initiates the NAC process for It applies a default ACL called Default-Filter on the VPN user session until the correct posture is determined.

This test scenario assumes that you are not running the CTA application on the VPN client. Consequently, the security appliance fails to receive a response from the host. The security appliance times out the request and sends an authentication request to the RADIUS server for the clientless user. If the RADIUS server authenticates this user, it sends a downloadable ACL, ACSACL#-IP-Clientless_ACL-4470a5d3, to the security appliance. Based on the access-control entries, the user gets limited access on the network.

Example 7-37   NAC Logs for Clientless Agents

CiscoASA(config)# show logging<some output removed>%ASA-6-335001: NAC session initialized - NAC Default ACL applied, ACL:NAC-default - EAPoUDP association initiated - EAPoUDP failed to get a response from host - Authentication request for NAC Clientless host - NAC Applying ACL:#ACSACL#-IP-Clientless_ACL-4470a5d3 -

Alternatively, you can enable the appropriate debugs to troubleshoot issues related to NAC. Example 7-38 shows the recommended debugs on a security appliance for NAC troubleshooting.

Example 7-38   Enabling NAC Logging on a Security Appliance

CiscoASA# debug nac auth CiscoASA# debug nac errors CiscoASA# debug nac events CiscoASA# debug eou eap CiscoASA# debug eou errors CiscoASA# debug eou events
1 2 3 4 Page 3
Page 3 of 4
SD-WAN buyers guide: Key questions to ask vendors (and yourself)