802.1x Multiauth mode and downstream switches

[Nathan Spitzer]

Setup:

I need to support a bunch of security cameras mounted on poles in our parking lot and an IP intercom system mounted on some gates. Because of environmental factors the switches at the poles need to be hardened and the spec from the vendor installing the gear is for GarretCom Industrial unmanaged switches which would make sense.

However when Information Security got wind of this scheme they (probably correctly) are requiring me to secure the ports that these unmanaged switches connect to. I have 2 choices: port security w/ MAC filtering or 802.1x. Because all the devices at the poles and gates support 802.1x and because I may need to go out there to troubleshoot stuff (and will invariably forget to add the MAC of whatever device I am using) I would prefer 802.1X multi-auth mode.

Problem:

When I ran a quick test on a test 3560 running some 15.0.1 code I could get a laptop to connect via 802.1x EAP-TLS successfully if it was directly connected but when I connected the same laptop via a dumb Netgear switch I confiscated from a luser  it would not connect. The 3560 error said that the laptop never responded.

Question:

Before I spend a whole lot of time on this, is this something that should work? I don't see any practical use for the feature if it won't however the documentation I am using specifically mentions downstream hubs but I am not sure if they mean real hubs (which I don't think are even made anymore) or if they mean unmanaged switches.

I plan to try a couple of different unmanaged switches tomorrow and digg a little but I would like to know if I am wasting my time on something that will never work or if there is a little gotcha somewhere.

Thanks!

[Nathan Spitzer]

Update: I tried this on a cheap-as-dirt Trendnet TE100-S5 10/100 switch and it worked but tried it on a different Netgear (a Prosafe GS105) and it did not work.

What could be different on these unamanged switches to cause this?

[Tedwheat53]

Just curious if you have implemented. I set up multi-auth in my lab also. Did you stick with trendnet switches or different unmanaged switches? Thx.

Sent from Cisco Technical Support iPad App

[Svetlin Simeonov]

HI

I faced same problem. My workaround is MAC (MAB) authentication. I tested with netgear and 3COM.

[Svetlin Simeonov]

Unmanaged Switches Between MS and Client for RADIUS Authentication

When using PEAP EAP-MSCHAPv2 on an MS switchport, if an unmanaged switch is between the supplicant (user machine) and the RADIUS client (MS) the authentication will fail. The reasoning is explained below:

The destination of the eapol (RADIUS exchange) frame is a special multicast address that 802.1D-compliant bridges do not forward.
This destination is labeled as "nearest" in Wireshark which means that the frame should only be forwarded to the next layer 2 device.
If the unmanaged switch is added into the topology between the client and the MS, the next layer 2 device is the unmanaged switch and because the multi-cast nearest address is not meant to traverse multiple switches, the unmanaged switch drops the packets. This prevents the client from being authorized.

There is a work-around to this but special considerations must be taking before implementing them:

This is not due to a fault in the MS but is the way that eapol is designed.
It is possible to circumvent this by using MAC based RADIUS authentication. If one machine authenticates via MAC based RADIUS through the MS on an unmanaged switch, the machine that has authenticated will be granted access. It is a workaround and it is less secure and requires more configuration on the NPS and DC.
https://documentation.meraki.com/MS/Access_Control/MS_Switch_Access_Policies_(802.1X)