Feature #12466
openOption to Disable Renegotiation timer in OpenVPN Server
0%
Description
We should add an option to the OpenVPN server webConfigurator so that we can disable renegotiation in OpenVPN. This toggle should turn on the server option for "reneg-sec 0" and also add the option to the OpenVPN Client Export as well for the end user config.
This is useful for situations where the customer is using RADIUS or LDAP with a 2FA authentication. When OpenVPN goes to renegotiate the password has changed because the login password is usually [password][OTP] mashed together. When it goes to renegotiate after 60 minutes the client will get booted due to failure of negotiation. The customer can add this option manually to both the client and server, but it would be nice to make this more automated.
Related issues
Updated by Jim Pingle almost 3 years ago
- Tracker changed from Bug to Feature
- Subject changed from Add Option to Disable Renegotiation in OpenVPN Server for User with OTP to Option to Disable Renegotiation timer in OpenVPN Server
- Priority changed from Normal to Very Low
- Affected Architecture deleted (
All)
Updated by Viktor Gurov almost 3 years ago
openvpn(8):
--reneg-sec args Renegotiate data channel key after at most max seconds (default 3600) and at least min seconds (default is 90% of max for servers, and equal to max for clients). reneg-sec max [min] The effective --reneg-sec value used is per session pseudo-uniform-randomized between min and max. With the default value of 3600 this results in an effective per session value in the range of 3240 .. 3600 seconds for servers, or just 3600 for clients. When using dual-factor authentication, note that this default value may cause the end user to be challenged to reau‐ thorize once per hour. Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.
Updated by Kris Phillips almost 3 years ago
Viktor Gurov wrote in #note-2:
openvpn(8):
[...]
Since the option needs to be on both client and server, we probably should automatically include this in the export tool when it's enabled on the server.
Updated by Kris Phillips almost 3 years ago
Kris Phillips wrote in #note-3:
Viktor Gurov wrote in #note-2:
openvpn(8):
[...]Since the option needs to be on both client and server, we probably should automatically include this in the export tool when it's enabled on the server.
This is correct. We probably should add the option to the OpenVPN server itself and then have the setting automatically be added to the export tool.
We could have a field for "Renegotiation interval" and then have a note in the description below it and in the docs that states setting it to 0 disables this feature or have a checkbox to turn it off. Either way this should still automatically populate in the export tool.
Updated by Marcos M over 2 years ago
It's better to implement --auth-gen-token [lifetime]
--auth-gen-token [lifetime]
After successful user/password authentication, the OpenVPN server will with this option generate a temporary authentication token and push that to client. On the following renegotiations, the OpenVPN client will pass this token instead of the users password. On the server side the server will do the token authentication internally and it will NOT do any additional authentications against configured external user/password authentication mechanisms.The lifetime argument defines how long the generated token is valid. The lifetime is defined in seconds. If lifetime is not set or it is set to 0, the token will never expire.
This feature is useful for environments which is configured to use One Time Passwords (OTP) as part of the user/password authentications and that authentication mechanism does not implement any auth-token support.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
Updated by Jim Pingle over 2 years ago
Both auth-gen-token
and reneg-sec
are useful in different ways, we should expose and (optionally) use both. Though they aren't so alike they should be in the same feature request, we should make a separate feature request just for auth-gen-token
.
Updated by Marcos M over 2 years ago
I created https://redmine.pfsense.org/issues/13293 for that. Given that auth-gen-token
handles the issue with frequent reauth when using MFA, what benefit would changing reneg-sec
have?
Updated by Marcos M over 2 years ago
- Related to Feature #13293: Option to set auth-gen-token in OpenVPN GUI added
Updated by Jim Pingle over 2 years ago
Marcos Mendoza wrote in #note-7:
I created https://redmine.pfsense.org/issues/13293 for that. Given that
auth-gen-token
handles the issue with frequent reauth when using MFA, what benefit would changingreneg-sec
have?
reneg-sec
is about periodically renegotiating the data channel key, which is beneficial for security, and isn't necessarily tied to authentication. auth-gen-token
is purely about authentication. Someone may want to refresh the key more/less often but use certs only so they don't care about the auth token/MFA bits as much as how often the data channel key gets updated.
Updated by Kris Phillips over 2 years ago
Jim Pingle wrote in #note-9:
Marcos Mendoza wrote in #note-7:
I created https://redmine.pfsense.org/issues/13293 for that. Given that
auth-gen-token
handles the issue with frequent reauth when using MFA, what benefit would changingreneg-sec
have?
reneg-sec
is about periodically renegotiating the data channel key, which is beneficial for security, and isn't necessarily tied to authentication.auth-gen-token
is purely about authentication. Someone may want to refresh the key more/less often but use certs only so they don't care about the auth token/MFA bits as much as how often the data channel key gets updated.
Hello Jim,
The problem is that renegotiating the data channel key, in the default operation in pfSense, will resent username and password credentials. The auth-gen-token config flag substitutes password for a generated token that is negotiated at first auth and is used for renegotiating with the username, rather than with a password.
Having both of these options exposed would be prudent, I think, in the webConfigurator.
Updated by Jim Pingle over 2 years ago
Kris Phillips wrote in #note-10:
The problem is that renegotiating the data channel key, in the default operation in pfSense, will resent username and password credentials. The auth-gen-token config flag substitutes password for a generated token that is negotiated at first auth and is used for renegotiating with the username, rather than with a password.
Having both of these options exposed would be prudent, I think, in the webConfigurator.
That's what I already said above. See notes 6 and 9.
Updated by Kris Phillips 12 months ago
Created additional redmine for auth-gen-token to be added here: https://redmine.pfsense.org/issues/14924