Guest

Cisco NAC Appliance (Clean Access)

Cisco Clean Access Server and Cisco Catalyst 6500 Series Wireless LAN Services Module Integration Guide

Table Of Contents

Cisco Clean Access Server and Cisco Catalyst 6500 Series Wireless LAN Services Module Integration Guide

CCA Overview

CCA with WLSM

Guest User Design Requirements

Considerations for Implementation

Designing the Network Architecture

System Requirements

Wireless Guest Traffic Flow

Adding Clean Access Servers

Wireless Guest Traffic Flow with Clean Access Server

Configuring Catalyst 6500 Switches and WLSM

Configuring the Catalyst 6500 Wireless LAN Service Module

Configuring Cisco Aironet Access Points

Configuring Cisco Clean Access Server and Manager


Cisco Clean Access Server and Cisco Catalyst 6500 Series Wireless LAN Services Module Integration Guide


This document describes how to integrate the Cisco Clean Access (CCA) solution with the Cisco Catalyst 6500 Series Wireless LAN Services Module (WLSM) to provide public and guest Internet access management features and functionality for wired and wireless networks.

CCA Overview

The Cisco Catalyst 6500 series WLSM is part of the Catalyst 6500 series of multilayer switches. It operates as a Wireless Domain Service (WDS) device supporting Cisco Aironet access points deployed in autonomous mode.

Cisco Clean Access is a Network Admission Control (NAC) appliance solution that automatically detects, isolates, and cleans infected or vulnerable devices which are attempting to access the network. It identifies whether machines are compliant with security policies and repairs vulnerabilities before permitting access to the network.

In 2003, Cisco introduced NAC as a way for networks to make compliance with security policies a prerequisite for network access. Today, customers can choose to deploy NAC functionality in two ways:

through an industry-collaborative framework that leverages solutions of other vendors.

through the CCA product family, which combines the features of authentication, posture assessment, quarantine, and remediation into a self-contained product.

The CCA solution consists of three components:

Clean Access Server (CAS). An in-line or out-of-band device that acts as the first challenge for any end user trying to access the network. The CAS challenges the end user with a login page or requires the download of a clean access agent before permitting access to the network.

Clean Access Manager (CAM). This server manages clean access servers remotely, globally, or individually and enables administrators to establish user roles, device checks, and remediation requirements. It also acts as the authentication proxy to the authentication servers that reside on the back end.

Clean Access Agent (CAA). An optional client-side component of the clean access system. It is a read-only client that delivers device-based registry scans on unmanaged environments. This component is downloadable and provisioned over the web; in fact, customers who use the agent often require this download before network access is granted.

CCA with WLSM

CCA provides authentication, posture assessment, and remediation services when Layer 2 adjacency (such as MAC address visibility) is available. These services occur because a connection through a local switch, a connection through a trunked interface using 802.1Q, or a tunneled Layer 2 via L2TPv3 is achieved.

With Layer 3 multi-hop clients on WLSM, the CCA product provides authentication and accounting services. An example of this implementation is for guest users (such as a visitor or a trainee in a training lab). CCA provides the following key features when deployed with WLSM for guest authentication and accounting services:

Web login authentication leveraging one or more authentication servers such as RADIUS, Kerberos, LDAP, NTLM, etc.

Customizable splash web page, distinctively unique per managed subnet or VLAN or operation system

Detailed RADIUS accounting for login and logout and duration based billing

L3/L4 role based access control (RBAC) to permit guest access to specific port, protocol, or subnet

Bandwidth throttling for each guest role by assigning shared or dedicated bandwidth usage

Guest session timeout management such as 2 hours for visitor and 6 hours for trainees

Customizable URL redirection to a pre-defined page for Acceptable User Policy notice

Guest User Design Requirements

All guest wireless traffic coming into the Cat6500 from the tunnel interface is forced to go through the CAS before going anywhere else. Use VPN Routing and Forwarding (VRF) to establish a completely separate routing table where a default route points to the CAS untrusted interface.

After the guest users are authenticated either locally or using an external server (RADIUS, LDAP, Kerberos) by the CAS/CAM, the user traffic passes through the CAS to reach the outside network. Optionally, you can also set the user timeout session, bandwidth, and access control management.

