Guest

Cisco NAC Appliance (Clean Access)

Cisco NAC Layer 3 OOB Using VRF-Lite for Traffic Isolation

Cisco - Cisco NAC Layer 3 OOB Using VRF-Lite for Traffic Isolation

Document ID: 112169

Updated: Sep 23, 2010

   Print

Contents

Introduction

This guide describes an implementation of Cisco Network Admission Control (NAC) in a Layer 3 Out-of-Band (OOB) deployment that is based on virtual route forwarding (VRF)-Lite.

Solution Overview

This section gives a brief introduction to Layer 3 OOB using VRF-Lite methods in order to implement a NAC architecture.

Executive Summary

Cisco NAC enforces the network security policies of an organization on all devices that seek network access. Cisco NAC allows only compliant and trusted endpoint devices, such as PCs, servers, and PDAs, onto the network. Cisco NAC restricts the access of noncompliant devices, which limits the potential damage from emerging security threats and risks. Cisco NAC gives organizations a powerful, roles-based method in order to prevent unauthorized access and improve network resiliency.

The Cisco NAC solution provides these business benefits:

  • Security policy compliance—Ensures that endpoints conform to security policy; protects infrastructure and employee productivity; secures managed and unmanaged assets; supports internal environments and guest access; tailors policies to your risk level

  • Protects existing investments—Is compatible with third-party management applications; flexible deployment options minimize need for infrastructure upgrades

  • Mitigates risks from viruses, worms, and unauthorized access—Controls and reduces large-scale infrastructure disruptions; reduces operating expenses by making moves, adds, and changes dynamic and automated, thus enabling higher IT efficiency; integrates with other Cisco Self-Defending Network components in order to deliver comprehensive security protection

Solution Description

Cisco NAC is used in the network infrastructure in order to enforce security policy compliance on all devices that seek access to network resources. Cisco NAC allows network administrators to authenticate and authorize users and to evaluate and remediate their associated machines before they are granted network access. You can use several configuration methods to accomplish this task. This document focuses specifically on the VRF-based implementation of Cisco NAC in a Layer 3 OOB deployment where the Cisco NAC server (Cisco Clean Access Server) is configured in real IP gateway (routed) mode.

Layer 3 OOB is one of the most popular deployment methodologies for NAC. This shift in popularity is based on several dynamics that include better utilization of hardware resources. By deploying Cisco NAC in a Layer 3 OOB methodology, a single Cisco NAC Appliance can scale to accommodate more users. It also allows Cisco NAC Appliances to be centrally located rather than distributed across the campus or organization. Therefore, Layer 3 OOB deployments are more cost-effective both from a capital and operational expense standpoint.

This guide describes an implementation of Cisco NAC in a Layer 3 OOB deployment that is based on VRF-Lite.

Simple Definition of VRF

One way to look at VRF device virtualization is to equate it to the advent of VLANs. VLANs created virtual switches out of a single physical switch. VRFs extend that virtualization past the Layer 2 boundary, and allow the creation of virtual routers. Virtual routers provide for fully-virtualized networks from end-to-end.

Another way to look at VRF design is that each VRF acts just like a VPN or tunnel. The traffic that is placed into a VRF cannot communicate outside of the VRF (tunnel) until the traffic passes through the device that terminates the tunnel (the destination VPN router).

Note: These definitions are meant to help introduce a new concept. These definitions are not exact representations or official definitions of VRF.

Figure 1 shows an illustration of device virtualization with VRFs. Each colored layer in the diagram represents a different virtual router, or VRF. VRF methodology provides control plane and data plane path isolation, along with the ability to have multiple isolated data planes. In other words, it provides the possibility for a separate virtual router or network for each traffic type that is expected in an environment that uses Cisco NAC. Typical traffic types are:

  • Unauthenticated user traffic

  • Authenticated user traffic

  • Contractor traffic

  • Guest traffic

Figure 1 – Device Virtualization

nac-layer3-01.gif

Solution Architecture

The Cisco NAC Servers were initially designed to be in-band appliances. The use of Cisco NAC Appliances on a Cisco network infrastructure allows you to take an appliance that was designed to be in-band to all network traffic, and deploy it with an OOB methodology.

The solution architecture (see Figure 2) identifies the key solution components and integration point of the Cisco NAC Server.

Note: In this document, the terms “edge switch” and “access switch” are used interchangeably.

Figure 2 – Solution Architecture

nac-layer3-02.gif

The next sections describe the access, distribution, core, and data center layers that make up a typical campus architecture.

Access Layer

The Layer 3 OOB Cisco NAC solution is applicable to a Routed Access campus design. In routed access mode, Layer 3 switched virtual interfaces (SVIs) are configured on the access switch. As Figure 3 shows, the Layer 3 access VLAN (for example, VLAN 100) is configured on the edge switch, Layer 3 routing is supported from the switch to the upstream distribution switch or router, and the Cisco NAC Manager manages the ports on the access switch.

Figure 3 – Access Switches with Layer 3 to the Edge

nac-layer3-03.gif

Distribution Layer

The distribution layer is responsible for Layer 3 routing and aggregation of the access layer switches. While you can place the Cisco NAC Servers in this layer in a Layer 2 OOB design, you do not locate them here in a Layer 3 OOB design. Instead, place the Cisco NAC Servers centrally at the Data Center Service Block, as the solution architecture shows (Figure 2).

Core Layer

The core layer uses Cisco IOS-based routers. The core layer is reserved for high-speed routing, without any services. Place services on a service switch in the data center.

Data Center Services Layer

The data center services layer uses Cisco IOS-based routers and switches in the campus network. The Cisco NAC Manager and Cisco NAC Server are centrally located at the Data Center Service Block in this Layer 3 OOB design.

Solution Components

Cisco NAC Manager

The Cisco NAC Manager is the administration server and database that centralizes configuration and monitoring of all Cisco NAC Servers, users, and policies in a Cisco NAC Appliance deployment. For an OOB Cisco NAC deployment, the Cisco NAC Manager provides the OOB management in order to add and control switches in the domain of the Cisco NAC Manager and configure switch ports.

Cisco NAC Server

The Cisco NAC Server is the enforcement point between the untrusted (managed) network and the trusted (internal) network. The Server enforces polices defined in the Cisco NAC Manager, and endpoints communicate with the Server during authentication. In this design, the Server logically separates the untrusted and trusted networks, and it serves as the centralized enforcement point for all access lists (ACLs) and bandwidth restrictions for devices in the untrusted network. See the OOB Mode section for more information.

Cisco NAC Agent

The Cisco NAC Agent is an optional component of the Cisco NAC solution. When the Agent is enabled for your Cisco NAC deployment, it ensures that computers that access your network meet the system posture requirements you specify. The Agent is a read-only, easy-to-use, small-footprint program that resides on user machines. When a user attempts to access the network, the Agent checks the client system for the software you require, and helps you acquire any missing updates or software. See Step 6: Update Policies from Cisco.com on the Cisco NAC Manager for more information.

Design Considerations

When you consider a Layer 3 OOB NAC deployment, review several design considerations. These considerations are listed in these sub-sections, along with a brief discussion of their importance.

OOB Mode

In the Cisco NAC Appliance OOB deployment, the NAC Server communicates with the end host only during the authentication process, posture assessment, and remediation. After the end host is certified, it does not communicate with the Server.

