How To Troubleshoot Cloud RADIUS

How To Troubleshoot RADIUS Configuration in EZRADIUS

If you have setup your Cloud RADIUS instance and are having trouble authenticating users, this guide will help you troubleshoot your Cloud RADIUS configuration for EAP-TLS or Entra ID Wifi Authentication in EZRADIUS.

1. The first step to troubleshoot your RADIUS connection is to go to your EZRADIUS portal and click on Audit Logs. This will have most of the information you need to troubleshoot your RADIUS connection.
2. In the top tab selector select “Authentication Logs” to view the logs of users authenticating to your Cloud RADIUS instance.
3. In the next sections we will go through some common issues and how to troubleshoot them.

How to Troubleshoot No Logs in Authentication Logs

1. In here we should see some connection attempts from your access points. If you don’t see any logs, it means your access points are not sending the RADIUS requests to your Cloud RADIUS instance. or that the wrong IP address is configured in your access points.
2. Check your IP address in Nord VPN page and ensure that that is the IP address you have configured in your RADIUS policy:
3. If the IP address is correct, check your access point configuration and ensure that the RADIUS server is configured correctly.
4. You can also Run Wireshark on your test machine with the filter ‘udp port 1812’ to see if the RADIUS requests are reaching your Cloud RADIUS instance. This is how a successful RADIUS request looks like:
5. If you only see one way ensure that your firewall is not blocking the RADIUS requests.

How to Troubleshoot RADIUS Authentication Failure

1. If you see an error “The wrong shared secret was used to connect your network to EZRADIUS please check your configuration” or “Incorrect Shared Secret” it means that the shared secret configured in your access point is incorrect.
2. This means that your access point is sending the RADIUS request with the wrong shared secret. This can be caused due to 3 reasons:
   1. the wrong secret was sent by the networking device. Ensure that the shared secret in your access point matches the shared secret in your RADIUS policy.
   2. The shared secret was recently changed in your RADIUS policy, both networking devices and EZRADIUS have caching mechanisms that might take a few minutes to update.
   3. The shared secret is too long for your networking device. Some networking devices have a limit on the length of the shared secret. To troubleshoot this ensure that the shared secret is less than 16 characters.

How to Troubleshoot RADIUS Authentication EAP-TLS Failure

In EAP-TLS authentication, the client sends a certificate to the RADIUS server. The RADIUS server validates the certificate and if it is valid, it sends an Access-Accept message to the client. If the certificate is invalid, the RADIUS server sends an Access-Reject message to the client. There are many issues that might be causing the EAP-TLS authentication to fail. Here are some common issues and how to troubleshoot them:

How To Troubleshoot EAP-TLS Authentication Failure Invalid Certificate

1. If you see an error “Failed to build and validate certificate (XXXX): RevocationStatusUnknown: unable to get certificate CRL OfflineRevocation: unable to get certificate CRL UntrustedRoot: self-signed certificate in certificate chain” it means that one of the certificates in the certificate chain is invalid. Please ensure that all the certificates in the certificate chain are part of your Policy Trusted Certificate Authorities.

How To Troubleshoot EAP-TLS Authentication Failure Certificate Expired

1. If you see an error “Failed to build and validate certificate (XXX): NotTimeValid: certificate has expired” it means that the certificate has expired. Please ensure that the certificate is not expired.

How To Troubleshoot EAP-TLS Authentication Failure Failed to build certificate chain to a valid CA

If you see an error “Failed to build and validate certificate (XXX): UntrustedRoot: self-signed certificate in certificate chain” or “Invalid certificate: Failed to build certificate chain to a valid CA” it means that the certificate is not trusted. Please ensure that the certificate is part of your Policy Trusted Certificate Authorities. Another common issue that might cause this error is that the certificate that Windows (or whatever device you are using) is using to authenticate to the RADIUS server is not the one you expect and therefore it is not trusted by the RADIUS server. To solve this issue, you must ensure that the certificate being used by the client is the one you expect. You can do this by going to your Audit logs and ensuring that the certificate thumbprint matches the one you expect.