Considerations for Implementation

The following design guidelines should be considered before implementation:

Use different SSIDs for employees and guest wireless users

Use 802.1X authentication and strong encryption (WPA with TKIP/MIC or WPA2 with AES) for employees

Use fast secure roaming for internal users (CCKM required, available with LEAP and EAP-FAST)

Establish open authentication for guest and broadcast the guest SSID

Use WLSM to terminate the wireless traffic on a GRE tunnel interface in the Catalyst Supervisor 720 in the Catalyst 6500 at the remote location

Specify one GRE tunnel interface per SSID

Use mobility untrusted for guest traffic to allow only clients with DHCP addresses (and not static IP addresses) to receive traffic

Apply security policies to the wireless traffic directly on the tunnel interface

Restrict traffic only from the DHCP assigned IP addresses using ACL

Limit per-user rate to restrict bandwidth

Use VPN routing and forwarding technology to forward the guest user traffic to the MDSZ interface of a firewall, bypassing the internal traffic

Designing the Network Architecture

Figure 1 shows a typical network architecture.

Figure 1 Network Architecture

System Requirements

The design requires the following equipment:

One 6503 with Sup720 PFC3B and WLSM blade

Internet access: Firewall

Cisco Clean Access Server

Cisco Clean Access Manager

Cisco Aironet access points running in autonomous mode (Cisco Aironet models: 1300, 1240 AG, 1230 AG, 1200, 1130 AG, or 1100

Cisco Aironet a/b/g client card

The following software versions are required:

Cisco IOS Release 12.2(18) SXD3 for Sup720 or later

Cisco IOS Release 1.1.2 for WLSM or later

Cisco Clean Access Server 3.4.3 or later

Cisco Clean Access Manager 3.4.3 or later

Wireless Guest Traffic Flow

The following process is followed in a wireless guest traffic flow.

1. Wireless traffic is terminated at the GRE tunnel interface.

2. (Optional) Rate limit is applied using Netflow QoS.

3. Using VPN Routing and Forwarding (VRF) instance, "guest#1" packets are routed to the inside interface of the CAS.

4. Traffic is sent from the CAS to the DMZ-guest interface of the firewall.

5. Security policy is added at the firewall so guest traffic is only directed to the outside and blocked from entering the intranet.

Adding Clean Access Servers

The following section explains how to add clean access servers. The clean access solution has three deployment methods in the in-band solution.

1. Virtual Gateway: If you configure CAS as the virtual gateway, it acts as a pass through device, and no routing and DHCP changes are needed in the network. This is the quickest and easiest deployment.

2. Real-IP Gateway: The CAS is the gateway for all end users and it handles all routing for that side of the network. The CAS can be the DHCP server and can hand out IP addresses or be a DHCP relay and keep all IP information the same.

3. NAT Gateway: The same as Real-IP where the CAS uses network address translation (NAT). All addresses appear on the untrusted side.

In the WLSM solution, the Real-IP gateway deployment method is used, and the CAS server acts as a DHCP relay.

Wireless Guest Traffic Flow with Clean Access Server

The guest traffic is forwarded to the clean access server by the following process.

1. The traffic is forwarded to the inside interface of the clean access server.

2. Policies are applied.

3. Traffic is redirected (if needed).

4. Traffic is routed through the outside interface of the clean access server to the DMZ interface of the firewall and then to the internet.

5. Firewall policies are applied.

6. Traffic is sent to the internet.

The reverse path is followed for the returning traffic.

Configuring Catalyst 6500 Switches and WLSM

The following example code shows how to configure Catalyst 6500 switches and wireless LAN service modules.

sup720#sh run
Building configuration...

Current configuration : 8511 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service counters max age 10
!
hostname sup720
!
boot system flash sup-bootflash:s72033-jk9sv-mz.122-18.SXD3.bin
!
wlan module 3 allowed-vlan 20
vtp mode transparent
ip subnet-zero
!         
!
no ip domain-lookup
ip dhcp excluded-address 172.16.10.1 172.16.10.20
!
ip dhcp pool mobile
   network 172.16.10.0 255.255.255.0
   option 150 ip 10.1.21.5 
   default-router 172.16.10.1 
   dns-server 171.70.168.183 
!
ip dhcp snooping
ip vrf guest#1
 rd 1:100
!
vlan 9-14,16-18,20-21,50,80,90,100,105,110-113,115,120,200,210 
!
interface Loopback1
description source_of_tunnel_1
 ip address 10.100.10.10 255.255.255.0
!
interface Loopback4
 ip address 10.100.40.10 255.255.255.0
!
!
Create the mGRE tunnel interface for the "guest" Mobility Group. All data to and from 
wireless guest SSID will be sent/received over this interface. This interface is placed in 
the VRF "guest#1".
!
interface Tunnel1
 description Guest tunnel
 ip vrf forwarding guest#1
 ip address 172.16.10.1 255.255.255.0
 no ip redirects
 tunnel source Loopback1
 tunnel mode gre multipoint
mobility network-id 1
 mobility trust
!
!
interface FastEthernet4/44
 description connection to Cat3750
 no ip address
 switchport
 switchport access vlan 21
 switchport mode access
!
interface FastEthernet4/45
 description connection to ACS for WLSM setup
 no ip address
 switchport
 switchport mode access
!
interface Vlan1
 ip address 10.1.1.1 255.255.255.0
!
interface Vlan18
 ip vrf forwarding guest#1
 ip address 172.18.10.1 255.255.255.0
!
interface Vlan20
 description to_WLSM
 ip address 10.10.10.1 255.255.255.0
!
interface Vlan21
 description to_Cat3750
 ip address 10.1.21.1 255.255.255.0
!
router eigrp 100
 redistribute connected
 redistribute static
 network 10.0.0.0
 network 172.16.0.0
auto-summary
!
ip classless
!
The routing needed for each VRF. In this example we have used static routes but you can 
enable a routing protocol in each VRF using the command "address-family" in router 
configuration mode.
!
ip route vrf guest#1 0.0.0.0 0.0.0.0 172.18.10.2
no ip http server
!
!         
line con 0
 exec-timeout 15 15
line vty 0 4
 password cisco
 no login
!
!
end

Configuring the Catalyst 6500 Wireless LAN Service Module

The following code example shows how to configure Catalyst 6500 wireless LAN service modules.

wlsm#sh run
Building configuration...

Current configuration : 1948 bytes
!
version 12.3
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname wlsm-isg
!
enable password cisco
!
username cisco password 0 cisco
spd headroom 512
clock timezone EST -5
aaa new-model
!
!
aaa group server radius rad-peap
 server 10.1.1.11 auth-port 1645 acct-port 1646
!
aaa group server radius rad-leap
 server 10.1.1.12 auth-port 1645 acct-port 1646
!
aaa authentication login my-vty-list enable
aaa authentication login wlccp-infra group radius
aaa session-id common
ip subnet-zero
ip tftp source-interface Ethernet0/0.20
no ip domain lookup
!
!
wlan vlan 20 
 ipaddr 10.10.10.2 255.255.255.0
 gateway 10.10.10.1  
 admin
!
! 
no crypto isakmp enable
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.10.10.1
ip http server
no ip http secure-server
!
radius-server host 10.1.1.11 auth-port 1645 acct-port 1646
radius-server key cisco
radius-server vsa send accounting
!
wlccp authentication-server infrastructure wlccp-infra
wlccp authentication-server client any wlccp-infra
!
line con 0
 transport preferred all
 transport output all
line 1 3
 no exec
 transport preferred all
 transport input all
 transport output all
 flowcontrol software
line vty 0 4
 password cisco
 login authentication my-vty-list
 transport preferred all
 transport input all
 transport output all
!
end

Configuring Cisco Aironet Access Points

The following example code shows how to configure Cisco 1200 access points.

AP-1#sh run
Building configuration...

Current configuration : 4407 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname AP-1
!
logging queue-limit 100
enable secret 5 $1$NrNO$SHIs9OPkW2S9hGYDUWB/X0
enable password 7 02050D480809
!
username Cisco password 7 02250D480809
ip subnet-zero
no ip domain lookup
!
dot11 phone
dot11 arp-cache
!
bridge irb
!
!
interface Dot11Radio0
 no ip address
 no ip route-cache
 !
 ssid Guest
    vlan 11
    authentication open 
    guest-mode
    mobility network-id 1
 !
 ssid Maintenance
    vlan 14
    authentication open 
    mobility network-id 4
 !
 speed basic-11.0 12.0 18.0 24.0 36.0 48.0
 rts threshold 2312
 power local cck 50
 power local ofdm 30
 power client 100
 no preamble-short
 channel 2412
 station-role root
 no dot11 extension aironet
 l2-filter bridge-group-acl
!
interface Dot11Radio0.10
 encapsulation dot1Q 10 native
no ip route-cache
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
 bridge-group 1 spanning-disabled
!         
interface Dot11Radio0.11
 encapsulation dot1Q 11
 service-policy input voice
 service-policy output voice
 no ip route-cache
 bridge-group 11
 bridge-group 11 subscriber-loop-control
 bridge-group 11 block-unknown-source
 no bridge-group 11 source-learning
 no bridge-group 11 unicast-flooding
 bridge-group 11 spanning-disabled
!
interface Dot11Radio0.14
 encapsulation dot1Q 14
 service-policy input data
 service-policy output data
no ip route-cache
 bridge-group 14
 bridge-group 14 subscriber-loop-control
 bridge-group 14 block-unknown-source
 no bridge-group 14 source-learning
 no bridge-group 14 unicast-flooding
 bridge-group 14 spanning-disabled
!
interface FastEthernet0
 no ip address
 no ip route-cache
 duplex auto
 speed auto
!
interface FastEthernet0.10
 encapsulation dot1Q 10 native
 no ip route-cache
 bridge-group 1
 no bridge-group 1 source-learning
 bridge-group 1 spanning-disabled
!
interface FastEthernet0.11
 encapsulation dot1Q 11
 no ip route-cache
 bridge-group 11
 no bridge-group 11 source-learning
 bridge-group 11 spanning-disabled
!
interface FastEthernet0.14
 encapsulation dot1Q 14
 no ip route-cache
 bridge-group 14
 no bridge-group 14 source-learning
 bridge-group 14 spanning-disabled
!
interface BVI1
ip address 10.1.12.2 255.255.255.0
 no ip route-cache
!
ip http server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
ip radius source-interface BVI1 
bridge 1 route ip
!
!
wlccp ap username test password 7 01100F175804
wlccp ap wds ip address 10.10.10.2
!
line con 0
line vty 0 4
 login local
line vty 5 15
 login
!
end

AP-1# 

Configuring Cisco Clean Access Server and Manager

After you have configured the network to route all guest traffic to the CAS, you can authenticate the guest users using the CAS. The configuration is performed with the CAM. You configure the user management locally on the CAM. For CAS configuration, you must connect to the server by clicking Manage on the Clean Access Servers window (see Figure 2) and follow the steps below.

Figure 2 Clean Access Servers > Manage


Step 1 In order for the CAS to operate with WLSM, configure the server to operate in L3 mode by defining CAS. Choose Real-IP Gateway at the Clean Access Server type parameter (see Figure 3).

Figure 3 Real IP Gateway

Step 2 Enter the DNS server's IP address.

Step 3 Create the local database in the CAM by navigating to User Management > Local Users.

Step 4 Create the roles by choosing User Roles from the User Management Options on the left (see Figure 4).

Figure 4 User Roles

Step 5 To create a guest role, enter guest role in the Role Name field and create a redirect upon login that returns to www.cisco.com/HR (see Figure 5).

Figure 5 Guest Role

Step 6 Assign the users to different roles (see Figure 6) like guest or test user by editing the user.

Figure 6 Assigning Different Roles

Step 7 Create the guest portal page (see Figure 7).

Figure 7 Creating the Guest Portal

Step 8 To change the default login page for guest users, add Managed Subnet under CCA Servers > Manage > Network. Create a default route to get packets back to the Catalyst WLSM from subnet 172.16.10.x through the untrusted interface (see Figure 8).

Figure 8 Managed Subnet

Step 9 After users are successfully logged on, choose Online Users from the Monitoring options on the left.

Step 10 Choose the Display Settings tab to add additional information such as login time, OS, role, etc.