Hi, On Wed, Feb 7, 2018 at 3:41 PM, David Sommerseth <open...@sf.lists.topphemmelig.net> wrote: > On 07/02/18 21:21, Selva Nair wrote: >>> Selva may correct me if I'm wrong, but my understanding of it when clicking >>> "Reconnect", the local OpenVPN process which caches the auth-token is >>> stopped >>> and a new OpenVPN process is started. The client should in this case ask >>> for >>> username/password again. So in this case, the server side should treat this >>> connection as a fresh connection with no initial state. >> >> GUI's reconnect button is wired to send a SIGHUP to the client openvpn >> process. The problem is that if auth-token is in use, the client >> openvpn.exe does not forget it it when restarting the connection by >> SIGHUP or SIGUSR1 -- I think it should but it doesn't. That leads to >> an AUTH_FAILED from server. The GUI has hard time distinguishing >> between reasons for AUTH_FAILED, so it just assumes that password >> verification failed and clears the saved password and prompts for a >> new one. Obviously users are not happy. > > Ahh, thanks for the correction! > >> In my view auth-token handling in openvpn.exe is broken at multiple levels: >> >> Client process: >> (i) it should not remember the token after a reconnect is issued > > Agreed. This should trigger retrieving new user input in regards to SIGHUP at > least. Not sure yet about SIGUSR1 though. SIGHUP has a cleared semantic > though (hang-up).
IIRC, the server creates a new context on both SIGUSR1 and SIGHUP (and auth-token gets wiped). So I think the client should dump it before sending SIGUSR1 and SIGHUP. > >> (ii) it should not remember the auth-token when auth-nocache is in >> effect --- without that there is no way for the GUI to take over >> handling auth-token. In my view auth-nocache is the only way >> openvpn.exe can stand aside and let the GUI take over all password >> handling. Unless we introduce a --management-auth-token flag. > > Currently, OpenVPN will display the auth-token in the management interface > when received. So the management interface should be able to capture it and > at least know that a token has been received. But it should also have a > chance to override it. > >> Else what's the use of sending the token to the management interface? > > After a discussion with James in regards to the opposite problem with > NetworkManager. NM would actually disconnect clients on each tunnel > renegotiation, as the auth-token was not cached by the NM-openvpn plugin. > > We agreed the OpenVPN process was the owner of the token value, not the > management interface. So commit 571165360db0392f was applied. Now we at > least have a lot of more happy NM users :) I see. In that case a --management-auth-token or an extra parameter to management-auth would help. A willing GUI can then use that to indicate that it'll handle auth-token. Otherwise, openvpn should keep track of password and auth-token separately instead of using the same data structure to save it. And notify the GUI whether the failure was in auth-token or password. One way for the GUI to handle the current situation is to not take the first AUTH_FAILED seriously (i.e keep the saved password) when auth-token is in use. But I would consider that a hack. > >> Server process >> (iii) --gen-auth-token with an expiry just doesn't work -- we need to >> have a mechanism for the server to tell the client that the token has >> expired. > > Agreed. We've started looking into this. But it will require a bigger API > overhaul to get the needed structs at the proper place where we can send the > "auth-token expired" message back to the client. Those code paths involved, > both the send control channel message and the authentication functions have > quite different view to the session related structs. In the mean time we can just document that do not use token expiry. Selva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