How To Troubleshoot EAP-TLS Authentication Error Validating CRL

If you see an error “Exception occurred when validating the CRL” it means that the Certificate Revocation List (CRL) was not accessible by EZRADIUS. Please ensure that the certificates you are using have a valid CRL accessible through http (this is for the full chain, so it might also be the Root CA CRL).

1. If your CRL is not accessible by EZRADIUS, you can either bypass the CRL or set an alternative CRL URL. To do this, go to your RADIUS policy and select the Certificate Authority that does not have a CRL accessible by EZRADIUS and select the “Manage Validation” Button.
2. In here you can select the “Ignore Revocation” option to bypass the CRL check or set an alternative CRL URL that is accessible by EZRADIUS.
3. Once you have set your revocation settings, for all your CAs, you can go back to your RADIUS policy and select the “Save” button at the top to save your changes.

How To Troubleshoot TLS Handshake Failure

This error usually occurs when the client and the server cannot agree on the cryptographic tunnel to start the authentication. The most common issue with this is the client not trusting the server certificate. For this you must ensure that the server certificate is trusted by the client (if testing manually just accept when it as). When using an MDM you must distribute the Root Certificate Authority, (found under “Server Certificate in your RADIUS Policy) to your devices. and Add the subject name and IP address of the RADIUS server to the wifi profile. The other issue is if the client does not support the cryptographic tunnel that the server is trying to use. In this case, we recommend looking at the device logs to see what is the issue.

How To Troubleshoot Client Rejected RADIUS Server Certificate

For this you must ensure that the server certificate is trusted by the client (if testing manually just accept when it as). When using an MDM you must distribute the Root Certificate Authority, (found under “Server Certificate in your RADIUS Policy) to your devices and add the subject name and Subject alternate name of the RADIUS server certificate to the Wifi profile. For example, if I was using Intune I would (assuming we already added the Root CA for the RADIUS server as a trusted Root In Intune):

1. I would go to Intune and open my wifi Profile:
2. In the server trust I would add the Root CA for the RADIUS server.
3. Get the server certificate from the RADIUS policy in EZRADIUS.
4. Open the Certificate and get the Subject Name (This one is usually EZRADIUS) and Subject Alternate Names that are found in the details tab.
5. Add the Subject Name and Subject Alternate Names to the Wifi Profile in Intune Note the ones for your certificate will be different don’t just copy the ones here.

RADIUS Handshake Failure After Certificate Is Trusted By Client

If you have ensured that the certificate is trusted by the device and you are still getting the “Handshake Failure” and you are on a Windows device, this might be due to the TPM having some issues with signing the TLS handshake. To solve this issue, you can try the following:

1. Open the Registry Editor (regedit).
2. Backup this key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003
3. Under Functions remove the following signature suites from the list:
   • RSAE-PSS/SHA256
   • RSAE-PSS/SHA384
   • RSAE-PSS/SHA512
4. Reboot your device.

How to Troubleshoot RADIUS Password Authentication

1. If you see the error “Username and Password authentication failed. Error password expired” it means that the password has expired. Please reset the password in the EZRADIUS portal.

How to Troubleshoot RADIUS EAP Session Was Lost

“EAP Session was lost” is a common issue when troubleshooting RADIUS, it usually means that the client device did not respond to the RADIUS server in time. This can be caused due to many reasons, here are the most common ones:

EAP Session Was Lost Due to Client Device Timeout

If your device (laptop, phone, etc) has the timeout set too low, it might timeout before the RADIUS server responds. causing it to stop responding to the RADIUS server. To troubleshoot this increase the timeout on your device, if you are using and MDM such as Intune, then you can increase the timeout in the wifi profile (EZRADIUS times out after 30 seconds, so we recommend setting it to 30 seconds).:

EAP Session Was Lost Due to Access Point Timeout

