Clean Access Server Operating Modes
The Clean Access Server can operate in one of the following in-band (IB) or out-of-band (OOB) modes:
- IB Virtual Gateway (L2 transparent bridge mode)—Operates as a bridge between the untrusted network and an existing gateway, while providing posture assessment, filtering and other services.
- IB Real-IP Gateway —Operates as the default gateway for the untrusted network.
- OOB Virtual Gateway (L2 transparent bridge mode)—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).
- OOB Real-IP Gateway —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).
The Clean Access Manager can control both in-band and out-of-band CASs in its domain. However, the Clean Access Server itself must be either in-band or out-of-band.
For more information on OOB configuration in the CAM, see the Cisco NAC Appliance - Clean Access Manager Configuration Guide, Release 4.9(x). The following sections further describe each CAS operating mode.
In the Real-IP Gateway configuration, the Clean Access Server operates as the default gateway for untrusted network (managed) clients. All traffic between the untrusted and trusted network passes through the Clean Access Server, which applies the IP filtering rules, access policies, and any other traffic handling mechanisms you configure.
Figure 2-1 Real-IP Gateway Configuration
When using the Clean Access Server as a Real-IP Gateway, you need to specify the IP addresses of its two interfaces: one for the trusted side and one for the untrusted side. The two addresses should be on different subnets. The Clean Access Server can manage one or more subnets, with its untrusted interface acting as a gateway for the managed subnets. For details on setting up managed subnets, see Configuring Managed Subnets or Static Routes.
The Clean Access Server does not advertise routes. Instead, static routes must be added to the next hop router indicating that traffic to the managed subnets must be relayed to the Clean Access Server’s trusted interface.
Note In Real-IP Gateway mode, the CAS can send traffic out of the trusted port in one VLAN only. You cannot configure the switch port connecting to the trusted port of the CAS as a trunk port.
Additionally, when the Clean Access Server is in Real-IP Gateway mode, it can act as a DHCP server or relay. With DHCP server functionality enabled, the CAS provides the appropriate gateway information to the clients, that is, the appropriate gateway IP held by the CAS for the particular managed subnet. If the CAS is working as a DHCP relay, then the DHCP server must be configured to provide the managed clients with the appropriate gateway information (that is, the appropriate gateway IP held by the CAS for the particular managed subnet). For further details, refer to Configuring Managed Subnets or Static Routes and Chapter 5, “Configuring DHCP”.
In Virtual Gateway deployment, the Clean Access Server operates as a standard Ethernet bridge, but with the added functionality provided by the IP filter and IPSec module. This configuration is typically used when the untrusted network already has a gateway and you do not wish to alter the existing configuration.
For example, if there are two untrusted subnets, 10.1.1.0/24 and 10.1.2.0/24, with gateways 10.1.1.1 and 10.1.2.1, respectively, the CAS in Virtual Gateway mode is deployed between the untrusted subnets and their gateways (Figure 2-2). The untrusted subnets are configured as “Managed Subnets” in the CAS. Note especially that:
- The CAS needs to have an IP address on each managed subnet.
- Traffic from clients must pass through the CAS before hitting the gateway.
Figure 2-2 Virtual Gateway Configuration
When the CAS is a Virtual Gateway:
- The CAS and CAM must be on different subnets.
- eth0 and eth1 of the Clean Access Server can have the same IP address.
- All end devices in the bridged subnet must be on the untrusted side of the CAS.
- The CAS should be configured for DHCP forwarding.
- Make sure to configure managed subnets for the CAS. For the example in Figure 2-2, you would configure two managed subnets:
– 10.1.1.2 / 255.255.255.0 1001
– 10.1.2.2 / 255.255.255.0 1002
When the CAS is an Out-of-Band Virtual Gateway, the following also applies:
- The CAS and CAM must be on different VLANs.
- The CAS should be on a different VLAN than the user or Access VLANs.
Note ● For Virtual Gateway (In-Band or OOB), Cisco recommends connecting the untrusted interface (eth1) of the CAS to the switch only after the CAS has been added to the CAM via the web console.
- 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 Configure VLAN Mapping.
Central Versus Edge Deployment
The Clean Access Server can be deployed either centrally or at the edge of your network. A central deployment reduces the number of Clean Access Servers you need to deploy, facilitating management and scalability. In a central deployment, the Clean Access Server can be configured to perform either routing or bridging for the untrusted network.
Cisco NAC Appliance allows you to achieve multi-hop L3 deployment if you want to move the CAS several hops away from users.
Routed Central Deployment (L2)
In a routed central deployment, the Clean Access Server is configured to act as the Real-IP Gateway for each of the subnets that you wish to manage.
The specific steps to deploy a centrally routed Clean Access Server in a typical network include:
1. Turn off routing on your existing Layer 3 switch or router for the subnets that you wish to manage through the CAS.
2. Configure the untrusted interface of the CAS to be the gateway for the managed subnets.
3. Configure the default gateway of the CAS’s trusted interface to be the L3 switch or the router.
4. Add static routes on the L3 switch or router to route traffic for the managed subnets to the CAS's trusted interface.
5. If using your own DHCP server, modify its configuration so that the default gateway address that the DHCP server passes to clients with the lease is the address of the CAS’s untrusted interface.
Note Agent communication with the CAS requires a Maximum Transmission Unit (MTU) of 1500 bytes. In routed or tunneled environments (like VPN, GRE, Metro Ethernet etc.), all hops must allow 1500 byte packets or support Path MTU Discovery (PMTU-D).
If there appears to be an issue with Agent communication in such environments yet basic IP connectivity has been verified, evaluate the MTU end-to-end. Please contact your Cisco WAN support representative for specific options to address this requirement.
In a VLAN-enabled environment, multiple VLANs are trunked through a single Clean Access Server. Aggregating multiple VLANs—organized by location, wiring, or shared needs of users—through a single CAS (by VLAN trunking) can help to simplify your deployment. Figure 2-3 shows a centrally-routed deployment:
Figure 2-3 Routed Central Deployment in a VLAN-Enabled Network
Multi-Hop L3 Deployment
You can choose to deploy the CAS either closer to the edge of the network or several hops away from the network. With centralized L3 deployment, the CAS(es) may be placed several hops away from users. Multi-hop L3 deployment allows:
- Easier deployment. The CAS(es) are deployed between routers, spanning VLANs is not necessary and fewer CASs are needed.
- Not every packet has to go through the CAS. User traffic only needs to traverse the CAS for trusted network access.
However, note that Cisco NAC Appliance policies are enforced at the CAS only. Traffic which does not reach the CAS is not subject to policy enforcement.
The specific steps to deploy a centrally routed Clean Access Server in a typical network include:
1. Enable L3 on the CAS by going to Device Management > CCA Servers > Manage [CAS_IP] > Network and clicking the checkbox for Enable L3 support for Clean Access Agent.
2. Managed subnets should be configured for user subnets that are Layer 2 adjacent to the CAS. For user subnets that are one or more hops away from the CAS, static routes should be configured. Hence if enabling L3 support on the CAS, for the L3 users configure their subnets under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > Static Routes and NOT under Device Management > CCA Servers > Manage [CAS_IP] > Advanced > Managed Subnets.
3. Ensure the IP address in the Discovery Host field under Device Management > Clean Access > Clean Access Agent > Installation is the correct address for your network.
4. If enabling the L3 multi-hop feature for VPN concentrator integration, perform all the configuration described in Chapter6, “Integrating with Cisco VPN Concentrators”
Bridged Central Deployment
In a central deployment with the Clean Access Server configured as a bridge (Virtual Gateway), VLAN trunks are used to aggregate the traffic from the managed subnets to the CAS before being forwarded to their respective gateways on the L3 switch or router.
To ensure that no path exists from the clients to the gateway, Cisco recommends deploying a switch that aggregates all VLANs to the untrusted interface of the CAS, while the trusted interface of the CAS is directly connected to the L3 switch or the router, as shown in Figure 2-4. Note that the Clean Access Server interfaces will be connected to trunked ports and should provide VLAN passthrough.
Figure 2-4 Bridged Central Deployment in a VLAN-Enabled Network
While central deployment has advantages in terms of reducing the number of required Clean Access Servers, a central deployment is not always possible. For example, if using gigabit throughput to your network’s edge, an edge deployment is required. In edge deployment, the Clean Access Server is placed between each managed subnet and router in the network, as illustrated in Figure 2-5. This allows the Clean Access Server to continue to capture MAC addresses for the devices to be managed. In edge deployment, the CAS can act as either a Virtual Gateway or a Real-IP Gateway.
Figure 2-5 Edge Deployment