Security

Hi Guys,

 

Quick question, I hope.

 

I'm using a 7210 controller and 2 x CPPM devices.

 

Dell OS Version 6.3.1.10

Dell CPPM Version 6.3.4.65370

 

I've configured a guest SSID with a CPPM guest captive portal. The captive portal URL points to the DNS name which resolves to the Virtual IP address.

 

I've setup self registration but it's redirecting back to the captive portal login page after sucessful authentication.

I'm also using the CPPM Virtual IP as my RADIUS server for this SSID on the controller.

 

When I swap the portal URL to CPPM1 server and use CPPM1 as the RADIUS it works.

 

I need to do some more investigation before I say what I think is happening.

 

Can anyone tell me why this is happeninig?

 

Cheers

J

#7210

Do you have the VIP as your AAA radius server in your controller ?

Hi Victor,

Yes I do.

Is COA enabled for the VIP as a RFC3576 in your controller

Well, if you're doing normal guest captive portal with Controller Initiated login then CoA doesn't come into account during this first login.

 

Since you have CPPM VIP I'm assuming this this a CPPM cluster setup using Publisher - Subscriber as Standby Publisher. Can you verify that the cluster is in sync and that your cppm1 is designated Publisher?

 

Any related entries in the Access Tracker and Event viewer you can share?

 

 

Other thoughts..

What you describe tho is a common scenario when Radius doesn't go through, is rejected due to missing/wrong Radius config (secret, wrong controller IP used as device etc), the correct service doesn't hit. 

-> Is there perhaps some firewall/access list denying Radius from Controller to the VIP?

 

Anything in the logs on the controller?

 

 

The VIP appears to be associated with CPPM2 as when I browse to it I can clearly see that it's not the publisher I'm on.

 

CPPM1 is my designated publisher.

 

However when I look at the VIP settings it's telling me that the VIP is associated with CPPM1.

 

Here you can see the publisher is set to 002 which is CPPM1 with a .162 address

 

Here you can see the VIP is associated with 002 (CPPM1) 

 

When I browse tot he VPN you can see I'm not on the publisher!

 

Thoughts?

Well - not anything good ;)

 

Check the VIP settings when logged on to the CPPM2. Verify that VIP settings show the same as on CPPM1.

Is this a production system or can you try some things like stopping/starting VIP service on both CPPM's, deleting VIP and re-establishing it.. Try pinging the VIP address at intervals when you do this to see if it stops responding when it should ;)

 

 

I rebooted CPPM2 whilst pinging the VIP. The VIP stopped responding to pings till CPPM2 came back online.

 

service restart all on CPPM1 seems to have "woken" it back up.

 

The VIP appears to be working ok now.

 

Thanks Guys.

Great news!

If you don't mind me asking - is this a new installation so that there hasn't been any reboots after VIP and Cluster was established?

 

Just adding to my own "experience database" for future reference :)

 

Actually it's still broken. Always seems to point at CPPM2 even though CPPM1 is up.

 

Also I just rebooted CPPM2 and checked the VIP which stopped responding to pings and it showed as not being assigned. 

 

Will call TAC. Dell TAC though. :(

Are these virtual or hardware appliances?

 

If virtual, are your vSwitches configured to Accept Forged Transmits?

 

They're physical appliances.

Both ClearPass instances think they're the active virtual IP host.

 

 

We've removed and re-added the virtual IP setting to no avail. Dell and Aruba TAC are investigating.

Removed Virtual IP settings

Removed standby publisher settings

Dropped subscriber

Ran make subscriber

Added virtual IP settings

Checked and both nodes still show as the current node of virtual IP.

 

Anyone else running virtual IP settings??

The only time I have seen that issue is where there is a firewall between and the heartbeat is being blocked between the cluster from the subscriber.

Installed the same setup you have at a customer site with VIP - no problems.
You sure there is wide open Layer2 connection between those two boxes? Just asking since problems in that area could give those symptoms.

Customer assures me there's no firewall between the clearpass instances. They're both on the same VLAN within the same building. 

UPDATE!

 

To rule out the wired infrastructure we patched both ClearPass instances into the same switch. We still saw the same behaviour though.

Tried patching both ClearPass into another switch and boom! Well not boom, but VRRP started working as expected.

 

Looked like an issue with the Dell switch the customer was using.

 

Well done! Thanks for providing the solution to this problem.

Additional information...

 

Clearpass is using UCARP not VRRP to share a common virtual IP address between instances.

 

Currently Dell switches (see details below) do not support the UCARP protocol. 

As mentioned disabling IGMP snooping is a workaround to get this working.

 

UCARP has been put forward as a feature request.

 

Switch details:

Dell Networking N2048P

OS 6.0.1.3

 

May not be limited to this model and OS.

Cheers
James