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. The problem with 1 is that it means a Windows config will not work with Tunnelblick unless the config is changed. I could add a checkbox to enable it, or to disable it, but that's a pain for users and clutters up the GUI. The problem with 2 is that if the guess is incorrect it will break existing setups and cause them to loop trying to connect instead of simply failing. I could add a checkbox to enable it, or to disable it, but that's a pain for users and clutters up the GUI. 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. 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. 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? Best regards, and thanks for all your help, Jon ------------------------------------------------------------------------------ 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
