ClearPass – How to setup a Generic Radius Catch-all Service
One of the common questions that I am asked is “how do I know what attributes I can use to differentiate services in ClearPass. My response is always “have you setup a generic RADIUS catchall service?” Their response is usually “what is that?” I wanted to take a few minutes to share this simple yet very valuable service on CPPM.
So why do we need to setup a Generic RADIUS catch-all service? The purpose of the generic service is to give us visibility into any valid RADIUS request coming into CPPM from a known Network Device and allows us to use the incoming RADIUS attributes in those requests to customize our more specific services to trigger on a particular attribute. Here is a quick example of the attributes that are passed in a RADIUS authentication request:
The first thing we need to do to create a new service. In CPPM select Configuration -> Start Here. This will bring up the Service Template Options. Scroll down and select RADIUS Enforcement (Generic).
This will bring up the Add Service Screen. You will need to enter a name for the newly created service. I like to call it Generic RADIUS Catch-all. Do not add any Service Rules to this service.
Select Next. This will take you to the authentication tab. You will need to select any authentication method that will be used in your network. I typically select EAP MSCHAPv2, EAP PEAP, EAP TLS, EAP TTLS, MSCHAP, CHAP, and PAP. Under the authentication source drop down select Local User Repository.
Select Next. This will take you to the Roles Tab. Since we are only using this service for visibility into the RADIUS attributes sent in a RADIUS request we do not need to perform any Role Mappings.
Select Next. This will take you to the Enforcement Tab. Since we are only using this service for visibility into the RADIUS attributes sent in a RADIUS request we do not need to define a custom Enforcement Profile. Leave the “Sample Allow Access Policy” as the defined Enforcement Policy.
Select Next. This will take you to the Summary tab. You can review the service configuration on this tab. Click Save.
When you click Save you will be taken to the Reorder Service screen. You need to make sure that the Generic RADIUS service that you just created is the LAST SERVICE in the list!!! This will insure that it will not interfere with any customized RADIUS services. With that being said, when you are ready to create the new customized services you need to make sure you reorder them as well so they are processed before the generic service.
The next step is to add your controllers or switches to CPPM as valid NAD devices under Configuration->Network->Devices.
Once your network devices are added all incoming RADIUS Requests will trigger this service. Now you are ready to make a RADIUS user authentication request to see what information CPPM will receive.
This post isn’t ACMX related but I thought someone might find it useful. Today I spent a good part of the day diagnosing client connectivity issues to an Instant AP. Here are a few commands that came in handy:
show clients: Displays basic information about all of the clients that are connected to the swarm.
show clients status <mac of client>: Displays detailed information on a specific client device
And if you really want to get the details on a client:
show ap debug client-table | include <client mac>
Now for the nerdy stuff. The Instant CLI has the capability to do a packet trace on the console to dig into issues with the packet flow across the AP. Here are the commands that you need to run:
debug pkt match <mac/ip/port/vlan> : this sets the value for the source of the traffic that we need to match on
debug pkt <mac/ip/port/vlan> <actual client mac/ip/port/vlan> : identifies the specific source that we are tracking
debug pkt type <arp/icmp/dhcp/tcp/udp/all> : identifies the traffic that we are tracking
debug packet dump: tells the IAP to dump the output to the console
Here is an example of troubleshooting a specific client’s tcp traffic:
debug pkt match mac
debug pkt mac 00:25:9c:f9:be:fc
debug pkt type tcp
debug pkt dump
Yes I know these images suck. I will try to get larger screen grabs tomorrow. Now go have fun grabbing packets.
Once a network has scaled up beyond a single controller capacity, a master/local architecture is recommended. This allows the master controller to handle configuration and correlation while the locals can be responsible for handling the user traffic.
Steps to Add a local controller to an existing Master:
From the Master GUI:
Configuration -> Network -> Controller -> System Settings
– Click New Local Controller IPSec Keys
– Enter the IP Address of the local controller that you are adding
– Enter an IPSec key
– Re-Enter the IPSec key
– Click Add
– Click Apply (don’t forget)
– Save Configuration
Or From the Master CLI:
localip <local ip address> ipsec <ipsec key>
From the Local GUI:
Configuration -> Network -> Controller -> System Settings
– Select Controller Role Drop-Down and select Local
– Enter the Master Controller IP (VRRP address if using master redundancy)
– Enter IPSec Key (Same key you entered on Master)
– Click Apply
– Reboot Controller
Or From the Local CLI:
masterip <master ip address> ipsec <ipsec key>
In order to make the WLAN function, the access points need connectivity to the controller. Let’s review what an AP does during the boot process
Acquire IP address (can be static or acquired from DHCP)
- IP address is required for communication with the controller using PAPI and GRE
- To verify the access point properly acquires an IP you will need console access to the AP
- The AP goes through the following process in trying to discover a controller
- Statically assigned
- DHCP Vendor Option 43
- ADP Multicast: Group Address 188.8.131.52 (requires multicast routing to be enabled on infrastructure)
- ADP L2 Broadcast
- DNS (aruba-master.<localsuffix>
- The AP will follow the sequence exactly as above. Once the AP learns a controller address, it terminates the discovery process and attempts to communicate with the learned address. If the AP doesn’t receive a response from the learned address, then the AP will initiate a full reboot and start the process again
Update Code if necessary
- AP Compares the code level to the controller’s code level
- If the code revision matches the AP will continue the boot process
- If the code revision does not match the AP will obtain the new code from the controller using FTP (TFTP is used on the initial join or if the AP is purged
- The AP will automatically reboot after the code upgrade/downgrade
- “show ap database” shows the current status of each AP (will list if upgrading, rebooting, etc)
Obtain Configuration Information
- Once an AP connects to a controller and has compatible code, it will receive its configuration over PAPI
- “show ap config ap-name <ap-name>” will show the AP configuration being pushed to the AP
Build GRE Tunnel
- GRE is used to carry all of the wireless traffic between the AP and the local controller
- A GRE tunnel is created per SSID per AP
- The AP System Profile Controller LMS-IP setting tells the AP which controller the AP should terminate with
- Be sure to allow Protocol 47 between the controllers and APs
- “show ap debug system-status ap-name <ap-name>” – shows the communication status between the controller and AP
- “show datapath tunnel table” – shows the GRE tunnels established with the controller (look for prt 47)
- “show ap debug counters” – shows how many times an AP has rebooted or bootstrapped
- Once the GRE tunnel has been established the Radios will become enabled
- “show profile-errors” – shows the list of invalid user created profiles. An invalid user profile could cause the AP not to broadcast its assigned SSIDs.
Aruba – Network Ports Needed