---
title: Troubleshooting RADIUS Authentication with Access Server
canonical: https://openvpn.net/as-docs/radius-troubleshooting/
product: Access Server Docs
description: Resolve RADIUS authentication issues in Access Server using third-party directories like JumpCloud, Active Directory, or Entra ID.
---

# Troubleshooting RADIUS Authentication with Access Server

Access Server can look up users in directory services using RADIUS. You can [configure RADIUS](https://openvpn.net/as-docs/radius.md) authentication with the [Admin Web UI](https://openvpn.net/as-docs/admin-web-ui-user-manual.md) or the [command-line interface](https://openvpn.net/as-docs/tutorials/tutorial--radius-command-line.md).

This topic provides troubleshooting tips and help for various error messages and use cases customers have encountered. Feel free to reach out to [support](https://support.openvpn.com/) for help as well.

## Enable verbose debugging

You can enable verbose authentication debugging to help troubleshoot connection issues with your directory service.

1. Sign in to the terminal or connect via SSH to your Access Server.
2. Execute the following commands:

   ```
   sudo echo "DEBUG_AUTH=true" >> /usr/local/openvpn_as/etc/as.conf
   sudo systemctl restart openvpnas
   ```

   - Access Server will now log verbose authentication messages to the standard Access Server log file at `/var/log/openvpnas.log`.
3. You can send the file to [our support team](https://support.openvpn.com/); they will assist you further.

Once you've finished debugging, turn off verbose authentication logging to prevent your logs from growing too fast.

1. Open the **as.conf** for editing:

   ```
   nano /usr/local/openvpn_as/etc/as.conf
   ```
2. Delete or comment out the line `DEBUG_AUTH=true`.
3. Save and exit the file.
4. Restart the Access Server service:

   ```
   sudo systemctl restart openvpnas
   ```
5. Verbose authentication logging no longer occurs.

## User not found

**Issue:** This error occurs when the RADIUS username doesn't exist in the directory service used by the RADIUS server.

**Solution:** Ensure you're using a valid username as configured in the RADIUS server.

## RADIUS access denied

**Issue:** RADIUS access is denied due to incorrect credentials or mismatched RADIUS configurations.

**Solution:** Check the following:

1. Verify that the password for the RADIUS user is correct.
2. Ensure Access Server is sending the correct data to the RADIUS server and that the RADIUS server is accepting it.

## RADIUS timeout on try #2 server

**Issue:** A timeout error indicates a communication failure between the OpenVPN Access Server and the RADIUS server.

**Solution:** Consider these potential causes:

- Ensure that Access Server can communicate with the RADIUS server.
- Check for any network firewalls, routers, or proxies blocking RADIUS traffic.
- Verify the shared secret is correct.
- Ensure the RADIUS authentication isn't timing out.
- Ensure that external MFA solutions are not causing delays, which may result in a timeout.

## Check that the correct RADIUS Username and Password are used while authenticating with Access Server

**Issue:** Ensure that external MFA solutions are not causing delays, which may result in a timeout.

**Solution:**

- Double-check the RADIUS username and password on the RADIUS server.
- If the password is expired or forgotten, reset it and try again.

## MFA causes user to get locked out

**Issue:** Users are locked out due to MFA-related issues or missed enrollment steps. A user receives a **LOCKOUT** error message when attempting to sign in.

**Solution:** This is tied to Access Server's lockout policy. Refer to [User Lockout](https://openvpn.net/as-docs/authentication-failure-lockout-policy.md) for details.

If your user hasn't enrolled in MFA yet, when they first sign in, they're prompted with challenges to enroll. Each challenge is seen as a login attempt in your Access Server logs. If the user waits 15 minutes, they can sign in again and shouldn't be locked out anymore. Adjust lockout policies in Access Server if needed.

## DENY: user in deny list, account suspended, or access denied

**Issue:** You encountered one of these error messages:

- **DENY: user in deny list**
- **user account suspended**
- **User access denied**

**Reason:** This error message occurs in one of two situations:

1. The **deny access** box is checked for the user in the **User Permissions** table.
2. The **Deny access to unlisted accounts by default** is set to **Yes**. The user authenticates with an external system (PAM, LDAP, RADIUS, or SAML) and doesn't exist in the **User Permissions** table or match the username in the external system.

### Resolution for deny access box

1. Sign in to the Admin Web UI.
2. Click **User Management \> User Permissions**.
3. Click **Deny Access** to uncheck the box for the username.
4. Select **Save Settings** and **Update Running Server**.

### Resolution for Deny access to unlisted accounts by default

You can resolve the issue by adding the user to Access Server's user permissions table or by allowing Access Server to add users automatically by setting **Deny access to unlisted accounts by default** to **No**.

Follow the steps below for your preferred option.

#### Add the user:

1. Sign in to the Admin Web UI.
2. Click **User Management \> User Permissions**.
3. Add the user to the **User Permissions** table if it doesn't exist.
   - Ensure the spelling and case match between Access Server and the external authentication server.
4. Select **Save Settings** and **Update Running Server**.

#### Allow Access Server to add users:

##### Via the Admin Web UI

1. Sign in to the Admin Web UI.
2. Click **Authentication \> Settings**.
3. Under **External User Registration**, set **Deny access to unlisted accounts by default** to **No**.
4. Select **Save Settings** and **Update Running Server**.

##### Via the command-line interface (CLI)

1. Connect to the console and get root privileges.
2. Switch to the scripts directory:

   ```
   cd /usr/local/openvpn_as/scripts/
   ```
3. Run the blow command to change the value to "false" (Default) or "true":

   ```
   ./sacli --user "__DEFAULT__" --key "def_deny" --value "false" UserPropPut
   ./sacli start
   ```

## Check that the correct RADIUS Server (Domain or IP) is configured on the RADIUS Client (Access Server)

**Issue:** RADIUS communication fails if the RADIUS Server domain or IP is incorrectly configured in Access Server.

**Solution:** Verify that the correct RADIUS server domain or IP is configured on Access Server.

## Check that the correct RADIUS Client (Access Server)Domain or IP is configured on the RADIUS Server

**Issue:** RADIUS authentication fails if the RADIUS client (Access Server) is not correctly configured on the RADIUS server.

**Solution:** Ensure that the RADIUS client domain or IP is correctly configured in the RADIUS server.

## Check that the Shared Secret matches on both RADIUS Server and Access Server

**Issue:** Mismatched shared secrets will cause authentication failures between the Access Server and the RADIUS server.

**Solution:** Double-check that the shared secret matches on both the Access Server and the RADIUS server.

## Check that the correct Authentication Port is configured on Access Server

**Issue:** If the RADIUS authentication port is misconfigured, authentication will fail.

**Solution:** By default, the RADIUS authentication port is UDP 1812. Ensure that the RADIUS server is listening on the correct authentication port (UDP 1812 by default), and configure this port correctly on both the Access Server and the RADIUS server.

## Check that the Authentication Port (UDP 1812) is open on the RADIUS Server

**Issue:** If port UDP 1812 is blocked, RADIUS communication will fail.

**Solution:** Ensure that UDP port 1812 is open on the RADIUS server and that no firewall, router, or proxy in between is blocking this port.

## Check if the RADIUS Server supports Message-Authenticator Attribute

**Issue:** RADIUS authentication may fail if the server requires support for the Message-Authenticator attribute but Access Server doesn't support it.

**Solution:** If your RADIUS server enforces the Message-Authenticator attribute, ensure it is enabled on Access Server. If it's unsupported, disable it in Access Server's RADIUS settings.

## Check if the Accounting is enabled on your RADIUS Server

**Issue:** RADIUS accounting mismatch can result in authentication failure.

**Solution:** Ensure that accounting is either enabled or disabled on both the RADIUS server and Access Server.

## Check that the correct RADIUS Authentication Method is configured on both sides (RADIUS Server and Client)

**Issue:** Authentication method mismatch between Access Server and the RADIUS server can cause authentication to fail.

**Solution:** Confirm that Access Server and the RADIUS server use compatible authentication methods. Access Server supports PAP, CHAP, and MSCHAP-V2.

## Check that your RADIUS Users are in active state on the RADIUS Server

**Issue:** If the RADIUS user is inactive or denied in the RADIUS server, authentication will fail.

**Solution:** Ensure the RADIUS user is in an active state in the RADIUS server.

## If you're using external MFA solution, check MFA timeout

**Issue:** External MFA timeout causes RADIUS authentication failure.

**Solution:** Increase the RADIUS timeout or the MFA timeout to avoid timeouts causing authentication failure.

> **Note**
>
> When you use an external MFA solution such as JumpCloud MFA or MFA via Azure NPS Extension, this MFA flow is transparent for Access Server. From the Access Server perspective, the MFA flow is part of his RADIUS flow. Thus, if the RADIUS timeout on Access Server is one minute, but the MFA challenge takes more than one minute, the RADIUS authentication fails due to timeout.

## Use radtest for troubleshooting

**Issue:** You want to test RADIUS authentication using the **radtest** utility.

**Solution:**

### Install radtest

1. Connect to your console and get root privileges.
2. Run the following command to install the RADIUS utilities:
   - For Ubuntu/Debian:

     ```
     apt update && apt -y install freeradius-utils
     ```
   - For RHEL:

     ```
     yum -y install freeradius freeradius-utils freeradius-mysql freeradius-perl
     ```
3. You can now use the **radtest** tool.

### Basic radtest command

Below is the syntax of the **radtest** command:

```
radtest -t Method Username Password Server 0 SharedSecret
```

When you use the **radtest** utilities, you enter your RADIUS settings as the values. For our examples below, we use the following RADIUS settings in our Access Server:

- **Method:** pap
- **Username:** ovpnuser
- **Password:** pass123
- **Server:** 203.0.113.30
- **SharedSecret:** shared123

> **Note**
>
> In our documentation, we use example IPv4 addresses and subnets [reserved for documentation](https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4), such as `192.0.2.0/24`, `198.51.100.0/24`, and `203.0.113.0/24`.
>
> Ensure you replace them with valid IPv4 addresses and subnets for your network(s).

### Example commands

Use the following example commands to input your specific RADIUS settings for troubleshooting.

- Run a RADIUS Access-Request using PAP:

  ```
  radtest -t pap ovpnuser pass123 203.0.113.30 0 shared123
  ```
- Run a RADIUS Access-Request using CHAP:

  ```
  radtest -t chap ovpnuser pass123 203.0.113.30 0 shared123
  ```
- Run a RADIUS Access-Request using MSCHAP:

  ```
  radtest -t mschap ovpnuser pass123 203.0.113.30 0 shared123
  ```

After successful authentication, a message similar to the following displays:

```
root@openvpnas2:~# radtest -t pap ovpnuser pass123 203.0.113.30 0 shared123
Sent Access-Request Id 184 from 0.0.0.0:35736 to 203.0.113.30:1812 length 75
User-Name = "ovpnuser"
User-Password = "pass123"
NAS-IP-Address = 127.0.1.1
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "pass123"
Received Access-Accept Id 184 from 203.0.113.30:1812 to 0.0.0.0:0 length 38
Message-Authenticator = 0x296f8a9d86fe12d3d134771d3d1262dd
```

> **Important**
>
> The **radtest** tool doesn't support MSCHAP-v2. So, if your OpenVPN Access Server and the RADIUS Server are using MSCHAP-v2, using **radtest** won't help for troubleshooting.

## Using authcli tool for troubleshooting

You can use **authcli**, the authentication testing tool available in the command line, to run tests and get useful debugging information. To run **authcli**, ensure you are in the `/usr/local/openvpn_as/scripts/` directory and run the commands as a root user.

- Verify user authentication:

  ```
  ./authcli --user <USER_NAME> --pass <PASSWORD>
  ```

  - Sample output of a successful authentication:

    ```
    API METHOD: authenticate
    AUTH_RETURN
      status : SUCCEED
      user : ovpnuser
      reason : RADIUS MS-CHAP2 access accpeted
      proplist : {'prop_autogenerate': 'true', 'prop_force_lzo': 'false', 'type': 'user_connect', 'pvt_password_digest': '$P$pd6QIFjNFHGVjYQrRnlf3A==$nZ244AMtfn9Zv8cYvXRvB1tHAiEoqHJuVdRbm1K/clk=', 'user_auth_type': 'radius'}
      session_id : AS_DPsv5PfpSRZU56qPN2vzmg==
      expire : 173213664
    ```
- If you use Access Server built-in multi-factor authentication (MFA), verify authentication with this command:

  ```
  ./authcli --user <USER_NAME> --pass <PASSWORD> --sr=<MFA_CODE_HERE>
  ```

> **Caution**
>
> Using `--sr` in the above commands works only with Access Server's built-in MFA. It doesn't work if you have MFA through another provider.

---

Prev: [SAML](https://openvpn.net/as-docs/saml-troubleshooting.md)
Next: [Failure](https://openvpn.net/as-docs/failure.md)
Index: https://openvpn.net/as-docs/llms.txt