How-To: Troubleshoot Cloud RADIUS

How To Troubleshoot RADIUS Configuration in EZRADIUS - Video Version

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. Within the Audit Logs section, you should see 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 Add your IP Address Dynamically to your Cloud RADIUS Policy

If you have checked all the previous steps and you are still not seeing any logs in your EZRADIUS portal, it might be due your traffic being NATed and therefore the IP address that is reaching EZRADIUS is not the one you have configured in your RADIUS policy. To solve this issue, we have added a feature that allows you to add any IP address that connects to the RADIUS server with a specific shared secret. To use this feature, you must go to your RADIUS policy and click the Enable IP Auto-Discovery for 10 minutes checkbox and save the policy. This will give you a new shared secret that you can use in your access point. Any IP address that connects to the RADIUS server with this shared secret will be automatically added to the allowed IP addresses in your RADIUS policy for 10 minutes.

NOTE: In our basic plan this is limited to 10 minutes, but if you have a private or enterprise instance this can be enabled permanently allowing you to automatically add locations with dynamic IP addresses.

How to Troubleshoot RADIUS Authentication Failure

The wrong shared secret was used to connect your network to EZRADIUS please check your configuration

Incorrect Shared Secret

If you see the 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:

There are three common issues that might be causing this error:

1. Incorrect password: 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. Caching: If the shared secret was recently changed in your RADIUS policy, your networking devices and EZRADIUS have caching mechanisms that might take a few minutes to update. Please wait for a few minutes and try again.
3. Shared secret length: 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 Server Certificate

A RADIUS server certificate is used to establish a secure, encrypted connection between the client and the RADIUS server during EAP-TLS and EAP-TTLS authentication. If there is an issue with the RADIUS server certificate, the client will not be able to establish a secure connection with the RADIUS server and the authentication will fail.

If you see the following error:

There is an issue retrieving your server certificate please manually renew it in the portal

This means your server certificate is expired, corrupted, or missing. To solve this issue, you can renew your server certificate:

1. Log into the EZRADIUS portal with your admin account.
2. Navigate to the Policies page in the left-hand menu.
3. Scroll down to your RADIUS policy and find the Server Certificate > Existing Certificate section.
4. Click on the “Renew” button to renew your server certificate.
   • If you used an Auto-Generated or EZCA certificate, the certificate will be automatically renewed and there is no further action needed on your part.
   • If you used a 3rd party CA, follow the instructions to generate a CSR, get it signed by your CA, and then upload the new certificate to EZRADIUS.

Since your new server certificate will be issued by the same Certificate Authority (CA) as your existing certificate, you will not need to push any new trusted CA to your devices, as they will already trust the new server certificate. They will automatically trust the new certificate once it is issued.

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

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

If you see the 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

Failed to build and validate certificate (XXX): NotTimeValid: certificate has expired

If you see error Failed to build and validate certificate (XXX): NotTimeValid: certificate has expired, it means that the certificate has expired. Using your existing PKI infrastructure, please renew the certificate and push it to your devices.

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

Failed to build and validate certificate (XXX): UntrustedRoot: self-signed certificate in certificate chain

Invalid certificate: Failed to build certificate chain to a valid CA

If you see the 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

Exception occurred when validating the CRL

If you see the 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

Continue connecting?
If you expect to find <SSID> in this location, go ahead and connect. Otherwise, it might be a different network with the same name.

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 you are testing you can click Connect and continue).

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

Username and Password authentication failed. Error password expired

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

The error “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

Invalid secret for the server

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

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

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 solve this, you must enable “RADIUS Testing” in your RADIUS server configuration in the Meraki portal.

How to Troubleshoot RadSec Authentication Issues

Trying to troubleshoot RadSec issues can be tricky since if the RadSec authentication fails, we do not know which customer made the request so we cannot log it in your RADIUS authentication logs. However, if you add your public IP address to the Classic RADIUS section of your RADIUS policy, you will be able to see the failed RadSec requests that come from that IP address in your RADIUS authentication logs. This way, you can troubleshoot the issue and then remove the IP address from the Classic RADIUS section once you have resolved the issue.

Certificate Authority Already Claimed By Someone Else

Because RadSec attributes a request to an EZRADIUS instance based on the certificate used to authenticate the request, a certificate authority can only be used by one EZRADIUS policy. It cannot be shared between multiple policies. If you are trying to use the same certificate authority in multiple RADIUS policies, you will get the error “Error: Certificate Authority already claimed by someone else”. To solve this issue, you must ensure that each certificate authority is only used in one RADIUS policy.

If you need different behavior for different access points, we recommend using one RADIUS policy with different Matching Request Attributes under Advanced Settings to differentiate the access points.

I Can’t Get RadSec to Work, and I don’t see Any Logs in the RADIUS Authentication Logs?

RadSec is tricky to diagnose, because if the RadSec authentication fails, we do not know which customer made the request so we cannot log it in your RADIUS authentication logs. However, if you add your public IP address to the Classic RADIUS section of your RADIUS policy, you will be able to see the failed RadSec requests that come from that IP address in your RADIUS authentication logs. This way, you can troubleshoot the issue and then remove the IP address from the Classic RADIUS section once you have resolved the issue.

Misconfigured RADIUS and Accounting Ports

If you’re seeing the following error:

Authentication service only supports processing Access-Request datagrams

This usually means that you are sending Accounting logs to port 1812 instead of port 1813. Make sure you configure your network controller to send Accounting logs to port 1813 and Authentication logs to port 1812.