Client is not properly notified with AUTH_FAILED when using auth-gen-token and reneg-sec about openvpn HOT 8 OPEN

I am trying to understand what the core problem is that you are trying to solve. The auth-token are replacing other authentication like MFA or user/password. So as long as the auth-token is valid renegotiation will work. After it is expired the renegotiation will no longer work. We also only check if the user is still allowed on these renegotiations.

If I understand your issue correctly you want the auth-token lifetime to double as session time? So the user gets kicked off after the auth-token expired?

from openvpn.

If I understand your issue correctly you want the auth-token lifetime to double as session time? So the user gets kicked off after the auth-token expired?

I suppose I am, yes. That's currently what I'm using reneg-sec for on a different server, not utilizing tokens at all. I don't want my clients permanently connected so reneg-sec is set to 24 hours, they auth once and have to reconnect every 24 hours.

After reading through the docs it seemed like using auth tokens was the proper way to limit session time, and reneg-sec is meant to rotate the data channel keys. I don't see any other way to limit "sessions" specifically.

Since I'm setting up a new server I've been testing out tokens and so I don't have to wait forever between tests I've purposefully made these lifetimes very short.
Currently they are:
auth-gen-token 300
reneg-sec 60

What I'm seeing:
Renegotiation works properly every 60 seconds until the token expiration at 300 seconds. At the 360 mark the server logs note the reauth failed because of an expired token, but the client is never notified. The client still thinks its connected at this point while the server rejects the traffic, logs indicate the TLSs keys are out of sync. At the 420 mark reauth fails again but but this time the AUTH_FAILED is sent and the client finally disconnects.

The core problem is this results in the client appearing connected but not able to actually pass traffic. The server doesn't send the client AUTH_FAILED until the second failed attempt to reauth with an expired token.

I suppose I may be misusing these settings as well so please let me know if I am.

from openvpn.

from openvpn.

OTOH, you are using 2.5.1, which is old

Yeah this is the latest version in the Debian 11 stable repo. Looks like 2.6.0-rc1 is in backports so I may try that unless there is something important between rc1 and rc2 I should consider.

Thanks for the feedback

from openvpn.

Following up. This same behavior is present in 2.5.8-bullseye0 from the openvpn.net apt repo but when using version 2.6.0-bullseye0 the client is notified immediately after the server rejects the auth token.

from openvpn.

@inclementweather there have been a lot of improvement in the TLS state machine during 2.6 development, so that 2.6 shows better behaviour is not unexpected. There some states that are kind of fine and are theoretically recoverable but in reality are not recovered so we error out in them earlier now and send the client quickly a fail message.

from openvpn.

Good to know. I'll deploy 2.6 and test with a few clients before rolling it out to a wider user base and fall back to 2.5.8 without auth-token if there are other issues. Feel free to close this ticket. Thank you for your attention on this.

from openvpn.

@schwabe shall we try to fix this in 2.5.8? I've seen the same behaviour (but not always) on token expiry / AUTH_FAILED in earlier versions - but all my servers have been running git master for a while, and those got it fixed...

OTOH we can just document this as "everything before 2.6.0 can get desynchronized on renegotiation, leading to partial outages, please upgrade"

from openvpn.