pfSense

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.

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.

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.

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/

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.

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?

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 changing reneg-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.

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 changing reneg-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.

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.

Created additional redmine for auth-gen-token to be added here: https://redmine.pfsense.org/issues/14924

Currently, in Android 15 at least, this client options is ignored and never applied
When added in server, as a custom option: reneg-sec 36000 and in client as push "reneg-sec 0", it will lead to an error reneg-sec cannot be used in this context ([push-options]) (in OpenVPN for Android app logs). In OpenVPN Connect app, it shows also an error as ignored option. The connection still gets reset after 3600 seconds.

So, definately, reneg-sec option cannot be altered on the client currently even in custom options and renegociation will occur every 3600 seconds
On server, setting it to 10 seconds shows it properly works. Just not on the client

However, using auth-gen-token 36000 as instructed in https://redmine.pfsense.org/issues/13293 does work in "OpenVPN for Android" app
It can only be added in server advanced options, and cannot be used as a push option in client, else we get an out of context error again in logs. Not sure if it is by design in OpenVPN protocol or a limitation in Android!

However, the option auth-gen-token doesn't properly apply to "OpenVPN Connect" app. At least, it cannot be tested as this official app still asks for user/pass combo when connection changes from Wifi to LTE or the opposite. Despite using the same config file as the OpenVPN for Android app, OpenVPN Connect app doesn't seem to keep the connection authentication when IP changes

Is this something that can be fixed on pfsense side ?

Also, not being able to push reneg-sec to clients, is a limitation in the Android apps ?

Phil Wardt wrote in #note-13:

Currently, in Android 15 at least, this client options is ignored and never applied
When added in server, as a custom option: reneg-sec 36000 and in client as push "reneg-sec 0", it will lead to an error reneg-sec cannot be used in this context ([push-options]) (in OpenVPN for Android app logs). In OpenVPN Connect app, it shows also an error as ignored option. The connection still gets reset after 3600 seconds.

So, definately, reneg-sec option cannot be altered on the client currently even in custom options and renegociation will occur every 3600 seconds
On server, setting it to 10 seconds shows it properly works. Just not on the client

However, using auth-gen-token 36000 as instructed in https://redmine.pfsense.org/issues/13293 does work in "OpenVPN for Android" app
It can only be added in server advanced options, and cannot be used as a push option in client, else we get an out of context error again in logs. Not sure if it is by design in OpenVPN protocol or a limitation in Android!

However, the option auth-gen-token doesn't properly apply to "OpenVPN Connect" app. At least, it cannot be tested as this official app still asks for user/pass combo when connection changes from Wifi to LTE or the opposite. Despite using the same config file as the OpenVPN for Android app, OpenVPN Connect app doesn't seem to keep the connection authentication when IP changes

Is this something that can be fixed on pfsense side ?

Also, not being able to push reneg-sec to clients, is a limitation in the Android apps ?

Using the option auth-gen-token on a server should automatically push the option to the client. There should be nothing necessary in the client config and adding anything there will produce the context error as a result.

pfSense has no control over the OpenVPN client being used and any bugs there need to be brought up with the app maintainer.

Kris Phillips wrote in #note-14:

pfSense has no control over the OpenVPN client being used and any bugs there need to be brought up with the app maintainer.

I thought that options with push "option args" are pushed to the client where as options like option args are used by the server only. That's how openvpn command line works

So what's the diff between the 2 in pfsense ?

Phil Wardt wrote in #note-15:

Kris Phillips wrote in #note-14:

pfSense has no control over the OpenVPN client being used and any bugs there need to be brought up with the app maintainer.

I thought that options with push "option args" are pushed to the client where as options like option args are used by the server only. That's how openvpn command line works

So what's the diff between the 2 in pfsense ?

Sorry that reply was confusing. What I meant to say is that pfSense has no control on whether the client RESPECTS pushed parameters. All pfSense can do is push the parameters to the client and hope they're respected. If the client is ignoring them, there is nothing it can do.