Add the CAS to the CAM
This section describes the following topics:
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 4-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
6. The Out-of-Band Server Types appear in the dropdown menu when you apply an OOB-enabled license to a Cisco NAC Appliance deployment. For OOB, the CAS operates as a Virtual or Real-IP Gateway while client traffic is In-Band (in the Cisco NAC Appliance network) during authentication and certification. Once clients are authenticated and certified, they are considered “out-of-band” (no longer passing through the Cisco NAC Appliance 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).
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. For details on OOB operating modes, see “Switch Management and Configuring Out-of-Band (OOB) Deployment” in the Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9(1).
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
Note • eth0 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.
- 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.
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.
4. If the CAM is down and the CAS is performing VLAN mapping in “fail open” state, do not reboot the CAS because the VLAN mapping capability will be lost until the CAM comes back online.
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 4-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 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 Configuration Guide, Release 4.9(1)).
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.5 and later. You must correct your certificate chain to successfully upgrade to release 4.5 and later. For details on how to fix certificate errors on the CAM/CAS after upgrade to release 4.5 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 Manage Trusted Certificate Authorities and the “View and Remove Trusted Certificate Authorities” section in the Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9(1), 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 Configuration Guide, Release 4.9(1) 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:
Step 2 Go to Administration > Authorization (Figure 4-3).
Figure 4-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=184.108.40.206, 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 “CCA Manager Certificate” entry in the certificate information table in 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 the “CAS CLI Commands” section in the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 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 SSL certificates. For details, see Typical SSL Certificate Setup on the CAS and Troubleshooting Certificate Issues in this guide, and the corresponding sections of the CAS guide.
4. 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 the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 and Cisco NAC Appliance Service Contract/Licensing Support for more details.
5. 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
6. If the CAS is a Virtual Gateway, make sure the CAM and CAS are on different subnets (or VLANs).
7. 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.
8. Check the CAM Event Log (under Monitoring > Event Logs). This can help pinpoint license and other issues.
9. Make sure there are no firewall rules blocking RMI ports (see the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 for details):
10. Perform service perfigo restart on both the CAM and CAS.
11. Perform service perfigo reboot on both CAM and CAS.
12. Contact TAC. See Obtaining Documentation and Submitting a Service Request, page xv .
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 Configuration Guide, Release 4.9(1).
Configure Network Settings for the CAS
This section describes the following:
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 4-4.
Figure 4-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.
The IP form in the Network tab (Figure 4-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 4-5 CAS Network IP Settings
2. The CAS IP form includes the following settings:
– In-Band: Virtual Gateway or Real-IP Gateway
– OOB: Out-of-Band Virtual Gateway or Out-of-Band Real-IP Gateway
- 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 and 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 NAC 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 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 NAC Agent —When this option is enabled, the CAS verifies the source MAC address of user packets against the MAC address sent by the 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.
Note • If 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 the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 and Getting Started with Cisco NAC Network Modules in Cisco Access Routers.
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 the “CAS CLI Commands” section in the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 for more information.
- Trusted Interface— The 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 and the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 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.
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 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 Chapter2, “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 the Cisco NAC Appliance Hardware Installation Guide, Release 4.9). 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 gateway clients get a new IP address after successful authentication and certification.
Note If using a version 220.127.116.11 or later 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 Configuration Guide, Release 4.9.
Enable Network Access (L3, L3 Strict or L2 Strict)
By default, Cisco NAC Appliance supports In-Band web login and 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 Agent clients from connecting to the Clean Access Server through NAT devices.
For L2 discovery, the Agent sends SWISS discovery packets to all the default gateways of all the adapters on the machine on which the Agent is running. If a CAS is present either as the default gateway (Real-IP Gateway) or as a bridge before the default gateway (Virtual Gateway), the CAS will respond and the Agent will attempt to authenticate the CAS before launching a login session.
Note This function does not apply to the Cisco NAC Web Agent.
If the CAS does not respond via L2 discovery, the Agent performs L3 discovery (if enabled). The 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 Agent. The Agent then attempts to authenticate the CAS before launching a login session
Note To discover the CAS, the 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 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 4-5).
2. Click Update.
3. Click Reboot.
Note For 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 Agent and Web Login users:
1. Go Device Management > CCA Servers > Manage [CAS_IP] > Network and uncheck the option for “ Enable L3 support ” (see Figure 4-5).
2. Click Update.
3. Click Reboot.
VPN/L3 Access for Agents
The Clean Access Manager, Clean Access Server, and 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 Agent from the CAS through the Agent download 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 the following ways:
– Agent Download web page (i.e., via web login)
– Auto-Upgrade to Agent version 18.104.22.168 or later
– “Launch Cisco NAC Web Agent” web page
- You can enable SSO by integrating Cisco NAC Appliance with Cisco VPN Concentrators and/or Cisco Adaptive Security Appliances (ASAs).
Note • Uninstalling the Agent while still on the VPN connection does not terminate the connection.
- For VPN SSO deployments, if the Agent is not downloaded from the CAS and is instead downloaded by other methods (e.g. the Cisco Software Download Site), 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 Software Download Site), 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 Agent clients from connecting to the Clean Access Server through NAT devices using the Enable L3 strict mode to block NAT devices with NAC 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 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 NAC 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 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 NAC Agent —When this option is enabled, the CAS verifies the source MAC address of user packets against the MAC address sent by the 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 Agent users to be connected to the Clean Access Server directly as their only gateway using the Enable L2 strict mode to block L3 devices with NAC Agent option.
When this feature is enabled, the 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 an Agent
1. Device Management > CCA Servers > Manage [CAS_IP] > Network > IP. The management pages appear for the chosen Clean Access Server appear.
Figure 4-6 CAS Network Tab
2. Click the checkbox for Enable L2 strict mode to block L3 devices with NAC Agent.
3. Click Update.
4. Click Reboot.
Note • 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.
- L3 and L2 strict options are mutually exclusive; enabling one option disables the other.
See the “Cisco NAC Appliance Agents” chapter of the Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9(1) for additional information.
Connecting to the CAS Using the SWISS Protocol
This section describes the SWISS proprietary session initiation protocol the Agent uses to discover and initiate client machine connection to the CAS. This section contains the following topics:
What is the SWISS Protocol?
The 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).
To enhance network security and adhere to FIPS 140-2 compliance, Cisco NAC Appliance encapsulates SWISS communications between client machines and CASs, including Discovery Packet transmission/acknowledgement, authentication, and posture assessment results using the HTTPS protocol. The SWISS mechanism also features an enhanced handler that uses 3DES encryption for SWISS protocol functions.
Note SWISS protocol interaction only applies between the CAS and the Windows and Macintosh Agents. The Cisco NAC Web Agent does not connect to the CAS using the SWISS protocol.
Figure 4-7 outlines the basic Agent discovery and login session initiation process.
Figure 4-7 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 Agent starts sending UDP discovery packets on both ports 8905 and 8906.
2. The CAS intercepts SWISS discovery packets and responds to the Agent with the CAS certificate and instructs the Agent to initiate a user login session on the client machine.
3. The Agent and CAS engage in a SWISS protocol request-response exchange to determine:
– Authenticity of the CAS prompting login from the Agent
– 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
– Agent upgrade version, availability, and messaging
– SSO status (Windows Agents 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 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 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 Agent displays the user login dialog on the client machine.
Note In a Layer 3 Out-of-Band deployment, Cisco recommends adding an ACL on your network access switch(es) to prevent SWISS packets from traversing the access VLAN. This simultaneously cuts down on unnecessary packets on the access network, and can help prevent authentication looping on the client machine when SWISS packets make it back to the CAS.
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 Agent uses to address Layer 3 discovery packets by right clicking on the Agent icon on the client taskbar and selecting Properties to bring up the Agent Properties and Information dialog (Figure 4-8).
Figure 4-8 Discovery Host Address in Agent Properties Dialog
In order for the 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 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 Agent installer 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 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 Agents get updated if the Discovery Host IP address changes on the CAM. You can accomplish this in one of the following ways:
Cisco NAC Agent on Windows Client Machines
- Change the DiscoveryHost parameter in the Agent configuration XML file ( NACAgentCFG.xml) and upload it to the CAM so users will automatically get the new XML file at their next login, or make the Agent update mandatory so that when users download the Agent update, the client machines are automatically updated to direct queries to the new Discovery Host address.
Note For details on using the Discovery Host parameter in Windows and Macintosh versions of the Clean Access Agent, refer to the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.5(1) and Release Notes for Cisco NAC Appliance, Version 4.5(1).
VPN SSO Considerations
If users are connected to the network through an existing VPN connection and the 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 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
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. To help ensure client machines are able to discover and authenticate with a Clean Access Server in a network featuring this sort of inherent latency, you can specify a value for the setting in the NACAgentCFG.xml Agent configuration file to affect the behavior of client machines where the Cisco NAC Agent is installed. For more details, see the “Cisco NAC Agent XML Configuration File Settings” section in the Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9(1).
Note For details on configuring this feature for Windows and Macintosh versions of the Clean Access Agent, refer to the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.5(1) and Release Notes for Cisco NAC Appliance, Version 4.5(1).
Using Layer 3 SWISS Packet Delay to Conserve Bandwidth
In an effort to cut down on discovery packet transmission on the network, the 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 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 Client Machine
The Cisco NAC Appliance system supports 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 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 Agent session. To address this potential problem, when responding to a 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 Configuration Guide, Release 4.9(1).
Figure 4-9 illustrates a common scenario where the CAS behavior helps avoid a potential problem. If the user logs in to the network via an 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 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 4-9 Multiple Active Interfaces Pointing to the Same CAS eth1 IP Address
Configuring Managed Subnets or Static Routes
This section describes the following:
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 4-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].
Note • For 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) for details.
Table 4-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)
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 4-11.
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 4-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 4-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 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 4-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.
6. Reboot. A reboot is needed after adding a managed 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 4-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 4-13 illustrates a Layer 3 deployment scenario that requires a static route.
Figure 4-13 Static Route Example (Layer 3)
Configuring Static Routes for Layer 2 Deployments
Figure 4-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 4-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 4-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 4-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.
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 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 the Cisco NAC Appliance Hardware Installation Guide, Release 4.9.
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 Configuration Guide, Release 4.9 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 4-17.
Figure 4-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.
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.
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 4-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 4-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:
Discard all unmapped VLAN packets
Discard all VLAN packets regardless of mapping
Potential Layer 2 UDP broadcast storm due to VLAN packet loop
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 4-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 Configuration Guide, Release 4.9(1) for details.
Note 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. See CAS Fallback Policy 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 4-21 Local Device Filters List
Step 2 Click New. The New local filter form appears as shown in Figure 4-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:
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:
- ALLOW— IB - bypass login, bypass posture assessment, allow access
- DENY— IB - bypass login, bypass posture assessment, deny access
- ROLE— IB - bypass login, bypass L2 posture assessment, assign role
- CHECK— IB - 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):
Figure 4-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 4-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 4-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 the Cisco NAC Appliance Hardware Installation Guide, Release 4.9 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.
Note If the CAS enters Fallback mode and the Enable Heartbeat Timer option is enabled in the Device Management > CCA Servers > Manage [CAS_IP] > Misc > Heartbeat Timer web console page, user sessions are still terminated and cleared from the Online Users List and Certified Devices List after the specified time period has passed. For more information, see Local Heartbeat Timer.
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.5(1), 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 4-25 CAS Fallback
Step 2 From the Fallback Polic y 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 4-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.5(1) and later. 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 4-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 4-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 4-2 Sample CAS Fallback Settings and Results
Detect Interval (specify)
Number of CAS Polls over Detect Timeout
Fail Percentage 25%-50%
Number of Failed Polls to Trigger CAS Fallback (CAS Polls x Fail Percentage)
(100 - Fail Percentage/2)
Number of Successful Polls over Detect Timeout for CAS to Resume Operation
(CAS Polls x Resume Percentage)
5 (4.5 rounded up)
13 (12.75 rounded up)
26 (25.5 rounded up)
88% (87.5% rounded up)
18 (17.5 rounded up)