5400R v2: OSX clients won't authenticate (802.1X)

[fmuecher]

Hello,

I have some trouble with OSX devices authenticating via 802.1X (PEAP-MSCHAPv2) when patched behind an already authenticated SIP phone. It seems the OSX clients don't initiate the EAPOL session and the switch doesn't, because the port is already up. When I force a reauthentication for the port or the client is patched directly on the switch, authentication succeeds almost instantly.

I have played around with the reauth-period, tx-period and so on (basically all commands in chapter 25 of the latest Access Security Guide) but didn't accomplish anything.

Any suggestions on how to remedy this?

Thanks,
Fabian

PS: Somewhat funny side-note: My Windows clients have no problem whatsoever and when I connect an OSX client to a SIP phone, where a Windows client was previously authenticated, the OSX client has no problem as well...even with minutes between disconnecting the Windows and connecting the OSX client.

HPE 5412R zl2, tested with KB.16.07.0002 and KB.16.08.0002.

AAA config
aaa accounting network start-stop radius
aaa authentication port-access eap-radius


Interface config
   aaa port-access authenticator
   aaa port-access authenticator reauth-period 900
   aaa port-access authenticator unauth-vid 2
   aaa port-access authenticator unauth-period 10
   aaa port-access authenticator client-limit 5

[fmuecher]

Ok, so I have narrowed the problem down. It seems that as soon as the SIP phone gets a config via LLDP-MED, the switch does not intitiate another EAPOL-session on this port, even when a new device connects.

I can see in my packet captures that the client sends out DHCP Discover and receives LLDP packets from the switch. Once I remove the LLDP config from the port, upon connection the client immediately receives a EAP-Start from the switch.

A workaround would be to assign the necessary configurations via RADIUS and disable LLDP for the devices altogether. This way, I lose a lot of flexibility.

@FunnyDingo hat the same issue back in 2016 (https://community.hpe.com/t5/Aruba-ProVision-based/LLDP-MED-and-802-1x/m-p/6833223#M9460).

Is that a known issue or maybe even by design?

[bala5]

Hi,

Looks like only the OSX client only having this issue. Can you please log support case

along with wireshark logs. Please send for both the OS so that it will be helpful to compare.

Also please mention the OSX version details. 

[fmuecher]

I did file a support case (#5337963753), but since I managed to find a workaround - and the problem most likely is the macOS >10.13.6 - it should be closed by now.

My wireshark output however contradicts the HPE EAP schematics in which the authenticator _never_ initiates EAP and _always_ awaits the first EAP packet from the supplicant. In my packet captures, it was always the switch who sent the first EAP packet and the macOS client responding.
When the SIP phone was successfully authenticated and a LLDP config was active on the switchport, the switch simply did not send out EAP packets to the macOS - only LLDP packets.