In OOB mode, the Cisco NAC Manager uses simple network management protocol (SNMP) in order to control switches and set VLAN assignments for ports. When the Cisco NAC Manager and Server are set up for OOB, the Manager can control the switch ports of supported switches. The control of the switch ports is known as the SNMP control plane. For a list of supported switch models, refer to the OOB Supported Switches section of Switch Support for Cisco NAC Appliance.

OOB mode is primarily used for wired deployments. When the VRF method of Layer 3 OOB is used, all traffic from the untrusted (dirty) VLANs, including the agent traffic, reaches the centralized Cisco NAC Server where all enforcement takes place. Traffic enforcement at the Server is a key differentiator between the VRF method and the ACL method of Layer 3 OOB.

Note: The Cisco NAC Server was originally engineered to be an in-band device. In other words, the Server was designed to have all traffic flow through it, which would allow the Server to be the control point. When you use the VRF Method of Layer 3 OOB, all unauthenticated user traffic flows through the Server exactly as if it were an in-band deployment. This traffic flow allows for a consistent, predictable environment.

Endpoint Classification

Several factors contribute to endpoint classification, and includes device types and user roles. Both device type and user role impact the endpoint role.

These are the possible device types:

  • Corporate devices

  • Non-corporate devices

  • Non-PC devices

These are the possible user roles:

  • Employee

  • Contractor

  • Guests

Initially, all endpoints are assigned to the unauthenticated VLAN. Access to the other roles is permitted after the identity and posture process is complete.

Endpoint Roles

The role of each type of endpoint must be initially determined. A typical campus deployment includes several roles, such as employees, guests, contractors, and other endpoints such as printers, wireless access points, and IP cameras. Roles are mapped to the edge switch VLANs.

Note: An additional role is required for Authentication to which all endpoints initially belong. This role maps to an unauthenticated “dirty” VLAN.

Role Isolation

For this type of NAC design, traffic classified as “dirty” must flow into the “untrusted” side of the Cisco NAC Server. Keep this principle in mind while you design a Cisco NAC implementation. Additionally, do not allow the “clean” and “dirty” networks to communicate directly with each other.

Figure 4 shows that when a Layer 3 OOB design uses VRFs, the VRF ensures that unauthenticated traffic remains isolated in its own virtual network. The Cisco NAC Server acts as the enforcement point or controller that ensures the segregation and secure communication between the “clean” and “dirty” networks.

Figure 4 – The Cisco NAC Server Connects to the Dirty and Clean Sides

nac-layer3-04.gif

Traffic Flow

The NAC process begins when an endpoint is connected to a NAC-managed switchport. Traffic classified as “dirty” or “unauthenticated” is isolated from the rest of the network(s) as it is in the “dirty” VRF. This traffic is isolated and sent to the untrusted interface on the Cisco NAC Server. See Figure 4.

Note: The Cisco NAC Appliance is oblivious to how traffic is presented to it. In other words, the Appliance itself has no preference whether the traffic arrives through a generic routing encapsulation (GRE) tunnel or is redirected through a policy-based routing configuration, VRF-routed, or other redirection methods.

Cisco NAC Server Mode

You can deploy a Cisco NAC Server in one of these two modes:

Virtual Gateway (Bridge) Mode

The virtual gateway (bridge) mode is typically used when the Cisco NAC Server is Layer 2 adjacent to the endpoints. In this mode, the Server acts as a bridge and is not involved in the routing decision of the network traffic.

Note: This mode is NOT applicable for this particular ACL design.

Real-IP Gateway (Routed) Mode

The real-IP gateway (routed) mode is more applicable in a design where the Cisco NAC Server is multiple Layer 3 hops away from the endpoint, such as Layer 3 OOB. When you use the Server as a real-IP gateway, specify the IP addresses of its two interfaces: one for the trusted side (server management) and one for the untrusted (dirty) side. The two addresses must be on different subnets. The untrusted interface IP is used for communicating with the endpoint on the untrusted subnet. The mode that this guide uses is real-IP gateway.

User Experience (with Cisco NAC Agent)

Typically, corporate entities have the Cisco NAC Agent deployed in advance to the end clients. The Discovery Host setting in the Agent triggers discovery packets to be sent to the untrusted interface of the Cisco NAC Server, which automatically continues the endpoint through the NAC process.

In a Layer 3 OOB with VRF model, the Discovery Host is typically set to be the DNS name or IP address of the Cisco NAC Manager. The Manager exists in the clean network. Because all traffic from the “dirty” networks is routed by default through the Cisco NAC Server, the Discovery packets automatically flow through the Server. The traffic flow described here is one of the benefits to the VRF Method. This traffic flow provides for a consistent, predictable experience. See Cisco NAC Process Flows for more information.

User Experience (without Cisco NAC Agent)

The ability to operate without a Cisco NAC Agent is another benefit of the VRF model. All traffic from the “dirty” networks is routed naturally through the Cisco NAC Server. This means that a user on a machine without a Cisco NAC Agent only has to open a web browser and browse to any valid website. The browser traffic attempts to pass through the Server, which in turn captures the browser session and redirects it to a captive portal. See Cisco NAC Process Flows for more information.

Note: For the best end-user experience possible, use certificates that are trusted by the end-user's browser. Self-generated certificates on the Cisco NAC Server and Cisco NAC Manager are not recommended for a production environment.

Note: Always generate the certificate for the Cisco NAC Server with the IP address of its untrusted interface.

Cisco NAC Process Flows

This section explains the basic process flow for a NAC OOB solution. Scenarios are described both with and without a Cisco NAC Agent installed on the client machine. This section shows how the Cisco NAC Manager controls the switch ports using SNMP as the control medium. These process flows are macro-analytical in nature and contain only functional decision steps. The process flows do not include every option or step that occurs and do not include authorization decisions that are based on endpoint assessment criteria.

Refer to the process flow diagram in Figure 6 for the circled steps that are in Figure 5.

Figure 5 – NAC Process Flow for the Layer 3 OOB Cisco NAC Solution

nac-layer3-05.gif

Figure 6 – Cisco NAC Process Flow Block Diagram

nac-layer3-06.gif

Cisco NAC Solution Implementation

This section describes how to implement a Cisco NAC solution.

Topology

Figure 7 shows the topology used for the creation of this guide. The internal network, which consists of VLANs 200 and 210, is routed by using the global routing table. The internal network has no VRF associated with it.

The Dirty VRF contains only the DIRTY VLAN and the associated transit networks that are needed in order to create a single virtual network for all Dirty traffic to flow to the Dirty side of the centralized Cisco NAC Server.

The Guest VRF contains the GUESTS VLAN and associated transit networks that are needed in order to terminate all data sourced from the GUESTS VLAN on a separate sub-interface on the firewall. Each of the three virtual networks (DIRTY, GUESTS, and GLOBAL) is carried on the same physical infrastructure and provides complete traffic and path isolation.

Figure 7 – Topology Used in this Guide

nac-layer3-07.gif

Order of Operations

The order of operations for the deployment of a Cisco NAC solution is easily up for debate. Do you configure the NAC portion of the solution before the network is prepared? Or, do you prepare the network before you configure the Cisco NAC devices?

For purposes of organization, this guide focuses on the network configuration first. This ensures that the network is ready for NAC, then the configuration of the Cisco NAC products.

Network Configuration

This guide focuses on end-to-end VRF-Lite for path isolation. It is important to note that you can use VRFs with a GRE tunnel in order to allow the path isolation through an existing distribution and core layer, without requiring any configuration in those devices. For more information on when and why to use GRE tunnels compared to an end-to-end VRF design, see the Extend a VRF Between Two Devices section. You can also refer to NAC Layer 3 Out of Band Design Guide That Uses VRF-Lite for Traffic Isolation.

This document is a full design guide focused on the VRF-Lite with GRE method.

Additionally, full tag switching can be used in place of VRF-Lite where applicable. Tag switching is considered out-of-scope for the purposes of this document.

Important Considerations for VRF-Lite

Note: VRF-Lite is a feature that enables you to support two or more virtual networks. VRF-Lite also allows for overlapping IP addresses among the virtual networks. However, IP address overlap is not recommended for a NAC implementation, because while the infrastructure itself supports the overlapping addresses, it can create troubleshooting complexities and incorrect reporting.

Details given in the steps provided in this section outline the steps necessary in order to configure your network for path isolation using VRF-Lite. The configuration required for inserting the Cisco NAC Appliance into your network as a Layer 3 OOB real-IP gateway is also provided.

VRF-Lite uses input interfaces in order to distinguish routes for different virtual networks and forms separate virtual routing tables by associating one or more Layer 3 interfaces with each VRF. Interfaces in a VRF can be either physical, such as Ethernet ports, or they can be or logical, such as sub-interfaces, Tunnel Interfaces, or VLAN switch virtual interfaces (SVIs).

Note: A Layer 3 interface cannot belong to more than one VRF at a time.

Note these VRF-Lite considerations:

  • VRF-Lite is locally significant only to the switch where it is defined, and VRF membership is determined by the input interface. No packet header or payload manipulation is performed.

  • A switch with VRF-Lite is shared by multiple virtual networks (security domains), and all security domains have their own unique routing tables.

  • All security domains must have their own VLANs.

  • VRF-Lite does not support all Multiprotocol Label Switching (MPLS)-VRF functionality such as label exchange, Label Distribution Protocol (LDP) adjacency, or labeled packets which are also know as tag-switching).

  • The Layer 3 ternary content addressable memory (TCAM) resource is shared between all VRFs. In order to ensure that any one VRF has sufficient content addressable memory (CAM) space, use the maximum routes command.

  • A Catalyst switch that uses VRF-Lite can support one global network and up to 64 VRFs. The total number of routes supported is limited by the size of the TCAM.

  • You can use most routing protocols such as Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), and static routing between devices that run VRF-Lite.

  • In most cases, there is no need to run BGP with VRF-Lite.

  • VRF-Lite does not affect the packet switching rate.

  • You cannot configure Multicast and VRF-Lite on the same Layer 3 interface at the same time.

  • Use the capability vrf-lite subcommand under router OSPF when you configure OSPF as the routing protocol between network devices.

Define a VRF

In this design example, path isolation must be provided for unauthenticated or dirty users and guests. All other traffic is permitted to use the internal network. You must define two VRFs as this configuration shows:

VRF Configuration Example

!--- This command creates a VRF for the DIRTY virtual network:

!
ip vrf DIRTY
!

!--- This command names the VRF and places you into VRF configuration mode:

!
description DIRTY_VRF_FOR_NAC
!

!--- Gives the VRF a user friendly description field for documentation

!
rd 100:3
!

!--- Creates a VRF table by specifying a route distinguisher. 
!--- Enter either an AS number and an arbitrary number (xxx:y) or an IP 
!--- address and arbitrary number (A.B.C.D:y).

!

!--- This document uses the Autonomous System number and a unique router-id in that AS. 
!--- This example signifies AS 100:Router-ID 3

!

Note: The route distinguisher is not a required configuration for VRF-Lite. However, it is considered a best practice to configure the route distinguisher for the future, so that it works seamlessly with tag switching.


! -- Here we create a VRF for the GUEST Virtual Network:

!
ip vrf GUESTSdescription GUESTS_VRF_FOR_VISITORSrd 600:3
!

Associate a VLAN or Interface with a VRF

After the VRF is defined on the Layer 3 switch or router, you must associate the interfaces that are going to participate in the VRF-Lite configuration with the VRF where they belong. You can associate either physical or virtual interfaces with a VRF. This section provides examples of a physical interface, a sub interface, a switched virtual interface, and a tunnel interface that are all associated with a VRF.

Note: The examples are samples only, and were not used in the topology of this document.

Physical Interface Configuration Example
interface FastEthernet0/1
ip vrf forwarding GUESTS

!--- Associates the interface with the appropriate VRF defined in Step 1.

ip address 192.168.39.1 255.255.255.252

Sub-Interface Configuration Example
interface FastEthernet3/1.10
encapsulation dot1Q 10
ip vrf forwarding DIRTY
ip address 192.168.10.1 255.255.255.252

Switched Virtual Interface Configuration Example
interface Vlan100
ip vrf forwarding DIRTY
ip address 192.168.100.1 255.255.255.0

Tunnel Interface Configuration Example
interface Tunnel0
ip vrf forwarding GUESTS
ip address 192.168.38.2 255.255.255.252
tunnel source Loopback0
tunnel destination 192.168.254.1

Extend a VRF Device Between Two Devices

There are several acceptable methodologies you can use in order to extend a VRF between two pieces of infrastructure. Make sure that the method you choose is based on these criteria:

  • Consider the capabilities of the platform. All current Cisco Layer 3-capable Enterprise Switching and Routing platforms support VRF-Lite. These platforms include, but are not limited to, the Catalyst 6500, 4500, 3750, and 3560 platforms.

  • A routing platform must run the appropriate IOS. The platforms include, but are not limited to, the 7600, 3900, 3800, 2900, 2800, 1900, 1800, and 800 series integrated services routers (ISRs).

  • Consider the number of Layer 3 hops between relevant pieces of infrastructure. In order to determine the number of Layer 3 hops, keep the deployment as simple as possible. For example, if five Layer 3 hops exist between the infrastructure that hosts the Channel Associated Signaling (CAS) devices and the clients, it can create administrative overhead.

With the incorrect solution:

  • Layer 2 trunking creates a very sub-optimal Layer 2 topology.

  • Layer 3 sub-interfaces create many additional interfaces to configure. More interfaces to configure can create additional management overhead and potential IP addressing issues. With the assumption that there is no redundancy in the infrastructure, each layer of the network has both an ingress and egress physical interface. The computation for the number of subi-nterfaces is then (2 * number of tiers in the network * number of VRFs). Our example has two VRFs, so the formula is (2 *5 * 2) or 20 sub-interfaces. After redundancy is added, this number more than doubles. Compare this to GRE extension, where only four interfaces are required with the same end result. This comparison illustrates how GRE reduces the configuration impact.

Layer 2 Trunking

Layer 2 trunking is preferred in scenarios where the access layer devices do not support sub-interfaces. The Catalyst 3560, 3750, and 4500 platforms do not support sub-interfaces.

In a Layer 3 access model that connects to a platform that does not support sub-interfaces to a platform that does, only use Layer 2 trunking on one side and use sub-interfaces on the other side. This configuration maintains all the benefits of a Layer 3 closet architecture and still overcomes the limitation of no sub-interface support on some platforms.

One of the primary advantages of configuring Layer 2 trunking on only one side of the link is that Spanning Tree is not introduced back into the Layer 3 environment. See the 3750 Relevant Configuration Example where a 3750 Access Switch. which does not support GRE or sub-interfaces, is connected to a 6500 Distribution Switch. The 6500 Distribution Switch does support GRE and sub-interfaces.

