Wireless Access

I have a question on cluster some controllers together in regards to the nas-ip and nas-id.

 

Here is a current setup with IP's and VLAN's

3 controller cluster using the IP's 10.10.10.2, 3 and 4 on vlan 10
1 VRRP created as 10.10.10.10 with all 3 controllers using that for like AP discovery

I thought that was all that really needed. I was set up for L2 connectivity and it was all good.

 

I'm reading the ACMP book and was reading on using VRRP addresses for RADIUS COA and all that instead of the phyiscal. I understand the concept of it and would like to implement it in my production for better failover/redundancy.

 

So in my lab I added in a new vlan and new IP's that would be used for a the VRRP for RADIUS requests.

 

controller 10.10.10.2 priority 128 mcast-vlan 0 vrrp-ip 10.10.20.2 vrrp-vlan 20 group 0
controller 10.10.10.3 priority 128 mcast-vlan 0 vrrp-ip 10.10.20.3 vrrp-vlan 20 group 0
controller 10.10.10.4 priority 128 mcast-vlan 0 vrrp-ip 10.10.20.4 vrrp-vlan 20 group 0

 

Now under the authenticating server, I don't have any entries added in for the NAS ID or IP. As well as under the Radius Client section i do not have any NAS IP address or NAS IP source interfaces configured.

On the authenticating server side only the 10.10.10.x addresses are added in. It knows nothing of the 10.10.20.x VRRP addresses. On my client i attempted to connect to the network and it went through and it showed my NAS IP was a 10.10.20.x (VRRP) address.

 

In the book (so far) it doesn't really distinguish between the NAS IP and NAS ID. Can someone please help me understand the difference between the two? If my authenticating server doesn't know of that VRRP IP, how can it authenticate using the physical address? Does it not need to know about the new VRRP subnets? It should be authenticating via the VRRP for redundancy. Does it does this all automatically once the cluster commands are updated with the VRRP-ID and VRRP-VLAN? Does anything else need to be updated and configured?

In the book it says the following. "Figure 6-22 shows a packet cpature, from NAS IP address 10.1.10.201. This is a RADIUS request from MC2 (10.1.10.101). Notice that the NAS-IP is the VRRP IP address 10.1.10.201. The RADIUS client IP should be the real IP of the MC's. "
In that packet capture snippet it shows the NAS IP as the VRRP and the NAS ID as the phyiscal address.

NAS-ID is optional. NAS-IP is required and should match the source IP of the request in relation to the RADIUS server.

So why would my authentication be successful from on that server if the 10.10.20.x VRRP addresses aren't added in?  In the log of that server it showed the NAS IP as that 10.10.20.x subnet. But in theory, that 10.10.20.x subnet should be configured on that authenticating server?

Once the VRRP IP is configured on the controller cluster command, it automatically becomes the RADIUS IP source for that controller?

I am also got confused with this setting.

From my understanding, NAS-IP will be the source address of controller when doing authentication request. (from OS 6.x)

 

When i try configured NAS-P using VRRP address (not VIP-of-CoA) - and only register the VRRP-IP on NPS side, the auth get rejected.

Looking at the logs tell me the source is the real controller IP

 

But when I add controller real IP as NPS rad-client, here are the information collected on auth session (no changes on controller config):

NAS:
	NAS IPv4 Address:	192.168.11.23--> (VIP-CoA)
	NAS IPv6 Address:-
	NAS Identifier:		192.168.11.20 --> (VRRP)
	NAS Port-Type:		Wireless - IEEE 802.11
	NAS Port:		0

RADIUS Client:
	Client Friendly Name:	PDC-21--> registerd on NPS
	Client IP Address:	192.168.11.21 --> (Real IP)

So in the end, I have to add all the controllers IP to NPS ?

 

 

Best Regards

Yopianus Linga

 

Hi,

 

[edit based on actual experience. 03/27/2019]

 

controller real ip will always be used as source address in IP header of Radius request. So only that IP needs to be added to radius clients.

 

Additionally add the Controller Cluster VIP to the radius clients in CPPM.

If you use device groups to select services or to define downloadable user rules, CPPM will try to match the NAS IP to the device group. If you only add the controller real IP to that group, CPPM will not match that device group.

So just adding the real IP to radius clients is good for special cases, where you do not use a match to tha NAS IP. Therefore it is recommended to add both.

- the real IP, cause CPPM matches against this IP to allow the client

- the NAS IP, which is the controller VIP in our case, to be able to match this in policy objects

 

This is also described in the threat, mentioned/linked by jgoff somewhere here in this threat. 

 

[end of edit]

 

If you have a single controller or a cluster without configuring controller-CoA-VIPs, then the real ip will becopied to the radius-NAS-IP-field.

 

If you configure controller-CoA-VIPs for your cluster, then these IPs will be copied to radius-NAS-IP-field. But still real IP is used as source for radius communication.

 

Aruba ClearPass wil send CoA requets to the NAS-IP (not to the real IP).

Thus, if a controller in a cluster with configured CoA-IPs dies, the CoA packets will be send to the controller, who is now owning the CoA-VIP of the broken controller.

 

Not sure, if you can do CoA with NPS and what IP it will use to send the CoA packets to. But usually you leave NAS-IP in controller config at default and let controller decide, which IP to put into NAS-IP.

 

NAS-ID only needs to be altered, if you use that in your policy definitions/decisions.

So I leave this on default settings in most installations.

 

Regards, Jö

 

hi Yopi, take a look over in this thread, post your questions there as Kapildev is actively monitoring the thread.
-jeff