Wireless Access

Hi all.

I am trying to configure guest network with open ssid and using internal captive portal. authentication is done in clear pass and authenticated role is pushed to controller from clearpass. 

Before authentication role is logon and 1001 is the vlan assignment to the role. I am getting the IP addres from 1001.

After authentication role is guest and 203 is vlan assignment to the role but i am unable to get the ip address  and doesnt change from 1001.

Is it possible to change vlans when we are doing with L3 authentication??

Not possible with Captive Portal, because the physical devices does not know that the layer 2 network has changed in the background.  There is a way, where you can give a DHCP lease on the initial VLAN of 30 seconds or less and the client will re-dhcp and get an ip address on the new VLAN, but it is not practical.

I am able to get the new role .

---

@cjoseph wrote:

Not possible with Captive Portal, because the physical devices does not know that the layer 2 network has changed in the background.  There is a way, where you can give a DHCP lease on the initial VLAN of 30 seconds or less and the client will re-dhcp and get an ip address on the new VLAN, but it is not practical.

---

Actually i have tried to release and renew the ip address but still it didnt changed.

This is after the client has authenticated via captive portal?  Are you sure that you are allowing DHCP traffic in the post-authentication role?

---

@cjoseph wrote:

This is after the client has authenticated via captive portal?  Are you sure that you are allowing DHCP traffic in the post-authentication role?

 

---

For post authentication role, i have allowed all

Does DHCP work on the new VLAN?  Does "show user-table verbose" show that the user has been switched to the new VLAN?

yes dhcp on controller is configured.

and i have checked user-table verbose. I can see role assigned but vlan is not changing.

Changing vlan by specifying in the new role doesn't work for L3 authentication like captive portal. 

In the CLI guide for command 'user-role <role> vlan x'

Identifies the VLAN ID or VLAN name to which the user role is
mapped. This parameters works only when using Layer-2
authentication such as 802.1X or MAC address, ESSID, or
encryption type role mapping because these authentications
occur before an IP address is assigned. If a user authenticates
using a Layer-3 mechanism such as VPN or captive portal this
parameter has no effect.

 You could probably switch the vlan by having a server derivation rule based on an attribute returned by Clearpass, but I've not tested exactly that for captive portal.  You would still need the short initial lease as Colin mentioned though.

---

@Michael_Clarke wrote:

Changing vlan by specifying in the new role doesn't work for L3 authentication like captive portal. 

 

In the CLI guide for command 'user-role <role> vlan x'

 

Identifies the VLAN ID or VLAN name to which the user role is
mapped. This parameters works only when using Layer-2
authentication such as 802.1X or MAC address, ESSID, or
encryption type role mapping because these authentications
occur before an IP address is assigned. If a user authenticates
using a Layer-3 mechanism such as VPN or captive portal this
parameter has no effect.

 You could probably switch the vlan by having a server derivation rule based on an attribute returned by Clearpass, but I've not tested exactly that for captive portal.  You would still need the short initial lease as Colin mentioned though.

 

 

---

So , Switching vlan based on roles is done only in L2 authentication i.e 802.1x and mac authentication?

correct.  It won't work for captive portal.  Having said that, you don't need to return the Aruba role.  A simple 'radius-accept' will put the user into the correct authenticated role.

If you return an attribute such as Filter-Id=guest-vlan as well, then in your server-group you create a vlan derivation rule based on that attribute.  Hopefully then the user will be in the authenticated role AND the correct vlan.

Or you can use the Aruba VSA attributes for this

Aruba-User-VLAN
Aruba-Named-User-VLAN

---

@Michael_Clarke wrote:

correct.  It won't work for captive portal.  Having said that, you don't need to return the Aruba role.  A simple 'radius-accept' will put the user into the correct authenticated role.

 

If you return an attribute such as Filter-Id=guest-vlan as well, then in your server-group you create a vlan derivation rule based on that attribute.  Hopefully then the user will be in the authenticated role AND the correct vlan.

 

Or you can use the Aruba VSA attributes for this

 

Aruba-User-VLAN
Aruba-Named-User-VLAN

---

I have tried pushing aruba user role and aruba user vlan from server(clear pass). Then only role is getting updated by the controller.

then i have tried pushing only user vlan. Then im continoulsy getting portal page to login. as the role is not changing nor the ip address.

Changing a user's vlan is fraught with difficulties, especially if they already have an ip in a different vlan.

This WILL break many iOS devices and various apps will stop working cause they think they are still on the old vlan.

Forget about changing the vlan.....you life will be so much easier.

I understood that switching vlan based on roles doesnt happen during L3 authentication. But we can achieve it in L2 authentication.

Cheers

srikanth soogoor

yes for L2 and dot1x auth, it works nicely.  You just specify the vlan in the role.

Be warned though if you try it with dhcp fingerprinting, you will get mixed results, particularly with iOS devices.  Many things will stop working even though they have an ip in the correct vlan and they are in the correct role.

---

@Michael_Clarke wrote:

yes for L2 and dot1x auth, it works nicely.  You just specify the vlan in the role.

 

Be warned though if you try it with dhcp fingerprinting, you will get mixed results, particularly with iOS devices.  Many things will stop working even though they have an ip in the correct vlan and they are in the correct role.

---

Michael_Clarke,

DHCP fingerprinting derivation rules run after all other derivation rules and supersede them.  There were bug(s) where this would not work with 802.1x  enabled but it has been fixed in ArubaOS 6.2.1.1

61935
66647
67620
50192
Symptom: A user did not derive a VLAN from a user derived rule based on DHCP fingerprinting due to errors in the internal key exchange process. This issue has been resolved.
Scenario: This issue occurred in controllers running ArubaOS 6.1 or later when the SSID used 802.1X authentication.

---

@cjoseph wrote:
What are you using to change the vlan?

---

Role derivation from clear pass. and i have assigned post authenticattion vlan to that role in controller