This may be a bit off topic, as it involves Cisco switches as 802.1x authenticators, but any help gratefully received. Scenario is to use UAC to authenticate Alcatel 4018 phones using 802.1X on both Juniper EX and Cisco Catalyst switches.
As far as I know, the Alcatel phones are only capable of EAP-MD5 and EAP-TLS, and from the phone setup I have enabled both using the default settings. UAC has a dedicated realm for the phones, with the default user name and password added as a user. This realm is matched via sign-in policy to a protocol set that contains only EAP-MD5-Challenge and EAP-TLS.
This configuration works happily on the EX switches, but not on the Cisco switches. I have checked with the Cisco switches that they can authenticate other "normal" users correctly via 802.1X to the UAC, but the phones fail.
A policy trace on the UAC and the user event log show no sign of the attempt, but we do receive radius. A tcpdump on the UAC shows the following:
1. Switch sends Access-Request with correct user name
2. UAC sends Access-Challenge with EAP-code = Request and EAP-type=TTLS
3. Switch sends Access-Request with correct user name, EAP-code=Response, Eap-Type=Legacy-NAK, Desired EAP-type=EAP-TLS
4. UAC sends Access-Challenge with EAP-code = Request and EAP-type=TLS
5. Switch sends Access-Request with correct user name, EAP-code=Response, Eap-Type=EAP-TLS and some SSL content
6. UAC sends Access-Challenge with EAP-code = Request and EAP-type=TLS, plus some SSL that wireshark says is malformed (is this normal?)
7. Switch repeats Step 5
8. UAC sends Access-Challenge with EAP-code = Request and EAP-type=TLS, plus some SSL that wireshark displays as "Ignored unknown record"
Steps 7 and 8 are then repeated continuously.
Any ideas what's going on?
I suspect that The "Unknown Record" might be caused by a combination of your TCP and SSL protocol settings.
May be changing this and checking authentication again might help.
Problem resolved, but not exaclty sure why...
I removed TLS from another protocol set, pointing to a different sign-in page, and now the traffic from the Cisco switch is processed properly. I have no clear idea why TLS being present in the other protocol set would have prevented this negotiation, though. Surely I would have seen a message to the effect of "failed authentication for user X in realm Y"?
It's a good thing that the other protocol set doesn't really need TLS, or I'd have a problem to resolve.