Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide, Release 4.1(8)
Configuring the CAS Managed Network
Downloads: This chapterpdf (PDF - 1.57MB) The complete bookPDF (PDF - 11.82MB) | Feedback

Configuring the CAS Managed Network

Table Of Contents

Configuring the CAS Managed Network

Overview

Add the CAS to the CAM

Add New Server

IP Addressing Considerations

Additional Notes for Virtual Gateway with VLAN Mapping (L2 Deployments)

List of Clean Access Servers

Configure Clean Access Server-to-Clean Access Manager Authorization

Summary of Steps to Configure Clean Access Server-to-Clean Access Manager Authorization

Enable Authorization and Specify the Authorized Clean Access Manager

Troubleshooting when Adding the Clean Access Server

Configure Network Settings for the CAS

Navigating the CAS Management Pages

IP Form

Change Clean Access Server Type

Switching Between NAT and Real-IP Gateway Modes

Switching Between Virtual Gateway and NAT/ Real-IP Gateway Modes

Enable Network Access (L3, L3 Strict or L2 Strict)

Enable L3 Support

Enable L3 Strict Mode

Enable L2 Strict Mode

Connecting to the CAS Using the SWISS Protocol

What is the SWISS Protocol?

Discovery Host

VPN SSO Considerations

Overcoming Network Latency Issues That Can Delay Discovery

Layer 3 SWISS Packet Delay to Conserve Bandwidth

Supporting Multiple Active NICs on the Clean Access Agent Client Machine

Configure DHCP

Configure DNS Servers on the Network

Configuring Managed Subnets or Static Routes

Overview

Configure Managed Subnets for L2 Deployments

Adding Managed Subnets

Configure Static Routes for L3 Deployments

Configuring Static Routes for Layer 2 Deployments

Add Static Route

Configure ARP Entries

Add ARP Entry

Understanding VLAN Settings

Enable Subnet-Based VLAN Retag in Virtual Gateway Mode

VLAN Mapping in Virtual Gateway Modes

Native VLAN, Management VLAN, Dummy VLAN

VLAN Mapping for In-Band

VLAN Mapping for Out-of-Band

Switch Configuration for Out-of-Band Virtual Gateway Mode

Configure VLAN Mapping

Local Device and Subnet Filtering

Configure Local Device Access Filter Policies

View Active L2 Device Filter Policies

Configure Subnet Access Filter Policies

CAS Fallback Policy

Configuring CAS Fallback

NAT Session Throttle

Configure 1:1 Network Address Translation (NAT)

Configure 1:1 NATing

Configure 1:1 NATing with Port Forwarding

Configure Proxy Server Settings on the CAS


Configuring the CAS Managed Network


This chapter describes how to set up the Clean Access Server's managed domain. Topics include:

Overview

Add the CAS to the CAM

Configure Network Settings for the CAS

Connecting to the CAS Using the SWISS Protocol

Configure DHCP

Configure DNS Servers on the Network

Configuring Managed Subnets or Static Routes

Configure ARP Entries

Understanding VLAN Settings

VLAN Mapping in Virtual Gateway Modes

Local Device and Subnet Filtering

CAS Fallback Policy

NAT Session Throttle

Configure 1:1 Network Address Translation (NAT)

Configure Proxy Server Settings on the CAS

Overview

After installing the Clean Access Server, it needs to be added to the Clean Access Manager's domain. You can then configure the Clean Access Server's managed (untrusted) network.

Configuring the Clean Access Server managed network involves setting up passthrough policies, specifying managed subnets (subnets you want to manage that are not within the address space specified at the untrusted network interface), setting up static routes, along with other tasks described here.

Add the CAS to the CAM

This section describes the following topics:

Add New Server

IP Addressing Considerations

Additional Notes for Virtual Gateway with VLAN Mapping (L2 Deployments)

List of Clean Access Servers

Configure Clean Access Server-to-Clean Access Manager Authorization

Troubleshooting when Adding the Clean Access Server

The Clean Access Server gets almost all of its runtime parameters from the Clean Access Manager, and cannot operate unless it is added to the domain of a Clean Access Manager. Once it is added to the CAM, the CAS can be configured and monitored through the admin console.

Add New Server


Note If intending to configure the Clean Access Server in Virtual Gateway mode (IB or OOB), you must disable or unplug the untrusted interface (eth1) of the CAS until after you have added the CAS to the CAM from the web admin console. Keeping the eth1 interface connected while performing initial installation and configuration of the CAS for Virtual Gateway mode can result in network connectivity issues.

For Virtual Gateway with VLAN mapping (In-Band or OOB), the untrusted interface (eth1) of the CAS should not be connected to the switch until VLAN mapping has been configured correctly under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > VLAN Mapping.
See Additional Notes for Virtual Gateway with VLAN Mapping (L2 Deployments) for details.


1. Open a web browser and type the IP address of the CAM as the URL to access the CAM web admin console.

2. Go to the Device Management module and click CCA Servers.

3. Click the New Server tab to add a new CAS.

Figure 5-1 New Server

4. In the Server IP address field, type the IP address of the Clean Access Server's eth0 trusted interface.


Note The eth0 IP address of the CAS is the same as the Management IP address.


5. The Server Type dropdown menu determines whether the Clean Access Server operates as a bridge or a gateway. For in-band operation, choose one of the following CAS operating modes as appropriate for your environment:

Virtual Gateway—CAS operates as a bridge between the untrusted network and an existing gateway


Note See Additional Notes for Virtual Gateway with VLAN Mapping (L2 Deployments).


Real-IP Gateway—CAS operates as a gateway for the untrusted network

NAT Gateway—CAS operates as a gateway and performs NAT services for the untrusted network


Note NAT Gateway mode is primarily intended to facilitate testing, as it requires the least amount of network configuration and is easy to initially set up. However, because it is limited in the number of connections it can handle, NAT Gateway mode (in-band or out-of-band) is not supported for production deployment. See Configuring the CAS Behind a NAT Firewall, page 4-23 and NAT Session Throttle for additional details.


6. The Out-of-Band Server Types appear in the dropdown menu when you apply an OOB-enabled license to a Clean Access deployment. For OOB, the CAS operates as a Virtual, Real-IP, or NAT Gateway while client traffic is in-band (in the Clean Access network) during authentication and certification. Once clients are authenticated and certified, they are considered "out-of-band" (no longer passing through the Clean Access network) and allowed directly onto the trusted network. Choose one of the following operating modes for the CAS:

Out-of-Band Virtual Gateway—CAS operates as a Virtual Gateway during authentication and certification, before the user is switched out-of-band (i.e., the user is connected directly to the access network).

Out-of-Band Real-IP Gateway—CAS operates as a Real-IP Gateway during authentication and certification, before the user is switched out-of-band (i.e., the user is connected directly to the access network).

Out-of-Band NAT Gateway—CAS operates as a NAT Gateway during authentication and certification, before the user is switched out-of-band (i.e., the user is connected directly to the access network).


Note NAT Gateway (in-band or out-of-band) is not supported for production deployment.


Note that the CAM can control both in-band and out-of-band Clean Access Servers in its domain. However, the CAS itself must be either in-band or out-of-band.

For details on in-band operating modes, see Clean Access Server Operating Modes, page 2-1. For details on OOB operating modes, see "Switch Management and Configuring Out-of-Band (OOB) Deployment" in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8).

7. Click Add Clean Access Server. The Clean Access Manager looks for the CAS on the network, and adds it to its list of managed Clean Access Servers.

IP Addressing Considerations


Noteeth0 and eth1 generally correlate to the first two network cards—NIC 1 and NIC 2—on most types of server hardware.

For Virtual Gateway (IB or OOB), do not connect the untrusted interface (eth1) of the CAS to the switch until after the CAS has been added to the CAM via the web console, and VLAN mapping has been configured correctly under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > VLAN Mapping.


Real-IP Mode:

The trusted (eth0) and untrusted (eth1) interfaces of the CAS must be on different subnets.

You must add static routes on the L3 switch or router to route traffic for the managed subnets to the trusted interface of the respective CASs.

If using DHCP relay, make sure the DHCP server has a route back to the managed subnets.

NAT Gateway Mode:

The trusted (eth0) and untrusted (eth1) interfaces of the CAS must be on different subnets.

Virtual Gateway Mode:

The CAS and CAM must be on different subnets (or VLANs).

The trusted (eth0) and untrusted interfaces (eth1) of the CAS can have the same IP address.
(Note: this is equivalent to an L3 switched virtual interface (SVI) IP address)

All end devices in the bridged subnet must be on the untrusted side of the CAS.

Managed subnets must be configured on the CAS for all the user subnets that are managed by the CAS. When configuring the Managed subnet, make sure that you type an unused IP address in that subnet (for the CAS to use), and not a subnet address.

The CAS is automatically configured for DHCP Passthrough when set to Virtual Gateway mode.

Traffic from clients must pass through the CAS before hitting the gateway.

OOB Virtual Gateway Mode:

When the CAS is an OOB VGW, the following also applies:

The CAS interfaces must be on a separate subnet (or VLAN) from the CAM.

The CAS management VLAN must be on a different VLAN than the user or Access VLANs.

Additional Notes for Virtual Gateway with VLAN Mapping (L2 Deployments)

1. There should be a management VLAN setting on the CAS IP page (and in your network configuration) to allow communication to the CAS's trusted and untrusted IP addresses.

2. The Native VLAN ID on the switch ports to which CAS eth0 and eth1 are connected should ideally be two otherwise unused VLAN IDs (e.g. 999, 998). Choose any two VLAN IDS from a range that you are not using anywhere on your network.

3. Do not connect eth1(untrusted interface) of the CAS until after you have configured and enabled VLAN Mapping entries in the CAS (under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > VLAN Mapping). See Configure VLAN Mapping for detailed steps.


Caution To avoid switch errors, make sure to correctly set VLAN Mapping in the CAS before connecting the eth1 interface of the CAS. Failure to do so could cause spanning tree loops and shut down the switch.


Note The Clean Access Server needs to receive Ethernet frames and only supports Ethernet as the LLC (Logical Link Control) protocol. For any non-IP protocol, such as SNA or IPX, the CAS can support it only if Ethernet is used as the LLC protocol, the CAS is a Virtual Gateway, and there is no VLAN mapping (i.e. the CAS is in Edge Deployment mode).


List of Clean Access Servers

Once you add the CAS to the Clean Access Manager, the CAS appears in the List of Servers tab.

Figure 5-2 List of Servers

Each Clean Access Server entry lists the IP address, server type, location, and connection status of the CAS. In addition, four management control icons are displayed: Manage, Disconnect, Reboot, and Delete. You access the management pages of a Clean Access Server by clicking the Manage icon next to the CAS.

Configure Clean Access Server-to-Clean Access Manager Authorization

When you add Clean Access Servers to the CAM, you can also choose to enable mutual Authorization between the appliances to enhance network security.

