Mailing Lists wrote:
1). I've run radtest, both locally on the router and over the wire from my computer using:
radtest MyTestUser MyTestPassword 192.168.1.1 1812 -sSharedSecretKey
Result: Access-Accept for both tests.
That isn't always indicative. See the top of raddb/sites-available/inner-tunnel for instructions on testing the inner-tunnel virtual server.
2). I've run eapol_test over the wire from my computer using various configuration sets for peap-mschapv2, eap-tls, ttls-pap and ttls-eap-mschapv2 along with the certificates I'd generated and copied to the router. The following command and variations of the following configuration show SUCCESS:
If eapol_test works, then FreeRADIUS is fine.
If I attempt to connect using Ubuntu's built in Wi-Fi client using TLS or PEAP, everything is fine. However, if I attempt to connect using Tunnelled TLS, which is the protocol I'd prefer to use, that's when I get hit with the failure. It doesn't work at all, for PAP, CHAP, MSCHAPv1 or MSCHAPv2.
The the Ubuntu client is broken. Which is weird, because I *thought* it was based on wpa_supplicate. (i.e. using the same code base as eapol_test).
Looking through the log to compare the ttls-eap-mschapv2 output from the eapol_test against the log generated by Ubuntu's wifi client, I notice that one of the requests (3 in log attached) appears to pass a dynamically generated username and the shared secret that I defined in my clients.conf file
What does that mean? "dynamically generated user name"? The debug log you posted shows no such thing.
1). Is there anything specific that needs to be done with FreeRADIUS in order for Ubuntu to connect using Tunnelled TLS and MSCHAPv2? i.e. are there any settings in FreeRADIUS that don't play well with Ubuntu - particularly 13.10
No. If eapol_test works, FreeRADIUS is fine.
2). Do the certificates need the same grooming that Windows Certificates would need?
No. Only Windows needs that idiocy. The documentation says this.
Or would generating them from the command line on Ubuntu using OpenSSL suffice?
Don't. Use the scripts in raddb/certs. That directory has a README, too.
i.e. Could I assume that Ubuntu's Wi-Fi client utilizes the same process as eapol_test when using the target configuration?
It should.
3). Is it a fair assumption that if the eapol_test results in SUCCESS using my targeted configuration (TTLS-EAP-MSCHAPv2) that the FreeRADIUS server is indeed set up correctly and that something else may be causing the problem i.e. The router's Wi-Fi/RADIUS proxy, Ubuntu's Wi-Fi client etc.
Yes.
Log Output from radiusd -X ==========================
Which shows a success, but no failure. Making it impossible to debug any failure. Alan DeKok.