3750 Relevant Configuration

In this configuration, the default setting for the NATIVE VLAN is VLAN 1 on FastEthernet 1/0/1. This configuration has not been changed. However, VLAN 1 is not allowed to be trunked across the link. The allowed VLANs are limited to only the VLANs that are tagged.

There is no need for switch-to-switch trunk negotiation or VLAN Trunk Protocol (VTP) traffic in this Layer 3 topology. Therefore, there is also no need for any untagged traffic to be transmitted on this link. This configuration increases the security posture of the architecture because it does not open up unnecessary Layer 2 security holes.

3750 Relevant Configuration Example

!--- 3750 Switch configuration, related to connecting it to a 
!--- sub-interface capable switch (Catalyst 6500):

!
ip vrf DIRTY
 rd 100:1
!
ip vrf GUEST
 rd 600:1
!
interface GigabitEthernet1/0/48
 description Uplink to Cat6k
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 901-903,906
 switchport mode trunk
 spanning-tree portfast trunk
!

!--- Since the 3750 does not support sub-interfaces, 
!--- you must configure one SVI per transit network:

!
interface Vlan901
 description DIRTY_TRANSIT
 ip vrf forwarding DIRTY
 ip address 172.26.120.2 255.255.255.252
!
interface Vlan902
 description GLOBAL_TRANSIT
 ip address 172.26.120.6 255.255.255.252
!
interface Vlan906
 description GUEST_TRANSIT
 ip vrf forwarding GUEST
 ip address 172.26.120.14 255.255.255.252
!

!--- This configuration uses EIGRP as the routing protocol 
!--- of choice in this document.
!--- Each VRF is defined as a separate 
!--- Autonomous System under the Global AS.

!
router eigrp 26
 !
 address-family ipv4 vrf DIRTY
  network 172.26.120.0 0.0.0.255
  autonomous-system 100
  no auto-summary
 exit-address-family
 !
 address-family ipv4 vrf GUEST
  redistribute static
  network 172.26.120.0 0.0.0.255
  autonomous-system 600
  no auto-summary
 exit-address-family
 network 172.26.0.0

6500 Relevant Configuration

In this configuration, dot1q encapsulation is used in order to tag the frames with VLAN 901, 902, and 906. When you select the VLAN tags to use on a sub-interface, you cannot use a VLAN number that is already defined locally in the VLAN database on the switch.

6500 Relevant Configuration Example

!--- 6500 Switch configuration, related to connecting it 
!--- to a non-sub-interface capable switch (Catalyst 3750):

!
ip vrf DIRTY
 rd 100:26
!
ip vrf GUEST
 rd 600:26
!
interface FastEthernet1/34
 description NAC LAB - 3750
 no ip address
!
interface FastEthernet1/34.901
 encapsulation dot1Q 901
 ip vrf forwarding DIRTY
 ip address 172.26.120.1 255.255.255.252
!
interface FastEthernet1/34.902
 encapsulation dot1Q 902
 ip address 172.26.120.5 255.255.255.252
!
interface FastEthernet1/34.906
 encapsulation dot1Q 906
 ip vrf forwarding GUEST
 ip address 172.26.120.13 255.255.255.252
!

!--- EIGRP is the routing protocol of choice in this document.
!--- Each VRF is defined as a 
!--- separate Autonomous System under the Global AS.
!--- See Configure Routing for the VRF for more information.

!
router eigrp 26
 network 172.26.0.0 0.0.255.255
 no auto-summary
 passive-interface Vlan1
 redistribute static
!
 address-family ipv4 vrf DIRTY
  autonomous-system 100
  network 172.26.120.0 0.0.0.3
  network 172.26.160.0 0.0.0.255
  no auto-summary
  no default-information out
  redistribute static route-map gw-route
 exit-address-family
! address-family ipv4 vrf GUEST
  redistribute static
  network 172.26.120.0 0.0.0.255
  autonomous-system 600
  no auto-summary
 exit-address-family
!

Configure Routing for the VRF

As discussed earlier in the Important Considerations for Using VRF-Lite section, VRF-Lite supports BGP, OSPF, and EIGRP. In this configuration example, EIGRP is selected because it is the routing protocol that Cisco recommends for implementation on Campus networks where fast convergence is required.

Note: OSPF works equally well with VRF-Lite, as does BGP.

Note: BGP is required if the design requires that traffic be “leaked” between VRFs.

Routing for a VRF with EIGRP Configuration Example
!

!--- This base routing protocol configuration handles the routing 
!--- for the Global Routing Table.

!
router eigrp 26
 network 172.26.50.0 0.0.0.255
 network 172.26.51.0 0.0.0.255
 network 172.26.52.0 0.0.0.255
 network 172.26.55.0 0.0.0.255
 network 172.26.60.0 0.0.0.255
 network 172.26.61.0 0.0.0.255
 network 172.26.62.0 0.0.0.255
 network 172.26.120.4 0.0.0.3
 network 172.26.176.0 0.0.0.255
 network 172.26.254.1 0.0.0.0
 no auto-summary
 passive-interface Vlan1
 redistribute static
!

!--- You must define an address family for each VRF 
!--- that is to be routing using the routing protocol. 
!--- Routing protocol options such as auto-summarization, 
!--- AS number, and router id are all configured under the 
!--- address family. EIGRP does not form a neighbor 
!--- relationship without the AS specified under the address family. 
!--- Also, this AS number needs to be unique for 
!--- each VRF and cannot be the same as the global AS number.

!
 address-family ipv4 vrf DIRTY
  autonomous-system 100
  network 172.26.120.0 0.0.0.3
  network 172.26.160.0 0.0.0.255
  no auto-summary
  no default-information out 
  redistribute static route-map gw-route
 exit-address-family
! address-family ipv4 vrf GUEST
  redistribute static
  network 172.26.120.0 0.0.0.255
  autonomous-system 600
  no auto-summary
 exit-address-family
!

Route Traffic Between the Global Routing Table and the Dirty VRF

Depending on the NAC deployment requirements, it may be necessary to pass traffic from the untrusted or dirty side of the network to the trusted or clean side of the network. For example, remediation services can potentially live on the Trusted side of the Cisco NAC Appliance. In the case of Active Directory single sign-on deployments, it is necessary to pass a subset of traffic to Active Directory in order to allow interactive logons Kerberos ticket exchange, and so on.

In any event, it is very important that the global routing table knows how to reach the dirty VRF, and that the dirty VRF knows how to reach the global routing table if any data needs to pass between the two. This is typically handled by the methodology in Figure 8.

The dirty VRF defaults to the untrusted or dirty interface of the Cisco NAC Appliance. The global has static routes only to the subnets that are considered dirty VLANs. Those static routes point to the clean (trusted) interface of the Cisco NAC Server as the next hop.

Figure 8 – Routing Flows

nac-layer3-08.gif

The first Layer 3 hop on the untrusted or dirty side of the Cisco NAC Appliance redistributes a default route into a routing process that points to the Cisco NAC Appliance. The first Layer 3 hop on the trusted or clean side of the Cisco NAC Appliance redistributes a static route for the subnet(s) that belong to the dirty VLAN(s) in the access layer (in this case 172.26.123.0/26).

Note: The first Layer 3 hop on opposite sides of the Cisco NAC Appliance can be on the same physical device, but in different VRFs.

