Why do desktop switches (unmanaged switches) drop the EAP-TLS message in 802.1x deployment?

[Jose Pablo]

Hi,

I'm doing differents tests with 802.1x to find the best setting to my network but I've found a problem with the desktop switches that I don't know how I can resolve.If there are solution,

I'll try to explain the case....

Scenario:

Hardware Setup:
Cisco Switch <-> Unmanaged Switch <-> PC

I'm using a switch WS-C2960+24PC-L with 15.0(2)SE5 IOS with the following 802.1x setting:

interface
 switchport mode access
 authentication host-mode multi-auth
 authentication port-control auto
 authentication periodic
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 3
 spanning-tree portfast
 

well....although I can access to my lab without any problem when I plug the PC directly to the port, I can't connect when I use a unmaneged switch between them (I don't don't receive the EAP message in my RADIUS and the switch try to authenticate using MAB)

I repeat the same with a old hub that I had in my desk and I connected correctly so I think the problem is in the unmanaged switch but I'm using 3-4 3Com differents models.

Someone know why the desktop switch (unmanaged switch) does not forward the EAP message?

Are there any restriction or bug in this kind of devices?

Thanks in advance,

[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.