02-24-2017 02:26 AM
We have got CPPM guest portal authenticating the users (webauth). We have three groups of people.
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.
- If I use the “terminate session”, whether the user requires to connect back to wireless again?.
- How wireless controller will store the vlan id for the particular user and allow users to connect back without authenticating users.
02-24-2017 04:21 AM
02-24-2017 04:45 AM
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?
02-24-2017 04:48 AM
02-24-2017 04:48 AM
02-24-2017 06:22 AM
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.
02-27-2017 04:49 AM
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.
If you have urgent issues, please contact your Aruba partner or Aruba TAC.
02-28-2017 12:59 AM
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..
-ACMX #316 :: ACCP-
Intelecom - Norway
Remember to Kudo if a post helped you! || Problem Solved? Click "Accept as Solution" in a post!