Note: In the topology used for this document, the untrusted or dirty side of the Cisco NAC server is in a VRF, while the trusted or clean side of the Cisco NAC Appliance remains in the global routing table. However, both interfaces are connected to the same data center switch.

Cisco NAC Layer 3 OOB VRF-Lite Configuration Example

In order to successfully deploy a Cisco NAC OOB solution, you need to configure the NAC components in order to match the desired architecture. Figure 9 is a Layer 3 Cisco NAC OOB logical network diagram that is used in this section in order to show the relevant configuration of the Cisco NAC Manager, Cisco NAC Server, and edge switch for a NAC Layer 3 OOB with VRF-Lite deployment.

Figure 9 – Cisco NAC Layer 3 OOB Logical Topology

nac-layer3-09.gif

Complete the steps in these sections in order to configure a Layer 3 real-IP OOB VRF Cisco NAC deployment:

Step 1: Configure the Edge Switch

As these configuration examples show, create two more VLANs (DIRTY and GUEST) on the edge switch.

The existing production VLAN (VLAN 200) is used for all corporate systems. This example creates the VLANs, their associated transit networks, and assigns both to the correct VRFs. The enforcement takes place at the Cisco NAC Server, so you do not need to apply ACLs to each VLAN at the switch.

Unauthenticated Role: VLAN 100, Dirty VRF Configuration Example

!--- Define the DIRTY VRF.

ip vrf DIRTY
 rd 100:3

!--- Create the SVI for the DIRTY VLAN.

interface Vlan100
 ip vrf forwarding DIRTY
 ip address 172.26.123.1 255.255.255.224
 ip helper-address vrf DIRTY 172.26.51.11

!--- Create the SVI for the DIRTY_TRANSIT_NETWORK.

interface Vlan301
 ip vrf forwarding DIRTY
 ip address 172.26.120.50 255.255.255.252

!--- Set the allowed VLAN on the trunk.

interface FastEthernet1/0/48
 switchport trunk allowed vlan add 301

!--- Set up the routing for the VRF.

router eigrp 26
 address-family ipv4 vrf DIRTY
  network 172.26.0.0
  autonomous-system 100
  no auto-summary
 exit-address-family

Guest Role: VLAN 600, GUEST VRF Configuration Example

!--- Define the GUEST VRF.

ip vrf GUEST
 rd 600:3 

!--- Create the SVI for the GUEST VLAN.

interface Vlan600
 ip vrf forwarding GUEST
 ip address 172.26.123.193 255.255.255.224 

!--- Create the SVI for the DIRTY_TRANSIT_NETWORK.

interface Vlan306
 ip vrf forwarding GUEST
 ip address 172.26.120.62 255.255.255.252 

!--- Set the allowed VLAN on the trunk.

interface FastEthernet1/0/48
 switchport trunk allowed vlan add 306

!--- Set up the routing for the VRF.
 
router eigrp 26
 address-family ipv4 vrf GUEST
  network 172.26.0.0
  autonomous-system 600
  no auto-summary
 exit-address-family

Step 2: Configure the Core Switch

The configuration examples in this section show the simulation of a collapsed core with a Catalyst 3750-E Switch. In most environments, this is not an edge-class switch. However, the switch was built in the lab environment used for this document.

Create four more VLANs for transit networks, two for the DIRTY VLAN and two for the GUEST VLAN. See Figure 10.

  • DIRTY VLAN

    • VLAN 301 DIRTY from edge to core

    • VLAN 901 DIRTY from core to data center

  • GUEST VLAN

    • VLAN 306 GUEST from edge to core

    • VLAN 906 GUEST from core to data center

A transit network is being built from the edge to the core, and a second for the core to the data center. The transit networks must be completed in order for both the DIRTY and GUEST VRFs. If tag switching is enabled instead of VRF-Lite, this is not necessary.

Note: This document focuses on VRF-Lite, and tag switching is considered out-of-scope.

Figure 10 – Transit Networks

nac-layer3-10.gif

:

VLAN 301 DIRTY from Edge to Core; VLAN 901 DIRTY from Core to Data Center Configuration Example

!--- This is the core switch.
!--- Define the DIRTY VRF.

ip vrf DIRTY
 rd 100:1

!--- Create the SVI for the DIRTY VLANs.

interface Vlan301
 desc This is the Transit Network between the Edge & Core
 ip vrf forwarding DIRTY
 ip address 172.26.120.49 255.255.255.252 

interface Vlan901
 desc This is the Transit Network between the Core and the DC
 ip vrf forwarding DIRTY
 ip address 172.26.120.2 255.255.255.252

!--- Set the allowed VLAN on the trunks.

interface GigabitEthernet1/0/3
 switchport trunk allowed vlan add 301

interface GigabitEthernet1/0/48
 switchport trunk allowed vlan add 901

!--- Set up the routing for the VRF. 

router eigrp 26
 address-family ipv4 vrf DIRTY
  network 172.26.0.0
  autonomous-system 100
  no auto-summary
 exit-address-family
exit-address-family

VLAN 306 GUEST from Edge to Core; VLAN 906 GUEST from Core to Data Center Configuration Example

!--- This is the core switch.

!

!--- Define the GUEST VRF.

ip vrf GUEST
 rd 600:1

!--- Create the SVI for the GUEST VLANS.

interface Vlan306
 desc This is the transit network between the Edge & Core
 ip vrf forwarding GUEST
 ip address 172.26.120.61 255.255.255.252 

interface Vlan906
 description Transit Network between Core & DC
 ip vrf forwarding GUEST
 ip address 172.26.120.14 255.255.255.252

!--- Set the allowed VLAN on the trunks.

interface GigabitEthernet1/0/3
 switchport trunk allowed vlan add 306

interface GigabitEthernet1/0/48
 switchport trunk allowed vlan add 906

!--- Set up the routing for the VRF.

router eigrp 26
 address-family ipv4 vrf GUEST
  network 172.26.0.0
  autonomous-system 600
  no auto-summary
 exit-address-family

Step 3: Configure the Data Center Switch

As the configuration example shows, the Cisco NAC Server has both interfaces connected to the same 6500 data center switch. The trusted interface is in VLAN 60, and the untrusted interface is in VLAN 160, which is in the DIRTY VRF.

  1. Create four more VLANs for the connection to the core:

    • A dirty VLAN (160)

    • A clean VLAN (60)

    • A dirty transit network (901)

    • A clean transit network (906)

    1. Add the DIRTY VLAN to the DIRTY VRF.

    2. Terminate GUEST VRF in a GUEST DMZ (999) that uses a Cisco ASA Firewall (out of scope for this document) in order to connect guest users to the Internet and perform Network Address Translation (NAT) functions.

  2. Create the DIRTY and GUEST transit sub-interfaces.

    The commands shown in the Data Center Switch Configuration Example perform these tasks:

    • Define the DIRTY and GUEST VRFs.

    • Create the DIRTY and CLEAN networks for the Cisco NAC Server.

Data Center Switch Configuration Example

!--- Define the DIRTY and GUEST VRFs.

ip vrf DIRTY
 rd 100:26

ip vrf GUEST
 rd 600:26

!--- Create the sub-interface and switched virtual interface (SVI)
!--- for the DIRTY and GUEST VLANs.

interface FastEthernet1/34.901
 desc Transit Network from Core to DC for DIRTY traffic
 encapsulation dot1Q 901
 ip vrf forwarding DIRTY
 ip address 172.26.120.1 255.255.255.252

