Problem with EAP PEAP Authentication on freeradius 3.22
Hello world! Trying to enable EPA2 Enterprise authentication for a Cisco Meraki AP. EAP Authenticaton section fails with the following: ===================================== (2) eap: Peer sent EAP Response (code 2) ID 2 length 161 (2) eap: Continuing tunnel setup (2) [eap] = ok (2) } # authorize = ok (2) Found Auth-Type = eap (2) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (2) authenticate { (2) eap: Expiring EAP session with state 0x1da40b4e1ca6122b (2) eap: Finished EAP session with state 0x1da40b4e1ca6122b (2) eap: Previous EAP request found for state 0x1da40b4e1ca6122b, released from the list (2) eap: Peer sent packet with method EAP PEAP (25) (2) eap: Calling submodule eap_peap to process data (2) eap_peap: Continuing EAP-TLS (2) eap_peap: [eaptls verify] = ok (2) eap_peap: Done initial handshake (2) eap_peap: (other): before/accept initialization (2) eap_peap: TLS_accept: before/accept initialization tls: TLS_accept: Error in SSLv2/v3 read client hello A (2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol (2) eap_peap: ERROR: System call (I/O) error (-1) (2) eap_peap: ERROR: TLS receive handshake failed during operation (2) eap_peap: ERROR: [eaptls process] = fail (2) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (2) eap: Sending EAP Failure (code 4) ID 2 length 4 (2) eap: Failed in EAP select (2) [eap] = invalid (2) } # authenticate = invalid (2) Failed to authenticate the user ===================================== Any idea where I may need to start troubleshooting? I haven't touched Authentication at all from its original. Authorization is done through python3 and seems to be working just fine. By the way, exactly the same error occurs on a different freeradius server running 3.021 Thank you! Gleb
On Apr 22, 2020, at 11:27 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
Hello world!
Trying to enable EPA2 Enterprise authentication for a Cisco Meraki AP.
What end-user system are you using? Windows? Linux? The AP just copies EAP packets between the end-user system and the RADIUS server. The AP doesn't have anything to do with the EAP methods.
tls: TLS_accept: Error in SSLv2/v3 read client hello A (2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
This is a magically unhelpful error from OpenSSL. There are many reason why it could happen. All of these reasons are related to TLS negotiation and/or certificate issues.
Any idea where I may need to start troubleshooting? I haven't touched Authentication at all from its original. Authorization is done through python3 and seems to be working just fine. By the way, exactly the same error occurs on a different freeradius server running 3.021
Then the issue is the end-user system. You can't debug an end-user system by looking at the RADIUS server. It's looking in entirely the wrong place. The RADIUS server is just telling you what the error is. The RADIUS server isn't *creating* the error. Alan DeKok.
Thanks Alan! For the end system OS, I have no idea... Meraki web-based dashboard has a built-in test tool to validate RADIUS configuration. This is what I used to check my setup so far, and haven't tried any "real" client *Is there any way to see from the RADIUS server side what client is doing/sending wrong/incorrectly?* Meraki does have a set of instructions on how to configure freeRADIUS to work with Meraki EAP-TLS authentication, but those seem to be dated as I could not even find ./etc/freeradius/eap.conf file that they suggest to edit. https://documentation.meraki.com/MR/Encryption_and_Authentication/Freeradius... *Perhaps you can help me to translate those instructions into 3.022 version terms and files to edit?* *And lastly, is there anything that had to be done in principle to enable EAP-TLS on the server irrespective of the client behaviour?* Thanks a lot again! Gleb On Thu, Apr 23, 2020 at 9:48 AM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 22, 2020, at 11:27 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
Hello world!
Trying to enable EPA2 Enterprise authentication for a Cisco Meraki AP.
What end-user system are you using? Windows? Linux?
The AP just copies EAP packets between the end-user system and the RADIUS server. The AP doesn't have anything to do with the EAP methods.
tls: TLS_accept: Error in SSLv2/v3 read client hello A (2) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
This is a magically unhelpful error from OpenSSL. There are many reason why it could happen. All of these reasons are related to TLS negotiation and/or certificate issues.
Any idea where I may need to start troubleshooting? I haven't touched Authentication at all from its original. Authorization is done through python3 and seems to be working just fine. By the way, exactly the same error occurs on a different freeradius server running 3.021
Then the issue is the end-user system.
You can't debug an end-user system by looking at the RADIUS server. It's looking in entirely the wrong place. The RADIUS server is just telling you what the error is. The RADIUS server isn't *creating* the error.
Alan DeKok.
On Apr 23, 2020, at 4:04 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
For the end system OS, I have no idea... Meraki web-based dashboard has a built-in test tool to validate RADIUS configuration. This is what I used to check my setup so far, and haven't tried any "real" client
Ah.... then it's rather more difficult to fix.
Is there any way to see from the RADIUS server side what client is doing/sending wrong/incorrectly?
That error message from OpenSSL is all we have/
Meraki does have a set of instructions on how to configure freeRADIUS to work with Meraki EAP-TLS authentication, but those seem to be dated as I could not even find ./etc/freeradius/eap.conf file that they suggest to edit. https://documentation.meraki.com/MR/Encryption_and_Authentication/Freeradius... Perhaps you can help me to translate those instructions into 3.022 version terms and files to edit?
Well... no. I don't rewrite documentation for vendors. We have documentation on how to configure EAP-TLS. See mods-available/eap. It's relatively straightforward.
And lastly, is there anything that had to be done in principle to enable EAP-TLS on the server irrespective of the client behaviour?
If the error is in OpenSSL, then you have to figure out *what* to configure. The server works by default. There is no magical setting which turns off a *broken* configuration and enables a *working* one. Alan DeKok.
Fair enough! :-) If you read the following instructions, where do you think the changes will need to be made if eap.conf file is nowhere to be found? Edit /etc/freeradius/eap.conf with the following changes 1. Change *default_eap_type* to “tls” 2. Comment out all the authentication methods sections except for tls 3. Comment out “private_key_password” with # 4. Change *private_key_file* to ${certdir}/radius.key 5. Change *certificate_file* to ${certdir}/radius.crt 6. Change *CA_file* to ${cadir}/ca.crt Below is a configuration file after the changes have made. [image: 69f8f9b8-9b8e-450c-8b95-3a15d4c67c6a] Thank you, Gleb On Thu, Apr 23, 2020 at 4:53 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 23, 2020, at 4:04 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
For the end system OS, I have no idea... Meraki web-based dashboard has
a built-in test tool to validate RADIUS configuration. This is what I used to check my setup so far, and haven't tried any "real" client
Ah.... then it's rather more difficult to fix.
Is there any way to see from the RADIUS server side what client is doing/sending wrong/incorrectly?
That error message from OpenSSL is all we have/
Meraki does have a set of instructions on how to configure freeRADIUS to work with Meraki EAP-TLS authentication, but those seem to be dated as I could not even find ./etc/freeradius/eap.conf file that they suggest to edit.
https://documentation.meraki.com/MR/Encryption_and_Authentication/Freeradius...
Perhaps you can help me to translate those instructions into 3.022 version terms and files to edit?
Well... no. I don't rewrite documentation for vendors.
We have documentation on how to configure EAP-TLS. See mods-available/eap. It's relatively straightforward.
And lastly, is there anything that had to be done in principle to enable EAP-TLS on the server irrespective of the client behaviour?
If the error is in OpenSSL, then you have to figure out *what* to configure.
The server works by default. There is no magical setting which turns off a *broken* configuration and enables a *working* one.
Alan DeKok.
On Apr 23, 2020, at 5:52 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
If you read the following instructions, where do you think the changes will need to be made if eap.conf file is nowhere to be found?
I *did* tell you to edit mods-available/eap. Or, if you read the documentation in raddb/README.rst, you can look for "eap.conf". The file has moved, and the move is documented. This whole business of "I give up, you tell me what to do" is just not acceptable.
Edit /etc/freeradius/eap.conf with the following changes • Change default_eap_type to “tls” • Comment out all the authentication methods sections except for tls • Comment out “private_key_password” with # • Change private_key_file to ${certdir}/radius.key • Change certificate_file to ${certdir}/radius.crt • Change CA_file to ${cadir}/ca.crt
If you read the file I told you to read, you would see that those configuration items are in the file. It is very much inappropriate to ask for help, and then refuse to follow the advice you're given. If you can't be bothered to follow instructions, I can't be bothered to give instructions. Alan DeKok.
Hi Alan, Thanks for setting me straight. I will do more reading, The major reason for my "lazy attitude" (not giving up though) is your prompt and helpful responses (why bother reading/researching if Alan can help right away). And perhaps I took your "no. I don't rewrite documentation for vendors." response too literally. But your advice is already helping. E.g. the actual client requests behave better than the Meraki test applet. So maybe it's not even worth bothering with that particular error, because it does point to a problem on the client side, for which I don't really care much. So, thank you. Gleb On Thu, Apr 23, 2020 at 7:50 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 23, 2020, at 5:52 PM, Gleb Lisikh <in4bit.general@gmail.com> wrote:
If you read the following instructions, where do you think the changes
will need to be made if eap.conf file is nowhere to be found?
I *did* tell you to edit mods-available/eap.
Or, if you read the documentation in raddb/README.rst, you can look for "eap.conf". The file has moved, and the move is documented.
This whole business of "I give up, you tell me what to do" is just not acceptable.
Edit /etc/freeradius/eap.conf with the following changes • Change default_eap_type to “tls” • Comment out all the authentication methods sections except for tls • Comment out “private_key_password” with # • Change private_key_file to ${certdir}/radius.key • Change certificate_file to ${certdir}/radius.crt • Change CA_file to ${cadir}/ca.crt
If you read the file I told you to read, you would see that those configuration items are in the file.
It is very much inappropriate to ask for help, and then refuse to follow the advice you're given. If you can't be bothered to follow instructions, I can't be bothered to give instructions.
Alan DeKok.
participants (2)
-
Alan DeKok -
Gleb Lisikh