Security

I have two CP VMs configured in a cluster with a vIP using only the MGMT interface. I am testing radius pointed to the vIP and it looks like it bounces between the publisher and subscriber for authentication. I was watching the access tracker and couldn't see authenication requests come through even though they were suceeding. I found that I had to actually change the filter to both servers to see all the requests because it was bouncing between the two. I also verified that sometimes the subscriber would show the vIP active in the virutal IP settings.    

 

These VMs are in an pretty robust ESX enviroment next to each other connected via 10Gb switches and I don't see any reported issues on the network or software side. 

 

Ideas?

Do you have RADIUS load balancing configured in your server group?

Do you have each individual server listed in your server group or just the VIP?

Right now I am just testing off of a cisco switch configured with just the single vIP address. I'm not aware of any radius load balancing features on clearpass? Or did you mean an Aruba controller? 

Can you have a continuous ping to both and make sure you are not dropping packets ?

What's the value you have setup to switchover to the backup ?

What version of ClearPass do you have installed ?

Can you look in the event viewer and see if there are any Virtual IP service events?

I could be a number of issues. 

 

The main thing to look at is that the VIP is bouncing between the servers. That means that there is a connectivity issue or the radius is locking up.

 

1. Connectivity between the cluster. 

2. If they are VMs make sure you built them to spec.

3. The VIP does not do any fail over it is designed to be for failover only....

4. The main purpose of the VIP in my opinion should be used if you need HTTP failover for guest and onboarding. I would use the capabilities of the NAS device for load balancing. 

Thanks for the help guys, I am still having issues with this. 

 

The VMs are built to spec and haven't been moved to production so utilization is very very low. They live in a pretty robust vSphere enviorment and resources are not an issue. These ESX hosts are connected via 2 x 10Gb cables to Nexus Switches and currently host a variety of other production VMs that do not report or so any signs of network related problems. 

 

I have done continuous ping tests to both VMs MGMT addresses as well as the vIP and I haven't seen a single drop. I'm not sure where to set the vIP settings for failover timeouts or preempt but right now they are set to default. The VMs live on different ESX hosts but in the same datacenter on the same Nexus switches (super close together). 

 

I dont see any events in event viewer referencing the failover, here are the logs showing the server changing. 

 

10.103.160.11 = Primary

10.103.160.12 = Secondary

vIP = 10.103.160.10 which is what the NADs are pointed to

 

1.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:23
2.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:22
3.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:22
4.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:21
5.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:21
6.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:21
7.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:20
8.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:19
9.	10.103.160.12	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:01:19
10.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:08
11.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:07
12.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:06
13.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:06
14.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:05
15.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:04
16.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:03
17.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 12:00:03
18.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 11:59:57
19.	10.103.160.11	RADIUS	test	IT Cisco [Administra	ACCEPT	2014/08/18 11:59:56

I am using version 6.3.4.64924

Does your VMWare server(s) have the allow MAC spoofing enabled?

hi. what version of ClearPass are you using on the VMs? Same on both?

Hi I've seen and experience issues similar to what you've experencing. Typically this has occured when the ESXi host are using Distributed vSwicthes rather than standard vSwitch.

 

Can you please confirm which you are using?

 

I've seen environements where the Distrubuted switchs port security profile limit/suppresses the multicast trafic used for functions like VRRP.

 

Go take a close look at the security settings for the swicthes in general, even if you using standard vSwitch.

We are using distributed vswitches, I will check the security settings now and let you guys know. Thanks again for the help!

Looks like promiscuous mode, mac address changes and forged transmits are all set to reject. I am working with the system admins to get these modified and then I will retest. 

You should only need forged transmits for the distributed switch.

That fixed it, thanks everyone for the help!