Wireless Access

We are in the process of setting up Airgroup on our test controller running 6.3.1.2.  We've noticed that even though our system settings on the controller are setup to send all radius packets from our loopback address, it seems that the Airgroup radius packets are getting sent from the VRRP address of the controller.

We noticed this since we only had the loopback of the controller setup in our clearpass radius server.

Has anyone else noticed this behaviour?  Is it a bug?

- Zachary

The nas-ip parameter is something that is user-configurable in the Radius definition on the Aruba Controller.  Check to see if that is something that is configured to the VRRP.  If so, remove it and see if that changes.

I do have my source interface configured:

ip radius source-interface loopback

... so this is why I'm saying that the airgroup radius packets are ignoring this config entry

That is not what I am talking about.  In each radius server, you can define a nas-ip:.  That could be overriding your source interface parameter.  Please check:

I checked that and there is nothing configured in the NAS IP or Source Interface field of the radius server configuration.

Where is the radius message that says it is comin from the wrong interface?

In my clearpass setup, I had only configured the loopback of my controller as a valid radius client.  When I was setting up airgroup, I noticed that I wasn't seeing the request come in so when I went into my clearpass event viewer, I saw the radius requests coming in from an 'unknown host' which turned out to be the ip address of the vrrp interface on my controller.

Please open up a case with TAC.  thank you.

I'm currently experiencing this same problem although perhaps slightly different, running 

6.3.1.2 as well.

I have noticed that regardless of entering system settings on the controller to send all radius packets from a specific VLAN, or as cjoseph suggested setting the nas-ip parameter. All Airgroup radius packets are coming from the incorrect VRRP address.

I also stumbled upon this because only one of the VRRP addresses had been setup in our clearpass radius server.

Currently the controllers have two vrrp addresses a 10.16.x.x for corporate and a 192.168.x.x for guest/dmz. For some strange reason the corporate clients (10.16.x.x) requests are coming from the 192.168.x.x address and I can't seem to change it.

Did you have any luck with raising a case mzac?

Thanks for the help.

-Liam

The source interface of the radius packets are configured below:   It is never the VRRP, by default:

Thanks for the prompt reply.

Given that the controller address is 10.16.211.11 with a vrrp address of 10.16.211.10, which reside on vlan 211. Should what I have set in the screenshot below be working? 

I did try "ip radius source-interface vlan 211" previously but it didn't appear to have any effect.

The source interface should NEVER be a VRRP, because you always want to know what controller the request comes from.  You need to configure individual controllers in the Airgroup Settings, anyway.  A VRRP is only really meant to be an inbound load-balancing mechanism.  It is not really meant to be the source ip address of any traffic that is leaving the controller. Make the source VLAN any routable VLAN (preferably the switch-ip or management VLAN).  That ip address will correspond with the "Access Device IP/Port:" parameter i the Radius Access Tracker and is also what you use when you enter the controller(s) as network devices.  When you configure a controller in Airgroup, that is the ip address that is used.  A VRRP is only really meant to be an inbound load-balancing mechanism.  It is not really meant to be the source ip address of any traffic that is leaving the controller.  The NAS-IP address does not really come into play in Airgroup.

I opened a case with TAC and here is what is happening:

Subject: RE: McGill University: Case # 1504447: Controller using wrong source IP for Airgroup radius requests

Hi Zachary,

This issue will be fixed in 6.3.1.5. Please let me know if there is anything else we can assist you with or good to close the case.

mzac,

Thank you.