Hi Selva,
thank you for your reply. Please help me, how can I set a token from
management-client? Should I generate a token, store it and use ’client-auth’ +
’auth-toke $token’ + ’END’ simply? (and verify it upon REAUTH)
Thanks,
Tom
From: Selva Nair [mailto:selva.n...@gmail.com]
Sent: Thursday, April 30, 2020 8:10 PM
To: Dajka Tamás <vi...@vipernet.hu>
Cc: openvpn users list (openvpn-users@lists.sourceforge.net)
<openvpn-users@lists.sourceforge.net>
Subject: Re: [Openvpn-users] OTP + auth-token
Hi,
On Thu, Apr 30, 2020 at 11:16 AM Dajka Tamás <vi...@vipernet.hu
<mailto:vi...@vipernet.hu> > wrote:
Hi All,
I assume the issue from 2017 with auth-nocache + auth-token still exists.
However, I’ve bumped into something, which I cannot understand. Same setup with
OTP, but removed the ’auth-nocache’ from the client.conf.
I would suggest not to use auth-gen-token along with management-client-auth. It
has never been tested and in my experience auth-gen-token is just too buggy. A
number of bugs/misbehaviours have been fixed in later patches but I have lost
track of what is fixed and what remains, let alone what is yet unknown
With management client-auth you can handle REAUTH in your management client,
set a token from there, so auth-gen-token is not really necessary.
In server.conf the following is set:
reneg-sec 18000
auth-gen-token 39600
In the client.conf:
reneg-sec 18000
(auth-nocache is NOT set)
This is a TAP setup with external DHCP server (needed for client proxy setting
push). Management-client-auth is used with ’client-auth-nt’ on server side
(works ok, but I don’t see any ’REAUTH’ message in logs – I assuem this is due
to the token auth)
I’ve connected to the server at 10:30:
Thu Apr 30 10:30:43 2020 us=121829 MANAGEMENT:
>STATE:1588235443,CONNECTED,SUCCESS,,SERVER_IP,443,192.168.0.52,54937
Next messages in client log (these should be the DHCP periodic messages,
dhcp-lease-time 14400; max-lease-time 43200):
Thu Apr 30 12:30:39 2020 us=429095 Extracted DHCP router address: 10.14.12.1
Thu Apr 30 14:30:39 2020 us=62016 Extracted DHCP router address: 10.14.12.1
At 15:30 the key expired (18000s = 5 hours), data-connetion reinitiated (’TLS:
soft reset’ + ’TLS: Username/auth-token authentication succeeded for username’
in server.log ) :
Thu Apr 30 15:30:33 2020 us=405908 Outgoing Data Channel: Cipher 'AES-256-GCM'
initialized with 256 bit key
Thu Apr 30 15:30:33 2020 us=405908 Incoming Data Channel: Cipher 'AES-256-GCM'
initialized with 256 bit key
Thu Apr 30 15:30:33 2020 us=406908 Control Channel: TLSv1.2, cipher TLSv1.2
ECDHE-ECDSA-AES256-GCM-SHA384, 521 bit EC, curve: secp521r1
However, at 16:30 I got disconnected, which I did not understand (same message
in client.log and server.log):
Thu Apr 30 16:30:31 2020 us=11284 TLS: tls_process: killed expiring key
Thu Apr 30 16:30:31 2020 us=876533 Connection reset, restarting [0]
The disconnection 1 hour after reneg appears to indicate the session did not
get replaced by the newly negotiated one and the connection continued with the
old session key. I think the previous session key is only kept for 1 hour after
a reneg is triggered (this 1 hour is unrelated to reneg-sec), that would
explain why the connection dies at that point. This is just a guess, not sure
how to confirm this or why this happens.
I would first test the setup without auth-gen-token and use REAUTH to identify
when to re-authenticate the user.
Selva
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
