Skip to main content

Troubleshooting RADIUS Authentication with Access Server

Abstract

Resolve RADIUS authentication issues in Access Server using third-party directories like JumpCloud, Active Directory, or Entra ID.

Access Server can look up users in directory services using RADIUS. You can configure RADIUS authentication with the Admin Web UI or the command-line interface.

This topic provides troubleshooting tips and help for various error messages and use cases customers have encountered. Feel free to reach out to support 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 service openvpnas restart

    • 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; 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 service openvpnas restart

  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 Authentication failure lockout policy 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.

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.

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.

Via the command-line interface (CLI)

  1. Connect to the console and get root privileges.

  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, 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.

In this section: