Header Only - DO NOT REMOVE - Extreme Networks

help with 802.1x?

  • 9 June 2016
  • 9 replies

Userlevel 1
Let me preface and say that I am probably going to ask some fundamentally basic questions, and probably misunderstand some things about either how 802.1x works in general, or how Extreme's implementation of 802.1x works, as I did see a post that made mention that Extreme does auth a little differently, as far as port vs MAC auth. So I apologize in advance.

I was wondering if anyone can point me in the right direction as far as possible template configurations, or specific sections of the concepts guide? I looked through the concepts guide, and tried some of it out, and still had issues.

We are a university, and ideally, I'd like to be able to have a port:
  • unauthenticated - guest/student vlan
  • authenticated as a student - guest/student vlan
  • authenticated as staff - staff vlan
  • phone authenticates with MAC (which I still need to figure out how to do) - voip vlan
First off, is the above possible?

I found somethings about using VSAs, but then they reference placing users in groups in AD, and then, if those users authenticate, send back a specific VLAN name, which confuses me a little, probably because we're doing it wrong.

In our environment, each building has its own VLAN, let's say building A is VLAN 1000. In the switch, that VLAN name is "buildingA" (we also have VoIP VLANs as "voice_buildingA"). Likewise, building B is VLAN 1010, building C is VLAN 1030, etc. The first thing I'm wondering is, what happens if the VLAN name the VSA is sending on auth, doesn't exist on that switch? For example. Staff member is part of the 802.1x auth group in AD. They're in buildingA, and RADIUS sends the "buildingA" VLAN name. Cool. What happens if they go to building B? RADIUS would send "buildingA", which doesn't exist on that switch stack. "buildingB" does, but not "buildingA."

Is the VSA portion necessary, or is it an overcomplication, and can everything just be done with NPS?

Sorry if this is confusing. It's just new territory, and I want to try and implement something during the summer so we can smooth it out before students return en masse. As it is right now, students can just come up to administrative buildings or classrooms, and plug right in and get full network access. Sure they need administrative credentials to access resources, but ideally they shouldn't be able to get to a lot of that in the first place.

Thanks in advance (and please be gentle).

9 replies

Userlevel 6

I believe the functionality you need should be possible.

A few questions:

Do you have only one VLAN per building or is there a student, staff, and VOIP VLAN per building?
What IP address would the switch be sending the RADIUS request from?

One way to solve your location based problem would be to send different VLANs in the VSA based on the RADIUS client (the switch) that is sending the request. So if a switch in BuildingA sends the request then the VSA sent is for VLAN BuildingA. If a switch in BuildingB sends the request then BuildingB VSA is sent.

The VSA portion is necessary in order to place users in different VLANs based on their user credentials.

Userlevel 1
Chad, thanks for the quick response.

So we have a simple star topology with, for the most part, Core to Access. We don't really have Distribution switches, except in a few cases...sort of.

Generally each building typically just has one VLAN for staff, and then one VLAN for VoIP. There are a few locations where a switch will have more than one VLAN for staff because the switch in that situation serves end users, as well as acts kind of like a distribution switch for another building.

For example, for most locations, we have Core > BuildingA, so in that situation, building A's switch stack will just have two VLANs - staff and VoIP. A handful of other locations have Core > BuildingB > BuildingC. So in that respect, building B will have both buildingB and buildingC staff and VoIP VLANs (with buildingC VLANs only tagged on the uplink to core and buildingC).

Each switch stack's Client IP will be the .2 (upwards of .4) of each building's respective staff VLAN. So, Core has a router interface for VLAN 1000 (buildingA) of BuildingA switch stack will be, and again, that's the staff VLAN.