Using the CAM Authorization web console page, administrators can enter the Distinguished Names (DNs) of one or more CASs to ensure secure communications between the CAM and CAS(s). Once you enable the Authorization feature and add one or more CASs to the Authorized CCA Servers list, the CAM does not accept communications from CASs that do not appear in the list. Therefore, when you choose to employ and enable this feature in your network, you must add all of your managed CASs to the Authorized CCA Servers list to ensure you maintain CAM-CAS connection for all of the CASs in your network.

Likewise, you must also enable this feature and specify a CAM DN on all of the CASs in your network to establish two-way authorization between the CAMs/CASs.


Note Administrators should expect a few minutes of downtime when updating Trusted CAs on the CAS, as updating certificate information restarts services. This is due to the fact that, starting from release 4.1(6), the CAM/CAS use mutual authentication to communicate back and forth and although you are no longer required to reboot the CAS when you change the certificate or import new Trusted CAs, the CAM-to-CAS connections are still "reset" to ensure network security. Therefore, Cisco recommends performing this type of action during periods of very low Cisco NAC Appliance network traffic.


If you have deployed your CAMs/CASs in an HA environment, you can enable authorization for both the HA-Primary and HA-Secondary machines in the HA pair by specifying the DN of only the HA-Primary appliance. For example, if the CAM manages a CAS HA pair, you only need to list the HA-Primary CAS on the CAM's Authorization page. Likewise, if you are enabling this feature on a CAS managed by a CAM HA pair, you only need to list the HA-Primary CAM on the CAS's Authorization page.)

Summary of Steps to Configure Clean Access Server-to-Clean Access Manager Authorization

1. Configure CAS Authorization on the CAM web console under Device Management > Clean Access Servers > Authorization (see Enable Authorization and Specify the Authorized Clean Access Manager).

2. Configure CAM Authorization on the CAS web console under Administration > Authorization (see the "Enable Authorization and Specify Authorized Clean Access Servers" section in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8)).

3. Before deploying in a production environment, obtain trusted CA-signed certificates for CAM and CAS and import them to CAM/CAS under Administration > SSL > Trusted Certificate Authorities (for CAM), and Administration > SSL > Trusted Certificate Authorities (for CAS).


Warning If your previous deployment uses a chain of SSL certificates that is incomplete, incorrect, or out of order, CAM/CAS communication may fail after upgrade to release 4.1(6) and later. You must correct your certificate chain to successfully upgrade to release 4.1(6) and later. For details on how to fix certificate errors on the CAM/CAS after upgrade to release 4.1(6) and later, refer to the How to Fix Certificate Errors on the CAM/CAS After Upgrade Troubleshooting Tech Note.


4. If you are upgrading your Cisco NAC Appliance release, clean up Trusted Certificate Authorities on the CAM under Administration > CCA Manager > SSL > Trusted Certificate Authorities, and on the CAS under Administration > SSL > Trusted Certificate Authorities (see View and Remove Trusted Certificate Authorities, page 12-19 and the "View and Remove Trusted Certificate Authorities" section in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8), respectively).


Note If you use the Authorization feature in a CAS HA-pair, follow the guidelines in "Backing Up and Restoring CAM/CAS Authorization Settings" in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8) to ensure you are able to exactly duplicate your Authorization settings from one CAS to its high availability counterpart.


Enable Authorization and Specify the Authorized Clean Access Manager

To enable authorization and specify the CAM authorized to communicate with your CAS:


Step 1 Open a web browser and type the IP address of the CAS's trusted (eth0) interface in the URL/address field (https://<CAS_eth0_IP_address>/admin). For example:

https://172.16.1.2/admin

Step 2 Go to Administration > Authorization (Figure 5-3).

Figure 5-3 Administration > Authorization

Step 3 Click the Enable CCA Server Authorization to turn on the Cisco NAC Appliance authorization feature.


Warning Do not click the Enable CCA Server Authorization option without also entering one or more full distinguished names of CAMs you want to authorize to communicate securely with the CAS. If you enable this feature and have not specified any CAM distinguished names, you will not be able to communicate with any of the CAMs in your network.


Step 4 Click the plus icon "+" and enter the full distinguished name of the CAM you want to authorize to communicate securely with the CAS. For example, enter a text string like "CN=110.21.2.123, OU=cca, O=cisco, L=sj, ST=ca, C=us" in the Distinguished Name field.


Note Distinguished names require exact syntax. Therefore, Cisco recommends copying the CAM DN from the bottom portion of the Administration > CCA Manager > SSL > X509 Certificate CAM web console page and pasting it into the CAS's Authorization page to ensure you specify the exact name for the CAM on the CAS.


Step 5 Click Update to ensure the CAM you have added is authorized to communicate back-and-forth with the CAS.

When you click Update, the CAS restarts services between the CAS and CAM in the Authorized CCA Manager list, which may cause brief network interruptions to users logged into the Cisco NAC Appliance system.


Troubleshooting when Adding the Clean Access Server

If the Clean Access Server cannot be added to Clean Access Manager, check the following:

1. Ping connectivity from the CAS to the CAM and from the CAM to the CAS.

a. If the CAS is not pingable, network settings may be incorrect. Reset them using service perfigo config. See CAS CLI Commands, page 4-19 for details.

b. If the CAS is pingable but cannot be added to the CAM:

Physically disconnect the eth1 interface of the CAS.

Wait 2 minutes, then add the CAS again from the CAM web console.

When the CAS is successfully added, physically connect the eth1 interface of the CAS.

2. SSH from the CAM to the CAS and from the CAS to the CAM and check for any errors.

3. Check the shared secret key on both the CAM and CAS under: cat /root/.secret. If this is the problem, reset the shared secret with service perfigo config.

4. Check the SSL certificates. For details, see Typical SSL Certificate Setup on the CAS, page 12-10 and Troubleshooting Certificate Issues, page 12-34 in this guide, and the corresponding sections of the CAS guide.

5. Check the product license. Make sure you have a license for OOB if using OOB. If running OOB, the "Switch Management" module will be present in left hand pane of the web admin console. When upgrading, your previous license must already enable OOB, or you must obtain a new license to use OOB features. See Product Licensing and Service Contract Support, page 1-5.

6. Check the date/time on both the CAM and CAS via SSH. The date/time difference cannot be more than 3 minutes.

To check the time on the CAS/CAM, issue: date

To change the time on the CAS/CAM, issue: service perfigo time

7. If the CAS is a Virtual Gateway, make sure the CAM and CAS are on different subnets (or VLANs).

8. If the CAS is a Virtual Gateway, and both ports of the CAS are connected to the same switch:

a. Physically disconnect the eth1 interface of the CAS.

b. Configure VLAN mapping (under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > VLAN Mapping).

c. Wait 2 minutes.

d. Physically connect the eth1 interface of the CAS.

9. Check the CAM Event Log (under Monitoring > Event Logs). This can help pinpoint license and other issues.

10. Make sure there are no firewall rules blocking RMI ports (see CAM/CAS Connectivity Across a Firewall, page 4-23 for details):

11. Perform service perfigo restart on both the CAM and CAS.

12. Perform service perfigo reboot on both CAM and CAS.

13. Contact TAC. See Obtaining Documentation and Submitting a Service Request, page -xvii.

For further details on disconnecting, rebooting or deleting a Clean Access Server see "Working with Clean Access Servers" in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8).

Configure Network Settings for the CAS

This section describes the following:

Navigating the CAS Management Pages

IP Form

Change Clean Access Server Type

Enable L3 Support

Navigating the CAS Management Pages

When you click the Manage icon for a Clean Access Server in the List of Servers tab, the Clean Access Server management pages appear with a default view of the CAS Status tab, as shown in Figure 5-4.

Figure 5-4 Clean Access Servers Management Pages

The tabs in the Clean Access Server management pages are as follows:

Status—Status of Clean Access Server modules (Started or Stopped)

Network—Operating mode and interface settings (IP address, VLAN, L2/L3) for the CAS itself, DNS settings, SSL certificate management, and DHCP configuration for managed subnets.

Filter—Local (per CAS) device and subnet access policies, local traffic control and bandwidth policies (by role), and local Certified Device and Floating Device lists.

Advanced—Routing settings for the CAS, such as Managed Subnets (L2) or Static Routes (L3), VLAN mapping for Virtual Gateways, NAT, 1:1 NAT, ARP, and Proxy server settings.

Authentication—Enable and configuration settings for local login page, OS detection, VPN concentrator SSO and Windows AD SSO.

Misc—CAS software upgrade, system time, and heartbeat timer for all users.

Within each tab, click the submenu links to access individual configuration forms.

IP Form

The IP form in the Network tab (Figure 5-5) contains the network settings of the CAS configured at initial installation (or using the service perfigo config utility), as well as the CAS operating mode chosen when the CAS was added to the CAM. You must use the IP form to configure the CAS for L3 or L2 strict deployment, and you can use this form to view or change the IP address and network settings of the CAS as described below.

1. Access the IP form by navigating in the web console to Device Management > CCA Servers > List of Servers > Manage [CAS_IP] > Network > IP.

Figure 5-5 CAS Network IP Settings

2. The CAS IP form includes the following settings:

Clean Access Server Type—This is the operating mode of the CAS, set when you Add the CAS to the CAM. See Change Clean Access Server Type for additional details.

In-Band: Virtual Gateway, Real-IP Gateway, or NAT Gateway

OOB: Out-of-Band Virtual Gateway, Out-of-Band Real-IP Gateway, Out-of-Band NAT Gateway


Note NAT Gateway (in-band or out-of-band) is not supported for production deployment.


Enable L3 support—When this option is enabled, the CAS allows all users from any hops away. For multi-hop L3 in-band deployments, this setting enables/disables L3 discovery of the CAS for web login users and Clean Access Agent/Cisco NAC Web Agent users at the CAS level. When set, the CAS is forced to use the routing table to send packets. See Enable L3 Support for details.

Enable L3 strict mode to block NAT devices with Clean Access Agent—When this option is checked (in conjunction with "Enable L3 support"), the CAS verifies the source IP address of user packets against the IP address sent by the Clean Access Agent/Cisco NAC Web Agent and blocks all L3 Agent users with NAT devices between those users and the CAS. See Enable L3 Strict Mode for details.

Enable L2 strict mode to block L3 devices with Clean Access Agent—When this option is enabled, the CAS verifies the source MAC address of user packets against the MAC address sent by the Clean Access Agent/Cisco NAC Web Agent and blocks all L3 Agent users (those more than one hop away from the CAS). The user is forced to remove any router between the CAS and the user's client machine to gain access to the network. See Enable L2 Strict Mode for details.

All L3 or L2/L3 strict options left unchecked (Default setting)—The CAS performs in L2 mode and expects that all clients are one hop away. The CAS will not be able to distinguish if a router is between the CAS and the client and will allow the MAC address of a router as the machine of the first user who logs in and any subsequent users. Checks will not be performed on the actual client machines passing through the router as a result, as their MAC addresses will not be seen.


