If you have followed the steps for configuring EAP and are encountering problems, there are only a few things that go wrong. This article goes through the most common issues and how to fix them.
Troubleshooting "explicit EAP failure received" error
For Windows systems, an "explicit EAP failure received" message indicates that the RADIUS server explicitly rejected the authentication attempt during the EAP exchange. This error message is generic and doesn't reveal why the EAP session failed. This vague message is frustrating and causes issues for administrators and end-users.
This section describes some common causes of the EAP failures, and what to do about them.
Common causes of explicit EAP failures
Certificate validation problems
The most frequent cause is certificate issues. The client may be unable to validate the server certificate due to:
Expired server certificates
Missing intermediate CA certificates in the certificate chain
Client lacks the root CA certificate to validate the chain
The server cannot validate the client certificate (if it exists) due to certificate revocation list (CRL) or OCSP validation failures
The solution to the above issues is to work closely with the server administrator to verify the certificates and to ensure that the Windows system is configured correctly.
EAP method mismatch
The client and server must agree on an EAP method. Explicit failures occur when:
Client requests an EAP method the server doesn't support (e.g. client wants EAP-TLS but server only offers PEAP)
Phase 2 (inner authentication) method mismatch in tunnelled EAP methods like PEAP or TTLS
The solution to EAP method mismatch is to check that the Windows system is configured to use the correct EAP methods. The RADIUS server administrator may have documentation or tools that describe the correct configuration.
Credential problems
Even with correct EAP negotiation, authentication can fail due to:
Incorrect username or password
User account locked or disabled in the authentication backend
Password storage format incompatible with the EAP method (see our guide on RADIUS password compatibility)
The solution to credential problems is to double-check that the credentials exist and are valid. The RADIUS server administrator may be able to provide a web page where the user credentials can be checked.
TLS version incompatibility
Modern security requirements can cause issues:
Client only supports older TLS versions (1.0, 1.1) that the server has disabled
Server requires TLS 1.3 but client doesn't support it
Cipher suite mismatch between client and server TLS configurations
The solution to TLS version incompatibility is to ensure that both the Windows system and the RADIUS server are using the most recent version of TLS.
Diagnostic steps for explicit EAP failures
1. Check the RADIUS server logs in debug mode
Run FreeRADIUS in debug mode (`radiusd -X`) to see detailed EAP exchange information. Look for certificate validation errors, EAP method negotiation failures, or backend authentication rejections.
Simply searching the logs for the words “ERROR” or “WARNING” or “Reject” will usually lead you to a message that tells you exactly what is going wrong.
2. Verify certificate validity and chain
The server administrator should check that the server certificate is valid, not expired, and includes all intermediate certificates. Test certificate validation from the client side, too.
3. Confirm EAP method configuration
Verify that both client supplicant and RADIUS server are configured to the same EAP method. Check that any required phase 2 methods and credentials match.
4. Test with known-good credentials
Rule out credential issues by testing with a verified working account.
5. Check TLS configuration compatibility
Review enabled TLS versions and cipher suites on both client and server. Modern clients should support TLS 1.2 or 1.3.
Preventing explicit EAP failures
After resolving EAP configuration issues, validate device compatibility and authentication capabilities systematically across your device fleet. For organisations managing diverse wireless devices - such as ISPs, mobile operators, and enterprises – our EAP Inspector tool provides automated device authentication profiling to identify compatibility issues before they cause authentication failures.
The EAP Inspector tool gives you information on:
Supported EAP methods for each device
TLS version and cipher suite compatibility
Certificate validation behaviour
Authentication performance and session resumption capabilities
The EAP Inspector tool is available exclusively to InkBridge Networks support clients. Learn more about EAP Inspector.
Common "EAP authentication failed" errors
Beyond explicit failures, EAP authentication can fail at various stages of the process. Understanding where in the EAP exchange the failure occurs helps narrow down the root cause. The issues here are largely solvable only by the RADIUS server administrator.
Authentication timeout failures
Symptoms: Authentication attempts time out without completing the EAP exchange.
Common causes:
Network connectivity issues between client and RADIUS server
Firewall blocking RADIUS traffic (UDP port 1812 for authentication)
RADIUS server overloaded or not responding
Proxy configuration errors in federated authentication (e.g. eduroam)
Resolution: Verify network connectivity, check firewall rules, confirm RADIUS server is running and responsive, review proxy configurations.
Phase 1 vs Phase 2 failures
For tunnelled EAP methods (PEAP, TTLS, TEAP), authentication occurs in two phases:
Phase 1 (outer authentication): Establishes the TLS tunnel
- Failures here typically involve certificate or TLS configuration issues
- Client often displays generic "cannot connect" or "certificate error" messages
Phase 2 (inner authentication): Authenticates the user inside the tunnel
- Failures here typically involve credentials or backend authentication issues
- More difficult to diagnose as the tunnel encrypts the inner authentication
Diagnostic tip: If Phase 1 succeeds (TLS tunnel establishes) but authentication still fails, focus on credentials and backend authentication configuration.
Backend authentication failures
Even when EAP negotiation succeeds, authentication can fail if the backend cannot validate credentials:
LDAP or Active Directory connectivity issues
SQL database connection failures
User not found in authentication backend
Incorrect LDAP search filters or SQL queries
Permission issues accessing the authentication backend
Resolution: Test backend connectivity independently, verify user accounts exist, check RADIUS server logs for backend-specific error messages.
Server unresponsive after sending request
Problem: A lot of text scrolls by, the server sends an Access-Challenge, and then prints out a message saying
Cleaning up request ...
After that, nothing more happens. The debug output will likely contain a message about unknown CA.
Diagnosis: The client does not like the server certificate, or the CA which issued that certificate.
Solution: On a testing system, un-check Validate Server Certificate as noted in the EAP page.
Solution: On a production system, ensure that the client has been configured with the certificates from the proper Certificate Authority and Server certificate, as noted in the EAP page.
Solution: On a production system, ensure that the client has Server certificate has the proper “TLS Web server” OID’s (Object Identifiers). (Yes, EAP needs a “web server” certificate. That decision was made 20 years ago, and can’t be changed now.)
Don’t worry, the FreeRADIUS certificate creation scripts in /etc/raddb/certs/ create the certificates with the proper information. Unless you already have a certificate management system, these certificate creation scripts should always be used to create RADIUS certificates.
See also KB-814394. Note that we do not necessarily agree with their explanations, but the fix does appear to work.
Server sends Access-Reject
Problem: The server sends an Access-Reject.
Diagnosis: The password entered on the client does not match the “known good” password that the server has.
Solution: Double-check that the passwords are the same. Use the simplest possible configuration to do this.
Other issues
Problem: The Windows client still won’t connect.
Diagnosis: If none of the above fixes work, and you still see the Access-Challenge sent… and then nothing, the problem is some kind of Windows magic.
Solution: Enable EAPHost Tracing.
To enable tracing, run the following commands from a privileged command prompt (i.e. as Administrator):
netsh wlan set tra yes netsh ras set tr * en
After the problem has been reproduces (using one login attempt), tracing can be disabled by:
netsh ras set tr * dis netsh wlan set tra no
The output files (*.etl) will be in the %windir%\tracing\wireless\ directory, usually in various subdirectories. The .etl files can be converted to .txt files via the following command:
tracerpt
The final files can be put on a web page, and questions posted to the freeradius-users list.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Additional resources for EAP authentication
Testing and validation
Command-line testing for EAP with FreeRADIUS - Learn how to test EAP authentication manually using eapol_test
Configuring EAP for FreeRADIUS - Step-by-step guide to EAP configuration
EAP Inspector - Automated device authentication testing for support clients
Understanding EAP methods
How authentication protocols work - Deep dive into EAP, PAP, CHAP, and MS-CHAP
RADIUS protocol and password compatibility - Which authentication methods work with which password storage formats
Security and best practices
Making RADIUS more secure - Security hardening for RADIUS deployments
Is PAP secure? - Understanding PAP security in EAP-TTLS deployments
Related Articles
Creating server certificates for FreeRADIUS
Once the initial EAP testing has been performed, it's time to create the production-grade server certificates for your FreeRADIUS environment. These certificates form the foundation of secure communications in your production network and will be configured on the end hosts using PEAP, TTLS, or EAP-TLS authentication.
Command line testing for EAP with FreeRADIUS
As part of the process of configuring EAP for FreeRADIUS, you will need to test whether or not it works. If you prefer to use a command line tool rather than clicking through windows, this article walks through the steps for testing your EAP configuration.