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). > (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 :) > 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. >>> It looks like nobody uses that button. >>> >>> So, I asked several users, they confirmed they do not use Reconnect. >> This is no good argument for me. This is one specific setup with 1000 users. >> It would be more valuable with 50 different setups having 20 users each. >> Your >> conclusion is based on a very homogeneous environment. > > Indeed. Actually I use that button frequently. > >>> After auth-token were introduced, when user press "Reconnect", it leads to >>> auth fail (saved password is forgotten), > > That reads as if introduction of auth-token broke reconnect. It did > not. Only those users who have 2-factor turned on and use > --gen-auth-token on the server are affected. Yeah, I can see that being a bad combination. We clearly didn't consider the "restart" scenario well enough. -- kind regards, David Sommerseth OpenVPN Inc
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-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
