2018-02-08 1:21 GMT+05:00 Selva Nair <selva.n...@gmail.com>:
> Hi,
>
> On Wed, Feb 7, 2018 at 2:58 PM, David Sommerseth
> <open...@sf.lists.topphemmelig.net> wrote:
> > On 07/02/18 20:32, Илья Шипицин wrote:
> >> After auth-token were introduced, when user press "Reconnect", it leads
> to
> >> auth fail (saved password is forgotten), we run about 1000 users, nobody
> >> complains.
> >
> > This is actually expected, I'd say - but smells like a bug on the server
> side
> > authentication.
> >
> > 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.
>
users don't care :)
if they we ever unhappy, we should fix it.
currently, I'm open to ideas how to perform a (proper) investigation in
order to actually remove "Reconnect" button
>
> 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
> (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. Else
> what's the use of sending the token to the management interface?
> In other words if a user wants auth-token and no GUI, they should not
> use auth-nocache, GUI users should use it if they want the GUI to
> control all password requests. No need to bend over backwards to
> support auth-nocache with auth-token as we now do.
>
> 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.
>
> >> 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.
>
> Selva
>
------------------------------------------------------------------------------
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
