1 ACCEPTED SOLUTION
I see, its a bit more clear now. If you have not tried the following already, give it a go. I think this configuration can help you.
I have recently implemented the exact same scenario with XCC version 5.26 for few different deployments. I assign same role to users but flip VLAN based on the user’s location, location could be a building or a floor etc. Assuming you are something similar. To achieve this, I used RFC3576 with the attributes I mentioned in my previous post. This use case is addressed a bit differently in XCC, unlike identifi HYBRID mode where we could use RFC3580 and pass role and VLAN as two separate attributes, XCC needs a bit more config. I am not sure what your deployments looks like and how granular the VLAN assignment is. This config example is based on one VLAN per building, therefore “location” is used as a key differentiator. Likewise, you can have one VLAN per floor/device group/AP etc.
You can use “Location” tab in Site configuration to configure location/zone information, you will use this as a match condition for VLAN assignment, you can either use the name of the SITE itself or one of the following location parameters:
Then, make change to AAA policy in XCC and configure either site name/city/region/ as Called station ID to the NAC (based on how granular the VLAN assignment is). XCC will replace original Called station ID with the one you specify here while sending the authentication request to the NAC.
On the NAC, create “location groups” and specify the “Site Name” or whatever parameter you used as Called Station ID. NAC will match this with the incoming Called Station ID.
As for the Policy Mapping, you can create Policy Mappings with the same Role name and specify different “Map to location” value for each of them. This will allow NAC to determine which VLAN to return based on location while still using the same Policy Role.
Regards,
Ovais
So, looks like there is something wrong with the policy assignment:
If I send only the FilterID 'policy=Guest Access' the client, the client get's authenticated, but still on the default WLAN VLAN (120). If I send the VTA attributes as follows, the same client can't authenticate:
Filter-Id=Enterasys:version=1:%MANAGEMENT%policy=%POLICY_NAME%
Login-LAT-Port=%LOGIN_LAT_PORT%
Service-Type=%MGMT_SERV_TYPE%
Tunnel-Private-Group-Id=%VLAN_ID%:%VLAN_TUNNEL_TAG%
Tunnel-Type=13:%VLAN_TUNNEL_TAG%
Tunnel-Medium-Type=6:%VLAN_TUNNEL_TAG%
When the guest authenticates, do you see it getting “Guest Access” role in XCC “Clients” tab? the only reason it should fall back to the default WLAN VLAN is when one of the following is true:
- The XCC didn’t receive the correct filter-id for the role, therefore it puts the client on default WLAN VLAN.
- It received the filter-id but the AP profile does not have this roles assigned/mapped on it.
- You are using the attributes to pass VLAN ID, may be you don’t have VLAN configured in policy mapping settings.
I was wondering why do you need to use RFC3580 and pass the VLAN ID as an attribute, not saying it doesn’t work that way, it does, I have done it many time with RFC3576 and passing VLAN as an attribute like following when the requirement is to assign same user Role but different VLANs based on location for instance.
Filter-Id=Enterasys:%POLICY_NAME%
Login-LAT-Port=%LOGIN_LAT_PORT%
Tunnel-Private-Group-Id=%VLAN_ID%:%VLAN_TUNNEL_TAG%
Tunnel-Type=13:%VLAN_TUNNEL_TAG%
Tunnel-Medium-Type=6:%VLAN_TUNNEL_TAG%
In case, you just need to use diff. Roles each with diff. VLAN, passing the Role as a filter-id to XCC should do the trick since XCC already has the VLAN defined within the Role. If that’s not happening, I will delete the VLAN configuration on the XCC and re-create it.
Regards,
Ovais
