On 10/23/24 17:23, Gert Doering wrote:
Hi,
On Wed, Oct 23, 2024 at 04:49:03PM +0300, Razvan Cojocaru wrote:
This in turn allows the server to signal to the client that it
should no longer attempt to reconnect, if it wants to keep the
client out after an AUTH_FAILED.
This should not be necessary. After an AUTH_FAILED the token is
already invalidated on the client side.
Can you describe your use case a bit better? This code is complex
enough as it is, so I'm not really willing to add more cases to it
(which I do have to test then and forever) if not needed.
Thanks for the quick reply!
Of course! The use case pertains to the device posture checks that
OpenVPN has rolled out.
Long story short, these are meant to allow the server to make decisions
on whether the client is allowed to connect (and stay connected, which
is the part I'm addressing here) based on information about it.
For example, if it has an up-to-date antivirus, or if it has full disk
encryption enabled.
So a client may connect and be allowed in, then for some reason its
antivirus may not be updated for a considerable while, at which point a
check will want to disconnect said client. Reconnects will be possible
after whoever manages the client machine updates the antivirus.
In this case, we want to disconnect the client and it should stay
disconnected. A simple AUTH_FAILED for this scenario will have the
client attempt another connection. But if we invalidate the token, then
the client will not attempt to reconnect.
Another reason for this patch is that the OpenVPN 3 client does allow
setting the auth-token to an empty string, and when it is empty the
logic is to not reconnect - so this would allow both version 2 and
version 3 clients to behave the same way.
Thanks,
Razvan
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
