Caiyos Computer Services

Menu

How to Use OpenVPN with Radius Authentication

02/13/2023

I have found that the interweb is rife with confusing, incomplete, and incorrect information regarding the use of OpenVPN with radius authentication. So, after a lot of work and testing I'm documenting my working setup along with some important notes and pitfalls I've discovered. In our case the need was to allow remote vpn clients access to an office LAN using SSL certificates and Windows AD authentication.

In our setup the radius server is on the same machine as the vpn server and communicates with Active Directory via secure ldap (LDAPS)—but the configuration of the radius server and LDAPS is another story and not covered in this article.

Required Software and Services

  • Ubuntu server 22.04 LTS
  • openvpn (2.5.5)
  • libpam-radius-auth (2.0.0)

Also (setup not covered in this article):

  • freeradius (3.0.26)
  • Windows Active Directory server (Win2016)

Install Required Packages

$ sudo apt install openvpn libpam-radius-auth

The auth-pam plugin is part of the OpenVPN project and installs with the openvpn package on Ubuntu. FYI, we also experimented with openvpn-auth-radius but decided against it since it seems abandoned and has not been updated in about ten years.

libpam-radius-auth is a PAM module maintained by the Freeradius project that allows PAM-enabled linux machines to function as radius clients. It provides the PAM configuration that the OpenVPN auth-pam plugin utilizes in order to connect to a radius server.

OpenVPN Configuration

I won't cover a full OpenVPN server config (that would be another whole article)—but the relevant lines for radius authentication in the server config are:

# /etc/openvpn/server/remote-vpn.conf
...
setenv deferred_auth_pam 1
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so "openvpn login USERNAME password PASSWORD"
...

The fist line enables asynchronous execution of the plugin to allow OpenVPN to continue functioning while it processes the authentication request.

The "plugin" directive tells OpenVPN to use the auth-pam plugin with the "openvpn" pam service (which we define below), and pass it the USERNAME and PASSWORD supplied by the OpenVPN client.

In the client configs we need:

...
auth-user-pass
...

This tells the OpenVPN client to authenticate with the server using a username and password.

PAM Configuration

Create and edit the PAM openvpn service file:

$ sudo vi /etc/pam.d/openvpn

Then add:

auth     sufficient  pam_radius_auth.so
account  sufficient  pam_permit.so
session  sufficient  pam_permit.so

Edit the libpam-radius-auth config file:

$ sudo vi /etc/pam_radius_auth.conf

Reference the notes in the file to add your radius server settings in the form:

SERVER_IP SHARED_SECRET TIMEOUT

E.g. in our case (with Freeradius running on the OpenVPN server itself):

127.0.0.1 SHARED_SECRET 120

(We chose a longer timeout to accommodate transitioning to an external MFA setup in the near future.)

 

IMPORTANT CAVEAT!!! (The following is based on my inferences from extensive testing.)

This configuration file caused me (and apparently many other people) a lot of wasted time and confusion because of the following:

The 'SHARED_SECRET' in the pam_radius_auth.conf file is parsed in totality—that is, if it is quoted (which is often necessary for passwords in config files to prevent interpretation of special characters) those quotes are parsed as PART OF THE SHARED SECRET! This leads to errors when authenticating with the radius server. In the case of Freeradius the error displayed thus:

$ sudo freeradius -X
...
User-Password = "\xxx\xxx\xxx"
...
WARNING: Unprintable characters in the password. Double-check the shared secret on the server and the NAS!
...

So although the warning in this case states the problem it's not obvious why the issue is happening unless you understand that in the /etc/pam_radius_auth.conf file, "SHARED_SECRET", 'SHARED_SECRET', and SHARED_SECRET are all parsed as different shared secrets. So don't use quotes in this file!

To explain just a little further why this happens: the shared key is used to encrypt/decrypt the password between the radius client and server—so a mismatch causes the undecrypted password to be used in the authentication attempt.

Also, when using a Windows radius server (in my experience) you'll get no useful information about why authentication is failing—which adds another layer of confusion, if that's your setup.

Tags: IT, Linux, OpenSource,

Articles

Latest Articles

View by Tags

Other Views

About Us

We are a small business in Central Oregon who's mission is to help other small businesses simplify and optimize their technology resources with linux and open-source software.

Brooks, the owner of Caiyos, is self-educated and has over 20 years of experience working in the fields of IT and computer science with dozens of companies. Along with delivering professional service, he provides clear, understandable, and timely communication.