interface FastEthernet1/34.906
 desc Transit Network from Core to DC for GUEST traffic
 encapsulation dot1Q 906
 ip vrf forwarding GUEST
 ip address 172.26.120.13 255.255.255.252

interface Vlan60
 desc Trusted (CLEAN) side of the NAC Server
 ip address 172.26.60.1 255.255.255.0

interface Vlan160
 desc Untrusted (DIRTY) side of the NAC Server
 ip vrf forwarding DIRTY
 ip address 172.26.160.1 255.255.255.0

interface Vlan999
 description GUEST VLAN SVI
 ip vrf forwarding GUEST
 ip address 192.168.26.254 255.255.255.0


!--- Set up the routing for the VRFs.


router eigrp 26
 network 172.26.60.0 0.0.0.255
 no auto-summary
 redistribute static

 address-family ipv4 vrf DIRTY
  autonomous-system 100
  network 172.26.120.0 0.0.0.3
  network 172.26.160.0 0.0.0.255
  no auto-summary
  redistribute static

exit-address-family

 address-family ipv4 vrf GUEST
  network 172.26.0.0
  network 192.168.26.0
  autonomous-system 600
  no auto-summary
  redistribute static
 exit-address-family

!--- Set up the static routes for redistribution for the VRFs.

ip route 172.26.123.0 255.255.255.192 172.26.60.2
ip route vrf DIRTY 0.0.0.0 0.0.0.0 172.26.160.2
ip route vrf GUEST 0.0.0.0 0.0.0.0 192.168.26.1

Step 4: Perform Initial Setup of the Cisco NAC Manager and Server

Cisco NAC Manager and Server installation is performed through console access. The install utility guides you through the initial configuration for both Manager and Server. Go to Installing the Clean Access Manager and Clean Access Server in order to perform the initial setup.

Step 5: Apply a License to the Cisco NAC Manager

After you perform the initial setup through the console, access the Cisco NAC Manager GUI in order to continue configuring the Cisco NAC Manager and Server. First upload the Manager and Server licenses that came with the appliances. For more information on how to upload the licenses, go to the Access the CAM Web Console section of Installing the Clean Access Manager and Clean Access Server.

Note: All the Cisco NAC Manager and Server licenses are based on the eth0 MAC address of the Manager. In a failover setup, the licenses are based on the eth0 MAC address of both primary and secondary Cisco NAC Managers.

Step 6: Update Policies from Cisco.com on the Cisco NAC Manager

Cisco NAC Manager must be configured in order to retrieve periodic updates from the central update server located at Cisco. The Cisco NAC Appliance Supported AV/AS Product List is a versioned XML file distributed from a centralized update server that provides the most current matrix of supported antivirus and antispyware vendors and product versions used to configure antivirus or antispyware rules and antivirus or antispyware definition update requirements for posture assessment and remediation. This list is updated regularly for the antivirus and antispyware products and versions supported in each Cisco NAC Agent release and includes new products for new Agent versions. The list provides version information only. When the Cisco NAC Manager downloads the supported antivirus and antispyware product list, it is downloading the information about what the latest versions are for antivirus and antispyware products. It is not downloading actual patch files or virus definition files. Based on this information, the Agent can then trigger the native antivirus or antispyware application in order to perform updates. For more information about how updates are retrieved, go to the Require Agent Login for Client Machines section of Configuring Cisco NAC Appliance for Agent Login and Client Posture Assessment.

Step 7: Install Certificates from a Third-party Certificate Authority (CA)

During installation, the configuration utility script for both the Cisco NAC Manager and Cisco NAC Server requires you to generate a temporary SSL certificate. For the lab environment, you can continue to use the self-signed certificates. However, they are not recommended for a production network.

For more information on installing certificates on the Cisco NAC Manager from a third-party CA, go to the Set System Time and Clean Access Server Direct Access Web Console sections of Administering the CAM.

Note: If you use the self-sign certificates in the lab environment, the Cisco NAC Manager and Cisco NAC Server each need to trust the certificate of the other. This requires that you upload the certificates for both as a Trusted Certificate Authority under SSL > Trusted Certificate Authorities.

Step 8: Review Cisco NAC Server Setup

The most important thing to remember for a successful NAC design is that traffic classified as dirty must flow into the untrusted side of the NAC Server, as Figure 11 shows:

Figure 11 – Cisco NAC Server Deployment

nac-layer3-11.gif

Step 9: Add the Cisco NAC Server to the Cisco NAC Manager

Complete these steps in order to add the Cisco NAC Server to the Cisco NAC Manager:

  1. Click CCA Servers under the Device Management pane. See Figure 12.

  2. Click the New Server tab.

  3. Use the Server IP Address box in order to add the IP address of the Cisco NAC Server's trusted interface.

  4. In the Server Location box, enter OOB Cisco NAC Server as the server location.

  5. Choose Out-of-Band Real-IP-Gateway from the Server Type drop-down list.

  6. Click Add Clean Access Server.

Figure 12 – Adding Cisco NAC Server to Cisco NAC Manager

nac-layer3-12.gif

Note: The Cisco NAC Manager and Cisco NAC Server have to trust each other's CA in order for the Manager to successfully add the Server.

After you add the Cisco NAC Server, it appears in the list under the List of Servers tab. See Figure 13.

Step 10: Configure the Cisco NAC Server

Complete these steps in order to configure the Cisco NAC Server:

  1. Click the List of Servers tab.

  2. Click the Manage icon for the Cisco NAC Server in order to continue the configuration.

Figure 13 – Cisco NAC Server Managed by Cisco NAC Manager

nac-layer3-13.gif

After you click the Manage icon, the screen shown in Figure 14 appears.

Step 11: Enable Layer 3 Support

Complete these steps in order to enable Layer 3 support:

  1. Select the Network tab.

  2. Check the Enable L3 Support checkbox.

  3. Check the Enable L3 strict mode to block NAT devices with the NAC Agent checkbox.

  4. Click Update.

  5. Reboot the Cisco NAC Server as instructed.

Figure 14 – Cisco NAC Server Network Details

nac-layer3-14.gif

Note: Always generate the certificate for the Cisco NAC Server with the IP address of its untrusted interface. For a name-based certificate, the name needs to resolve to the untrusted interface IP address. When the end point communicates with the untrusted interface of the Server in order to begin the NAC process, the Server redirects the user to the certificate hostname or IP. If the certificate points to the trusted interface, the login process does not function correctly.

Step 12: Configure Static Routes

Complete these steps in order to configure static routes:

  1. After the Cisco NAC Server reboots, return to the Server and continue with the configuration.

    The Cisco NAC Server must use the untrusted interface in order to communicate with end points on the unauthenticated VLAN.

  2. Select Advanced > Static Routes in order to add routes to the unauthenticated VLAN.

  3. Fill in the appropriate subnets for the unauthenticated VLANs.

  4. Click Add Route.

  5. Select Untrusted interface [eth1] for these routes.

Figure 15 – Add a Static Route to Reach the Un-authenticated User Subnet

nac-layer3-15.gif

Step 13: Set Up Profiles for Switches in the Cisco NAC Manager

