Hi, On Thu, Apr 30, 2020 at 11:16 AM Dajka Tamás <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
