Wireless Access

Hi,

 We have got CPPM guest portal authenticating the users (webauth). We have three groups of people.

1. Guests
2. Contractors
3. Corp

We would like to assign a vlan( or vlan pool) based on the AD user group that user belongs. We have got three groups for the above users in AD. In this case, user gets the ip-address prior to authentication. We can move the users to different vlan based on Radius return parameters (Vlans). However, how to make the clients to release the old address and get the new addresses in a new vlan? I am thinking of using [Aruba Terminate Session] –Radius CoA as a return attribute along with new vlan id.

Questions are

1. If I use the “terminate session”, whether the user requires to connect back to wireless again?.
2. How wireless controller will store the vlan id for the particular user and allow users to connect back without authenticating users.

 

You need to do a server initiated workflow with a CoA disconnect if you want to change VLANs.

Hi Tim,

 

If we initiate that, whether the user needs to connect back the wireless again after vlan switchover. How controller/CPPM stores the successful authentication status to avoid the fresh authentication again..is it via mac address DB?

 

thanks,

The user's device should automatically reconnect.

The authentication is handle via a MAC Auth to ClearPass. You'd need to build a MAC caching service.

The user's device should automatically reconnect.

The authentication is handle via a MAC Auth to ClearPass. You'd need to build a MAC caching service.

Hi Tim,

 

Assume that I am building the mac cache service as you mentioned. I have got 3 different user vlans(corporate, guest, contractors) in the webauth environment. If the user comes back after sometime, will he be put into right vlan using mac cache. 

I think mac cache caches only the mac address of the user. Thanks for your help in advance.

 

 

 

 

Yes, you would build that as part of your policy.

What I did not see mentioned in this thread is that changing VLANs on Captive Portal is something that you should avoid unless it is an absolute necessity.

 

The issue is that with a Terminate Session, the client does not recognize that it needs to re-DHCP for a new IP in the new subnet; so it can be (and I have seen that in practice) that the client is still using the original IP from before captive portal. Most devices need to have a hard link-down for multiple seconds in order to trigger a new DHCP request. There are some reports from people that made this work by 

So unless you are on wired and can force a physical port down (like the HPE Port Bounce on Aruba switches), your deployment might not have the results you expected.There are some reports from people that made this work by 

There are some reports from people that made this work by setting the DHCP timers in the initial captive portal VLAN to a very low value, so the client will try to re-DHCP quickly; but that still seems not fully reliable.

 

If you have Aruba network infrastructure, user-roles are the recommended solution as with those roles you can set the access in the firewall policy for the roles and differentiate access without the need of different VLANs and external firewalling.

 

As Herman Robers pointed out you need to test this thoroughly to ensure the best experience for your users.

 

1. Build this as Tim explained using a server-initiated login workflow. This means WEBAUTH service to authenticate the Captive Portal login, and a RADIUS service which does the mac-authentication.

2. DO NOT change VLAN during captive portal authentication as this WILL cause problems. Instead return a session-timeout with a value of 60 seconds (tune this to your liking - too short will cause problems)

3. After 60 seconds the Controller/IAP will disconnect the client - which will reconnect, the MAC-auth workflow triggers and will return the correct VLAN.

 

NOTE! When testing this make sure the devices you test with does not have a more preferred network.. That will often cause the device to connect back to that network instead of your Guest network..