As far as VSA goes, I'm looking at NPS right now, and given what you've said (as well as what this article says, it seems like the following needs to happen when setting up the Network Policies:
  • We're going to need to put all dot1x staff in a group, and add that group as a condition
  • The switch stack's IP will need to be added as another condition as Client IP (or NAS IPv4?)
  • Authentication Methods in Constraints as shown in that article
  • Vendor Specific Attributes in Settings, that's where we'll set up the different VSAs, each with Vendor Code 1916, and Attribute Number 211, Attribute format string, and then Value as the VLAN *NAME* on the switch?
  • And we'll also need probably 3 policies (eventually) per switch stack (since the Client IP and User Group are defined in each policy's Conditions tab: so a policy for staff in builiding A, a policy for students in building A, and (eventually) a policy for phones in building A?
Another thing I thought of, can authentication failures also be set to keep people on the guest/student VLAN?

Userlevel 6

Replies to each of your 5 bullet points
  • Yes. You may also need/want a group for phones and students.
  • The actual terminology in NPS for a RADIUS client IP is "Client IPv4 Address". You can also use a wildcard. So you could create a condition for all BuildingA RADIUS clients by specifying 10.10.10.* (or whatever the network address is). This is probably not a good practice though considering there will be actual users in this same subnet. You should specify each individual RADIUS client.
  • Yes
  • The value is actually X where X is either U for untagged and T for tagged traffic. In this situation I believe you would always need untagged. So it would look something like "UBuildingA".
  • Yes, at least three policies per building.
There are a couple of options to solve the guest/student problem that I can think of.

IF you were ONLY using 802.1X netlogin on the ports then you could use the guest VLAN feature of netlogin. This effectively places all devices that do not participate in 802.1X authentication into the specified guest VLAN
  • configure netlogin dot1x guest-vlan vlan_name {ports port_list}
  • enable netlogin dot1x guest-vlan ports [all | ports]
Since it seems you may need to use both 802.1X and MAC auth on the ports (for phones) then you could also try using the authentication failure VLAN as the guest VLAN. Any device that is not authenticated either via 802.1X or MAC would be placed into this VLAN
  • configure netlogin authentication failure vlan VLAN_NAME
Also, you could create another "accept all" policy in NPS that authenticates all other devices and places them in a guest VLAN via VSA. This may be the best option. Simplified policy logic:
  • Staff user Auth with 802.1X go to staff VLAN
  • Student auth with 802.1X go to Student VLAN
  • Phone user authenticated via MAC list and placed in VOIP VLAN
  • All other authentications received from RADIUS Client (switch) go to guest VLAN
Userlevel 1
Chad, thanks for your detailed response. I'll have to review our policies as I've seen some set up with NAS IPv4 and some with Client IPv4, so that you for that clarification.

With regards to what you've said about U and T for VLAN Names, and with what I've read here: http://www.extremenetworks.guru/exos-802-1x/, does the U and T still apply if using Attribute 209 or 211 with VLAN ID instead of VLAN Name? (ex: U1000 instead of UBuildingA, or T2000 instead of TVoice_BuildingA ?)

I'll probably do some testing over the next couple days and will report back how it goes.

Thanks again.

Userlevel 6

You don't use U or T with 209. You can use U and T with a VLAN ID if you are using Attribute 211. A description of the VSAs can be found on page 872 of the 21.1 User Guide
Userlevel 1
Okay, so I've had some time today to play around with this a little and it seems like it's sort of working, but I have one immediate question and probably a couple more later.

Should I be able to auth two different supplicants on the same port? My work computer is a Mac, which I'm running Windows in a VM, and I can auth on the Mac, but if I'm auth'd on the Mac, then I can't auth from the VM. If I let the dot1x window timeout, or click cancel and just wait til I get kicked over to the guest vlan, then both my Mac and my VM will get an IP on the guest vlan.

Use case is obviously if we have an unmanaged switch in someone's office, or if we have a computer chained off a phone that has done MAC auth (which I still need to figure out how to do). But if we can only have one device auth'd on a port at a time (which can't be right), then I'll need to think this through a little more.

Is it possibly because my VM is getting access through my physical interfaces, and since my physical interface is already auth'd...Windows can't auth again? I guess I should try it from the other side - don't auth my Mac, and then see if I can auth my VM...

Also, I read in the User Guide that netlogin and ELRP don't work well together. How accurate is that? We need ELRP, and we've gone without dot1x thus far, but I'd like to implement it if possible. But if we can't have both, that's another thing I'll need to think through.

Thanks in advance, and happy Friday!
Userlevel 1
More confused now.

Both my VM and Mac were on the Guest VLAN. I disabled then enabled my VM NIC because that's the only way I've found to get the authentication window to pop up. I entered my credentials, but before I hit OK, I started a packet capture.

I hit OK and...nothing. I was still on the guest VLAN. I checked the packet capture, and this is what I saw:

But there was no Audit Success in the NPS Event Viewer, and I was still on the Guest VLAN.

I did the same process on my Mac and it auto-connected just fine.

Just for kicks I disabled both NICs, and then ran the following command on the switch (out my wireless NIC):

clear netlogin state agent dot1x mac-address WINDOWS-VM-MAC port PORT-NUMBER

Re-enabled both NICs, and both authenticated against NPS and connected to the Staff VLAN!

MAC IP address Authenticated Type ReAuth-Timer User
MAC-VM Yes, Radius 802.1x 254 Domain\Username
MAC-Mac Yes, Radius 802.1x 245 Username

But now, probably 5 minutes later, show netlogin port PORT-NUMBER shows:

MAC IP address Authenticated Type ReAuth-Timer User
MAC-VM No 802.1x 0
MAC-Mac No 802.1x 0


Session-Timeout is set for 300 seconds (for now) in the NPS Policy, because I read that value replaces the reauth-period timer on the switch. My assumption was that after 5 minutes, it would reauth again, and everything would reconnect just fine again, but that doesn't appear to be the case. My Windows VM disconnected, and my Mac is still connected.

And again, after typing all that, I saw that the Connection Time on my Mac restarted, and when I checked the switch, both devices re-auth'd.

But now again, after 5 minutes, my Windows VM disconnected, and my Mac is still connected, but this time, 10 minutes have gone by and my Mac is still connected, and my Window VM reconnected about 2 minutes ago.

I feel like I'm am still missing something about how the netlogin works, because clearly I can't roll this out as it is right now. Even if devices eventually reauth, we can't have people drop off the network for 5-10 minutes at a time.

Here's the config, if it helps:

# Module netLogin configuration.
configure netlogin vlan nt_login
enable netlogin dot1x
configure netlogin authentication protocol-order dot1x mac web-based
enable netlogin ports 17-20 dot1x
enable netlogin dot1x guest-vlan ports 17-20
configure netlogin dot1x ports 17 timers quiet-period 5 reauth-period 30
configure netlogin dot1x ports 18 timers quiet-period 5 reauth-period 30
configure netlogin dot1x ports 19 timers quiet-period 5 reauth-period 30
configure netlogin dot1x ports 20 timers quiet-period 5 reauth-period 30
configure netlogin dot1x guest-vlan UnPriv_dot1x ports 17-20
configure netlogin ports 17 mode port-based-vlans
configure netlogin ports 17 no-restart
configure netlogin ports 18 mode port-based-vlans
configure netlogin ports 18 no-restart
configure netlogin ports 19 mode port-based-vlans
configure netlogin ports 19 no-restart
configure netlogin ports 20 mode port-based-vlans
configure netlogin ports 20 no-restart
enable netlogin authentication failure vlan ports 17-20
enable netlogin authentication service-unavailable vlan ports 17-20
configure netlogin authentication failure vlan UnPriv_dot1x ports 17-20
configure netlogin authentication service-unavailable vlan UnPriv_dot1x ports 17-20

Help and/or thoughts (on Monday...cuz it's Friday) would be greatly appreciated.
Userlevel 6

You can auth multiple supplicants on the same port. However, if you want to authenticate multiple supplicants on the same port and place them into different VLANs untagged you will need to use mac-based-vlans on the port rather than port-based.

ELRP and Network Login are not currently supported on the same port.

Are your test ports added to any VLAN (show conf vlan)? If so, you are operating in ISP mode and for your implementation you need campus mode. Remove those VLANs from the ports.

I think it would be best at this point to open up a case with GTAC. That way we can start a better dialogue and attack the issues one at a time.

Userlevel 1
Chad, thanks for your response. I did indeed have it set to port-based instead of MAC based. And I do think I'll need to open a ticket because I'm running into issues with getting MAC auth working with our ShoreTel phones, in addition to the quirkiness I was already experiencing.

And the ports were assigned to VLANs as well. After doing configure delete [vlan] port 17-20, now when I do show vlan ports 17-20 it just shows the nt_login VLAN.

But thank you so much for your assistance thus far! It got me pointed in the right direction.