FreeRadius handshake failure with Android and Windows devices

[abij]

Hello,

I am running OpnSense on 20.1.9 with plugin os-freeradius 1.9.7 installed. Windows 10 & 7 and Android 10 devices won't connect to a WPA2 Enterprise wireless network set up with EAP type: MSCHAPV2. Connections to the same WPA2 Enterprise network using devices with Mac Catalina 10.15 and Debian 10 are OK. Details of the handshake failure were captured when radiausd debug mode was enabled. The most relevant part was highlighted in red. See below.

According to the error, there is a mismatch of TLS versions, but I am confused, is it freeradius requiring TLS 1.3  or the user is only capable of TLS 1.3?

Thanks.

(11) eap: Peer sent packet with method EAP PEAP (25)
(11) eap: Calling submodule eap_peap to process data
(11) eap_peap: Continuing EAP-TLS
(11) eap_peap: Peer indicated complete TLS record size will be 131 bytes
(11) eap_peap: Got complete TLS record (131 bytes)
(11) eap_peap: [eaptls verify] = length included
(11) eap_peap: (other): before SSL initialization
(11) eap_peap: TLS_accept: before SSL initialization
(11) eap_peap: TLS_accept: before SSL initialization
(11) eap_peap: <<< recv TLS 1.3  [length 007e]
(11) eap_peap: >>> send TLS 1.2  [length 0002]
(11) eap_peap: ERROR: TLS Alert write:fatal:handshake failure
tls: TLS_accept: Error in error
(11) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
(11) eap_peap: ERROR: System call (I/O) error (-1)
(11) eap_peap: ERROR: TLS receive handshake failed during operation
(11) eap_peap: ERROR: [eaptls process] = fail
(11) eap: ERROR: Failed continuing EAP PEAP (25) session.  EAP sub-module failed
(11) eap: Sending EAP Failure (code 4) ID 2 length 4
(11) eap: Failed in EAP select
(11)     [eap] = invalid
(11)   } # authenticate = invalid
(11) Failed to authenticate the user
(11) Using Post-Auth-Type Reject
(11) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(11)   Post-Auth-Type REJECT {
(11) attr_filter.access_reject: EXPAND %{User-Name}
(11) attr_filter.access_reject:    --> LGN5
(11) attr_filter.access_reject: Matched entry DEFAULT at line 11
(11)     [attr_filter.access_reject] = updated
(11)     [eap] = noop
(11)     policy remove_reply_message_if_eap {
(11)       if (&reply:EAP-Message && &reply:Reply-Message) {
(11)       if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
(11)       else {
(11)         [noop] = noop
(11)       } # else = noop
(11)     } # policy remove_reply_message_if_eap = noop
(11)   } # Post-Auth-Type REJECT = updated
(11) Login incorrect (eap_peap: TLS Alert write:fatal:handshake failure): [LGN5/<via Auth-Type = eap>] (from client Home AP port 23 cli 8c3ae3735337)
(11) Delaying response for 1.000000 seconds

[mimugmail]

Do you use LibreSSL or OpenSSL?
Server receives TLS1.3 from client but only supports 1.2 I'd guess.

[abij]

Do you use LibreSSL or OpenSSL?
Server receives TLS1.3 from client but only supports 1.2 I'd guess.

Thanks. Oh, my OPNSense is the OpenSSL flavour. So what you are saying is freeRadius at the moment does not support TLS 1.3? That's weird, since Win 10 by default doesn't support TLS 1.3 either, however it is the Windows machines that won't make connections to WPA2 Enterprise network; Linux and Macs are OK.

[mimugmail]

Are you sure you have the root certificate installed on windows trusted store? Or do you accept unknown root authorities in Windows?

I'm not aware of a change in radius plugin or freeradius itself, I also don't have a setup for this here.

[abij]

Are you sure you have the root certificate installed on windows trusted store? Or do you accept unknown root authorities in Windows?

I'm not aware of a change in radius plugin or freeradius itself, I also don't have a setup for this here.

I did install OPNSense generated Root CA cert and server cert on Windows machines, then move them to Trusted Root CA store, right click then choose the purposes (Server authentication etc.). But I am not sure whether it is the same thing as what you suggested. And not only Windows devices, Android devices suffer the same problem too. So I think it might be a freeRadius TLS problem?

[abij]

I found a solution to the handshake failure problem on Windows 10 and 7 machines. It can be solved by following this page.

https://www.windows-security.org/2c488aac52906551ff218fd5c2bdaddc/ssl-cipher-suite-order

Go to

Code: [Select]

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002!Functions
then add TLS 1.2 GCM cipher suites and delete old unsafe ones. Reboot then it should be OK.

But on Android devices, I haven't figured out a way to change the order of cipher list yet.

[mimugmail]

But wasnt it TLS1.3 which should be strongest?

[abij]

But wasnt it TLS1.3 which should be strongest?

The solution is mainly for Windows 7 as only Windows 10 has TLS 1.3 support? (and only experimental as of now).
 
I checked my Mac and Linux machines, when they successfully negotiated a handshake connection to freeRadius, it was using TLS 1.2 . So I think the freeRadius side will most likely accept TLS 1.2?