NoteIf using L2 deployment only, make sure the Enable L3 support option is not checked.

L3 and L2 strict options are mutually exclusive; enabling one option disables the other.

Enabling or disabling L3 or L2 strict mode always requires an Update and Reboot of the CAS to take effect. Update causes the web console to retain the changed setting until the next reboot. Reboot causes the process to start in the CAS.


Platform—The platform type for the CAS. This setting reads "APPLIANCE" if the CAS is a standard Clean Access Server appliance, or "NME-NAC" if the CAS is a Cisco NAC network module installed in a Cisco ISR router chassis.

For more information on the Cisco NAC network module, see the Cisco NAC network module information included in Cisco NAC Appliance Hardware Platforms, page 1-5.

For detailed installation and configuration information, see Getting Started with NAC Network Modules in Cisco Access Routers and Installing Cisco Network Modules in Cisco Access Routers.


Note You can also determine the CAS platform type using the CAS service perfigo platform CLI command. See Table 4-1 on page 4-20 for more information.


Trusted InterfaceThe trusted interface (eth0) connects the CAS to the trusted backend network.

IP Address: The IP address of the trusted (eth0) interface of the CAS.

Subnet Mask: The subnet mask for the trusted interface.

Default Gateway:

For Real-IP Gateway—This is the address of the default gateway on the trusted network, such as a network central router address.

For Virtual Gateway—This is the address of the existing gateway on the trusted network side of the CAS.

Set management VLAN ID: When set at the trusted interface, the specified VLAN ID is added to packets destined to the trusted network.


Note See also Native VLAN, Management VLAN, Dummy VLAN for additional information needed for Virtual Gateway.


Pass through VLAN ID to managed network: If selected, VLAN IDs in the packets are passed through the interface unmodified.

Untrusted Interface—The untrusted interface (eth1) connects the CAS to the untrusted managed network.

IP Address: The IP address of the untrusted (eth1) interface of the CAS.

Subnet Mask: The subnet mask for the untrusted interface.

Default Gateway:

For Real-IP Gateway—The default gateway is the untrusted interface IP address of the CAS.

For Virtual Gateway—The default gateway is the address of the existing gateway on the trusted network side of the CAS.

Set management VLAN ID: When set at the untrusted interface, the specified VLAN ID is added to packets destined to clients.

Pass through VLAN ID to managed network: If selected, VLAN IDs in the packets are passed through the interface unmodified.

3. After modifying settings, click Update and Reboot.
Update causes the web console to retain the changed setting until the next reboot.
Reboot causes the process to start in the CAS. The CAS will restart with the new settings.


Note Modified CAS IP settings always require an Update and Reboot of the CAS to take effect.



Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time/time zone, DNS, or Service IP. See Clean Access Server Direct Access Web Console, page 12-2 and Modifying High Availability Settings, page 13-26 for details.



Note If you do not have a CA-signed certificate based on the DNS name of the CAS, when changing the IP address of the CAS, you must also regenerate the certificate as described in Manage CAS SSL Certificates, page 12-5.


Change Clean Access Server Type

When you add the CAS to the Clean Access Manager, you specify its operating mode: In-Band or Out-of-Band Real-IP, NAT, or Virtual Gateway. This section describes how to change the Server Type of the CAS after it has been added to the CAM as a different operating mode.


Note You must have an OOB-enabled license to change the CAS from In-Band to Out-of-Band mode.


Switching Between NAT and Real-IP Gateway Modes

To switch between NAT and Real-IP Gateway modes:

Make the necessary configuration changes within the CAM admin console (for example, choose the type in the IP form, configure NAT behavior and DHCP properties, etc.)

Ensure the CAS eth1 interface IP address and all assignable DHCP addresses (if used) are routable

If you have two CASs configured in an HA deployment, after you make necessary configuration changes, be sure to reboot the HA-Primary CAS, then reboot the HA-Secondary CAS

Switching Between Virtual Gateway and NAT/ Real-IP Gateway Modes

To switch between Virtual and Real-IP/NAT Gateway modes, you will need to change the topology of the network to reflect the modification. You must also modify the routing table on the upstream router to reflect the change. For more information on possible topology changes that are required, see Chapter 2, "Planning Your Deployment." The general steps for switching between these types are:

1. Delete the CAS from the list of managed Clean Access Servers in the CAM.

2. Modify the network topology as appropriate. Change the cable connections to the CAS, if needed.

3. Access the CAS via SSH console and execute the service perfigo config utility to change the IP address of the CAS (see Perform the Initial Configuration, page 4-10). You must change the eth1 IP address of the CAS.

4. Ping the CAS from the CAM's subnet to make sure that the topology is correctly changed.

5. Add the CAS in the CAM admin console.

6. Add or re-add managed subnets with the address that the CAS will represent. The managed subnet entries must specify the CAS as the default gateway for each of the managed subnets.

7. Add static routes in the upstream router for the subnets managed by the CAS.

8. Change the CAS configuration on the CAM from the Device Management > CCA Servers > Manage [CAS_IP]> Network page, and Update and Reboot the CAS.

9. Set up the CAS as either a DHCP server or relay.

10. Update relevant configuration settings such as certificates.

11. If changing to an Out-of-Band Real-IP Gateway, make sure to enable Port Bouncing (Switch Management > Profiles > Port | Bounce the port after VLAN is changed) to help Real-IP or NAT gateway clients get a new IP address after successful authentication and certification.


Note If using the 4.1.2.0 and later Windows Clean Access Agent, ActiveX Control, or Java Applet to refresh client DHCP IP addresses, the Bounce the switch port after VLAN is changed option in the Port profile can be left disabled. If you use this method, be sure to follow the guidelines and warnings detailed in the "DHCP Release/Renew with Agent/ActiveX/Java Applet," "Configuring Access to Authentication VLAN Change Detection," and "Advanced Settings" sections of the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8).


Enable Network Access (L3, L3 Strict or L2 Strict)

By default, Cisco NAC Appliance supports in-band web login and Clean Access Agent and Cisco NAC Web Agent users within L2 proximity of the Clean Access Server.

For L2 deployments, you can optionally restrict L2 access so that Agent users cannot use home-based wireless routers or NAT devices to connect to the network.

If deploying for VPN/L3, you must enable L3 support for web login or Agent users that are multiple L3 hops away from the CAS.

You can additionally enable the "L3 strict" option, in conjunction with L3 support, to restrict L3 Clean Access Agent/Cisco NAC Web Agent clients from connecting to the Clean Access Server through NAT devices.

For L2 discovery, the Clean Access Agent sends SWISS discovery packets to all the default gateways of all the adapters on the machine on which the Clean Access Agent is running. If a CAS is present either as the default gateway (Real-IP/NAT Gateway) or as a bridge before the default gateway (Virtual Gateway), the CAS will respond.


Note This function does not apply to the Cisco NAC Web Agent.


If the CAS does not respond via L2 discovery, the Clean Access Agent will perform L3 discovery (if enabled). The Clean Access Agent attempts to send packets to the Discovery Host, an IP address on the trusted side of the CAS. This IP address is set in the Discovery Host field of the Installation page and is set by default to the IP address of the CAM (which is always assumed to be on the trusted side of the CAS). When these packets reach a CAS (if present), the CAS intercepts the packets and responds to the Clean Access Agent.


Note To discover the CAS, the Clean Access Agent sends SWISS (proprietary CAS-Agent communication protocol) packets on UDP port 8905 for L2 users and on port 8906 for L3 users. The CAS always listens on UDP port 8905 and 8906 and accepts traffic on port 8905 by default. The CAS will drop traffic on UDP port 8906 unless L3 support is enabled.The Clean Access Agent performs SWISS discovery every 5 seconds.



Note As a best practice recommendation, when users are L2 adjacent to the CAS, Cisco recommends using the Enable L2 strict mode to block L3 devices with the Agent. It is possible for a single CAS to support both L3 and L2 (non-restricted) Agent users. However, L2 strict mode and L3 support are mutually exclusive. Therefore, Cisco recommends against using the same CAS for L2 and L3 in-band deployment.


Enable L3 Support

To support multi-hop L3 deployments, you need to enable L3 support on each CAS. L3 support is disabled by default after upgrade or new install, and enabling L3 support requires an update and reboot of the Clean Access Server.

To Enable L3 Support:

1. Go Device Management > CCA Servers > Manage [CAS_IP] > Network and click the checkbox for "Enable L3 support" (see Figure 5-5).

2. Click Update.

3. Click Reboot.


Note For Clean Access Agent and Cisco NAC Web Agent users, the Discovery Host field (under Device Management > Clean Access > Clean Access Agent > Installation) automatically populates with the IP address of the CAM by default after new install or upgrade.


To Disable L3 Capability:

To disable L3 discovery of the Clean Access Server at the CAS level for web login and Clean Access Agent/Cisco NAC Web Agent users:

1. Go Device Management > CCA Servers > Manage [CAS_IP] > Network and uncheck the option for "Enable L3 support" (see Figure 5-5).

2. Click Update.

3. Click Reboot.

VPN/L3 Access for Agents

The Clean Access Manager, Clean Access Server, and Clean Access Agent/Cisco NAC Web Agent support multi-hop L3 deployment. The Agent:

1. Checks the client network for the Clean Access Server (L2 deployments), and if not found,

2. Attempts to discover the CAS by sending discovery packets to the CAM. This causes the discovery packets to go through the CAS even if the CAS is multiple hops away (multi-hop deployment) so that the CAS will intercept these packets and respond to the Agent.

In order for clients to discover the CAS when they are one or more L3 hops away, clients must initially download the Clean Access Agent from the CAS through the Download Clean Access Agent page after web login or through auto-upgrade. Either method allows the Agent to acquire the IP address of the Discovery Host (by default, the CAM) in order to send traffic to the CAM/CAS over the L3 network. Once installed in this way, the Agent can be used for L3/VPN concentrator deployments or regular L2 deployments. If using the or Cisco NAC Web Agent, clients must launch the Agent via the Launch Cisco NAC Web Agent page after web login.

Acquiring and installing the Agent on the client by means other than direct download from the CAS will not provide the necessary Discovery information to the Agent and will not allow those Agent installations to operate in a multi-hop Layer 3 deployment.

To support VPN/L3 Access, you must:

Check the option for "Enable L3 support" and perform an Update and Reboot under Device Management > CCA Servers > Manage [CAS_IP] > Network > IP.

There must be a valid Discovery Host under Device Management > Clean Access > Clean Access Agent > Installation (set by default to the trusted IP address of the CAM).

Clients must initially download the Agent from the CAS, in one of two ways:

"Download Clean Access Agent" web page (i.e. via web login)

Auto-Upgrade to 4.1.8.0 or later Clean Access Agent

"Launch Cisco NAC Web Agent" web page

SSO is only supported when integrating Cisco NAC Appliance with Cisco VPN Concentrators.


NoteUninstalling the Agent while still on the VPN connection does not terminate the connection.

For VPN-concentrator SSO deployments, if the Agent is not downloaded from the CAS and is instead downloaded by other methods (e.g. Cisco Downloads), the Agent will not be able to get the runtime IP information of the CAM and will not pop up automatically nor scan the client.

If a 3.5.0 or prior version of the Agent is already installed, or if the Agent is installed through non-CAS means (e.g. Cisco Downloads), you must perform web login to download the Agent setup files from the CAS directly and reinstall the Agent to get the L3 capability.


Enable L3 Strict Mode

Administrators with L3 deployments can optionally restrict L3 Clean Access Agent/Cisco NAC Web Agent clients from connecting to the Clean Access Server through NAT devices using the Enable L3 strict mode to block NAT devices with Clean Access Agent option.

When this feature is enabled in conjunction with "Enable L3 support," the CAS will check the client IP information automatically sent by the Clean Access Agent against source IP information to ensure no NAT device exists between the CAS and the client. If a NAT device is detected between the client device and the CAS, the user is not allowed to log in.

This provides administrators with the following options when enabling network access for clients on the CAS:

Enable L3 support—The CAS allows all users from any hops away.

Enable L3 strict mode to block NAT devices with Clean Access Agent—When this option is checked (in conjunction with "Enable L3 support"), the CAS verifies the source IP address of user packets against the IP address sent by the Clean Access Agent and blocks all L3 Agent users with NAT devices between those users and the CAS.

Enable L2 strict mode to block L3 devices with Clean Access Agent—When this option is enabled, the CAS verifies the source MAC address of user packets against the MAC address sent by the Clean Access Agent and blocks all L3 Agent users (those more than one hop away from the CAS). The user will be forced to remove any router between the CAS and the user's client machine to gain access to the network.

All options left unchecked (Default setting)—The CAS performs in L2 mode and expects that all clients are one hop away. The CAS will not be able to distinguish if a router is between the CAS and the client and will allow the MAC address of router as the machine of the first user who logs in and any subsequent users. Checks will not be performed on the actual client machines passing through the router as a result, as their MAC addresses will not be seen.

Enable L2 Strict Mode

Administrators can optionally restrict Clean Access Agent/Cisco NAC Web Agent clients to be connected to the Clean Access Server directly as their only gateway using the Enable L2 strict mode to block L3 devices with Clean Access Agent option.

When this feature is enabled, the Clean Access Agent will send the MAC addresses for all interfaces on the client machine with the login request to the CAS. The CAS then checks this information to ensure no NAT exists between the CAS and the client. The CAS verifies and compares MAC addresses to ensure that the MAC address seen by the CAS is the MAC address of the Agent client machine only. If user home-based wireless routers or NAT devices are detected between the client device and the CAS, the user is not allowed to log in.

To Enable L2 strict mode to block L3 devices with Clean Access Agent

1. Device Management > CCA Servers > Manage [CAS_IP] > Network > IP. The management pages appear for the chosen Clean Access Server appear.

Figure 5-6 CAS Network Tab

2. Click the checkbox for Enable L2 strict mode to block L3 devices with Clean Access Agent.

3. Click Update.

4. Click Reboot.


NoteEnabling or disabling L3 or L2 strict mode ALWAYS requires an Update and Reboot of the CAS to take effect. Update causes the web console to retain the changed setting until the next reboot. Reboot causes the process to start in the CAS.

L3 and L2 strict options are mutually exclusive; enabling one option disables the other.


See also the "Clean Access Agent" chapter of the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8) for additional information.

Connecting to the CAS Using the SWISS Protocol

This section describes the SWISS proprietary session initiation protocol the Clean Access Agent uses to discover and initiate client machine connection to the CAS. This section contains the following topics:

What is the SWISS Protocol?

Discovery Host

VPN SSO Considerations

Overcoming Network Latency Issues That Can Delay Discovery

Layer 3 SWISS Packet Delay to Conserve Bandwidth

Supporting Multiple Active NICs on the Clean Access Agent Client Machine

What is the SWISS Protocol?

The Clean Access Agent connects to the CAS by sending SWISS unicast discovery packets out on UDP ports 8905 (Layer 2) and 8906 (Layer 3) until a CAS responds and initiates a user login session. The UDP 8905 packets are directed to the client machine's default gateway and the UDP 8906 packets are directed to the IP address configured in the CAMs Discovery Host field (Device Management > Clean Access > Clean Access Agent > Installation).


Note SWISS protocol interaction only applies between the CAS and the Windows and Macintosh Clean Access Agents. The Cisco NAC Web Agent does not connect to the CAS using the SWISS protocol.


Figure 5-7 outlines the basic Clean Access Agent discovery and login session initiation process.

Figure 5-7 Clean Access Agent and CAS Interaction Using the SWISS Protocol

1. After the user connects to the network and the client machine receives an IP address (via network DHCP server or the CAS itself, depending on your system configuration), the Clean Access Agent starts sending UDP discovery packets on both ports 8905 and 8906.

2. The CAS intercepts SWISS discovery packets and responds to the Clean Access Agent with the CAS certificate and instructs the Clean Access Agent to initiate a user login session on the client machine.

3. The Clean Access Agent and CAS engage in a SWISS protocol request-response exchange to determine:

User login status (including client IP-MAC address pair for Cisco NAC Appliance release 4.1(3) and later)

Authentication provider list

VPN connection status

Clean Access Agent upgrade version, availability, and messaging

SSO status (Windows Clean Access Agent only)

VPN SSO delay interval (if required)

Layer 2 Discovery Packets

If the user is "Layer 2 adjacent" to the CAS, the UDP discovery packets sent out on port 8905 are directed to the client machine's default gateway IP address and arrive at the CAS before they reach the default gateway device. That way, the CAS is able to respond to the client machine's search for the Cisco NAC Appliance network and Clean Access Agent displays the user login dialog on the client machine. (Once it intercepts the UDP discovery packets, the CAS does not forward the packets on to the client machine's default gateway.)

Layer 3 Discovery Packets

If the user is one or more Layer 3 hops away from the CAS, the Clean Access Agent must establish a connection with the CAS using discovery packets sent out over UDP port 8906. Although the Layer 3 discovery packets are directed to the Discovery Host address on the CAM, which is most likely (but not always) the CAM's eth0 interface, these packets must traverse (pass from the untrusted to the trusted side of) the CAS in order to reach the CAM. That way, the CAS is able to intercept and respond to the client machine's search for the Cisco NAC Appliance network and the Clean Access Agent displays the user login dialog on the client machine.

Discovery Host

The Discovery Host address on the CAM can be any IP address on the trusted side of the Cisco NAC Appliance network. By default, the Discovery Host address is the CAM eth0 IP address, since CAM only exists on the trusted side of the network and has exist for the Cisco NAC Appliance system to work at all. You can display the destination Discovery Host IP address the Clean Access Agent uses to address Layer 3 discovery packets by right clicking on the Clean Access Agent icon on the client taskbar and selecting Properties to bring up the Agent Properties and Information dialog (Figure 5-8).

Figure 5-8 Discovery Host Address in Clean Access Agent Properties Dialog

In order for the Clean Access Agent to discover the CAS and initiate a user login session, the Discovery Host must match the address assignment on the CAM. When users install and launch the Clean Access Agent on the client machine, the Discovery Host setting automatically corresponds to the Discovery Host IP address configured on the CAM. The Discovery Host must be configured on the Clean Access Agent installer (Stub or full) in order for the Agent to discover the Cisco NAC Appliance network. If the Discovery Host is missing when the Agent is downloaded and installed on the client machine, the Clean Access Agent does not know which destination IP address to use for the UDP discovery packets and will not be able to appropriately direct SWISS discovery packets.

New Agent downloads and upgrades automatically use the most recent Discovery Host address assignment. You must ensure that previously-installed Clean Access Agent installations get updated if the Discovery Host IP address changes on the CAM. You can accomplish this in one of the following ways:

Windows Client Machines

Right-click on the Clean Access Agent icon on the client machine taskbar, select Properties, and enter the new IP address.

Change the client machine's HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\Clean Access Agent\ServerUrl host registry entry to feature the new IP address.

Upgrade the Clean Access Agent on the CAM and make Agent upgrade on the user side mandatory.

Macintosh Client Machines


Step 1 Navigate to /Applications/CCAAgent.app.

Step 2 Right-click on the CCAAgent.app and choose Show Package Contents.

Step 3 Locate the /Contents/Resources/setting.plist file and use a text editor or double-click on the setting.plist file to view the file contents.

Step 4 Change the "Discovery Host" entry to feature the new IP address.


VPN SSO Considerations

If users are connected to the network through an existing VPN connection and the Clean Access Agent automatically sends SWISS discovery packets out searching for a CAS through which the user can log in, the CAS uses the SWISS packet request-response mechanism to tell the Clean Access Agent not to display the user login dialog on the client machine. In addition, some VPN concentrators do not send out user session information immediately, so the CAS builds a "delay" into the user login session initiation process whenever VPN SSO has been configured on the Cisco NAC Appliance system. That way, the user is not required to enter their credentials more than once to log into the network for their session.

Overcoming Network Latency Issues That Can Delay Discovery

To help ensure client machines are able to discover and authenticate with a Clean Access Server in a network featuring inherent latency, you can use the "SwissTimeout" registry setting in Windows client machines. When the client machine sends out a SWISS discovery packet, it waits a full second for a CAS discovery response packet to return before trying to send a subsequent packet 5 seconds later. If the CAS responds, but network latency issues prevent the response packet from reaching the client machine in time, the client continues to check for a CAS through which it can connect to the network. To address this potential situation, administrators can set an additional "SwissTimeout" period on the client machine to allow a little extra time for the CAS discovery response packet to reach the client machine.

For more details, see Appendix C, "Windows Client Registry Settings" in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8).

Layer 3 SWISS Packet Delay to Conserve Bandwidth

In an effort to cut down on discovery packet transmission on the network, the Clean Access Agent is designed to begin increasing the interval for Layer 3 discovery packet transmission when the Agent is unable to locate a CAS on the network. Instead of perpetually sending discovery packets every 5 seconds (as is the case for all Layer 2 discovery packets sent out on UDP port 8905), the Layer 3 discovery packets sent out on UDP port 8906 decrease in frequency with each subsequent transmission until the interval between discovery packets reaches 30 minutes. After that, the Clean Access Agent stops searching for a CAS until a network connection event (like unplugging the Ethernet cable from the interface and plugging it back in again) "wakes up" port 8906 and restarts the discovery process.

Supporting Multiple Active NICs on the Clean Access Agent Client Machine

