On 08/03/18 00:22, Selva Nair wrote: > Hi, > > ...some good stuff snipped... > >> >> I'll admit I might see this with a bit too narrow perspective. But how I >> have >> understood this issue is that OpenVPN 2.x does not behave correctly as it >> doesn't understand *why* the authentication failed. If the client side would >> understand why auth failed, then it can query the user for credentials again >> - >> which I believe should resolve the current issues ... Or have I missed >> something? > > I hope we are slowly spiralling towards a solution; not going around > in circles... > > Anyway, to reiterate: we currently have two issues. (i) client is not > told when authentication fails during reneg > and (ii) client doesn't know that auth-gen-token's token is not > reusable across reconnects > (SIGHUP and SIGUSR1).
Okay, (i) is handled with AUTH_FAILED,SESSION messages today in OpenVPN 3. OpenVPN 2 should be taught to do the same - both server and client side. In regards to (ii), that is an implementation detail which I would say is incorrect with --auth-gen-token. As I am the one who implemented that feature, I would rather have this fixed so auth-gen-token works across restarts. Another new feature I can accept, is to enable rotating the auth-tokens. This is currently not possible. Not a need-to-have feature now, but more a nice-to-have. > Fixing (i) does not fix (ii). But (ii) easier to fix although we could > keep arguing whether a forget-token-reconnect should be used or not > etc.. > (i) is the trickier, though I'm not convinced it requires so much refactoring. > > Anyway, if there is an immediate solution to (i) it may be better to > fix (ii) along with it. Else just fixing (ii) along the lines Arne has > proposed looks like the way to go. Arne's approach with forget-token and IV_PROTO=3 diverges how OpenVPN 2 and OpenVPN 3 behaves. This is *not* an option for this issue. The reason is that OpenVPN Access Server 2.5 is now shipping with an unmodified (to my knowledge, at least) upstream OpenVPN 2.4. This server integrates well with the OpenVPN Connect clients, which we have for Android, iOS, macOS and Windows (All OpenVPN 3 based). It would be sad if the community side fixes something which isn't really an issue (as part of the solution is already there); we're just doing it wrong currently. The current approach by Arne would also require support in OpenVPN 3 too; and I doubt this approach will get easily accepted there. Also beware that more and more users will start deploying OpenVPN 3 based clients too; it is already widespread on iOS. And there are efforts on getting OpenVPN Connect into even more appstores for different platforms. On top of that, in addition to the new open source openvpn3-linux client, there will also be put some efforts to at least provide more mature reference implementation clients for Windows and macOS too. Plus Arne is also poking at using OpenVPN 3 in his Android client. Many of them will definitely connect against OpenVPN 2.x based servers; so OpenVPN 2 and OpenVPN 3 need to be well aligned. (With that said, I'm not saying OpenVPN 3 supports all OpenVPN 2 features 100% today, but the most important features are there - like authentication). -- 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-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
