Re: [Openvpn-users] Clarification on auth-gen-token and 2FA
Hi, On Fri, Jan 27, 2017 at 12:02:21AM +0100, David Sommerseth wrote: > On 26/01/17 19:45, Gert Doering wrote: > > On Thu, Jan 26, 2017 at 07:36:32PM +0100, David Sommerseth wrote: > >> Anyhow ... quick-fix/workaround: Don't use --auth-nocache > > > > What happens if you have --auth-nocache, the server sends a token, and > > the token expires? Will the client get something back that it can > > understand as "oh, I need to ask for a new password!"? > > > > (Sorry, I know I *should* have tested this long ago... :-) ) > > The when --auth-nocache is in use, the contents of password field in > struct user_pass is wiped and later ignored, regardless if the server > sent an --auth-token or not. Uh. My question did not make sense. Trying again: What happens if you do NOT have --auth-nocache, the server sends a token, and the token expires? Will the client get something back that it can understand as "oh, I need to ask for a new password!"? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP 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
Re: [Openvpn-users] Clarification on auth-gen-token and 2FA
On 26/01/17 19:45, Gert Doering wrote: > Hi, > > On Thu, Jan 26, 2017 at 07:36:32PM +0100, David Sommerseth wrote: >> Anyhow ... quick-fix/workaround: Don't use --auth-nocache > > What happens if you have --auth-nocache, the server sends a token, and > the token expires? Will the client get something back that it can > understand as "oh, I need to ask for a new password!"? > > (Sorry, I know I *should* have tested this long ago... :-) ) The when --auth-nocache is in use, the contents of password field in struct user_pass is wiped and later ignored, regardless if the server sent an --auth-token or not. -- kind regards, David Sommerseth 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
Re: [Openvpn-users] Clarification on auth-gen-token and 2FA
Hi, On Thu, Jan 26, 2017 at 07:36:32PM +0100, David Sommerseth wrote: > Anyhow ... quick-fix/workaround: Don't use --auth-nocache What happens if you have --auth-nocache, the server sends a token, and the token expires? Will the client get something back that it can understand as "oh, I need to ask for a new password!"? (Sorry, I know I *should* have tested this long ago... :-) ) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP 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
Re: [Openvpn-users] Clarification on auth-gen-token and 2FA
On 25/01/17 21:28, Scott Crooks wrote: > Greetings everyone, > > I'm doing some testing with moving our current OpenVPN solution to 2.4 > to utilize the benefits of the `auth-gen-token` parameter that was > recently introduced. I'm a little confused about how it works in > relation to the `reneg-sec` variable. We're using the free Authy OpenVPN > plugin (https://github.com/authy/authy-openvpn) for 2FA. > > Our authentication follows the following chain: > > 1. User must present valid client certificate (duplicate-cn in our case) > 2. User must present valid Authy token from their mobile device / browser > 3. User must present valid login credentials that are validated against > our LDAP backend > > Authy's documentation specifically says to set `reneg-sec` equal to '0' > so that renegotiation never happens; however, this was written with > OpenVPN 2.3 in mind. My questions are: > > 1. Since `auth-gen-token X` generates a token valid for X seconds, does > this mean I can turn renegotiation back on? From initial testing > (OpenVPN 2.4 on Windows 10), I set `reneg-sec` to something low (30 > seconds) to see what happened. The user is again presented with a > password prompt, which shouldn't happen. Correct, this should NOT happen. > 2. Does having `auth-nocache` on the client side conflict with > `auth-gen-token` ? Do I need to remove `auth-nocache` from the client > side to utilize the benefits of `auth-gen-token` ? Yes, this is a bug I detected very late in the RC releases. I tried to fix it, but first attempts exploded in my face. And haven't had time to dig into this further. When --auth-gen-token is enabled, the server pushes --auth-token with some random credential it saves for this particular session. When the client receives --auth-token push-reply, it replaces the current password value in the user/password storage with the token value. On next re-authentication, the client will then send username + token value (instead of password with expired OTP). The server then matches this token ("password") against the locally stored token in the session object. What happens is that when --auth-nocache is used, it basically tells the "retrieve user credentials function" to ignore whatever is stored in the password field (where the token now resides) in the user/password storage. And since it realises it doesn't have a password, it asks for it again. This is very basically what happens. And the fix is in theory very simple (disable --auth-nocache if server have pushed --auth-token) - but those places I tried to disable --auth-nocache didn't work or it made things even worse in some cases (where --auth-token was not pushed). So I have it on my TODO list ... now that people actually do test the --auth-gen-token feature, I'm definitely going to look into it a bit sooner. Anyhow ... quick-fix/workaround: Don't use --auth-nocache -- kind regards, David Sommerseth 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
Re: [Openvpn-users] 2.4.0 , address on tun inteface problem after reconnect to another server, linux
26.01.2017 16:43, debbie10t пишет: > > On 26/01/17 11:55, Dmitry Melekhov wrote: >> 26.01.2017 15:31, debbie10t пишет: >>> On 26/01/17 07:10, Dmitry Melekhov wrote: 26.01.2017 10:59, Gert Doering пишет: > Hi, > > On Thu, Jan 26, 2017 at 09:54:59AM +0400, Dmitry Melekhov wrote: >> Could you tell me is this expected behavior and, if yes, is there any >> workaround , something like dhcp-release for windows? > This is a bug - on SIGUSR1 reconnect with --persist-tun, if options change > (like: "new IP address") these is wrongly ignored. > > This is trac #812, and it was already fixed - to be released as part of > 2.4.1 "soon" (in the coming weeks). > > gert Thank you! I'll try to patch and rebuild 2.4.0. >>> Curiosity got me .. >>> >>> Do you need --persist-* on your client ? >> Really, no, there is no desperate need in it in this particular case :-) >> >> On the other hand , there is no contra, at least I don't see any... > Other than the problem you are currently experiencing .. > > --persist-* is necessary if you are dropping privileges. > (I am not aware of any other reason) And? Any reasons I can't drop privileges on server which provides LAN-to-LAN link, although it acts as openvpn client? And yes, I can not use it, because it is not server, so it has less security problems. So situation is absolutely as I wrote before- no desperate need. > >>> Or is it an option added by a config generator tool ? >>> EG: Network-manager >>> >>> I would recommend reading the manual for each of the options your client >>> does use and deciding what is actually necessary. >> Thank you for hint, I run openvpn since 2005 and never thought about >> reading manual ;-) > I presume you are ribbing me ;-) You are right :-P ;-) > > OTOH, you would not be the first to march blindly into the fray ! No, you started fray by assuming I did not read man . > > It might be interesting to know the difference in hits between > the official docs and, for example, a wordpress or Pi tutorial .. Well, I don't remember which tutorial I used more then 10 years ago :-( > Regards Fortunately this was known bug and now it is fixed on my servers :-) And I see no reasons to discuss do I use or not user and group in config, AFAIR, this is information I can't share according to internal policy ;-) Thank you! -- 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
Re: [Openvpn-users] 2.4.0 , address on tun inteface problem after reconnect to another server, linux
On 26/01/17 11:55, Dmitry Melekhov wrote: > 26.01.2017 15:31, debbie10t пишет: >> >> On 26/01/17 07:10, Dmitry Melekhov wrote: >>> 26.01.2017 10:59, Gert Doering пишет: Hi, On Thu, Jan 26, 2017 at 09:54:59AM +0400, Dmitry Melekhov wrote: > Could you tell me is this expected behavior and, if yes, is there any > workaround , something like dhcp-release for windows? This is a bug - on SIGUSR1 reconnect with --persist-tun, if options change (like: "new IP address") these is wrongly ignored. This is trac #812, and it was already fixed - to be released as part of 2.4.1 "soon" (in the coming weeks). gert >>> Thank you! >>> >>> I'll try to patch and rebuild 2.4.0. >> Curiosity got me .. >> >> Do you need --persist-* on your client ? > Really, no, there is no desperate need in it in this particular case :-) > > On the other hand , there is no contra, at least I don't see any... Other than the problem you are currently experiencing .. --persist-* is necessary if you are dropping privileges. (I am not aware of any other reason) > >> >> Or is it an option added by a config generator tool ? >> EG: Network-manager >> >> I would recommend reading the manual for each of the options your client >> does use and deciding what is actually necessary. > > Thank you for hint, I run openvpn since 2005 and never thought about > reading manual ;-) I presume you are ribbing me ;-) OTOH, you would not be the first to march blindly into the fray ! It might be interesting to know the difference in hits between the official docs and, for example, a wordpress or Pi tutorial .. Regards -- 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
Re: [Openvpn-users] 2.4.0 , address on tun inteface problem after reconnect to another server, linux
26.01.2017 15:31, debbie10t пишет: > > On 26/01/17 07:10, Dmitry Melekhov wrote: >> 26.01.2017 10:59, Gert Doering пишет: >>> Hi, >>> >>> On Thu, Jan 26, 2017 at 09:54:59AM +0400, Dmitry Melekhov wrote: Could you tell me is this expected behavior and, if yes, is there any workaround , something like dhcp-release for windows? >>> This is a bug - on SIGUSR1 reconnect with --persist-tun, if options change >>> (like: "new IP address") these is wrongly ignored. >>> >>> This is trac #812, and it was already fixed - to be released as part of >>> 2.4.1 "soon" (in the coming weeks). >>> >>> gert >> Thank you! >> >> I'll try to patch and rebuild 2.4.0. > Curiosity got me .. > > Do you need --persist-* on your client ? Really, no, there is no desperate need in it in this particular case :-) On the other hand , there is no contra, at least I don't see any... > > Or is it an option added by a config generator tool ? > EG: Network-manager > > I would recommend reading the manual for each of the options your client > does use and deciding what is actually necessary. Thank you for hint, I run openvpn since 2005 and never thought about reading manual ;-) -- 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
Re: [Openvpn-users] 2.4.0 , address on tun inteface problem after reconnect to another server, linux
On 26/01/17 07:10, Dmitry Melekhov wrote: > 26.01.2017 10:59, Gert Doering пишет: >> Hi, >> >> On Thu, Jan 26, 2017 at 09:54:59AM +0400, Dmitry Melekhov wrote: >>> Could you tell me is this expected behavior and, if yes, is there any >>> workaround , something like dhcp-release for windows? >> This is a bug - on SIGUSR1 reconnect with --persist-tun, if options change >> (like: "new IP address") these is wrongly ignored. >> >> This is trac #812, and it was already fixed - to be released as part of >> 2.4.1 "soon" (in the coming weeks). >> >> gert > > Thank you! > > I'll try to patch and rebuild 2.4.0. Curiosity got me .. Do you need --persist-* on your client ? Or is it an option added by a config generator tool ? EG: Network-manager I would recommend reading the manual for each of the options your client does use and deciding what is actually necessary. -- 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