The Cisco NAC Appliance system supports Clean Access Agent client machines with more than one active NIC pointing to the same (untrusted side) eth1 interface on a CAS. Historically, this particular scenario could lead to a problem where, even after a user had already logged into the network via the Clean Access Agent, another user login dialog would repeatedly appear and ask the user to enter their credentials again. This situation occurred because the CAS would receive SWISS discovery packets from over the additional active interface(s) and the CAS would not determine that the request from the additional IP address-MAC address pair(s) did not originate from the same client machine on which there was already an active Clean Access Agent session. To address this potential problem, when responding to a Clean Access Agent query for user login, the CAS includes a "valid" IP address-MAC address pair in the return SWISS packet(s) essentially saying, "You can establish a connection to the Cisco NAC Appliance network on the client machine interface <MAC address> with IP Address A.B.C.D. All other requests from this client will be ignored while this session remains active."


Note If you use the Access to Authentication VLAN change detection feature on a client machine with more than one active NIC, all active NICs on the client use the feature. By design, the NIC with the lowest metric always takes precedence for routing purposes, and you can determine the metric using the route print command from a command prompt. For more detailed information on the VLAN change detection feature, see "Configuring Access to Authentication VLAN Change Detection" section in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8).


Figure 5-9 illustrates a common scenario where the CAS behavior helps avoid a potential problem. If the user logs in to the network via a Clean Access Agent session using NIC1 (the client machine's active Ethernet interface), the CAS responds back that it will allow login requests from the NIC1 interface with the associated IP address. If the CAS then receives SWISS discovery packets originating from NIC2 (the client machine's Wireless Ethernet connection that points to the same eth1 interface on the CAS), the CAS does not initiate another Clean Access Agent login session because the IP address-MAC address pair for NIC2 does not match the pair the CAS allowed when the session was established using NIC1.

Figure 5-9 Multiple Active Interfaces Pointing to the Same CAS eth1 IP Address

Configure DHCP

You can configure the CAS to be a DHCP server when the CAS is in Real-IP/NAT Gateway mode, if a DHCP server does not already exist on your network. For complete details, see Chapter 6, "Configuring DHCP."

Configure DNS Servers on the Network

The DNS form lets you specify the Domain Name Service (DNS) servers to be queried for host name lookups.

To configure a DNS for your environment:

1. Go to Device Management > CCA Servers > Manage [CAS_IP] > Network >DNS.

Figure 5-10 DNS Form

2. Type the IP addresses of one or more domain name servers in the DNS Servers field. If entering multiple servers, use commas to separate the addresses. The Clean Access Server attempts to contact the DNS servers in the order they appear in the list.

Host NameThe host name you want to use for the Clean Access Server.

Host DomainThe domain name applicable in your environment.

DNS ServersThe IP address of the DNS server in your environment. Separate multiple addresses with commas. If you specify more than one DNS server, the Clean Access Server tries to contact them sequentially, until one of them returns a response.

3. Click Update.


Note For High Availability CAS pairs, any CAS network setting changes performed on an HA-Primary CAS through the CAS management pages or CAS direct access web console must also be repeated on the standby CAS unit through its direct access web console. These settings include updating the SSL certificate, system time/time zone, DNS, or Service IP. See Clean Access Server Direct Access Web Console, page 12-2 and Modifying High Availability Settings, page 13-26 for details.


Configuring Managed Subnets or Static Routes

This section describes the following:

Overview

Configure Managed Subnets for L2 Deployments

Configure Static Routes for L3 Deployments

Overview

For all CAS modes in L2 deployment (Real-IP/NAT/Virtual Gateway) when configuring additional subnets, you must configure Managed Subnets in the CAS so that the CAS can send ARP queries with appropriate VLAN IDs for client machines on the untrusted interface. You must configure the untrusted (authentication) VLAN in the VLAN ID field of the Managed Subnet.

Managed Subnets are only for user subnets that are Layer 2 adjacent to the CAS.

For all CAS modes in L3 deployment, Static Routes must be configured for the user subnets that are one or more hops away. Managed subnets should not be configured for these subnets. See Configure Static Routes for L3 Deployments for details.


Note In the case of a multi-hop L3 deployment where the VPN concentrator performs Proxy ARP for client machines, managed subnets can be used instead of static routes and should be created in the CAS.


Table 5-1 summarizes the steps required for each deployment. Forms mentioned below are located in the CAS management pages under Device Management > CCA Servers > Manage [CAS_IP].


NoteFor IPs with VLAN restrictions, all IPs must be in a managed subnet, and you must create a managed subnet first before creating an IP range (DHCP pool).

For IPs with relay restrictions, all IPs should typically be in static routes, but can be in managed subnets if integrating the CAS with Aironet devices or other non-RFC 2131/2132 compliant devices. Note that these IP address pools must be in either a static route or a managed subnet, and IPs with relay restrictions should only be put in a managed subnet for these non-compliant devices.

See Configuring IP Ranges (IP Address Pools), page 6-5 for details.


Table 5-1 Guidelines for Adding Managed Subnets vs. Static Routes

Layer 2—In-Band or Out-of-Band
(CAS has L2 proximity to users)
Layer 3 (Multi-Hop) —In-Band Only
(e.g. CAS is behind VPN Concentrator or Router or L3 Switch)
For Real-IP and NAT Gateways:
For Real-IP and NAT Gateways:
If the router below the CAS performs proxy ARP:
If the router below the CAS does NOT perform proxy ARP:

Add a managed subnet under Advanced > Managed Subnet to assign the gateway IP address of the subnet to the CAS.

For example, to configure the CAS to be the gateway (10.10.10.1) for VLAN 10 /subnet 10.10.10.0, specify the following managed subnet:

IP Address: 10.10.10.1
Subnet Mask: 255.255.255.0
VLAN ID: 10

Always add a managed subnet under Advanced > Managed Subnet

1. Always add static routes for the subnets on the untrusted side under Advanced > Static Routes. For example:

Network 			Mask 		Interface 			Gateway
10.10.10.0			/24		eth1			10.10.10.1
10.10.20.0			/24		eth1			10.10.20.1

Note /24 subnet mask = 255.255.255.0

2. Specify an ARP entry for the gateway IP that the CAS needs to hold under Advanced > ARP. For example:

10.10.10.0			255.255.255.255 			eth1	

See Figure 5-11.

For Virtual Gateways:
For Virtual Gateways:
If the router below the CAS performs proxy ARP:
If the router below the CAS does NOT perform proxy ARP:

Add a managed subnet under Advanced > Managed Subnet to assign an IP address to the CAS that is otherwise unused on the subnet.

For example, to have the CAS manage subnet 10.10.10.0/24 on VLAN 10 where the gateway for this subnet is 10.10.10.1, you will need to reserve an IP address for the CAS, such as 10.10.10.2. Specify the following managed subnet:

IP Address: 10.10.10.2
Subnet Mask: 255.255.255.0
VLAN ID: 10

The CAS is not the gateway, but owns the 10.10.10.2 address for this VLAN/subnet.

Always add a managed subnet under Advanced > Managed Subnet

1. Add static route for the subnets on the untrusted side under Advanced > Static Routes. For example:

Network 			Mask 		Interface 			Gateway
10.10.10.0			/24		eth1			10.10.10.1

Note When deploying the CAS in L3 VGW mode, the gateway is not optional and you must specify the gateway for the static route.



Note In general, when the CAS is in Virtual Gateway mode for Layer 2 or Layer 3, you cannot ping the gateways of the subnets being handled by the CAS. This should not affect the connectivity of the users on these subnets.


Figure 5-11 Configuring Static Routes for CAS in L3 Real-IP Gateway Deployment

Configure Managed Subnets for L2 Deployments

When the Clean Access Server is first added to the Clean Access Manager, the untrusted IP address provided for the CAS is automatically assigned a VLAN ID of -1 to denote a Main Subnet. By default, the untrusted network the Clean Access Server initially manages is the Main Subnet.

You can configure the CAS to manage additional subnets by adding them under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > Managed Subnet. In this case, the Clean Access Server acts as the virtual default gateway for the untrusted (authentication) managed subnets, and puts a virtual IP for the added managed subnet on the untrusted interface.


Note If the Clean Access Server is a Real-IP Gateway, you will need to add a static route on the upstream router to send traffic to the CAS. For example, for managed subnet 10.0.0.0/24, you will need to add static route 10.0.0.0/255.255.0.0 gateway <CAS_eth0_IP_address> to the upstream router.


To modify the Main Subnet of the CAS, go to Device Management > CCA Servers > Manage [CAS_IP] > Network > IP. To change the VLAN ID of the Main Subnet, enter it in the Set management VLAN ID field in the Untrusted Interface side of the form. If modifying the IP Address, Subnet Mask, Default Gateway, or management VLAN ID for the untrusted interface of the CAS, you must click Update then Reboot for the new settings to take effect on the CAS and on the network.

When you create a managed subnet, an ARP entry is automatically generated for the gateway of the subnet. Therefore, to manage a subnet of 10.1.1.0/255.255.255.0, configure the managed subnet with the following values:

IP Address: 10.1.1.1 (if 10.1.1.1 is the desired default gateway)

Subnet Mask: 255.255.255.0

An ARP entry is automatically generated for the 10.1.1.1 address, the presumed gateway. However, if using a non-standard gateway address (such as 10.1.1.213 for the 10.1.1.0/255.255.255.0 subnet), you will need to create the managed subnet as 10.1.1.213/255.255.255.0.

Adding Managed Subnets

1. Go to Device Management > CCA Servers > Manage [CAS_IP] > Advanced > Managed Subnet.

Figure 5-12 Managed Subnet

2. In the IP Address field, type the IP address that the CAS will own for the managed subnet (the CAS will perform ARP for this IP address):

For Real-IP/NAT Gateways, the CAS will own the gateway IP address of the managed subnet (for example, 10.10.10.1).

For Virtual Gateways, the CAS will own an IP address on the managed subnet that is otherwise unused (for example, 10.10.10.2)

See Table 5-1, "Guidelines for Adding Managed Subnets vs. Static Routes" for details.

3. In the Subnet Mask field, type the mask for the network address. The CAM calculates the network address by applying the subnet mask to the IP Address field.

4. In the VLAN ID field, type the untrusted (authentication) VLAN ID associated with this subnet. Use -1 if the subnet is not on a VLAN.


Note The VLAN column for the Main Subnet displays the eth1 Management VLAN of the CAS (if available) or "-1" if no eth1 Management VLAN is set for the CAS.


5. Click Add Managed Subnet to save the subnet.

If you need to provide an ARP entry for the managed subnet other than the one created by default, use the instructions in Add ARP Entry. For the entry, use the gateway address for the subnet and set the Link value to Untrusted (eth1).

Configure Static Routes for L3 Deployments

L3 deployments (and some VPN concentrators deployments) should not use Managed Subnets and should only use Static Routes to configure how the CAS should route packets. The Static Route form (Figure 5-15) lets you set up routing rules in the Clean Access Server. Static Routes have the form:

Network / subnet mask / send packets to interface (trusted or untrusted) / Gateway IP address (optional)

