Wireless Access

 View Only
  • 1.  802.1x Client fails key exchange

    Posted Dec 02, 2020 10:44 AM
    Hi, we have some new IoT devices that claim to support 802.1x. And unfortunately these appear to be a cheap chipset that supports 802.11g only and have an extremely limited interface to configure them. We have configured them to access our 802.1x network using EAP-PEAP (Clearpass is our authentication server) and they look to authenticate fine with the Clearpass logs confirming this. From here though they never connect and looking at the tracebuf log it appears that after authenticating they fail the 4 way handshake and either start authentication again or look to be stuck in a loop
    The network is in use by multiple other devices with no problems so it looks like it is a client issue
    I have included a portion of the log below. Any ideas on what the issue could be?


    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       128    59

    Dec  1 15:04:49  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       128    59

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  79     314   10.x.x.51

    Dec  1 15:04:49  rad-accept            <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  79     259

    Dec  1 15:04:49  eap-success           <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       128    4

    Dec  1 15:04:49  eap-start             ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       -      -

    Dec  1 15:04:49  wpa2-key1             <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       -      117

    Dec  1 15:04:49  eap-id-req            <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       129    5

    Dec  1 15:04:49  eap-id-resp           ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       129    17    test_ct_wifi

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       153    230   10.x.x.51

    Dec  1 15:04:49  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  153    88

    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       130    6

    Dec  1 15:04:49  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       130    64

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  86     319   10.x.x.51

    Dec  1 15:04:49  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  86     1124

    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       131    1034

    Dec  1 15:04:49  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       131    6

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  38     261   10.x.x.51

    Dec  1 15:04:49  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  38     1120

    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       132    1030

    Dec  1 15:04:49  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       132    6

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  141    261   10.x.x.51

    Dec  1 15:04:49  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  141    1120

    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       133    1030

    Dec  1 15:04:49  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       133    6

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  92     261   10.x.x.51

    Dec  1 15:04:49  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  92     1120

    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       134    1030

    Dec  1 15:04:49  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       134    6

    Dec  1 15:04:49  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  115    261   10.60.47.51

    Dec  1 15:04:49  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  115    346

    Dec  1 15:04:49  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       135    262

    Dec  1 15:04:50  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       135    348

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  41     605   10.x.x.51

    Dec  1 15:04:50  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  41     167

    Dec  1 15:04:50  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       136    85

    Dec  1 15:04:50  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       136    6

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  212    261   10.x.x.51

    Dec  1 15:04:50  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  212    141

    Dec  1 15:04:50  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       137    59

    Dec  1 15:04:50  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       137    75

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  142    330   10.x.x.51

    Dec  1 15:04:50  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  142    173

    Dec  1 15:04:50  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       138    91

    Dec  1 15:04:50  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       138    123

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  250    378   10.x.x.51

    Dec  1 15:04:50  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  250    189

    Dec  1 15:04:50  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       139    107

    Dec  1 15:04:50  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       139    59

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  69     314   10.x.x.51

    Dec  1 15:04:50  rad-resp              <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  69     141

    Dec  1 15:04:50  eap-req               <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       140    59

    Dec  1 15:04:50  eap-resp              ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       140    59

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  254    314   10.x.x.51

    Dec  1 15:04:50  user repkey change     *  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       65535  -     001a1e04891000000687aa94

    Dec  1 15:04:50  macuser repkey change  *  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       65535  -     20:f8:5e:35:8c:30

    Dec  1 15:04:50  rad-accept            <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84/CLEARPASS_VIP_RADIUS  254    259

    Dec  1 15:04:50  eap-success           <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       140    4

    Dec  1 15:04:50  wpa2-key1             <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       -      117

    Dec  1 15:04:50  eap-start             ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       -      -

    Dec  1 15:04:50  eap-id-req            <-  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       141    5

    Dec  1 15:04:50  eap-id-resp           ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       141    17    test_ct_wifi

    Dec  1 15:04:50  rad-req               ->  20:f8:5e:35:8c:30  18:64:72:5d:6d:84                       215    230   10.x.x.51



    ------------------------------
    Stewart Smith
    ------------------------------


  • 2.  RE: 802.1x Client fails key exchange

    Posted Dec 02, 2020 08:02 PM
    there's been cases before where some devices are not 'ready' to accept the key exchange after dot1x is done; you can try adjusting the following value in the authentication dot1x profile

    wpa2-key-delay         Set the delay between EAP-Success and unicast key exchange

    try a value of 500 (msec) or 1000 (msec) and see if that helps.

    Another thing to check is if you have modified the 11g-basic and 11g-transmit rates on the SSID profile, if so, try reverting them to default as a test

    ------------------------------
    Jeffrey Goff
    ------------------------------



  • 3.  RE: 802.1x Client fails key exchange

    Posted Dec 03, 2020 05:10 AM
    Thanks Jeffrey, will give the key delay a try

    ------------------------------
    Stewart Smith
    ------------------------------



  • 4.  RE: 802.1x Client fails key exchange

    Posted Dec 09, 2020 07:38 AM
    We tested with 500, 1000 and 2000 for the wpa key delay and still no luck. The basic rates are 6,12,24 and trasmit are 6,12,24,36,48,54. We tested on a PSK SSID with the same rates and it worked fine. The logs show association failure

    ------------------------------
    Stewart Smith
    ------------------------------



  • 5.  RE: 802.1x Client fails key exchange

    Posted Dec 10, 2020 12:24 AM
    Edited by jgoff Dec 10, 2020 12:25 AM
    indeed it seems the client doesn't like something, some thoughts:

    • after you introduced the delay, is it the case that the client still sends eap-start immediately after the wpa2-key1 ?
    • please check "show ap remote debug mgmt-frames ap-name <ap>" just after a failure
    • can you show the auth tracebuf for the same device when it comes up on PSK ?
    • can you try it on a plain unmodified ssid profile (i note the client should be 11g, but wouldn't be the first time i've seen weird things relating to missing 11b rates)


    I don't know if this will show anything, but we have some more detailed tracing for eapol now, maybe it will give a clue

    no paging
    ap debug eapol-debug enable ap-name <ap> client-mac <mac>
    << try to connect >>
    show ap debug driver-log ap-name <ap>
    show ap remote debug mgmt-frames ap-name <ap>
    show auth-tracebuf mac <mac>
    


  • 6.  RE: 802.1x Client fails key exchange

    Posted Dec 17, 2020 05:08 AM
    • Unfortunately we have not been able to carry out more testing due to office access restrictions. We have had a reply from the vendor of the equipment though stating that it is not compatible with Clearpass as a RADIUS server and that they are working to update the drivers
    • This seems strange to me as the authentication part seems to complete and it is the key installation that fails. Are there vendor specific attributes seen in the keys from different RADIUS vendors? 


    ------------------------------
    Stewart Smith
    ------------------------------



  • 7.  RE: 802.1x Client fails key exchange

    Posted Dec 17, 2020 07:40 AM

    "it is not compatible with Clearpass as a RADIUS server"

    ClearPass used the FreeRADIUS server which is the server that helps determine the RADIUS standard.

    If their product is not compatible with ClearPass, their product does not really support RADIUS authentication since it does not adhere to the requirements of the RFC defining the standard.. The whole purpose of standards is ease of interoperability.



    ------------------------------
    Bruce Osborne
    ------------------------------



  • 8.  RE: 802.1x Client fails key exchange

    Posted Dec 18, 2020 12:58 AM

    seems odd, as you note, by the time it gets to key exchange radius is done, and in this case the exchange is eapol over wifi, there are no "radius attributes" being transported back and forth (though it could be something with the fragment sizes etc.). Please keep us posted if the vendor delivers a fix for it.