Complete these steps in order to set up profiles for switches in the Cisco NAC Manager:

  1. Select OOB Management > Profiles > Device > Edit.

  2. Fill in the Device Profile information. Use Figure 16 as a guide.

    Each switch is associated with a profile. Add a profile for each type of edge switch the Cisco NAC Manager will manage. In this example, a 3750 switch is managed.

    Figure 16 – SNMP Profile Used to Manage the Switch

    nac-layer3-16.gif

  3. Set up the switch configuration for SNMP.

    Configure the edge switch for the same SNMP read/write community strings that are configured on the Cisco NAC Manager.

    snmp-server community Cisco123 RO
    snmp-server community Cisco1234 RW
  4. Select OOB Management > Profiles > Port > New. See Figure 17.

    • For individual port control, configure a port profile under OOB Management > Profiles > Port that includes the default unauthenticated VLAN and default access VLAN. In the access VLAN section, specify the User Role VLAN using the Access VLAN dropdown. The Cisco NAC Manager changes the unauthenticated VLAN to the access VLAN based on the VLAN defined in the role where the user belongs.

    • Define the port profile in order to control the port's VLAN based upon the user roles and VLANs implemented.

      The Auth VLAN is the UNAUTHENTICATED VLAN (VLAN 17) to which unauthenticated devices are initially assigned.

      The Default Access VLAN is the EMPLOYEES VLAN (VLAN 14). This VLAN is used if the authenticated user does not have a role-based VLAN defined.

      The Access VLAN can override the default VLAN to a user role VLAN, which is defined under the user role. For more information about setting up user roles, see Step 17: Configure User Roles. LDAP mappings can be used in order to map user roles in NAC to LDAP groups. For more information, refer to NAC(CCA) 4.x: Map Users to Certain Roles Using LDAP Configuration Example.

      Figure 17 – Port Profile to Manage the Switch Port

      nac-layer3-17.gif

      Note: You can also define VLAN names instead of IDs. If you define VLAN names, you can have VLAN IDs on different switches across the campus. However, the same VLAN name is attached to a particular role.

    • Additional options are available under the port profile for IP release and renew options. Scroll down the page shown in in order to see these options.

    • If the user is behind an IP phone, uncheck the Bounce the port after VLAN is changed checkbox. If this is checked, it can possibly reboot the IP phone when the port is bounced.

    Figure 18 – Various Options Available under Port Profile

    nac-layer3-18.gif

Step 14: Configure SNMP Receiver Settings

In addition to setting up the SNMP community string for Read/Write, you also need to configure the Cisco NAC Manager in order to receive SNMP traps from the switch. These traps are sent when the user connects and disconnects from the port. When the Cisco NAC Server sends the MAC/IP address information of a particular end point to the Manager, the Manager is able to build a mapping table internally for the MAC/IP and switch port.

  1. Select OOB Management > Profiles > SNMP Receiver.

  2. Configure the SNMP trap settings as this figure shows:

    Figure 19 – Cisco NAC Manager SNMP Receiver Setting to Collect SNMP Traps and Informs

    nac-layer3-19.gif

  3. In order to configure the switch settings for SNMP traps, increase the default switch Clean Access Manager (CAM) flush timer to 1 hour per Cisco best practice recommendations for NAC OOB. The CLI sample shows the mac-address-table aging-time parameter set to 3600.

    Setting the timer to 1 hour reduces the frequency of MAC notifications sent out of already connected devices to the Cisco NAC Manager. Use the source trap command in order to specify the source address that is used to send out the traps.

    3600 Configuration Example
    snmp-server enable traps mac-notification
    snmp-server host 172.26.51.52 informs version 2c Cisco1234
    snmp-server trap-source Vlan 200
    mac-address-table aging-time 3600

    Optionally, configure linkup and linkdown traps in order to send to the Cisco NAC Manager (not shown in the CLI sample). These traps are used only in a deployment scenario where the end hosts are not connected behind an IP phone.

    Note: SNMP informs are recommended because they are more reliable than the SNMP traps. Also, consider Quality of Service (QoS) for SNMP in a high-traffic network environment.

Step 15: Add Switches as Devices in the Cisco NAC Manager

Complete these steps in order to add switches as devices in the Cisco NAC Manager:

  1. Select OOB Management > Devices > Devices > New.

    Use the switch profile created in Step 13 in order to add the switch.

  2. Under the Device Profile, use the profile you created. Do not change the Default Port Profile value when you add the switch.

    Figure 20 – Add the Edge Switch in the Cisco NAC Manager to Control via SNMP

    nac-layer3-20.gif

  3. After the Switch is added to the Cisco NAC Manager, you can select the ports that you want to manage.

Step 16: Configure Switch Ports for the Devices to be Managed by NAC

Complete these steps in order to configure the switch ports for the devices to be managed by NAC.

  1. Select OOB Management > Devices Switch [IP address] > Ports > List in order to see the available switch ports you can manage.

    Figure 21 – Port Control Selection Available for a Managed Switch

    nac-layer3-21.gif

    Note: Do not leave the default profile as “uncontrolled” until you can mark the appropriate interfaces statically as “uncontrolled”. After the uplink ports, and any other on-off ports that need to remain uncontrolled are set; then change the default to your controlled port profile. Failure to do so in this order can result in less than desirable results.

  2. Select OOB Management > Devices Switch [IP address] > Ports > Manage in order to manage several ports at once.

Figure 22 – Manage Multiple Ports with the Join Option

nac-layer3-22.gif

Step 17: Configure User Roles

In this example, the VLANs that correspond to each role are already created in the edge switch.

  1. Select User Management > User Roles > Edit Role and create an employee role as this figure shows:

    Figure 23 – Create an Employee Role and Map the DATA VLAN

    nac-layer3-23.gif

  2. Select User Management > User Roles > Edit Role and create a guest role as this figure shows:

    Figure 24 – Create a Guest Role and Map the GUEST VLAN

    nac-layer3-24.gif

Step 18: Add Users and Assign to Appropriate User Role

In a campus environment, you will integrate with an external authentication server and map the user to a particular role by means of the LDAP attribute. This example uses a local user and associates that local user with a role.

Step 19: Customize the User Login Page for Web Login

A default login page is already created in Cisco NAC Manager. You can optionally customize the login page in order to change the appearance of the web portal. For a NAC Layer 3 OOB solution, you must download the ActiveX or Java component to the end client in order to perform these tasks:

  • Fetch the MAC address of the client machine.

  • Perform IP address release and renew.

  1. Select Administration > User Pages.

  2. Edit the page in order to enable the options as this figure shows:

Figure 25 – User Page Settings for Web Login

nac-layer3-25.gif

Step 20: Customize the Cisco NAC Agent for the User Roles

Complete these steps in order to customize the Cisco NAC Agent for user roles:

  1. Select Device Management > Clean Access > General Setup > Agent Login.

    You can configure the Cisco NAC Manager in order to make the Agent mandatory for any user role. In this example, the Agent is mandatory for the employee role. The contractor and guest roles must use web login.

  2. Check the Require use of Agent checkbox.

Figure 26 – Agent Login Required for Employee Role

nac-layer3-26.gif

Step 21: Distribute the Discovery Host for the Cisco NAC Agent

The Cisco NAC Agent software distribution, installation, and configuration are covered in Configure the Cisco NAC Appliance for Agent Login and Client Posture Assessment. This example configures the discovery host on the Cisco NAC Manager.

Select Device Management > Clean Access > Clean Access Agent > Installation:

Figure 27 – Discover the Host for a Cisco NAC Agent

nac-layer3-27.gif

The Discovery Host field is pre-populated if the Cisco NAC Agent is downloaded from the Cisco NAC Server. See Figure 27.

Note: In a Layer 3 OOB with VRF model, the Discovery Host is typically set to be the DNS name or IP address of the Cisco NAC Manager, which exists in the clean network. Because all traffic from the “dirty” networks is routed by default through the Cisco NAC Server, the Discovery packets automatically flow through the Server. The traffic flow described here is one of the benefits to the VRF Method. It provides for a consistent, predictable experience. See Cisco NAC Process Flows for more information.

Step 22: Web Login

Complete these steps in order to login through the web:

  1. Connect the client machine using one of the edge ports controlled by the Cisco NAC Manager.

    The client machine is placed in the unauthenticated VLAN. Make sure that the machine receives an IP address from the unauthenticated VLAN subnet.

  2. Open the browser in order to perform login.

    The assumption is that this client machine does not have a Cisco NAC Agent already installed. If all of the DNS entries are redirected to the untrusted interface of the Cisco NAC Server, the browser automatically redirects to a login page. If it does not, go to a specific URL such as guest.nac.local in order to perform login:

Figure 28 – Web Login Page

nac-layer3-28.gif

Step 23: Agent Login

You can distribute the Cisco NAC Agent just like any other software application to end users or you can force it using the Cisco NAC Server.

Note: More detailed information on Agent distribution and installation is available in the Cisco NAC Appliance - Clean Access Manager Configuration Guide.

This figure shows the screen that appears when the agent is activated:

Figure 29 – Agent Login

nac-layer3-29.gif

  1. Select the server from the Server dropdown list.

  2. Enter the Username.

  3. Enter the Password.

  4. Click Log In.

    Figures 30 and 31 shows the screens that appear:.

    Figure 30 – Cisco NAC Agent Performing IP Release or Renew

    nac-layer3-31.gif

    Figure 31 – Cisco NAC Agent Indicating Full Network Access After IP Refresh

    nac-layer3-30.gif

  5. Click OK.

Appendix

High Availability

Each of the individual Cisco NAC Managers and Cisco NAC Servers in the solution can be configured in high availability mode, meaning that there are two appliances that act in an active-standby configuration.

NAC Manager

You can configure the Cisco NAC Manager in high availability mode where there are two NAC Managers that act in an active-standby configuration. The entire configuration on a Manager is stored in a database. The standby Manager synchronizes its database with the database on the active Manager. Any configuration changes made to the active Manager are immediately pushed to the standby Manager. These key points provide a high-level summary of high availability Manager operation:

  • The Cisco NAC Manager high availability mode is an active or passive two-server configuration in which a standby Manager acts as a backup to an active Manager.

  • The active Cisco NAC Manager performs all tasks for the system. The standby Manager monitors the active Manager and keeps its database synchronized with the database of the active Manager.

  • Both Cisco NAC Managers share a virtual service IP for the Eth0 trusted interface. Use this service IP for the SSL certificate.

  • The primary and secondary Cisco NAC Managers exchange UDP heartbeat packets every 2 seconds. If the heartbeat timer expires, stateful failover occurs.

  • In order to ensure an active Cisco NAC Manager is always available, its trusted interface (Eth0) must be up. You must avoid the situation where a Manager is active but is not accessible through its trusted interface. This condition occurs if the standby Manager receives heartbeat packets from the active Manager, but the active Manager’s Eth0 interface fails. The link-detect mechanism allows the standby Manager to know when the active Manager’s Eth0 interface becomes unavailable.

  • You can choose to “automatically configure” the Eth1 interface in the Administration > CCA Manager > Failover page. However, you must manually configure other (Eth2 or Eth3) high availability interfaces with an IP address and netmask before you configure high availability on the Cisco NAC Manager.

  • The Eth0, Eth1, and Eth2/Eth3 interfaces can be used for heartbeat packets and database synchronization. In addition, any available serial (COM) interface can also be used for heartbeat packets. If you are using more than one of these interfaces, failover occurs only if all the heartbeat interfaces fail.

Note: The Cisco NAC Manager high availability pair cannot be separated by a Layer 3 link.

For more details, refer to the Cisco NAC Manager documentation at Configuring High Availability.

Cisco NAC Server

In order to provide protection against a single point of failure, you can configure the Cisco NAC Server in high availability mode. The high availability mode for the Cisco NAC Server is similar to that of the Cisco NAC Manager and also uses an active-standby configuration. The Cisco NAC Servers still share a virtual IP address (called a Service IP), but they do not share virtual MAC addresses.

These key points provide a high-level overview of high availability Cisco NAC Server operation:

  • The Cisco NAC Server high availability mode is an active-passive two-server configuration in which a standby Cisco NAC Server machine acts as a backup to an active Cisco NAC Server.

  • The active Cisco NAC Server performs all tasks for the system. Because most of the Server configuration is stored on the Cisco NAC Manager, when Server failover occurs, the Manager pushes the configuration to the newly-active Server.

  • The standby Cisco NAC Server does not forward any packets between its interfaces.

  • The standby Cisco NAC Server monitors the health of the active Server through a heartbeat interface (serial and one or more UDP interfaces). Heartbeat packets can be sent on the serial interface, dedicated Eth2 interface, dedicated Eth3 interface, or Eth0/Eth1 interface (if no Eth2 or Eth3 interface is available).

  • The primary and secondary Cisco NAC Servers exchange UDP heartbeat packets every two seconds. If the heartbeat timer expires, stateful failover occurs.

  • In addition to heartbeat-based failover, the Cisco NAC Server also provides link-based failover based on Eth0 or Eth1 link failure. The Server sends ICMP ping packets to an external IP address through the Eth0 and/or Eth1 interface. Failover occurs only if one Cisco NAC Server can ping the external addresses.

For more details, refer to the Cisco NAC Server documentation at Configuring High Availability.

Active Directory SingleSignOn (Active Directory SSO)

Windows active directory SSO is the ability for a Cisco NAC appliance to automatically log in users already authenticated to a backend Kerberos Domain Controller (Active Directory server). This ability eliminates the need to log into the Cisco NAC Server after you are already logged into the domain. For more details about configuring the active directory SSO on a Cisco NAC Appliance, go to Configuring Active Directory Single Sign-On.

Windows Domain Environment Considerations

In preparation for a NAC deployment, changes to the login script policy may be required. Windows login scripts can be classified as startup or shutdown and logon or logoff scripts. Windows runs startup and shutdown scripts in a “machine context.” Running the scripts only functions if the Cisco NAC appliance opens the appropriate network resources required by the script for the particular role when these scripts are executed at PC boot up or shutdown, which is typically the unauthenticated role. Logon and logoff scripts are executed in a “user context,” which means the logon script executes after the user has logged in trough Windows GINA. The logon script can fail to execute if the authentication or client machine posture assessment does not complete and network access is not granted in time. These scripts can also be interrupted by IP address refresh initiated by the Cisco NAC Agent after an OOB logon event. For more information regarding necessary changes to the login scripts, go to Windows GPO Scripts and Cisco NAC Interoperability.

Configure Cisco NAC Appliance for Agent Login and Client Posture Assessment

The Cisco NAC Agent and Cisco NAC Web Agent provide local posture assessment and remediation for client machines. Users download and install the Cisco NAC Agent or Cisco NAC Web Agent (read-only client software), which can check the host registry, processes, applications, and services. For more details about the agent and posture assessment and remediation, go to Configuring Cisco NAC Appliance for Agent Login and Client Posture Assessment.

Related Information

Updated: Sep 23, 2010
Document ID: 112169