Any packet that comes into the CAS is evaluated based on static routes, then routed appropriately to the router. When the CAS receives a packet, it looks through its static route table, finds the most specific match, and if that route has a gateway specified, the CAS sends packets through that gateway. If no gateway is specified, then the CAS puts packets on the interface specified for the route (eth0 or eth1).


Note If converting from L2 to L3 deployment, remove managed subnets and add static routes instead.


Figure 5-13 illustrates a Layer 3 deployment scenario that requires a static route.

Figure 5-13 Static Route Example (Layer 3)

Configuring Static Routes for Layer 2 Deployments

Figure 5-14 illustrates a Layer 2 deployment scenario that requires a static route. In this case, the Clean Access Server operates as a Virtual Gateway. Two gateways exist on the trusted network (GW1 and GW2). The address for the second gateway, GW2, is outside the address space of the first gateway, which includes the Clean Access Server interfaces. The static route ensures that traffic intended for GW2 is correctly passed to the Clean Access Server's trusted interface (eth0).

Figure 5-14 Static Route Example (Layer 2)

Add Static Route

1. Open the Static Routes form in the Advanced tab of the CAS management pages.

Figure 5-15 Static Routes

2. In the Static Routes form, type the destination IP address and subnet mask (in CIDR format) in the Dest. Subnet Address/Mask fields. If the destination address in the packet matches this address, the packet is routed to the specified interface.

3. If needed, type the external, destination Gateway address (such as 10.1.52.1 in Figure 5-14).


Note For Virtual Gateway mode, the Gateway address is not optional and must always be specified.


4. Choose the appropriate interface of the Clean Access Server machine from the Link dropdown list. In most cases this is eth0, since most static routing scenarios involve directing traffic from the untrusted to the trusted network.

5. Optionally, type a Description of the route definition.

6. Click Add Route.

Configure ARP Entries

An ARP (Address Resolution Protocol) entry allows you to associate IP addresses with one of the Clean Access Server's interfaces. An ARP entry is typically used to advertise to the trusted network that certain addresses are within the Clean Access Server's managed domain, so that traffic for the managed clients can be directed to the Clean Access Server's untrusted interface.

ARP entries are automatically created for:

The untrusted network specified for the Clean Access Server in the IP form.

Any managed subnets you added (see Configuring Managed Subnets or Static Routes).

Auto-generated subnets created during DHCP configuration. These entries are identified by the description "ARP Generated for DHCP." (see Figure 6-12 on page 6-14)

Add ARP Entry

Use the following steps to manually create an ARP entry.

1. Open the ARP form in the Advanced tab.

Figure 5-16 Create ARP Entry

2. Type the IP address of the network or machine to be associated with the interface along with the subnet mask in the Subnet Address/Mask fields. If creating an ARP entry for a single address, such as a virtual default gateway address, specify the address and use 255.255.255.255 as the subnet mask.

3. Choose the interface from the Link dropdown menu (usually eth1, the untrusted interface).

4. Optionally, type a Description of the ARP entry.

5. Click Add ARP Entry to save the settings.

6. Clicking the Flush ARP Cache button clears cached MAC-to-IP address associations.


Note Due to Roaming feature deprecation, the Continuously broadcast gratuitous ARP with VLAN ID option is removed.


Understanding VLAN Settings

The Clean Access Server can serve either as a VLAN termination point or it can perform VLAN passthrough. In a Virtual Gateway configuration, VLAN IDs are passed through by default.

In a Real-IP or NAT Gateway configuration, by default the VLAN identifiers are terminated at the CAS (that is, identifiers are stripped from packets received at the trusted and untrusted interfaces). However, if you enable VLAN ID passthrough, packets retain their VLAN identifiers.


Note If you are unsure of which mode to use, you should use the default behavior of the CAS.


For the VLAN identifier to be retained, passthrough only needs to be enabled for the first of the two interfaces that receives the message. That is, if VLAN ID passthrough is enabled for the untrusted interface, but terminated for the trusted interface, packets from the untrusted (managed) clients to the trusted network retain identifiers, but packets from the trusted network to the untrusted (managed) clients have their identifiers removed. Note, however, that in most cases you would enable or disable VLAN ID passthrough on both interfaces.

A management VLAN identifier is a default VLAN identifier. If a packet does not have its own VLAN identifier, or if the identifier was stripped by the adjacent interface, a management VLAN identifier specified at the interface is added to the packets (in order to route them properly through VLAN enabled equipment on the network).


Note The Clean Access Server is typically configured such that the untrusted interface is connected to a trunk port with multiple VLANs trunked to the port. In such a situation, the management VLAN ID is the VLAN ID of the VLAN to which the IP address of the CAS belongs.


Use care when configuring VLAN settings. Incorrect VLAN settings can cause the CAS to be inaccessible from the CAM web admin console. If you cannot access the CAS from the CAM after modifying the VLAN settings, you will need to access the CAS directly to correct its configuration, as described in Install the Clean Access Server Software from CD-ROM, page 4-8.

VLAN settings for the CAS eth0 and eth1 interfaces are set under Device Management > CCA Servers > Manage [CAS_IP] > Network > IP. The settings are as follows:

Set management VLAN ID—The default VLAN identifier value added to packets that do not have an identifier. Set at the untrusted (eth1) interface to add the VLAN ID to packets directed to managed clients, or at the trusted (eth0) interface to add the VLAN ID to packets destined for the trusted (protected) network.

Pass through VLAN ID to managed network / Pass through VLAN ID to protected network—If selected, VLAN identifiers in the packets are passed through the interface unmodified.

As mentioned, by setting the management VLAN ID value for the managed network, you can add VLAN ID tags to the outbound traffic of the entire managed network. You can also set VLAN IDs based on other characteristics. Specifically, the CAS can tag outbound traffic by:

Managed network
(under Device Management > CCA Servers > Manage [CAS_IP] > Network > IP)

Managed subnet
(under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > Managed Subnet)

User role
(under User Management> User Roles > User Roles > New or Edit Role)

For example, if you set the VLAN ID for the faculty role to 1005, the CAS would set that VLAN ID on every packet belonging to a user in that role as the packet went from the untrusted side to the trusted side of the Clean Access Server.

In addition, once VLAN tagging is configured, traffic from users on a particular VLAN ID and authenticated by an external authentication source can be mapped to a specific user role (under User Management> Auth Servers > Mapping Rules). Role mapping rules can use the user's VLAN ID as one of the attributes when assigning a user to a role. See the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8) for details.

Enable Subnet-Based VLAN Retag in Virtual Gateway Mode

The Managed Subnet form (Device Management > CCA Servers > Manage [CAS_IP] > Advanced > Managed Subnet) allows you to add managed subnets for Clean Access Servers in Real-IP, NAT and Virtual Gateway modes as described in Configure Managed Subnets for L2 Deployments. Traffic originating from the untrusted interface of the CAS is tagged according to the VLAN ID set for the managed subnet.

For CASs in Virtual Gateway mode only, the Enable subnet-based VLAN retag option appears at the top of the Managed Subnet form, as shown in Figure 5-17.

Figure 5-17 Enable Subnet-Based VLAN Retag for Virtual Gateway

This feature is more useful on wireless networks than on wired networks. For example, assume that a single CAS in Virtual Gateway mode is managing multiple subnets/VLANs, where each subnet is a separate VLAN. If a user is initially connected to an Access Point on VLAN A, the user will receive an IP address on subnet A. Assume that due to overlapping wireless signals, the user is subsequently connected to an AP on VLAN B. If the Enable subnet-based VLAN retag feature is not enabled, the user's traffic will not be routed correctly since their address is on subnet A (i.e. VLAN A) but their packets are tagged with VLAN B. This feature allows the CAS to retag packets based on the subnet to which they belong, thus enabling the packets to be routed correctly.

VLAN Mapping in Virtual Gateway Modes

For Clean Access Servers in Virtual Gateway mode only, the VLAN mapping form appears under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > VLAN Mapping. This forms allows you to map an untrusted interface VLAN ID to a trusted network VLAN ID.

Traffic going through the CAS will be VLAN-retagged according to this VLAN Mapping setting.

Native VLAN, Management VLAN, Dummy VLAN

For best practice purposes, and to prevent trunking configuration issues for Virtual Gateway deployments, Cisco NAC Appliance requires differentiating native, management, and dummy VLANs when configuring your switches.


Caution Do not put the Clean Access Server on VLAN 1.

A native VLAN is present whether or not one is declared; the default is VLAN 1. By default all Cisco switches have their ports configured to be in VLAN 1, and a trunk link has the native VLAN set as VLAN 1. In addition to the well-known vulnerabilities associated with VLAN 1, as a security appliance, Cisco explicitly recommends setting the native VLAN to a VLAN other than VLAN 1. This ensures that no traffic is unknowingly passed to or through the CAS on this VLAN. For example, if there is a misconfiguration on the trunk link or any unknown traffic on VLAN 1 (such as a user connecting a laptop on an unused port on default VLAN 1) this will not cause any problems on the CAS.


Note The VLAN 1 restriction is required for the CAS, and highly recommended for the CAM. Because of the configuration requirements on the CAS in Virtual Gateway mode, where no common VLANs should exist between the trusted and untrusted port, VLAN 1 should not be used at all on either the trusted port or the untrusted port. This ensures that a Layer 2 loop cannot occur on VLAN 1 due to misconfiguration.


Although the management VLAN could be the native VLAN, setting the management VLAN to another value also ensures that all traffic that passes to or through the CAS is tagged and that there is no question that the CAS properly associates the traffic either to the Management VLAN of the CAS or to the VLAN mappings from the untrusted to trusted interface of the CAS. For this reason, the "dummy" VLAN is also used so that any untagged packet is correctly dropped.


Note The Management VLAN for the CAS is set under Network > IP. VLAN mappings are set on the CAS under Advanced > VLAN Mapping.


Best practice dictates the use of different dummy VLAN IDs, for example 998 and 999, for the native VLANs on the eth0 and eth1 interfaces of the CAS. This ensures that untagged traffic is dropped and is never passed unknowingly between the Untrusted and Trusted CAS interfaces. The CAS should not pass the traffic in either case without a VLAN mapping. However, the use of different dummy VLAN IDs prevents the possibility of manual/administrator errors resulting in the incorrect passing of traffic to or through the CAS via the native VLAN.

VLAN Mapping for In-Band

When a Clean Access Server operates in Virtual Gateway mode, it passes network traffic from its eth0 interface to eth1 and from eth1 to eth0 without changing the VLAN tag.

For In-Band configurations, in order to pass traffic from both interfaces through the same Layer 2 switch without creating a loop, it is necessary to place incoming traffic to the Clean Access Server on a different VLAN from the outgoing traffic of the Clean Access Server.

VLAN Mapping for Out-of-Band

In Out-of-Band Virtual Gateway mode, the OOB Clean Access Server uses VLAN mapping to retag an unauthenticated client's allowed traffic (e.g. DHCP/DNS) from the Authentication VLAN to the Access VLAN and vice versa.


Note See the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8) for all other details on OOB configuration.


Switch Configuration for Out-of-Band Virtual Gateway Mode

Obtain the following VLAN IDs for Cisco NAC Appliance:

VLAN for the Clean Access Manager (the management VLAN, e.g. 64)

VLAN for the Clean Access Server (a new management VLAN, e.g. 222)


Note For a Virtual Gateway, the management VLAN for the CAS must be different from the CAM.


VLAN(s) for Access (e.g., 10, 20, 30, 40)

VLAN(s) for Authentication (e.g. 610, 620, 630, 640)

Dummy (unused) VLAN for native VLAN settings on switch interfaces connected to the CAS interfaces (e.g. 998, 999)

Example switch configuration on the switch interfaces connecting to eth0 of the CAS:

switchport trunk encapsulation dot1q

switchport trunk native vlan 998

switchport trunk allowed vlan 10,20,30,40,222

Example switch configuration on the switch interfaces connecting to eth1 of the CAS:

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

switchport trunk allowed vlan 610,620,630,640

CAS eth0 and eth1 network settings:
(Device Management > CCA Servers > Manage [CAS_IP] > Network > IP):

Set Trusted management VLAN ID (e.g. 222)

Figure 5-18 Setting the Management VLAN ID


Note You must prune VLANs on both the trusted and untrusted sides to only the VLANs that the CAS needs to manage. You must also prune VLAN 1 out of the trunk on both sides.


Configure VLAN Mapping

1. Go to Device Management > CCA Servers > List of Servers and click the Manage button for the CAS you added. The CAS management pages appear.

2. Click the Advanced tab.

3. Click the VLAN Mapping link.

Figure 5-19 Enable VLAN Mapping

4. Click the checkbox for Enable VLAN Pruning if you want to block any unmapped VLAN packets passing across CAS interfaces in both directions (from Untrusted -> Trusted and from Trusted -> Untrusted).


Note VLAN Pruning is enabled by default.


The following table briefly describes the net effect on VLAN traffic when VLAN pruning and VLAN mapping are enabled and disabled:

VLAN Pruning
VLAN Mapping
Result

ON

ON

Discard all unmapped VLAN packets

ON

OFF

Discard all VLAN packets regardless of mapping

OFF

ON

Potential Layer 2 UDP broadcast storm due to VLAN packet loop

OFF

OFF

Potential Layer 2 UDP broadcast storm due to VLAN packet loop



Warning If the Enable VLAN Pruning option is enabled alone, the CAS discards all VLAN packets passing through in either direction.


5. Click the checkbox for Enable VLAN Mapping and click Update.

6. Enter the Auth VLAN ID for the Untrusted network VLAN ID field.

7. Enter the Access VLAN ID for the Trusted network VLAN ID field.

8. Type an optional Description (such as Users on edge switch).

9. Click Add Mapping.

To Verify VLAN Mapping

1. Go to Device Management > CCA Servers > List of Servers > Manage [CAS_IP] > Advanced > VLAN Mapping.

2. The VLAN mappings you configured should be listed at the bottom of the page.

Figure 5-20 Verify VLAN Mapping

Local Device and Subnet Filtering

As typically implemented, Cisco NAC Appliance enforces authentication requirements on clients attempting to access the network. Device and subnet filters allow you to define specialized access privileges or limitations for particular clients.


Note Access policies set in the CAS management page apply only to the CAS being administered. To configure global passthrough policies for all Clean Access Servers, go to the Device Management > Filters module in the CAM web console. Note that local policies typically override global settings.


A device/subnet filter can:

Allow all traffic for a device/subnet without requiring authentication.

Block a device/subnet from accessing the network.

Exempt a device/subnet from authentication while applying other policies of a role for the device(s).

A filter policy is one way that a Cisco NAC Appliance role can be assigned to a client. The order of priority for role assignment as follows:

1. MAC address

2. Subnet / IP address

3. Login information (login ID, user attributes from auth server, VLAN ID of user machine, etc.)

Therefore, if a MAC address associates the client with "Role A", but the user's login ID associates him or her to "Role B", "Role A" is used.


Note The Clean Access Manager respects the global Device Filters list for Out-of-Band deployments. Cisco strongly recommends you do not configure any local (CAS-specific) device filters when deployed in an Out-of-Band environment. See "Global Device and Subnet Filtering" in the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(8) for details.


Configure Local Device Access Filter Policies

You can configure local device filter polices for in-band deployments.


Step 1 Go to Device Management > CCA Servers > List of Servers > Manage [CAS_IP] > Filter > Devices.

Figure 5-21 Local Device Filters List

Step 2 Click New. The New local filter form appears as shown in Figure 5-22.

Step 3 In the Devices form, enter the MAC address of the device(s) for which you want to create a policy in the MAC Address/IP Address Description text field. Type one entry per line using the following format:

<MAC>/<optional_IP> <optional_entry_description>

Note the following:

You can use wildcards "*" or a range "-" to specify multiple MAC addresses.

Separate multiple devices with a return.

If you enter both a MAC and an IP address, the client must match both for the rule to apply.

You can specify a description by device or for all devices. A description specific to a particular device (in the MAC Address field) supersedes a description that applies all devices in the Description (all entries) field. There cannot be spaces within the description in the device entry.

Step 4 Choose the policy for the device from the Access Type choices:

ALLOWIB - bypass login, bypass posture assessment, allow access

DENYIB - bypass login, bypass posture assessment, deny access

ROLEIB - bypass login, bypass L2 posture assessment, assign role

CHECKIB - bypass login, apply posture assessment, assign role

Step 5 If using CHECK or ROLE, choose a role from the User Role dropdown menu.

Step 6 Click Add to save the policy. The policy appears in the list at the bottom of the page.

The following examples are all valid entries (that can be entered at the same time):

00:16:21:11:4D:67/10.1.12.9 pocket_pc 
00:16:21:12:* group1 
00:16:21:13:4D:12-00:16:21:13:E4:04 group2 

Figure 5-22 New Local Filter


Note If bandwidth management is enabled, devices allowed without specifying a role will use the bandwidth of the Unauthenticated Role.


You can sort the columns of the filter list by clicking on the column heading label (MAC Address, IP Address, Description, Access Type).

You can edit a device access policy by clicking the Edit button. Note that the MAC address is not an editable property of the filter policy. To modify a MAC address, create a new filter policy and delete the existing policy.

You can remove any number of device access policies by clicking the checkbox next to the policy and clicking the Delete button.


View Active L2 Device Filter Policies

To view active Layer 2 devices in filter policies for a particular Clean Access Server:


Step 1 Go to Device Management > CCA Servers > List of Servers > Manage [CAS_IP] > Filter > Devices > Active.

Step 2 Click the Show All button first to populate the Active page with the information from all clients currently connected to the CAS, sending packets, and with their MAC addresses in a device filter.

Step 3 You can also perform a Search on a client IP or MAC address to populate the page with the result. By default, the Search parameter performed is equivalent to "contains" for the value entered in the Search IP/MAC Address field.

For performance considerations, the Active page only displays the most current device information when you refresh the page by clicking Show All or Search.

Figure 5-23 Active


Note To view active devices for all CASs from the CAM, go Device Management > Filters > Devices > Active.



Configure Subnet Access Filter Policies

The Subnets form allows you to specify access rules for an entire subnet. All devices accessing the network from the subnet are subject to the rule.

To set up subnet-based access controls:

1. Click the Subnets link in the Filter tab.

2. In the Subnet address/netmask fields, enter the address of the subnet and the netmask identifying the significant bits of the subnet address.

Figure 5-24 Local Subnet Filter

3. Optionally, type a description of the policy or device in the Description field.

4. Choose the network access policy for the device from the Access Type choices:

allow - Enables the device to access the network without authentication.

deny - Prevents the device from accessing the network. If applicable, the user is blocked and an HTML page appears notifying the user that access is denied.

use role - Applies a role to users with the specified device. If you select this option, also select the role to be applied. The user will not need to be authenticated.

5. Click Add to save the policy.

The policy, which takes effect immediately, appears in the filter policy list. From there you can remove a subnet policy using the Delete button or edit it by clicking the Edit button. Note that the subnet address is not an editable property of the filter policy. To modify an address, you need to create a new filter policy and delete the existing one.

You can sort the filter list by column by clicking the heading label (e.g. Subnet, Description).

CAS Fallback Policy

The CAS Fallback policy feature allows administrators to configure the level of user access permitted by the Clean Access Server when the Clean Access Manager becomes unreachable from the CAS. For example, if a remote CAS attempts to reach the CAM, but the WAN link fails, CAS Fallback can be used to specify the user access policy: allow all user traffic, block all user traffic, or only allow traffic for already-authenticated users (default CAS behavior).


Note The CAS Fallback feature is for situations where communication between the CAS and CAM is lost. For protection against CAS failure itself in a Central Deployment, Cisco recommends deploying a CAS high availability (HA) failover bundle. See Chapter 13, "Configuring High Availability (HA)" for details.


The CAS checks the status of the CAM periodically, according to the Detect Interval specified. If the CAM is unreachable a predetermined percentage of the time over the course of the specified Detect Timeout period, the CAS sets the traffic policy of every user role to "Allow All, "Block All" or "Ignore" based on the specified Fallback Policy. You can specify the Detect Interval, Detect Timeout, and Fail Percentage threshold values as described below.

Device filter settings and/or subnet filter settings take precedence over the CAS Fallback Policy. While in CAS fallback mode, CAS device filter settings determine behavior based on the client MAC address. If device filter settings do not apply (for example, if the CAS is a Layer 3 gateway and cannot determine the client MAC address), the CAS also looks for applicable subnet filter settings before applying the CAS Fallback Policy.

During CAS fallback recovery (where the CAS is reconnecting to the CAM), a login dialog appears to users accessing the Cisco NAC Appliance network via the CAS, but they are unable to authenticate and login for approximately 2 minutes. (Until CAS fallback recovery completes, users see a "Failed to add user to the list" error message when attempting to log in.)


Note You can use the failSafeStatus script in the CAS CLI to determine whether or not the CAS is currently operating normally or in Fallback state. To run the script, log into the CAS CLI as root and type failSafeStatus from the /perfigo/access/bin/ directory.



Note Starting from release 4.1(8), when a standby CAS in an HA pair assumes the role of an active CAS that is performing DHCP address management and has gone into Fallback state, the new active CAS also assumes DHCP functions in addition to user login.


Configuring CAS Fallback


Step 1 Go to Device Management > CCA Servers > Manage [CAS_IP] > Filter > Fallback.

Figure 5-25 CAS Fallback

Step 2 From the Fallback Policy dropdown menu, select one of the following options:

Ignore (default)—Allow traffic only for authenticated users but block new users. This allows existing (authenticated) users to access local and remote site resources, but new (unauthenticated) users will be blocked.

