topic NAC - location based VLAN Assignment in ExtremeCloud IQ- Site Engine Management Center

NAC - location based VLAN Assignment

Thomas_Hilber — Thu, 20 Jan 2022 12:42:00 GMT

We are using Extreme NAC as Proxy Radius with Microsoft NPS.
At the moments VLANs are assigned based on radius response from NPS which is working fine.

What we would like to do now is the following:

1. NPS responds with vlan name "client" if end system is successfully authenticated.
2. on switch1, if NPS response is "client" - vlan should be "client_1"
3. on switch2, if NPS response is "client" - vlan should be "client_2"
4. on switch3, if NPS response is "client" - vlan should be "client_3"
5. and so on

So based on switch location group we want modify the vlan information from NPS for the final assignment of the end system.
Is this possible to implement with Extreme NAC?

RE: NAC - location based VLAN Assignment

Brian_Anderson1 — Fri, 21 Jan 2022 17:44:00 GMT

Are you using policy with Extreme switches for the clients? If so Policy Vlan Islands may be your solution.

RE: NAC - location based VLAN Assignment

Ryan_Yacobucci — Sat, 22 Jan 2022 20:48:00 GMT

Hello,

Yes, NAC has the ability to provide a different authorization based on location group by utilizing location based policy mappings.

You will have one rule that has one profile that mappings to a number of policy mappings that are used based on location criteria within the policy mapping itself.

For instance:

Unregistered with "Map to Location" "Any"

Unregistered with "Map to location" "XCC". XCC being the IP address of the XCC controller.

So there are two policy mappings named "Unregistered", but if the XCC controller sends the RADIUS access request NAC will send a different policy named based on the policy mapping:

So NAC would send "Unregistered role for BCS_WIRELESS" as the filter-id ONLY to the XCC. Any other switch would have the filter-id of "Unregistered" sent.

So you would create a new policy mapping for each switch location group, and define the switches inside the location group.

You'll probably be working with RFC 3580 for VLAN authorization. There is no difference. Instead of filer-id you would send a different VLAN ID.

So:

policyMappingName - Location group: switch 1 - VLAN 1
policyMappingName - Location group: switch 2 - VLAN 2
policyMappingName - Location group: switch 3 - VLAN 3
policyMappingName - Location group: switch 4 - VLAN 4

They key is that the policy mapping name must all be the same, and you should leave one of the policy mappings set to location of "any" or NAC will throw an error on enforce saying that there is no default policy mapping.

Thanks
-Ryan

RE: NAC - location based VLAN Assignment

Thomas_Hilber — Wed, 26 Jan 2022 16:41:00 GMT

Hi Brian! Unfortunately we have got a lot of older switches which are not policy capable, but we will have a look on this.

RE: NAC - location based VLAN Assignment

Thomas_Hilber — Wed, 26 Jan 2022 16:51:00 GMT

Hi Ryan,

thank you this could be the way to go.

But is NAC also capable to evaluate the VLAN name returned with RFC 3580 from NPS server.

Because we could also have the following situation when the end system is a printer:
1. NPS responds with vlan name "printer" if end system is successfully authenticated.
2. on switch1, if NPS response is "printer" - vlan should be "printer_1"
3. on switch2, if NPS response is "printer" - vlan should be "printer_2"
4. on switch3, if NPS response is "printer" - vlan should be "printer_3"
5. and so on

So it would be a two stage process:
first look into vlan returned by NPS
then assign the "new" vlan name based on switch location

RE: NAC - location based VLAN Assignment

Ryan_Yacobucci — Wed, 26 Jan 2022 16:59:00 GMT

Hello,

If NPS is already providing the correct RADIUS attributes you can configure the profile to just pass through what NPS has already provided. In the NAC profile deselect "Replace RADIUS response attributes" and it will pass to the client whatever NPS send to NAC.

1. NPS responds with vlan name "printer" if end system is successfully authenticated.
2. on switch1, if NPS response is "printer" - vlan should be "printer_1" --> NAC passes through RFC 3580 VLAN to client
3. on switch2, if NPS response is "printer" - vlan should be "printer_2" --> NAC passes through RFC 3580 VLAN to client
4. on switch3, if NPS response is "printer" - vlan should be "printer_3" --> NAC passes through RFC 3580 VLAN to client
5. and so on

NAC can also evaluate RADIUS AVPs and they can be used in the rule criteria to make a rule decision. There is a RADIUS user group criteria where you can define the AVP returned by NPS in order to hit a specific rule. Eg. If NPS returns RFC 3580 tunnel-private-group of 7 that can be used as a criteria to match a group.

RE: NAC - location based VLAN Assignment

PeterK — Wed, 26 Jan 2022 19:23:00 GMT

why are you proxying the requests to the NPS? What values and sources uses the NPS for decision?

From my current point of view, it would be much easier for you, to only use the NAC.
I don't know if NAC is able to modify the vlan-tunnel-atribute received from the NPS.

RE: NAC - location based VLAN Assignment

Ryan_Yacobucci — Wed, 26 Jan 2022 21:19:00 GMT

This is the way I would recommend to do it:

1. NAC rule for Printers:

2 Policy Mapping for Printers has multiple mappings with location group per switch:

All printers will hit the "Printer" rule and NAC will send different RFC 3580 VLAN authorizations based on the switch that sent the authentication request.

Brian's solution is a one too. If Policy VLAN islands or policy isn't supported by the older or 3rd party devices as long as they can process an RFC 3580 VLAN authorization with VLAN name instead of VLAN ID you can configure the same VLAN name on all switches, and map it to a different VLAN ID per switch.

So:
Switch 1 would would have "Printer" VLAN be VLAN 1
Switch 2 would would have "Printer" VLAN be VLAN 2
Switch 3 would would have "Printer" VLAN be VLAN 3

NAC would always send back RFC 3580 VLAN NAME (Printer), and the individual switch can provision the unique VLAN per switch accordingly.

Policy VLAN Islands just makes it easy to deploy and manage this type of configuration.