By default most networking devices have the RADIUS timeout set to 5 seconds, if the RADIUS server does not respond in 5 seconds the networking device will stop responding to the RADIUS server, this does not account for RADIUS servers not hosted in your network, so we recommend increasing the timeout to 30 seconds. Here is a sample on how to setup the RADIUS timeout under RADIUS Advanced Settings a Cisco Meraki device:

Multiple IP Addresses in RADIUS Setup Causing EAP Session Was Lost

We have seen some networking devices (mostly cisco (including Meraki) and fortinet) that have issues when there are multiple IP addresses in the RADIUS (They will send the request to the first IP address and then the second IP address, but the second IP address will not respond since the first IP is the one that started the authentication). If you are facing this issue, we recommend removing the second IP address from the RADIUS configuration (Don’t worry while it is only one IP address that does not mean it is one server we have multiple servers per availability zone).

How to Troubleshoot RADIUS Authentication Error When There are No Logs in the RADIUS Server

When there are no logs or the logs are ambiguous such as “EAP session lost”, it is usually due to the RADIUS server not receiving the request. This can be caused due to many reasons, some of them are network related, but some others can be caused by the Windows device not trusting the RADIUS server certificate or the network to see these logs in Windows you must:

1. Open the Event Viewer.
2. Go to Applications and Services Logs -> Microsoft -> Windows -> WLAN-AutoConfig -> Operational.
3. In here you can find Error logs that will help you troubleshoot the issue.

Invalid Secret For The Server on Fortinet Devices

If you are using Fortinet devices, and you updated to Fortigate 7.2.10 you are probably getting the ‘Invalid secret for the server’ error.

This is due to the Fortigate now requiring the Message Authenticator attribute in the RADIUS request (while not sending it in the initial request). To fix this you must enable the “Always Send Message Authenticator” in your RADIUS policy in EZRADIUS.

No matching access policies

If you see the error “No matching access policies” it means that we couldn’t find any access policies that match your requirements this can be caused due to two reasons:

1. The Access Policies were not saved, ensure that you have saved the Access Policies in the EZRADIUS portal.
2. Your “Matching Attributes in Request” under advanced settings is too strict, we recommend setting the Matching Scheme to “Contains” since some networking devices may add more information to the field you are checking:

Thumbprint Showing up as the Username

If you see the thumbprint showing up as the username in the logs, it means that EZRADIUS is performing the basic certificate validation on the certificate and it is not doing some of the more advanced checks such as Entra ID or Intune matching. To enable these checks you must enable the “Match with Entra ID Objects” in the RADIUS policy and tell EZRADIUS where to find the username or device ID.

Unauthorized Certificate Failed to Get ID from Certificate

This error usually occurs when a certificate is issued by a CA that is trusted by EZRADIUS but we were not able to get the User Email or Device ID from the certificate. This is usually caused due to the certificate not having the User Email or Device ID in field you specified in the RADIUS policy. To solve this issue, you must ensure that the certificate has the User Email or Device ID in the field you specified in the RADIUS policy. You can do this by going to your RADIUS access policy and check under the “Match Certificate Attribute with Entra ID” section and ensure that the field you specified in the RADIUS policy matches the field in the certificate. Below are some examples of the fields you can use to match the certificate with Entra ID:

Certificate Subject Alternative Name (Email)

Certificate Subject Alternative Name (UPN)

Certificate Subject Name

Meraki MS Switch is not authenticating to RADIUS

If you are using Meraki MS Switches and you are not able to authenticate to RADIUS, it is probably due to the switch marking the RADIUS server as “unhealthy” and never connecting to it again this seems to be a known issue that requires RADIUS Monitoring to be enabled from the backend. To enable this you must contact Meraki support and ask them to enable RADIUS Monitoring on your switch. Once this is enabled, you should be able to authenticate to RADIUS without any issues. Here is a direct quote from Meraki support: “This is related to a known issue, particularly on MSxxx, that is still being investigated with engineering (not sure of the trigger). I had to enable a workaround on the backend which enables RADIUS monitoring and it would need to be added to other networks with MSxxx in order to avoid running into the issue. I do not have an ETA on when the permanent solution will be rolled out”.