On 07/03/18 12:52, Arne Schwabe wrote:
>> So, failure due to token expiry that normally happens during a reneg[*]
>> will not trigger AUTH_FAILED and the client will continue trying reneg
>> until the previous TLS session expires (1 hour?). This is a
>> basic limitation of the present implementation and I do not see it
>> being addressed by the patch.
> I will look into sending AUTH_FAILED also without management-client-auth.

Just a quick response.  AUTH_FAILED can provide an explanation which the
client can pick up and act upon.  I did that in an earlier attempt, but it
required lots of refactoring as the send_control() function depends on a few
structs not being available where the token failures can be tackled.

See this mail thread for details:
   Message-Id: 1477918318-18561-1-git-send-email-dav...@openvpn.net
   Mail archive:

This approach is what James initially recommended me to do, and this approach
of providing a failure message back to the client should already be supported
in OpenVPN 3 and the OpenVPN Connect clients.  This messaging I believe is
already used by the Access Server and Private Tunnel.  OpenVPN 2 in client
mode, could in these cases catch this "message" and ask for user credentials

In regards to having the tokens survive reconnect, I agree.  But lets try to
split this challenge into a few more minor patches.

The challenge I see with starting with a new IV_PROTO=3 is that this also
requires support in the OpenVPN 3 library as well.  I believe the "expiring
auth-token" feature would be better handled with proper AUTH_FAILED signalling.

I'll have a closer look (hopefully) later today, just wanted to give this
quick feedback before its too late.

kind regards,

David Sommerseth
OpenVPN Inc

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to