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.