Thanks, Selva, On Mon, Jul 23, 2018 at 1:30 PM, Selva Nair <selva.n...@gmail.com> wrote: > > Hi, > > > On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard > <jkbull...@gmail.com> wrote: > > Hi, > > > > On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair <selva.n...@gmail.com> wrote: > >> Jon: I have a server for testing static and dynamic challenge. If > >> interested I can send you a config. Or use access server with a free > >> test license. Mine will just challenge with 1 + 1 = ? kind of > >> questions, nothing fancy. > > > > Thanks, Selva! Your testing server worked fine and I have Tunnelblick > > doing dynamic challenge/response properly now. > > > > However, dynamic C/R needs to include '--auth-retry interact' to work > > because the default is to fail fatally. From what I understand, the > > configs generated by Open Access Server don't include '--auth-retry > > interact', but apparently OpenVPN GUI for Windows forces that option > > because it can assume that it is always being used interactively. > > Tunnelblick can't assume that because it can be and is used > > non-interactively (for example. to connect to a VPN when the computer > > starts up and nobody is logged in to interact with). > > > > I can think of four ways to deal with this problem: > > > > 1. Have Tunnelblick require that the user include 'auth-retry > > interact' in the OpenVPN configuration file. > > > > 2. Have Tunnelblick guess if the configuration is interactive and, if > > it is, to include '--auth-retry interact' in the command line when > > starting OpenVPN. > > > > 3. Have Tunnelblick send 'auth-retry interact' through the management > > interface as soon as it sees a ">PASSWORD:Verification Failed: 'Auth' > > ['CRV…" message. > > > > 4. Patch OpenVPN so that the connection will be restarted instead of > > getting a fatal error if the error message starts with > > ">PASSWORD:Verification Failed: 'Auth' ['CRV", ignoring --auth-retry. > > This looks like a good suggestion. > > > > > The problem with 3 is that it may not work, or it may work only > > sometimes because of a race between OpenVPN processing the failure > > message and processing the 'auth-retry interact' from the management > > interface. > > > > One problem I see with 4 is that I don't think that OpenVPN code > > (other than in OpenVPN GUI) actually "knows" about dynamic C/R. It > > looks to me to be simply a convention between the OpenVPN GUI (and > > other GUIs) and the scripts that run on the OpenVPN server. It would > > also break a dynamic C/R setup in which 'auth-retry nointeract' was > > specified, or in which no 'auth-retry' was included, but they wouldn't > > be working setups anyway. > > Instead of forcing auth-retry interact, it would be enough to change > the handling of receive_auth_failed() in push.c -- if the "reason" > text contains "AUTH_FAILED,CRV1:" handle it as if AR_INTERACT is > in effect. The reason text is already passed to that function. > > Not doing so looks like an unintentional consequence of the kludgy > way dynamic CR is implemented. > > That way other code paths where auth-retry is used (for private key > password etc.) are not affected.
I think that's a much better idea. > > Another problem with 4 is that presumably it wouldn't appear until > > OpenVPN 2.5, which means that it Tunnelblick would require OpenVPN 2.5 > > (which is included in Tunnelblick betas) for dynamic C/R to work. > > Some, perhaps including Selva's $payingCustomer, may not want to use > > Tunnelblick betas or use OpenVPN 2.5 until it is released. > > As an interim measure, you could send auth-retry interact as soon as > tunnelblick connects to the management interface and internally enforce > "auth-retry interact" or "none" if found in the config. Just opt not to count > the CRV1 message as an auth-failure. It may be also necessary > to remember the auth-retry setting in the config and set it back while > disconnecting from management interface. (Facepalm!) That's a great idea, thanks! It will still affect private keys, but I think that's OK because Tunnelblick will cause a private key auth failure to terminate the OpenVPN process, which is much the same as having OpenVPN terminate itself. > > The good things about 4 are that it would be a pretty small patch (I > > think) and it would "automatically" fix what I consider to be an > > OpenVPN configuration error. > > > > 4 is the best solution from a narrow thinking-only-of-Tunnelblick > > perspective. Would you all consider a patch that does 4? > > Yes, I think this would be a sane and useful change. > > 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
