Wireless Access

AAA with inital Role for Captive Portal Redirect - Works fine

 

CPPM passes back a Guest role after proper authentication - Seems OK too

 

The Guest Role as defined on the controller has a VLAN configured different from the VLAN configured for the VAP. 

 

The user has the correct ACL's as per the Guest Role assignment but is not getting placed on the VLAN as configured in that same Role. 

 

Show user mac - Shows the correct role but incorrect VLAN

Show station-table - shows the initial role for captive portal redirect still

 

Not sure how to overcome this. If I remove the VLAN from the VAP, then the correct VLAN is assigned per the user role. I however would like to leave this set as the default VLAN for any role passed back. I then want to 'override' the VLAN for specific roles, such as a Contractor Role being passed back. 

 

As a side note, MAC Authentication works properly. The same Guest role being passed back to the controller sets the correct vlan (as defined in the role) and the outputs of the commands above reflect the correct role.

 

What am I doing wrong? Must I leave the VAP VLAN empty and be sure to specify a VLAN in each User Role that would be passed back? That does seem right. 

You can not reliably flip a VLAN on a captive portal user because they already have an IP address.

I see. Makes sense why MAC Auth works. 

 

I am trying to take advantage of the Sponsored Guest feature to allow the Sponsor to pick a role for the registering guest. In this case my client already has vlan's defined with ACL's defined in his infrastructure. The goal was to place the Guest.. such as a Contractor on the appropriate VLAN. 

 

Maybe I CoA the user after initial Guest logon woth MAC Cache, then let the MAC Auth assign the correct role? Not desirable, but maybe a work around. 

Two things:

1) It is deprecated to assign the VLAN by role. The advised method is returning the VLAN with your RADIUS authentication.

2) For the captive portal (extension of what Tim answered), the problem is that when a client has received an IP address in a captive portal, if you just flip the VLAN (which should be possible with the RADIUS return attributes or a CoA), the client will not notice that it suddenly is in another VLAN. That results in loss of connectivity. If you are on wired, a hard port-bounce should work to let the client get a new IP; and some people reported that setting the DHCP lease in the initial VLAN very short (30 seconds-1 minute) worked to some extent but not very reliable. Best practice is to not flip VLANs in Captive Portal unless you cannot solve issues in another way. Ways of solving can be role-based access where you change the access based on the role instead of the VLAN, or dynamic access lists of you are working with non-Aruba equipment.

Thanks for the help guys. I also found this post discussing the DHCP leases. 

 

http://community.arubanetworks.com/t5/Wireless-Access/Radius-COA/td-p/116267

 

 

For others reading this.. I sent Aruba Terminate enforcement after Captive Portal auth. The user came back in and hit MAC Auth service which sent the correct role and vlan combination. SInce this is Pre-IP, it worked perfectly. 

You may want to consider using server-initiated login then instead of controller login so you can eliminate the middle authentication that is not necessary.