Security

Reply
Guest Blogger

ClearPass - not responding to RADIUS

Hello,

 

A customer started complaining that ClearPass wasn't responding to RADIUS requests. ClearPass is used by multiple components for RADIUS and TACACS+ authentication, like Cisco Catalyst switches for wired authentication. In the Cisco switches you get the error message "RADIUS server is dead". 

 

The ClearPass servers were accessible via the GUI, the RADIUS service was running and the issue wasn't continuously present. The customer rebooted the appliances multiple time, but the problem persisted. I asked if they had changed something and they told me they removed the NTP service from their core switch, which was used by one of the ClearPass servers.

 

I did some digging in the /var/log/messages file and I found the following lines at the time the NTP config was removed. It looks like the interface continuously gets disabled and enabled.

 

Has anyone seen this behavior in the past?

 

<6>1 2019-03-11T18:43:14.535873+01:00 clearpass kernel - - - [8726320.715543] br-bdd926241a5c: port 1(veth2646de7) entered disabled state
<6>1 2019-03-11T18:43:14.544877+01:00 clearpass kernel - - - [8726320.724533] br-bdd926241a5c: port 1(veth2646de7) entered disabled state
<6>1 2019-03-11T18:43:14.544888+01:00 clearpass kernel - - - [8726320.724768] device veth2646de7 left promiscuous mode
<6>1 2019-03-11T18:43:14.544889+01:00 clearpass kernel - - - [8726320.724776] br-bdd926241a5c: port 1(veth2646de7) entered disabled state
<6>1 2019-03-11T18:43:14.654867+01:00 clearpass kernel - - - [8726320.834767] device veth9988b5c entered promiscuous mode
<6>1 2019-03-11T18:43:14.654880+01:00 clearpass kernel - - - [8726320.834849] IPv6: ADDRCONF(NETDEV_UP): veth9988b5c: link is not ready
<6>1 2019-03-11T18:43:14.654881+01:00 clearpass kernel - - - [8726320.834852] br-bdd926241a5c: port 1(veth9988b5c) entered forwarding state
<6>1 2019-03-11T18:43:14.654882+01:00 clearpass kernel - - - [8726320.834855] br-bdd926241a5c: port 1(veth9988b5c) entered forwarding state
<6>1 2019-03-11T18:43:15.151861+01:00 clearpass kernel - - - [8726321.331805] IPv6: ADDRCONF(NETDEV_CHANGE): veth9988b5c: link becomes ready
<30>1 2019-03-11T18:43:18.500046+01:00 clearpass ntpd 9025 - -  Listen normally on 105 veth9988b5c fe80::e4fe:11ff:fe61:72c2 UDP 123
<30>1 2019-03-11T18:43:18.500309+01:00 clearpass ntpd 9025 - -  Deleting interface #104 veth2646de7, fe80::c9:3fff:fe8e:5468#123, interface stats: received=0, sent=0, dropped=0, active_time=943291 secs
<6>1 2019-03-11T18:43:21.500854+01:00 clearpass kernel - - - [8726327.680722] br-bdd926241a5c: port 1(veth9988b5c) entered disabled state
<6>1 2019-03-11T18:43:21.508353+01:00 clearpass kernel - - - [8726327.688448] br-bdd926241a5c: port 1(veth9988b5c) entered disabled state
<6>1 2019-03-11T18:43:21.508365+01:00 clearpass kernel - - - [8726327.688702] device veth9988b5c left promiscuous mode
<6>1 2019-03-11T18:43:21.508366+01:00 clearpass kernel - - - [8726327.688709] br-bdd926241a5c: port 1(veth9988b5c) entered disabled state
<6>1 2019-03-11T18:43:21.682860+01:00 clearpass kernel - - - [8726327.862968] device veth62e77a2 entered promiscuous mode
<6>1 2019-03-11T18:43:21.682871+01:00 clearpass kernel - - - [8726327.863044] IPv6: ADDRCONF(NETDEV_UP): veth62e77a2: link is not ready
<6>1 2019-03-11T18:43:21.682872+01:00 clearpass kernel - - - [8726327.863048] br-bdd926241a5c: port 1(veth62e77a2) entered forwarding state
<6>1 2019-03-11T18:43:21.682873+01:00 clearpass kernel - - - [8726327.863053] br-bdd926241a5c: port 1(veth62e77a2) entered forwarding state
<6>1 2019-03-11T18:43:21.936862+01:00 clearpass kernel - - - [8726328.116832] IPv6: ADDRCONF(NETDEV_CHANGE): veth62e77a2: link becomes ready
<30>1 2019-03-11T18:43:25.500095+01:00 clearpass ntpd 9025 - -  Listen normally on 106 veth62e77a2 fe80::c85:2cff:fe46:bd03 UDP 123
<30>1 2019-03-11T18:43:25.500573+01:00 clearpass ntpd 9025 - -  Deleting interface #105 veth9988b5c, fe80::e4fe:11ff:fe61:72c2#123, interface stats: received=0, sent=0, dropped=0, active_time=7 secs

In the end, the customer restored the NTP server on the core switch, restored the VM from a backup and removed and added the subscriber again. The problem was resolved after these steps.

@rene_booches | AMFX #26, ACMX #438, ACCX #725, ACDX #760, CCNP R&S, CEH | Co-owner/Solution Specialist@4IP / blog owner@booches.nl
MVP Guru

Re: ClearPass - not responding to RADIUS

It is highly recommanded to configure NTP server on publisher, after removing NTP server details from publisher does time is in sync?

Regards,
Pavan
If my post address your queries, give kudos and accept as solution!
NOTE: Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba or Hewlett Packard Enterprise.
Guest Blogger

Re: ClearPass - not responding to RADIUS

Time is now in sync again. The cluster uses 2 NTP servers:

  1. Primary: core switch
  2. Secondary: domain controller

There were no changes in the NTP configuration on ClearPass. The NTP service on the core switch was stopped in the morning and in the evening (around 6:45 PM) the problems started.

 

@rene_booches | AMFX #26, ACMX #438, ACCX #725, ACDX #760, CCNP R&S, CEH | Co-owner/Solution Specialist@4IP / blog owner@booches.nl
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: