OpenVPN RADIUS password length is not constant
I've been running a production OpenVPN server on pfSense for the past year and I have recently switched to a RADIUS based architecture for authentication of users.
The maximum password length that OpenVPN (or RADIUS) seem to support when integrated together is set at 256 bits (64 hex characters). This has been working fine. However, recently we received a few complaints of the VPN failing (100% packet loss) after an hour or so. Instantly I thought this is due to the default
reneg-sec value of 3600. Upon further testing it turns out that pfSense was reporting an authentication error when the client was trying to initiate a key renegotiation for the data channel. After a lot of time and effort I tried manipulating the password lengths and it turns out that the server would only re-negotiate with passwords that are of 216 bits or less (54 hex characters). I'm not sure why this is or whether this is due to the implementation of pfSense's integration with RADIUS and OpenVPN, but I'd thought I'd make you aware of it as it may cause other users to come across the same issue.
This seems rather odd to me, I think the max password lengths for initial authentication and subsequent renegotiations should be the same.
So to sum up - steps to reproduce:
- Setup an OpenVPN remote access server using the pfSense WebGUI (I used OpenVPN version 2.4.4, AES-256-GCM, ECDHE & TLS-CRYPT).
- Use RADIUS as the authentication mechanism (mine points to an SQL server with
radcheck as the user/password table).
- Export a client certificate for the server you created and add the directive
reneg-sec 5 to speed up the testing process.
- In the radcheck table add 2 users: one with a password length of 64 hex digits (this way you can easily verify the bit length) and another with a hex password length of 54 or less. I used the VARCHAR field type.
- Connect both clients and observe the server logs on pfSense with a verbosity level of 5.
- Client 1 will initially connect successfully and then fail subsequently for each renegotiation (every 5 seconds). Client 2 will connect successfully and succeed for all subsequent renegotiations.