This document describes how Network Admission Control (NAC) works with IP Security (IPsec) Dynamic Virtual Tunnel Interface (DVTI).
TOPOLOGY
The network topology is shown in Figure 1. The Windows client is running Cisco® VPN Client 4.0, while the Cisco 7200 hub router is running Cisco IOS® Software Release 12.4.4T using DVTI to terminate the IPsec connections. NAC is applied on the virtual template, and Cisco Secure Access Control Server (ACS) 3.3 is used as the authentication, authorization, and accounting (AAA) server for IPsec and NAC.
Figure 1. Network Topology
INITIAL SETUP
The PC running Cisco VPN Client 4.0 connects to the DVTI hub, and Internet Key Exchange (IKE) Authorization, Xauth and Mode-Config are completed through exchanges with the AAA server. Once the IPsec security associations (SA) are up, a virtual access interface is cloned from the DVTI virtual template. We have applied access control list (ACL) and NAC statements on the virtual template, which are inherited by the virtual access interface. The hub kicks off eopoudp authentication with the client, and exchanges eop over radius messages with the AAA server. The resulting PEAP session between client and AAA server is used to gather the Clients' posture. The client is running Cisco Trust Agent and sends its posture. The AAA server uses this posture for health assessment of the Client and sends appropriate access accept/reject messages to the hub.
In this sample test scenario, the posture validation is done based on the client OS string. Based on the posture, the RADIUS server sends an ACL (first sends ACL name, then hub gets the actual ACL) to the hub router. The hub router applies the ACL on the virtual access interface, allowing the client to send traffic to the corporate network, if it is healthy
In this scenario, the RADIUS server is Cisco Secure ACS 3.3, and is used for IPsec (IKE authorization, Xauth, and Mode-Cfg) and also for NAC. The minimum IPsec AAA attributes like IP Address, Preshared Keys etc are used. For more information on Easy VPN server and IPSec Radius attributes, please refer to: http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455b6a.html
The NAC setup is rudimentary in this test example. The client is not running any antivirus software. Posture validation is based on the client OS string-if it contains "Windows" it is defined as healthy and an `ip any any' ACL is pushed down to be applied to the virtual access interface. For more NAC deployment scenarios, please refer to the NAC documentation at: http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html
DVTI AND NAC CONFIGURATION
The DVTI and NAC configuration is shown below:
crypto isakmp profile nac
match identity group nac
client authentication list VPN-AAA
isakmp authorization list VPN-AAA
client configuration address respond
virtual-template 1
!
interface Virtual-Template1 type tunnel
ip unnumbered Loopback10
ip access-group 101 in
ip admission vti-nac
load-interval 30
tunnel mode ipsec ipv4
tunnel protection ipsec profile nac
!
access-list 101 permit udp any any eq 21862
CONFIGURING CISCO SECURE ACS 3.3
Cisco Secure ACS Version
Figure 2 shows the ACS version information.
Figure 2. ACS Version
IPsec Group Attributes
EzVPN Groupname = nac
Figure 3 shows the IPSec Group attributes defined on ACS.
Figure 3. IPSec Group Attributes
IPsec Xauth Username
Username = sunil
Figure 4 shows the username and password defined for the vpn client.
Figure 4. IPSec Xauth Username
Defining NAC External Database for Posture Validation
We define a Validation Policy that says a posture with an OS string containing "Windows" is declared as "healthy". Figure 5 shows the ACS External database definitions.