Allow All—Allow all traffic for all users (authenticated and new). This allows new and existing users to access local and remote site resources.

Block All—Block all traffic for all users (authenticated and new). This blocks all users from accessing local and remote site resources.

Step 3 Specify a Detect Interval (default is 20 seconds). The Detect Interval specifies how often the CAS polls the CAM to verify whether it is still reachable on the network. The minimum Detect Interval must be 20 seconds.

Step 4 Specify a Detect Timeout (default is 300 seconds). The Detect Timeout specifies the duration of time the CAS continues to poll the CAM before determining whether or not it is reachable. If the Fail Percentage of verification polls fail (see Table 5-2), the CAS declares the CAM unreachable and triggers the CAS Fallback Policy. The Detect Timeout value must be at least 15 times the Detect Interval (default is 300 seconds), but Cisco recommends setting the Detect Timeout to 30 times the Detect Interval value (e.g. Detect Timeout of 600 seconds for a Detect Interval of 20 seconds).


Note Default values for the Detect Interval and Detect Timeout settings apply to new installations of Cisco NAC Appliance release 4.1(8). If you upgrade from a previous Cisco NAC Appliance release, your original Detect Interval and Detect Timeout values are preserved, and you may have to specify new settings to maintain expected CAS Fallback behavior.


Step 5 Specify a Fail Percentage. The Fail Percentage specifies the percentage of CAS polling events allowed to fail over the course of the Detect Timeout before the CAS declares the CAM unreachable and triggers the Fallback Policy. To help ensure network stability and minimize CAS Failover events, the Fail Percentage setting must be at least 25%, but cannot be more than 50%.

To determine the number of CAS events/polls to monitor over the course of the Detect Timeout, simply divide the Detect Timeout by the Detect Interval. Once you know the number of verification polls the CAS performs, apply the Fail Percentage to determine how many poll events must fail during the Detect Timeout to trigger CAS Fallback.

For example, if the CAS performs 15 verification polls over the course of the Detect Timeout period, and the CAS is configured to Fallback when 30% of the CAS-to-CAM verification polls fail (that is, you have specified a Fail Percentage value of 30), then CAS Fallback will occur when 5 or more verification polls to the CAM fail—30% of 15 polls is 4.5 polls (rounded up to 5). (See Table 5-2 for more examples.)


Note For CAS Fallback calculations, always round fractions up to the next integer value.


Step 6 The Resume Percentage value is automatically populated depending on the specified Fail Percentage value. The Resume Percentage indicates the percentage of successful responses from the CAM required to bring the CAS back into normal operation after a CAS Fallback event.

Following a CAS Fallback event, the CAS continues monitoring connection with the CAM according to the specified Fallback parameters and resumes normal operation when the CAM responds to a minimum percentage of periodic connection verification polls over the course of the Detect Timeout. The function determining the Resume Percentage value is a 100% success rate minus one half of the Fail Percentage. Therefore, if the specified Fail Percentage is 30%, the CAS resumes normal operation when the CAM responds to 85% (100% minus one half of 30%, or 15%) of the polls during the Detect Timeout period.

Step 7 Click Update.


Table 5-2 provides some sample CAS Fallback settings with Fallback Policy results in a Cisco NAC Appliance system where CAS Fallback has been enabled. Values in bold are user specified.

Table 5-2 Sample CAS Fallback Settings and Results

Detect Interval (specify)
Detect Timeout (specify)
Number of CAS Polls over Detect Timeout
(Detect Timeout/
Detect Interval)
Fail Percentage 25%-50%
(specify)
Number of Failed Polls to Trigger CAS Fallback (CAS Polls x Fail Percentage)
Resume Percentage
(100 - Fail Percentage/2)
Number of Successful Polls over Detect Timeout for CAS to Resume Operation
(CAS Polls x Resume Percentage)

20 sec

300 sec

15

30%

5 (4.5 rounded up)

85%

13 (12.75 rounded up)

20 sec

600 sec

30

30%

9

85%

26 (25.5 rounded up)

20 sec

400 sec

20

25%

5

88% (87.5% rounded up)

18 (17.5 rounded up)

30 sec

600 sec

20

30%

6

85%

17


NAT Session Throttle

You can configure a throttle/threshold on a per-host basis when the Clean Access Server operates as a NAT Gateway. This allows the CAS to restrict the maximum number of connections each host can open at any one time and eliminate the chance of one host consuming all the connections (for example due to a malicious user or a user with a worm).


Step 1 Go to Device Management > CCA Servers > Manage[CAS_IP] > Advanced > NAT.

Figure 5-26 NAT Page

Step 2 Click the checkbox for Drop new connections when "max concurrent connections per host" is reached to enable the NAT session throttle feature for new user connections.
When this option is checked, all new sessions will be dropped for a user if the total number of current connections for the host exceeds the threshold set in the Max Concurrent Connections Per Host field. For example, if an existing user has 300 connections open, then the administrator enables this feature for a maximum of 100 connections per host, the user's existing connections will not be affected, but the user will not be able to open any new connections until the total number of connections is less than 100.

Step 3 Configure the following options:

Max Concurrent Connections Per Host—You can configure this threshold up to the maximum value of 45535 connections. Typically, 256 or 512 connections should be sufficient per host. If there are a lot of dropped connections for a user, you can increase the maximum number of connections allowed per host in this field.

TCP Session Timeout (seconds)—This field sets the idle time for each connection. If the user opens a connection (e.g. for Telnet) and the connection is idle past the number of seconds configured in this field, the connection will be dropped.

TCP Session Scan Interval (seconds)—This field sets the interval to scan the entire table of NAT connections (up to 45,535 entries) to check which connections have timed out. For example, if this value is 90 seconds, the table will be scanned every 90 seconds.

Step 4 Click Update to save and activate settings on the CAS NAT gateway.

For troubleshooting, the bottom of the page lists the current connection table for each host:

Total Connections—(x/45535)—This shows the total number of open connections out of the the 45,535 maximum number of concurrent connections available for a CAS in NAT gateway mode (for example, 33/45535 means 33 connections are open).

IP—IP address of the host

Current Connections—The total number of connections currently being consumed by this host, for example: 2, 10, etc. If the checkbox is NOT checked for Drop new connections when "max concurrent connections per host" is reached, the Current Connections value can be greater than the value set for Max Concurrent Connections Per Host.

Dropped Connections—The current number of connections that have been dropped for this host. This field can facilitate troubleshooting if a user wants to know why his/her connections are being dropped.


Configure 1:1 Network Address Translation (NAT)

In 1:1 NATing, there is a one-to-one correspondence between the external and internal addresses involved in the translation (in contrast to the default NAT behavior, in which many internal addresses share a single external address).

1:1 NATing conceals your internal network architecture, but does not economize on external IP addresses, since you must have an external address for every host that needs to communicate externally. It can be used in conjunction with the default, dynamic NATing, allowing you to make email servers, web servers or any other services accessible from the Internet.

You can map a range of addresses, or map individual addresses along with port numbers.

For a range, you need to specify the starting point for both the internal and external address ranges and the length of the range. For example, a configuration of:

public range begin: 11.1.1.2; port: *

private range begin: 192.168.151.200; port: *

range: 4

Results in the following address mappings:

192.168.151.200 <-> 11.1.1.2

192.168.151.201 <-> 11.1.1.3

192.168.151.202 <-> 11.1.1.4

192.168.151.203 <-> 11.1.1.5

By default, the port numbers are passed through unchanged (as indicated by the asterisk (*) port value).

By specifying an address range of 1, you can map single addresses. This mapping may include port mappings. For example, the following assignment maps incoming traffic for 11.1.1.6:8756 to the internal address 192.168.151.204:80:

public range begin: 11.1.1.6; port: 8756

private range begin: 192.168.151.204; port: 80

range: 1


Caution Make sure you do not include a particular address in more than one mapping at a time, for example, by including it in a range and as an individual mapping.

Configure 1:1 NATing

1. Go to Device Management > CCA Servers > Manage [CAS_IP] > Advanced > 1:1 NAT.

2. Select Enable NAT 1:1 Mapping and click Update.

3. Choose the Protocol for which NATing is performed. Options are TCP, UDP, or both.

4. Type the first address in the public address range in the Public IP Range Begin field. An asterisk in an address or port field results in the value passing translation unchanged.

5. Type the first address in the private address range in the Private IP Range Begin field.

6. Specify the length of the range, that is, the number of sequentially numbered addresses to be translated.

7. Optionally, type a description of the mapping in the Description field.

8. Click the Add Mapping button.

The new range mapping appears in the list of mappings.

Configure 1:1 NATing with Port Forwarding

You can use the port field to achieve port forwarding. To create a 1:1 mapping with port forwarding, type the public and private addresses in the appropriate fields, along with corresponding port numbers, and make the IP Range Length value 1, as shown in Figure 5-27.

Figure 5-27 1:1 NAT with Port Forwarding

Configure Proxy Server Settings on the CAS

By default, the Clean Access Server redirects client traffic on ports 80 and 443 to the login page. If users on your untrusted network are required to use a proxy server and/or different ports, you can configure the CAS with corresponding proxy server information in order to appropriately redirect HTTP/HTTPS traffic client traffic to the login page (for unauthenticated users) or HTTP/HTTPS/FTP traffic to allowed hosts (for quarantine or Temporary role users). You can specify:

Proxy server ports only (for example, 8080, 8000)—This is useful in environments where users may go through a proxy server but not know its IP address (e.g. university).

Proxy server IP address and port pair (for example, 10.10.10.2:80)—This is useful in environments where the IP and port of the proxy server to be used are known (e.g. corporate/enterprise).

The URL for a preconfigured Proxy PAC file—This is a file the CAS should use to redirect the user session. The URL you specify must have the same IP address and port as the Proxy server to successfully enable session redirection. If the URL has a different IP address or port from the Proxy settings, you must configure an IP or host policy for the user session, instead.

To Specify Proxy Server Settings on the CAS:


Step 1 Go to Device Management > Clean Access Servers > Manage [CAS_IP] > Advanced > Proxy.

Figure 5-28 Proxy Settings for Client Traffic

Step 2 Specify the proxy source:

Enter the Proxy IP address in the Proxy Server (IP:)Port. Type the port number or IP:port of the proxy server. Separate multiple entries with commas. For example:

3128,8080,8000,10.10.10.2:6588,10.10.10.2:3382


Note For better security, it is strongly recommended to specify both IP and port for the proxy server. This causes the CAS to intercept only those requests from the IP address specified. Either port or IP:port must be specified for the proxy server; you cannot specify an IP address alone.


Enter the URL for a preconfigured Proxy PAC file the CAS should use to redirect the user session.


Note The URL you specify must have the same IP address and port as the Proxy server to successfully enable session redirection. If the URL has a different IP address or port from the Proxy settings, you must configure an IP or host policy for the user session, instead.


Step 3 Click Update to save settings.