locked
EAP-TLS on wireless fails RRS feed

  • Question

  • Hello,

    I cannot authenticate a Windows 10 laptop via EAP-TLS on the wireless network on my demo setup. Ubuntu and iOS devices work fine.

    I have configured a RADIUS server to authenticate users via EAP-TLS. I have generated root CA, server and user certificate via openssl. I have installed the Root CA certificate, and the user certificate in the User's certificate store.
    I have also created a dummy user for PEAP authentication.

    I can successfully authenticate via PEAP on wireless when the server verification is enabled.
    I can successfully authenticate via EAP-TLS on wired ethernet. These tests proves that the root certificate and user certificate are correctly installed on the Windows host, and that the RADIUS server TLS version is compatible with the Windows host version (I've forced the version to TLS 1.2).

    However the authentication via EAP-TLS on wireless still fails.
    I took some debug log with the commands:
    netsh wlan set tra yes
    netsh ras set tr * en
    netsh ras set tr * dis
    netsh wlan set tra no

    The report information did not help, the error I got suggested to verify that the 802.11 version and TLS version are compatible between the host and the network access point. Since I can connect to the wireless network when I disable authentication, this is not a 802.11 protocol version problem.

    What could possibly go wrong ?




    Thursday, June 9, 2016 7:22 PM

Answers

  • Indeed, I am using freeradius-server version 3.0.11.

    My Access point was plugged to a switch which permit only UPD:1812 IP packets to the server.

    I have captured the traffic of the wired and wireless logon and I found out that the switch was dropping non-initial fragments of the IP packets.
    It was preventing the user to complete the SSL handshake (since the last Access-Request message was fragmented).

    I've modified the switch configuration and the Windows 10 laptop can authenticate both on wired and on wireless.

    Thanks for your support.

    Monday, June 13, 2016 6:36 PM

All replies

  • Well this post states "We removed the WPA option in Windows 8.1 for two reasons:
    • WPA is less secure than WPA2.  Most devices support WPA2, so there's little reason to use the less-secure encryption of WPA.
    • The Wi-Fi Alliance international standards organization released a new 2.0 version of the WSC protocol.  Version 2.0 removes support for WPA, so new 2.0-compliant devices may not be able to support WPA.  It would be misleading if Windows showed the option when the option would probably just fail on 2.0 devices anyway."
    So not sure but perhaps that explains it.
    Thursday, June 9, 2016 9:02 PM
  • Do a wireshark capture of both the wired and wireless logon. They should be identical except for the failing part. Post full Debug output of freeradius -XXX which I assume you are using. Could be a driver issue. Could be a bug in the wireless network stack. Only way to know where the problem occurs is by capturing the traffic.

    Post all data also to the freeradius mail group.  POST FULL DEBUG to get help there. Otherwise they will ignore or scold you.

    Make sure the CA is in the right place. Make sure to test adding it in both user and machine stores for trusted CA.

    Could be wired is running machine/wireless is user (or the other way around ?) Just gambling here.

    Try different builds of W10 to exclude a bug related to a certain build.

    Make sure to retest with the snakeoil certificates that Ubuntu/freeradius generates by default. If they work but your own do not. It is a certificate problem. (make sure the length is 2048)

    Make sure you are using the latest version of freeradius. Build from source.(GIT) there have been bugs with TLS issues in some builds.



    Friday, June 10, 2016 8:19 PM
  • Indeed, I am using freeradius-server version 3.0.11.

    My Access point was plugged to a switch which permit only UPD:1812 IP packets to the server.

    I have captured the traffic of the wired and wireless logon and I found out that the switch was dropping non-initial fragments of the IP packets.
    It was preventing the user to complete the SSL handshake (since the last Access-Request message was fragmented).

    I've modified the switch configuration and the Windows 10 laptop can authenticate both on wired and on wireless.

    Thanks for your support.

    Monday, June 13, 2016 6:36 PM
  • Hi Lucile Quirion,

    I am glad the issue has been resolved and thanks for updating. Please remember to mark the reply.

    Best regards


    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact tnmff@microsoft.com

    Tuesday, June 14, 2016 3:04 AM