| Message ID | 20200814080619.2108-1-arne@rfc2549.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [Openvpn-devel] Fix client's poor man NCP fallback | expand |
Hi, I tested this patch and it does make --data-ciphers and --data-ciphers-fallback behave in their intended "fashion". Unfortunately, the commit message is grammatically incorrect and also logically misleading. The intended fashion is for --data-ciphers to recognise that the correct cipher *has* been chosen and use it accordingly. And for --data-ciphers-fallback to *not* > be used in situations other than no OCC cipher. Reported-by: Richard Bonhomme <tincanteksup@gmail.com> Tested-by: Richard Bonhomme <tincanteksup@gmail.com> On 14/08/2020 09:06, Arne Schwabe wrote: > OpenVPN 2.5 clients do not correctly do a fallback to the server server. > This commit fixes that logic and also fixes --data-ciphers-fallback to > be used in situations other than no OCC cipher. > > To reproduce the error use a client with only --data-ciphers set against > a server without NCP. > > OPTIONS ERROR: failed to negotiate cipher with server. > Add the server's cipher ('AES-256-CBC') to --data-ciphers > (currently 'AES-256-CBC') if you want to connect to this server. > > Reported by: Richard Bonhomme <tincanteksup@gmail.com> > > Signed-off-by: Arne Schwabe <arne@rfc2549.org> > --- > src/openvpn/ssl_ncp.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c > index f522b8f0..c9ab85ce 100644 > --- a/src/openvpn/ssl_ncp.c > +++ b/src/openvpn/ssl_ncp.c > @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int found) > } > /* If the server did not push a --cipher, we will switch to the > * remote cipher if it is in our ncp-ciphers list */ > - bool useremotecipher = tls_poor_mans_ncp(&c->options, > - c->c2.tls_multi->remote_ciphername); > - > + if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername)) > + { > + return true; > + } > > /* We could not figure out the peer's cipher but we have fallback > * enabled */ > - if (!useremotecipher && c->options.enable_ncp_fallback) > + if (!c->c2.tls_multi->remote_ciphername && c->options.enable_ncp_fallback) > { > return true; > } >
Hi, On 14-08-2020 10:06, Arne Schwabe wrote: > OpenVPN 2.5 clients do not correctly do a fallback to the server server. > This commit fixes that logic and also fixes --data-ciphers-fallback to > be used in situations other than no OCC cipher. > > To reproduce the error use a client with only --data-ciphers set against > a server without NCP. > > OPTIONS ERROR: failed to negotiate cipher with server. > Add the server's cipher ('AES-256-CBC') to --data-ciphers > (currently 'AES-256-CBC') if you want to connect to this server. > > Reported by: Richard Bonhomme <tincanteksup@gmail.com> > > Signed-off-by: Arne Schwabe <arne@rfc2549.org> > --- > src/openvpn/ssl_ncp.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c > index f522b8f0..c9ab85ce 100644 > --- a/src/openvpn/ssl_ncp.c > +++ b/src/openvpn/ssl_ncp.c > @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int found) > } > /* If the server did not push a --cipher, we will switch to the > * remote cipher if it is in our ncp-ciphers list */ > - bool useremotecipher = tls_poor_mans_ncp(&c->options, > - c->c2.tls_multi->remote_ciphername); > - > + if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername)) > + { > + return true; > + } > > /* We could not figure out the peer's cipher but we have fallback > * enabled */ > - if (!useremotecipher && c->options.enable_ncp_fallback) > + if (!c->c2.tls_multi->remote_ciphername && c->options.enable_ncp_fallback) > { > return true; > } > This makes sense. Given that the commit message is fixed as suggested by Richard: Acked-by: Steffan Karger <steffan@karger.me> -Steffan
This is my suggestion for the commit message: -- This commit fixes two separate issues which are closely linked. First, a 2.5 client cannot connect to a server which does not support NCP and is not using one of the default --data-ciphers (AES-*-GCM). This is because the 2.5 client does not use its configured --data-ciphers cipher. Fix a 2.5 client to use the configured --data-ciphers cipher. Second, do not allow the 2.5 client to use --data-ciphers-fallback in the above situation because that is not it's intended use. Fix -data-ciphers-fallback to only be used when there is no OCC cipher. -- I wanted to get rid of the idea of fallback in the first part of the message because it is not "falling-back" to the --data-ciphers cipher. It is actually not recognising that it is configured with the correct cipher at all. And the second part is the *only* case in which a "fallback" is required and allowed. The original message reads as if the opposite were true and using --data-ciphers-fallback can be used in any situation other than no OCC cipher. This is only a suggestion to help clarify the commit. Reword it how you see fit. On 14/08/2020 19:50, tincanteksup wrote: > Hi, > > I tested this patch and it does make --data-ciphers and > --data-ciphers-fallback behave in their intended "fashion". > > Unfortunately, the commit message is grammatically incorrect and also > logically misleading. > > The intended fashion is for --data-ciphers to recognise that the correct > cipher *has* been chosen and use it accordingly. > > And for --data-ciphers-fallback to *not* >> be used in situations other than no OCC cipher. > > > Reported-by: Richard Bonhomme <tincanteksup@gmail.com> > Tested-by: Richard Bonhomme <tincanteksup@gmail.com> > > > On 14/08/2020 09:06, Arne Schwabe wrote: >> OpenVPN 2.5 clients do not correctly do a fallback to the server server. >> This commit fixes that logic and also fixes --data-ciphers-fallback to >> be used in situations other than no OCC cipher. >> >> To reproduce the error use a client with only --data-ciphers set against >> a server without NCP. >> >> OPTIONS ERROR: failed to negotiate cipher with server. >> Add the server's cipher ('AES-256-CBC') to --data-ciphers >> (currently 'AES-256-CBC') if you want to connect to this server. >> >> Reported by: Richard Bonhomme <tincanteksup@gmail.com> >> >> Signed-off-by: Arne Schwabe <arne@rfc2549.org> >> --- >> src/openvpn/ssl_ncp.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c >> index f522b8f0..c9ab85ce 100644 >> --- a/src/openvpn/ssl_ncp.c >> +++ b/src/openvpn/ssl_ncp.c >> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const >> int found) >> } >> /* If the server did not push a --cipher, we will switch to the >> * remote cipher if it is in our ncp-ciphers list */ >> - bool useremotecipher = tls_poor_mans_ncp(&c->options, >> - >> c->c2.tls_multi->remote_ciphername); >> - >> + if(tls_poor_mans_ncp(&c->options, >> c->c2.tls_multi->remote_ciphername)) >> + { >> + return true; >> + } >> /* We could not figure out the peer's cipher but we have fallback >> * enabled */ >> - if (!useremotecipher && c->options.enable_ncp_fallback) >> + if (!c->c2.tls_multi->remote_ciphername && >> c->options.enable_ncp_fallback) >> { >> return true; >> } >>
I have not specifically tested the scenarios that this is fixing (due
to time constraints and really poor Internet $here). I totally trust
Steffan's review and Richard's testing, though, to fix the problem
observed.
I have run it through t_client tests (against git master servers
about ~1 year old) and through the t_server tests (against 2.2/2.3/
2.3-small/2.4 and roughly 4-weeks-old master clients) and these all
pass. So it's definitely not breaking anything I'm currently
testing :-)
I have worked in Richard's most recent suggestions for the commit
message and reworded it a bit more. If it does not make *any* sense
anymore, it's all my fault.
Your patch has been applied to the master and release/2.5 branch.
commit 2ab0a92442dce1d82fcb9e2b305313ef668d40bf (master)
commit a61883406f7caf39aab274979bb2d43d85804df8 (release/2.5)
Author: Arne Schwabe
Date: Fri Aug 14 10:06:19 2020 +0200
Fix client's poor man NCP fallback
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Steffan Karger <steffan@karger.me>
Message-Id: <20200814080619.2108-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20734.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
kind regards,
Gert Doering
Hi Arne,
This thread has a could days but I'm testing the version 2.5-beta2 and I'm
getting the following error:
2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher
with server. Add the server's cipher ('BF-CBC') to --data-ciphers
(currently 'BF-CBC') if you want to connect to this server.
I have added the data-ciphers and also the data-ciphers-fallback to the
client's config file and in all attempts I'm getting the same error message.
data-ciphers BF-CBC
data-ciphers-fallback BF-CBC
I know that you guys are trying to get rid of the BF-CBC but my question
is, should it still work if we set these parameters in the config file or
am I missing or doing something wrong? :-)
BR
Gava
On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe <arne@rfc2549.org> wrote:
> OpenVPN 2.5 clients do not correctly do a fallback to the server server.
> This commit fixes that logic and also fixes --data-ciphers-fallback to
> be used in situations other than no OCC cipher.
>
> To reproduce the error use a client with only --data-ciphers set against
> a server without NCP.
>
> OPTIONS ERROR: failed to negotiate cipher with server.
> Add the server's cipher ('AES-256-CBC') to --data-ciphers
> (currently 'AES-256-CBC') if you want to connect to this server.
>
> Reported by: Richard Bonhomme <tincanteksup@gmail.com>
>
> Signed-off-by: Arne Schwabe <arne@rfc2549.org>
> ---
> src/openvpn/ssl_ncp.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index f522b8f0..c9ab85ce 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int
> found)
> }
> /* If the server did not push a --cipher, we will switch to the
> * remote cipher if it is in our ncp-ciphers list */
> - bool useremotecipher = tls_poor_mans_ncp(&c->options,
> -
> c->c2.tls_multi->remote_ciphername);
> -
> + if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername))
> + {
> + return true;
> + }
>
> /* We could not figure out the peer's cipher but we have fallback
> * enabled */
> - if (!useremotecipher && c->options.enable_ncp_fallback)
> + if (!c->c2.tls_multi->remote_ciphername &&
> c->options.enable_ncp_fallback)
> {
> return true;
> }
> --
> 2.26.2
>
>
>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
<div dir="ltr">Hi Arne,<div><br></div><div>This thread has a could days but I'm testing the version 2.5-beta2 and I'm getting the following error:</div><div><br></div><div>2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'BF-CBC') if you want to connect to this server.<br></div><div><br></div><div>I have added the data-ciphers and also the data-ciphers-fallback to the client's config file and in all attempts I'm getting the same error message.</div><div><br></div><div>data-ciphers BF-CBC<br>data-ciphers-fallback BF-CBC<br></div><div><br></div><div>I know that you guys are trying to get rid of the BF-CBC but my question is, should it still work if we set these parameters in the config file or am I missing or doing something wrong? :-)</div><div><br></div><div>BR</div><div><br></div><div>Gava</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe <<a href="mailto:arne@rfc2549.org">arne@rfc2549.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OpenVPN 2.5 clients do not correctly do a fallback to the server server.<br>
This commit fixes that logic and also fixes --data-ciphers-fallback to<br>
be used in situations other than no OCC cipher.<br>
<br>
To reproduce the error use a client with only --data-ciphers set against<br>
a server without NCP.<br>
<br>
OPTIONS ERROR: failed to negotiate cipher with server.<br>
Add the server's cipher ('AES-256-CBC') to --data-ciphers<br>
(currently 'AES-256-CBC') if you want to connect to this server.<br>
<br>
Reported by: Richard Bonhomme <<a href="mailto:tincanteksup@gmail.com" target="_blank">tincanteksup@gmail.com</a>><br>
<br>
Signed-off-by: Arne Schwabe <<a href="mailto:arne@rfc2549.org" target="_blank">arne@rfc2549.org</a>><br>
---<br>
src/openvpn/ssl_ncp.c | 9 +++++----<br>
1 file changed, 5 insertions(+), 4 deletions(-)<br>
<br>
diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c<br>
index f522b8f0..c9ab85ce 100644<br>
--- a/src/openvpn/ssl_ncp.c<br>
+++ b/src/openvpn/ssl_ncp.c<br>
@@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int found)<br>
}<br>
/* If the server did not push a --cipher, we will switch to the<br>
* remote cipher if it is in our ncp-ciphers list */<br>
- bool useremotecipher = tls_poor_mans_ncp(&c->options,<br>
- c->c2.tls_multi->remote_ciphername);<br>
-<br>
+ if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername))<br>
+ {<br>
+ return true;<br>
+ }<br>
<br>
/* We could not figure out the peer's cipher but we have fallback<br>
* enabled */<br>
- if (!useremotecipher && c->options.enable_ncp_fallback)<br>
+ if (!c->c2.tls_multi->remote_ciphername && c->options.enable_ncp_fallback)<br>
{<br>
return true;<br>
}<br>
-- <br>
2.26.2<br>
<br>
<br>
<br>
_______________________________________________<br>
Openvpn-devel mailing list<br>
<a href="mailto:Openvpn-devel@lists.sourceforge.net" target="_blank">Openvpn-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/openvpn-devel</a><br>
</blockquote></div>
Hi, sorry to interrupt, Rafael could you please confirm if you find this document to be correct/incorrect for your use case: https://community.openvpn.net/openvpn/wiki/CipherNegotiation Also note, this patch has been merged so make sure your binary has been compiled with it. On 29/08/2020 20:19, Rafael Gava wrote: > Hi Arne, > > This thread has a could days but I'm testing the version 2.5-beta2 and I'm > getting the following error: > > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher > with server. Add the server's cipher ('BF-CBC') to --data-ciphers > (currently 'BF-CBC') if you want to connect to this server. > > I have added the data-ciphers and also the data-ciphers-fallback to the > client's config file and in all attempts I'm getting the same error message. > > data-ciphers BF-CBC > data-ciphers-fallback BF-CBC > > I know that you guys are trying to get rid of the BF-CBC but my question > is, should it still work if we set these parameters in the config file or > am I missing or doing something wrong? :-) > > BR > > Gava > > > > > On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe <arne@rfc2549.org> wrote: > >> OpenVPN 2.5 clients do not correctly do a fallback to the server server. >> This commit fixes that logic and also fixes --data-ciphers-fallback to >> be used in situations other than no OCC cipher. >> >> To reproduce the error use a client with only --data-ciphers set against >> a server without NCP. >> >> OPTIONS ERROR: failed to negotiate cipher with server. >> Add the server's cipher ('AES-256-CBC') to --data-ciphers >> (currently 'AES-256-CBC') if you want to connect to this server. >> >> Reported by: Richard Bonhomme <tincanteksup@gmail.com> >> >> Signed-off-by: Arne Schwabe <arne@rfc2549.org> >> --- >> src/openvpn/ssl_ncp.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c >> index f522b8f0..c9ab85ce 100644 >> --- a/src/openvpn/ssl_ncp.c >> +++ b/src/openvpn/ssl_ncp.c >> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int >> found) >> } >> /* If the server did not push a --cipher, we will switch to the >> * remote cipher if it is in our ncp-ciphers list */ >> - bool useremotecipher = tls_poor_mans_ncp(&c->options, >> - >> c->c2.tls_multi->remote_ciphername); >> - >> + if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername)) >> + { >> + return true; >> + } >> >> /* We could not figure out the peer's cipher but we have fallback >> * enabled */ >> - if (!useremotecipher && c->options.enable_ncp_fallback) >> + if (!c->c2.tls_multi->remote_ciphername && >> c->options.enable_ncp_fallback) >> { >> return true; >> } >> -- >> 2.26.2 >> >> >> >> _______________________________________________ >> Openvpn-devel mailing list >> Openvpn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> > > > > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
Hi, On Sat, Aug 29, 2020 at 04:19:07PM -0300, Rafael Gava wrote: > This thread has a could days but I'm testing the version 2.5-beta2 and I'm > getting the following error: > > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher > with server. Add the server's cipher ('BF-CBC') to --data-ciphers > (currently 'BF-CBC') if you want to connect to this server. Which combination of client/server is this exactly? 2.5-beta2 on the client, what is on the server? Can we have some more log file, including the "PUSH_REPLY", please? And, if this is on windows, please make sure it's really "beta2" - the installer will not replace openvpn.exe when going from beta1 to beta2, so you might run an 2.5_beta1 openvpn.exe. [..] > I know that you guys are trying to get rid of the BF-CBC but my question > is, should it still work if we set these parameters in the config file or > am I missing or doing something wrong? :-) It definitely should work. It does work for my test bed, but I am not testing "2.5 client against 'some old server'" yet - only the other way round, 2.2/2.3/2.4/2.5 client against 2.5 server. It needs "data-ciphers BF-CBC" (or "cipher BF-CBC") to be added to the config for non-NCP combinations, but afterwards it works. gert
Hi Gert, Actually, I was testing Samuli's 2.5-beta2 installer from the link below: Note sure if it's with the patch for data-ciphers but I guess so. I'll pull the 2.5-beta2 code and build it in order to check if it's working properly. https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi Moreover, please see the comments inline... Please let me know if you need anything else. BR Gava On Sat, Aug 29, 2020 at 4:47 PM Gert Doering <gert@greenie.muc.de> wrote: > Hi, > > On Sat, Aug 29, 2020 at 04:19:07PM -0300, Rafael Gava wrote: > > This thread has a could days but I'm testing the version 2.5-beta2 and > I'm > > getting the following error: > > > > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher > > with server. Add the server's cipher ('BF-CBC') to --data-ciphers > > (currently 'BF-CBC') if you want to connect to this server. > > Which combination of client/server is this exactly? 2.5-beta2 on > the client, what is on the server? Can we have some more log file, > including the "PUSH_REPLY", please? > > The server version is 2.3.18. The client: 2020-08-29 16:02:50 us=235805 OpenVPN 2.5_beta2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 27 2020 2020-08-29 16:02:50 us=235805 Windows version 10.0 (Windows 10 or greater) 64bit 2020-08-29 16:02:50 us=235805 library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.10 And, if this is on windows, please make sure it's really "beta2" - the > installer will not replace openvpn.exe when going from beta1 to beta2, > so you might run an 2.5_beta1 openvpn.exe. > > [..] > > I know that you guys are trying to get rid of the BF-CBC but my question > > is, should it still work if we set these parameters in the config file or > > am I missing or doing something wrong? :-) > > It definitely should work. > > It does work for my test bed, but I am not testing "2.5 client against > 'some old server'" yet - only the other way round, 2.2/2.3/2.4/2.5 client > against 2.5 server. It needs "data-ciphers BF-CBC" (or "cipher BF-CBC") > to be added to the config for non-NCP combinations, but afterwards > it works. > > I falled back to the 2.5-beta1 using the same configuration and it worked. Attached are both logs and the client config. > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > gert@greenie.muc.de > <div dir="ltr"><div dir="ltr">Hi Gert,<div><br></div><div>Actually, I was testing Samuli's 2.5-beta2 installer from the link below: Note sure if it's with the patch for data-ciphers but I guess so. </div><div>I'll pull the 2.5-beta2 code and build it in order to check if it's working properly.</div><div><br></div><div><a href="https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi" rel="noreferrer" target="_blank">https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi</a> <br></div><div><br></div><div>Moreover, please see the comments inline...</div></div><div><br></div>Please let me know if you need anything else.<div><br></div><div>BR</div><div><br></div><div>Gava</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 29, 2020 at 4:47 PM Gert Doering <<a href="mailto:gert@greenie.muc.de">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Sat, Aug 29, 2020 at 04:19:07PM -0300, Rafael Gava wrote:<br> > This thread has a could days but I'm testing the version 2.5-beta2 and I'm<br> > getting the following error:<br> > <br> > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher<br> > with server. Add the server's cipher ('BF-CBC') to --data-ciphers<br> > (currently 'BF-CBC') if you want to connect to this server.<br> <br> Which combination of client/server is this exactly? 2.5-beta2 on<br> the client, what is on the server? Can we have some more log file,<br> including the "PUSH_REPLY", please?<br> <br></blockquote><div><br></div><div>The server version is 2.3.18.</div><div>The client: </div><div class="gmail_quote"><br></div>2020-08-29 16:02:50 us=235805 OpenVPN 2.5_beta2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 27 2020<br>2020-08-29 16:02:50 us=235805 Windows version 10.0 (Windows 10 or greater) 64bit<br>2020-08-29 16:02:50 us=235805 library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.10<br><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> And, if this is on windows, please make sure it's really "beta2" - the<br> installer will not replace openvpn.exe when going from beta1 to beta2,<br> so you might run an 2.5_beta1 openvpn.exe.<br> <br> [..]<br> > I know that you guys are trying to get rid of the BF-CBC but my question<br> > is, should it still work if we set these parameters in the config file or<br> > am I missing or doing something wrong? :-)<br> <br> It definitely should work.<br> <br> It does work for my test bed, but I am not testing "2.5 client against<br> 'some old server'" yet - only the other way round, 2.2/2.3/2.4/2.5 client<br> against 2.5 server. It needs "data-ciphers BF-CBC" (or "cipher BF-CBC")<br> to be added to the config for non-NCP combinations, but afterwards <br> it works.<br> <br></blockquote><div><br></div><div>I falled back to the 2.5-beta1 using the same configuration and it worked. Attached are both logs and the client config.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> gert<br> -- <br> "If was one thing all people took for granted, was conviction that if you <br> feed honest figures into a computer, honest figures come out. Never doubted <br> it myself till I met a computer with a sense of humor."<br> Robert A. Heinlein, The Moon is a Harsh Mistress<br> <br> Gert Doering - Munich, Germany <a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a><br> </blockquote></div></div></div> 2020-08-29 16:02:50 us=235805 WARNING: Ignoring option 'dh' in tls-client mode, please only include this in your server configuration 2020-08-29 16:02:50 us=235805 Current Parameter Settings: 2020-08-29 16:02:50 us=235805 config = 'Test.ovpn' 2020-08-29 16:02:50 us=235805 mode = 0 2020-08-29 16:02:50 us=235805 show_ciphers = DISABLED 2020-08-29 16:02:50 us=235805 show_digests = DISABLED 2020-08-29 16:02:50 us=235805 show_engines = DISABLED 2020-08-29 16:02:50 us=235805 genkey = DISABLED 2020-08-29 16:02:50 us=235805 genkey_filename = '[UNDEF]' 2020-08-29 16:02:50 us=235805 key_pass_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 show_tls_ciphers = DISABLED 2020-08-29 16:02:50 us=235805 connect_retry_max = 0 2020-08-29 16:02:50 us=235805 Connection profiles [0]: 2020-08-29 16:02:50 us=235805 proto = tcp-client 2020-08-29 16:02:50 us=235805 local = '[UNDEF]' 2020-08-29 16:02:50 us=235805 local_port = '[UNDEF]' 2020-08-29 16:02:50 us=235805 remote = '192.168.1.1' 2020-08-29 16:02:50 us=235805 remote_port = '443' 2020-08-29 16:02:50 us=235805 remote_float = DISABLED 2020-08-29 16:02:50 us=235805 bind_defined = DISABLED 2020-08-29 16:02:50 us=235805 bind_local = DISABLED 2020-08-29 16:02:50 us=235805 bind_ipv6_only = DISABLED 2020-08-29 16:02:50 us=235805 connect_retry_seconds = 5 2020-08-29 16:02:50 us=235805 connect_timeout = 120 2020-08-29 16:02:50 us=235805 socks_proxy_server = '[UNDEF]' 2020-08-29 16:02:50 us=235805 socks_proxy_port = '[UNDEF]' 2020-08-29 16:02:50 us=235805 tun_mtu = 1500 2020-08-29 16:02:50 us=235805 tun_mtu_defined = ENABLED 2020-08-29 16:02:50 us=235805 link_mtu = 1500 2020-08-29 16:02:50 us=235805 link_mtu_defined = DISABLED 2020-08-29 16:02:50 us=235805 tun_mtu_extra = 0 2020-08-29 16:02:50 us=235805 tun_mtu_extra_defined = DISABLED 2020-08-29 16:02:50 us=235805 mtu_discover_type = -1 2020-08-29 16:02:50 us=235805 fragment = 0 2020-08-29 16:02:50 us=235805 mssfix = 1450 2020-08-29 16:02:50 us=235805 explicit_exit_notification = 0 2020-08-29 16:02:50 us=235805 tls_auth_file = '[INLINE]' 2020-08-29 16:02:50 us=235805 key_direction = 1 2020-08-29 16:02:50 us=235805 tls_crypt_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 tls_crypt_v2_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 Connection profiles END 2020-08-29 16:02:50 us=235805 remote_random = DISABLED 2020-08-29 16:02:50 us=235805 ipchange = '[UNDEF]' 2020-08-29 16:02:50 us=235805 dev = 'tun' 2020-08-29 16:02:50 us=235805 dev_type = '[UNDEF]' 2020-08-29 16:02:50 us=235805 dev_node = '[UNDEF]' 2020-08-29 16:02:50 us=235805 lladdr = '[UNDEF]' 2020-08-29 16:02:50 us=235805 topology = 1 2020-08-29 16:02:50 us=235805 ifconfig_local = '[UNDEF]' 2020-08-29 16:02:50 us=235805 ifconfig_remote_netmask = '[UNDEF]' 2020-08-29 16:02:50 us=235805 ifconfig_noexec = DISABLED 2020-08-29 16:02:50 us=235805 ifconfig_nowarn = DISABLED 2020-08-29 16:02:50 us=235805 ifconfig_ipv6_local = '[UNDEF]' 2020-08-29 16:02:50 us=235805 ifconfig_ipv6_netbits = 0 2020-08-29 16:02:50 us=235805 ifconfig_ipv6_remote = '[UNDEF]' 2020-08-29 16:02:50 us=235805 shaper = 0 2020-08-29 16:02:50 us=235805 mtu_test = 0 2020-08-29 16:02:50 us=235805 mlock = DISABLED 2020-08-29 16:02:50 us=235805 keepalive_ping = 30 2020-08-29 16:02:50 us=235805 keepalive_timeout = 120 2020-08-29 16:02:50 us=235805 inactivity_timeout = 0 2020-08-29 16:02:50 us=235805 ping_send_timeout = 30 2020-08-29 16:02:50 us=235805 ping_rec_timeout = 120 2020-08-29 16:02:50 us=235805 ping_rec_timeout_action = 2 2020-08-29 16:02:50 us=235805 ping_timer_remote = DISABLED 2020-08-29 16:02:50 us=235805 remap_sigusr1 = 15 2020-08-29 16:02:50 us=235805 persist_tun = ENABLED 2020-08-29 16:02:50 us=235805 persist_local_ip = DISABLED 2020-08-29 16:02:50 us=235805 persist_remote_ip = DISABLED 2020-08-29 16:02:50 us=235805 persist_key = ENABLED 2020-08-29 16:02:50 us=235805 passtos = DISABLED 2020-08-29 16:02:50 us=235805 resolve_retry_seconds = 1000000000 2020-08-29 16:02:50 us=235805 resolve_in_advance = DISABLED 2020-08-29 16:02:50 us=235805 username = '[UNDEF]' 2020-08-29 16:02:50 us=235805 groupname = '[UNDEF]' 2020-08-29 16:02:50 us=235805 chroot_dir = '[UNDEF]' 2020-08-29 16:02:50 us=235805 cd_dir = '[UNDEF]' 2020-08-29 16:02:50 us=235805 writepid = '[UNDEF]' 2020-08-29 16:02:50 us=235805 up_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 down_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 down_pre = DISABLED 2020-08-29 16:02:50 us=235805 up_restart = DISABLED 2020-08-29 16:02:50 us=235805 up_delay = DISABLED 2020-08-29 16:02:50 us=235805 daemon = DISABLED 2020-08-29 16:02:50 us=235805 inetd = 0 2020-08-29 16:02:50 us=235805 log = ENABLED 2020-08-29 16:02:50 us=235805 suppress_timestamps = DISABLED 2020-08-29 16:02:50 us=235805 machine_readable_output = DISABLED 2020-08-29 16:02:50 us=235805 nice = 0 2020-08-29 16:02:50 us=235805 verbosity = 4 2020-08-29 16:02:50 us=235805 mute = 0 2020-08-29 16:02:50 us=235805 gremlin = 0 2020-08-29 16:02:50 us=235805 status_file = 'openvpn-status.log' 2020-08-29 16:02:50 us=235805 status_file_version = 1 2020-08-29 16:02:50 us=235805 status_file_update_freq = 60 2020-08-29 16:02:50 us=235805 occ = ENABLED 2020-08-29 16:02:50 us=235805 rcvbuf = 0 2020-08-29 16:02:50 us=235805 sndbuf = 0 2020-08-29 16:02:50 us=235805 sockflags = 0 2020-08-29 16:02:50 us=235805 fast_io = DISABLED 2020-08-29 16:02:50 us=235805 comp.alg = 1 2020-08-29 16:02:50 us=235805 comp.flags = 0 2020-08-29 16:02:50 us=235805 route_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 route_default_gateway = '[UNDEF]' 2020-08-29 16:02:50 us=235805 route_default_metric = 0 2020-08-29 16:02:50 us=235805 route_noexec = DISABLED 2020-08-29 16:02:50 us=235805 route_delay = 2 2020-08-29 16:02:50 us=235805 route_delay_window = 30 2020-08-29 16:02:50 us=235805 route_delay_defined = ENABLED 2020-08-29 16:02:50 us=235805 route_nopull = DISABLED 2020-08-29 16:02:50 us=235805 route_gateway_via_dhcp = DISABLED 2020-08-29 16:02:50 us=235805 allow_pull_fqdn = DISABLED 2020-08-29 16:02:50 us=235805 Pull filters: 2020-08-29 16:02:50 us=235805 ignore "route-method" 2020-08-29 16:02:50 us=235805 management_addr = '127.0.0.1' 2020-08-29 16:02:50 us=235805 management_port = '25340' 2020-08-29 16:02:50 us=235805 management_user_pass = 'stdin' 2020-08-29 16:02:50 us=235805 management_log_history_cache = 250 2020-08-29 16:02:50 us=235805 management_echo_buffer_size = 100 2020-08-29 16:02:50 us=235805 management_write_peer_info_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 management_client_user = '[UNDEF]' 2020-08-29 16:02:50 us=235805 management_client_group = '[UNDEF]' 2020-08-29 16:02:50 us=235805 management_flags = 6 2020-08-29 16:02:50 us=235805 shared_secret_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 key_direction = 1 2020-08-29 16:02:50 us=235805 ciphername = 'BF-CBC' 2020-08-29 16:02:50 us=235805 ncp_enabled = ENABLED 2020-08-29 16:02:50 us=235805 ncp_ciphers = 'BF-CBC' 2020-08-29 16:02:50 us=235805 authname = 'SHA1' 2020-08-29 16:02:50 us=235805 prng_hash = 'SHA1' 2020-08-29 16:02:50 us=235805 prng_nonce_secret_len = 16 2020-08-29 16:02:50 us=235805 keysize = 0 2020-08-29 16:02:50 us=235805 engine = DISABLED 2020-08-29 16:02:50 us=235805 replay = ENABLED 2020-08-29 16:02:50 us=235805 mute_replay_warnings = DISABLED 2020-08-29 16:02:50 us=235805 replay_window = 64 2020-08-29 16:02:50 us=235805 replay_time = 15 2020-08-29 16:02:50 us=235805 packet_id_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 test_crypto = DISABLED 2020-08-29 16:02:50 us=235805 tls_server = DISABLED 2020-08-29 16:02:50 us=235805 tls_client = ENABLED 2020-08-29 16:02:50 us=235805 ca_file = '[INLINE]' 2020-08-29 16:02:50 us=235805 ca_path = '[UNDEF]' 2020-08-29 16:02:50 us=235805 dh_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 cert_file = '[INLINE]' 2020-08-29 16:02:50 us=235805 extra_certs_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 priv_key_file = '[INLINE]' 2020-08-29 16:02:50 us=235805 pkcs12_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 cryptoapi_cert = '[UNDEF]' 2020-08-29 16:02:50 us=235805 cipher_list = '[UNDEF]' 2020-08-29 16:02:50 us=235805 cipher_list_tls13 = '[UNDEF]' 2020-08-29 16:02:50 us=235805 tls_cert_profile = '[UNDEF]' 2020-08-29 16:02:50 us=235805 tls_verify = '[UNDEF]' 2020-08-29 16:02:50 us=235805 tls_export_cert = '[UNDEF]' 2020-08-29 16:02:50 us=235805 verify_x509_type = 0 2020-08-29 16:02:50 us=235805 verify_x509_name = '[UNDEF]' 2020-08-29 16:02:50 us=235805 crl_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 ns_cert_type = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 65535 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_ku[i] = 0 2020-08-29 16:02:50 us=235805 remote_cert_eku = 'TLS Web Server Authentication' 2020-08-29 16:02:50 us=235805 ssl_flags = 192 2020-08-29 16:02:50 us=235805 tls_timeout = 2 2020-08-29 16:02:50 us=235805 renegotiate_bytes = -1 2020-08-29 16:02:50 us=235805 renegotiate_packets = 0 2020-08-29 16:02:50 us=235805 renegotiate_seconds = 3600 2020-08-29 16:02:50 us=235805 handshake_window = 60 2020-08-29 16:02:50 us=235805 transition_window = 3600 2020-08-29 16:02:50 us=235805 single_session = DISABLED 2020-08-29 16:02:50 us=235805 push_peer_info = DISABLED 2020-08-29 16:02:50 us=235805 tls_exit = DISABLED 2020-08-29 16:02:50 us=235805 tls_crypt_v2_metadata = '[UNDEF]' 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_protected_authentication = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_private_mode = 00000000 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_cert_private = DISABLED 2020-08-29 16:02:50 us=235805 pkcs11_pin_cache_period = -1 2020-08-29 16:02:50 us=235805 pkcs11_id = '[UNDEF]' 2020-08-29 16:02:50 us=235805 pkcs11_id_management = DISABLED 2020-08-29 16:02:50 us=235805 server_network = 0.0.0.0 2020-08-29 16:02:50 us=235805 server_netmask = 0.0.0.0 2020-08-29 16:02:50 us=235805 server_network_ipv6 = :: 2020-08-29 16:02:50 us=235805 server_netbits_ipv6 = 0 2020-08-29 16:02:50 us=235805 server_bridge_ip = 0.0.0.0 2020-08-29 16:02:50 us=235805 server_bridge_netmask = 0.0.0.0 2020-08-29 16:02:50 us=235805 server_bridge_pool_start = 0.0.0.0 2020-08-29 16:02:50 us=235805 server_bridge_pool_end = 0.0.0.0 2020-08-29 16:02:50 us=235805 ifconfig_pool_defined = DISABLED 2020-08-29 16:02:50 us=235805 ifconfig_pool_start = 0.0.0.0 2020-08-29 16:02:50 us=235805 ifconfig_pool_end = 0.0.0.0 2020-08-29 16:02:50 us=235805 ifconfig_pool_netmask = 0.0.0.0 2020-08-29 16:02:50 us=235805 ifconfig_pool_persist_filename = '[UNDEF]' 2020-08-29 16:02:50 us=235805 ifconfig_pool_persist_refresh_freq = 600 2020-08-29 16:02:50 us=235805 ifconfig_ipv6_pool_defined = DISABLED 2020-08-29 16:02:50 us=235805 ifconfig_ipv6_pool_base = :: 2020-08-29 16:02:50 us=235805 ifconfig_ipv6_pool_netbits = 0 2020-08-29 16:02:50 us=235805 n_bcast_buf = 256 2020-08-29 16:02:50 us=235805 tcp_queue_limit = 64 2020-08-29 16:02:50 us=235805 real_hash_size = 256 2020-08-29 16:02:50 us=235805 virtual_hash_size = 256 2020-08-29 16:02:50 us=235805 client_connect_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 learn_address_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 client_disconnect_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 client_config_dir = '[UNDEF]' 2020-08-29 16:02:50 us=235805 ccd_exclusive = DISABLED 2020-08-29 16:02:50 us=235805 tmp_dir = 'C:\Users\User\AppData\Local\Temp\' 2020-08-29 16:02:50 us=235805 push_ifconfig_defined = DISABLED 2020-08-29 16:02:50 us=235805 push_ifconfig_local = 0.0.0.0 2020-08-29 16:02:50 us=235805 push_ifconfig_remote_netmask = 0.0.0.0 2020-08-29 16:02:50 us=235805 push_ifconfig_ipv6_defined = DISABLED 2020-08-29 16:02:50 us=235805 push_ifconfig_ipv6_local = ::/0 2020-08-29 16:02:50 us=235805 push_ifconfig_ipv6_remote = :: 2020-08-29 16:02:50 us=235805 enable_c2c = DISABLED 2020-08-29 16:02:50 us=235805 duplicate_cn = DISABLED 2020-08-29 16:02:50 us=235805 cf_max = 0 2020-08-29 16:02:50 us=235805 cf_per = 0 2020-08-29 16:02:50 us=235805 max_clients = 1024 2020-08-29 16:02:50 us=235805 max_routes_per_client = 256 2020-08-29 16:02:50 us=235805 auth_user_pass_verify_script = '[UNDEF]' 2020-08-29 16:02:50 us=235805 auth_user_pass_verify_script_via_file = DISABLED 2020-08-29 16:02:50 us=235805 auth_token_generate = DISABLED 2020-08-29 16:02:50 us=235805 auth_token_lifetime = 0 2020-08-29 16:02:50 us=235805 auth_token_secret_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 vlan_tagging = DISABLED 2020-08-29 16:02:50 us=235805 vlan_accept = all 2020-08-29 16:02:50 us=235805 vlan_pvid = 1 2020-08-29 16:02:50 us=235805 client = ENABLED 2020-08-29 16:02:50 us=235805 pull = ENABLED 2020-08-29 16:02:50 us=235805 auth_user_pass_file = '[UNDEF]' 2020-08-29 16:02:50 us=235805 show_net_up = DISABLED 2020-08-29 16:02:50 us=235805 route_method = 3 2020-08-29 16:02:50 us=235805 block_outside_dns = DISABLED 2020-08-29 16:02:50 us=235805 ip_win32_defined = DISABLED 2020-08-29 16:02:50 us=235805 ip_win32_type = 1 2020-08-29 16:02:50 us=235805 dhcp_masq_offset = 0 2020-08-29 16:02:50 us=235805 dhcp_lease_time = 31536000 2020-08-29 16:02:50 us=235805 tap_sleep = 0 2020-08-29 16:02:50 us=235805 dhcp_options = DISABLED 2020-08-29 16:02:50 us=235805 dhcp_renew = DISABLED 2020-08-29 16:02:50 us=235805 dhcp_pre_release = DISABLED 2020-08-29 16:02:50 us=235805 domain = '[UNDEF]' 2020-08-29 16:02:50 us=235805 netbios_scope = '[UNDEF]' 2020-08-29 16:02:50 us=235805 netbios_node_type = 0 2020-08-29 16:02:50 us=235805 disable_nbt = DISABLED 2020-08-29 16:02:50 us=235805 OpenVPN 2.5_beta2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 27 2020 2020-08-29 16:02:50 us=235805 Windows version 10.0 (Windows 10 or greater) 64bit 2020-08-29 16:02:50 us=235805 library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.10 Enter Management Password: 2020-08-29 16:02:50 us=235805 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 2020-08-29 16:02:50 us=235805 Need hold release from management interface, waiting... 2020-08-29 16:02:50 us=516926 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 2020-08-29 16:02:50 us=624763 MANAGEMENT: CMD 'state on' 2020-08-29 16:02:50 us=624763 MANAGEMENT: CMD 'log all on' 2020-08-29 16:02:50 us=848766 MANAGEMENT: CMD 'echo all on' 2020-08-29 16:02:50 us=850226 MANAGEMENT: CMD 'bytecount 5' 2020-08-29 16:02:50 us=852207 MANAGEMENT: CMD 'hold off' 2020-08-29 16:02:50 us=857100 MANAGEMENT: CMD 'hold release' 2020-08-29 16:02:50 us=858056 Note: cannot open openvpn-status.log for WRITE 2020-08-29 16:02:50 us=862941 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6. 2020-08-29 16:02:50 us=862941 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2020-08-29 16:02:50 us=862941 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2020-08-29 16:02:50 us=862941 Control Channel MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ] 2020-08-29 16:02:50 us=862941 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ] 2020-08-29 16:02:50 us=862941 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' 2020-08-29 16:02:50 us=862941 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server' 2020-08-29 16:02:50 us=862941 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.1:443 2020-08-29 16:02:50 us=862941 Socket Buffers: R=[65536->65536] S=[65536->65536] 2020-08-29 16:02:50 us=862941 Attempting to establish TCP connection with [AF_INET]192.168.1.1:443 [nonblock] 2020-08-29 16:02:50 us=862941 MANAGEMENT: >STATE:1598727770,TCP_CONNECT,,,,,, 2020-08-29 16:02:51 us=924292 TCP connection established with [AF_INET]192.168.1.1:443 2020-08-29 16:02:51 us=924292 TCP_CLIENT link local: (not bound) 2020-08-29 16:02:51 us=924292 TCP_CLIENT link remote: [AF_INET]192.168.1.1:443 2020-08-29 16:02:51 us=924292 MANAGEMENT: >STATE:1598727771,WAIT,,,,,, 2020-08-29 16:02:51 us=939917 MANAGEMENT: >STATE:1598727771,AUTH,,,,,, 2020-08-29 16:02:51 us=939917 TLS: Initial packet from [AF_INET]192.168.1.1:443, sid=6429bf1d ea612b1e 2020-08-29 16:02:52 us=112198 VERIFY OK: depth=1, Removed 2020-08-29 16:02:52 us=112198 VERIFY KU OK 2020-08-29 16:02:52 us=112198 Validating certificate extended key usage 2020-08-29 16:02:52 us=112198 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2020-08-29 16:02:52 us=127317 VERIFY EKU OK 2020-08-29 16:02:52 us=127317 VERIFY OK: depth=0, Removed 2020-08-29 16:02:52 us=315262 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 2020-08-29 16:02:52 us=315262 [VenturusTMBconc] Peer Connection Initiated with [AF_INET]192.168.1.1:443 2020-08-29 16:02:53 us=627436 MANAGEMENT: >STATE:1598727773,GET_CONFIG,,,,,, 2020-08-29 16:02:53 us=627436 SENT CONTROL [VenturusTMBconc]: 'PUSH_REQUEST' (status=1) 2020-08-29 16:02:53 us=643016 PUSH: Received control message: 'PUSH_REPLY,route 194.145.17.0 255.255.255.0,route-gateway 20.20.0.1,topology subnet,ping 90,ping-restart 600,socket-flags TCP_NODELAY,ifconfig 20.20.0.2 255.255.0.0' 2020-08-29 16:02:53 us=643016 OPTIONS IMPORT: timers and/or timeouts modified 2020-08-29 16:02:53 us=643016 OPTIONS IMPORT: --socket-flags option modified 2020-08-29 16:02:53 us=643016 Socket flags: TCP_NODELAY=1 succeeded 2020-08-29 16:02:53 us=643016 OPTIONS IMPORT: --ifconfig/up options modified 2020-08-29 16:02:53 us=643016 OPTIONS IMPORT: route options modified 2020-08-29 16:02:53 us=643016 OPTIONS IMPORT: route-related options modified 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'BF-CBC') if you want to connect to this server. 2020-08-29 16:02:53 us=659181 ERROR: Failed to apply push options 2020-08-29 16:02:53 us=659181 Failed to open tun/tap interface 2020-08-29 16:02:53 us=659181 TCP/UDP: Closing socket 2020-08-29 16:02:53 us=659181 SIGTERM[soft,process-push-msg-failed] received, process exiting 2020-08-29 16:02:53 us=659181 MANAGEMENT: >STATE:1598727773,EXITING,process-push-msg-failed,,,,, 2020-08-29 21:08:10 us=91399 WARNING: Ignoring option 'dh' in tls-client mode, please only include this in your server configuration 2020-08-29 21:08:10 us=91399 Current Parameter Settings: 2020-08-29 21:08:10 us=91399 config = 'Test.ovpn' 2020-08-29 21:08:10 us=91399 mode = 0 2020-08-29 21:08:10 us=91399 show_ciphers = DISABLED 2020-08-29 21:08:10 us=91399 show_digests = DISABLED 2020-08-29 21:08:10 us=91399 show_engines = DISABLED 2020-08-29 21:08:10 us=91399 genkey = DISABLED 2020-08-29 21:08:10 us=91399 genkey_filename = '[UNDEF]' 2020-08-29 21:08:10 us=91399 key_pass_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 show_tls_ciphers = DISABLED 2020-08-29 21:08:10 us=91399 connect_retry_max = 0 2020-08-29 21:08:10 us=91399 Connection profiles [0]: 2020-08-29 21:08:10 us=91399 proto = tcp-client 2020-08-29 21:08:10 us=91399 local = '[UNDEF]' 2020-08-29 21:08:10 us=91399 local_port = '[UNDEF]' 2020-08-29 21:08:10 us=91399 remote = '192.168.1.1' 2020-08-29 21:08:10 us=91399 remote_port = '443' 2020-08-29 21:08:10 us=91399 remote_float = DISABLED 2020-08-29 21:08:10 us=91399 bind_defined = DISABLED 2020-08-29 21:08:10 us=91399 bind_local = DISABLED 2020-08-29 21:08:10 us=91399 bind_ipv6_only = DISABLED 2020-08-29 21:08:10 us=91399 connect_retry_seconds = 5 2020-08-29 21:08:10 us=91399 connect_timeout = 120 2020-08-29 21:08:10 us=91399 socks_proxy_server = '[UNDEF]' 2020-08-29 21:08:10 us=91399 socks_proxy_port = '[UNDEF]' 2020-08-29 21:08:10 us=91399 tun_mtu = 1500 2020-08-29 21:08:10 us=91399 tun_mtu_defined = ENABLED 2020-08-29 21:08:10 us=91399 link_mtu = 1500 2020-08-29 21:08:10 us=91399 link_mtu_defined = DISABLED 2020-08-29 21:08:10 us=91399 tun_mtu_extra = 0 2020-08-29 21:08:10 us=91399 tun_mtu_extra_defined = DISABLED 2020-08-29 21:08:10 us=91399 mtu_discover_type = -1 2020-08-29 21:08:10 us=91399 fragment = 0 2020-08-29 21:08:10 us=91399 mssfix = 1450 2020-08-29 21:08:10 us=91399 explicit_exit_notification = 0 2020-08-29 21:08:10 us=91399 tls_auth_file = '[INLINE]' 2020-08-29 21:08:10 us=91399 key_direction = 1 2020-08-29 21:08:10 us=91399 tls_crypt_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 tls_crypt_v2_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 Connection profiles END 2020-08-29 21:08:10 us=91399 remote_random = DISABLED 2020-08-29 21:08:10 us=91399 ipchange = '[UNDEF]' 2020-08-29 21:08:10 us=91399 dev = 'tun' 2020-08-29 21:08:10 us=91399 dev_type = '[UNDEF]' 2020-08-29 21:08:10 us=91399 dev_node = '[UNDEF]' 2020-08-29 21:08:10 us=91399 lladdr = '[UNDEF]' 2020-08-29 21:08:10 us=91399 topology = 1 2020-08-29 21:08:10 us=91399 ifconfig_local = '[UNDEF]' 2020-08-29 21:08:10 us=91399 ifconfig_remote_netmask = '[UNDEF]' 2020-08-29 21:08:10 us=91399 ifconfig_noexec = DISABLED 2020-08-29 21:08:10 us=91399 ifconfig_nowarn = DISABLED 2020-08-29 21:08:10 us=91399 ifconfig_ipv6_local = '[UNDEF]' 2020-08-29 21:08:10 us=91399 ifconfig_ipv6_netbits = 0 2020-08-29 21:08:10 us=91399 ifconfig_ipv6_remote = '[UNDEF]' 2020-08-29 21:08:10 us=91399 shaper = 0 2020-08-29 21:08:10 us=91399 mtu_test = 0 2020-08-29 21:08:10 us=91399 mlock = DISABLED 2020-08-29 21:08:10 us=91399 keepalive_ping = 30 2020-08-29 21:08:10 us=91399 keepalive_timeout = 120 2020-08-29 21:08:10 us=91399 inactivity_timeout = 0 2020-08-29 21:08:10 us=91399 ping_send_timeout = 30 2020-08-29 21:08:10 us=91399 ping_rec_timeout = 120 2020-08-29 21:08:10 us=91399 ping_rec_timeout_action = 2 2020-08-29 21:08:10 us=91399 ping_timer_remote = DISABLED 2020-08-29 21:08:10 us=91399 remap_sigusr1 = 15 2020-08-29 21:08:10 us=91399 persist_tun = ENABLED 2020-08-29 21:08:10 us=91399 persist_local_ip = DISABLED 2020-08-29 21:08:10 us=91399 persist_remote_ip = DISABLED 2020-08-29 21:08:10 us=91399 persist_key = ENABLED 2020-08-29 21:08:10 us=91399 passtos = DISABLED 2020-08-29 21:08:10 us=91399 resolve_retry_seconds = 1000000000 2020-08-29 21:08:10 us=91399 resolve_in_advance = DISABLED 2020-08-29 21:08:10 us=91399 username = '[UNDEF]' 2020-08-29 21:08:10 us=91399 groupname = '[UNDEF]' 2020-08-29 21:08:10 us=91399 chroot_dir = '[UNDEF]' 2020-08-29 21:08:10 us=91399 cd_dir = '[UNDEF]' 2020-08-29 21:08:10 us=91399 writepid = '[UNDEF]' 2020-08-29 21:08:10 us=91399 up_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 down_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 down_pre = DISABLED 2020-08-29 21:08:10 us=91399 up_restart = DISABLED 2020-08-29 21:08:10 us=91399 up_delay = DISABLED 2020-08-29 21:08:10 us=91399 daemon = DISABLED 2020-08-29 21:08:10 us=91399 inetd = 0 2020-08-29 21:08:10 us=91399 log = ENABLED 2020-08-29 21:08:10 us=91399 suppress_timestamps = DISABLED 2020-08-29 21:08:10 us=91399 machine_readable_output = DISABLED 2020-08-29 21:08:10 us=91399 nice = 0 2020-08-29 21:08:10 us=91399 verbosity = 4 2020-08-29 21:08:10 us=91399 mute = 0 2020-08-29 21:08:10 us=91399 gremlin = 0 2020-08-29 21:08:10 us=91399 status_file = 'openvpn-status.log' 2020-08-29 21:08:10 us=91399 status_file_version = 1 2020-08-29 21:08:10 us=91399 status_file_update_freq = 60 2020-08-29 21:08:10 us=91399 occ = ENABLED 2020-08-29 21:08:10 us=91399 rcvbuf = 0 2020-08-29 21:08:10 us=91399 sndbuf = 0 2020-08-29 21:08:10 us=91399 sockflags = 0 2020-08-29 21:08:10 us=91399 fast_io = DISABLED 2020-08-29 21:08:10 us=91399 comp.alg = 1 2020-08-29 21:08:10 us=91399 comp.flags = 0 2020-08-29 21:08:10 us=91399 route_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 route_default_gateway = '[UNDEF]' 2020-08-29 21:08:10 us=91399 route_default_metric = 0 2020-08-29 21:08:10 us=91399 route_noexec = DISABLED 2020-08-29 21:08:10 us=91399 route_delay = 2 2020-08-29 21:08:10 us=91399 route_delay_window = 30 2020-08-29 21:08:10 us=91399 route_delay_defined = ENABLED 2020-08-29 21:08:10 us=91399 route_nopull = DISABLED 2020-08-29 21:08:10 us=91399 route_gateway_via_dhcp = DISABLED 2020-08-29 21:08:10 us=91399 allow_pull_fqdn = DISABLED 2020-08-29 21:08:10 us=91399 Pull filters: 2020-08-29 21:08:10 us=91399 ignore "route-method" 2020-08-29 21:08:10 us=91399 management_addr = '127.0.0.1' 2020-08-29 21:08:10 us=91399 management_port = '25340' 2020-08-29 21:08:10 us=91399 management_user_pass = 'stdin' 2020-08-29 21:08:10 us=91399 management_log_history_cache = 250 2020-08-29 21:08:10 us=91399 management_echo_buffer_size = 100 2020-08-29 21:08:10 us=91399 management_write_peer_info_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 management_client_user = '[UNDEF]' 2020-08-29 21:08:10 us=91399 management_client_group = '[UNDEF]' 2020-08-29 21:08:10 us=91399 management_flags = 6 2020-08-29 21:08:10 us=91399 shared_secret_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 key_direction = 1 2020-08-29 21:08:10 us=91399 ciphername = 'BF-CBC' 2020-08-29 21:08:10 us=91399 ncp_enabled = ENABLED 2020-08-29 21:08:10 us=91399 ncp_ciphers = 'BF-CBC' 2020-08-29 21:08:10 us=91399 authname = 'SHA1' 2020-08-29 21:08:10 us=91399 prng_hash = 'SHA1' 2020-08-29 21:08:10 us=91399 prng_nonce_secret_len = 16 2020-08-29 21:08:10 us=91399 keysize = 0 2020-08-29 21:08:10 us=91399 engine = DISABLED 2020-08-29 21:08:10 us=91399 replay = ENABLED 2020-08-29 21:08:10 us=91399 mute_replay_warnings = DISABLED 2020-08-29 21:08:10 us=91399 replay_window = 64 2020-08-29 21:08:10 us=91399 replay_time = 15 2020-08-29 21:08:10 us=91399 packet_id_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 test_crypto = DISABLED 2020-08-29 21:08:10 us=91399 tls_server = DISABLED 2020-08-29 21:08:10 us=91399 tls_client = ENABLED 2020-08-29 21:08:10 us=91399 ca_file = '[INLINE]' 2020-08-29 21:08:10 us=91399 ca_path = '[UNDEF]' 2020-08-29 21:08:10 us=91399 dh_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 cert_file = '[INLINE]' 2020-08-29 21:08:10 us=91399 extra_certs_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 priv_key_file = '[INLINE]' 2020-08-29 21:08:10 us=91399 pkcs12_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 cryptoapi_cert = '[UNDEF]' 2020-08-29 21:08:10 us=91399 cipher_list = '[UNDEF]' 2020-08-29 21:08:10 us=91399 cipher_list_tls13 = '[UNDEF]' 2020-08-29 21:08:10 us=91399 tls_cert_profile = '[UNDEF]' 2020-08-29 21:08:10 us=91399 tls_verify = '[UNDEF]' 2020-08-29 21:08:10 us=91399 tls_export_cert = '[UNDEF]' 2020-08-29 21:08:10 us=91399 verify_x509_type = 0 2020-08-29 21:08:10 us=91399 verify_x509_name = '[UNDEF]' 2020-08-29 21:08:10 us=91399 crl_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 ns_cert_type = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 65535 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_ku[i] = 0 2020-08-29 21:08:10 us=91399 remote_cert_eku = 'TLS Web Server Authentication' 2020-08-29 21:08:10 us=91399 ssl_flags = 192 2020-08-29 21:08:10 us=91399 tls_timeout = 2 2020-08-29 21:08:10 us=91399 renegotiate_bytes = -1 2020-08-29 21:08:10 us=91399 renegotiate_packets = 0 2020-08-29 21:08:10 us=91399 renegotiate_seconds = 3600 2020-08-29 21:08:10 us=91399 handshake_window = 60 2020-08-29 21:08:10 us=91399 transition_window = 3600 2020-08-29 21:08:10 us=91399 single_session = DISABLED 2020-08-29 21:08:10 us=91399 push_peer_info = DISABLED 2020-08-29 21:08:10 us=91399 tls_exit = DISABLED 2020-08-29 21:08:10 us=91399 tls_crypt_v2_metadata = '[UNDEF]' 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_protected_authentication = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_private_mode = 00000000 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_cert_private = DISABLED 2020-08-29 21:08:10 us=91399 pkcs11_pin_cache_period = -1 2020-08-29 21:08:10 us=91399 pkcs11_id = '[UNDEF]' 2020-08-29 21:08:10 us=91399 pkcs11_id_management = DISABLED 2020-08-29 21:08:10 us=91399 server_network = 0.0.0.0 2020-08-29 21:08:10 us=91399 server_netmask = 0.0.0.0 2020-08-29 21:08:10 us=91399 server_network_ipv6 = :: 2020-08-29 21:08:10 us=91399 server_netbits_ipv6 = 0 2020-08-29 21:08:10 us=91399 server_bridge_ip = 0.0.0.0 2020-08-29 21:08:10 us=91399 server_bridge_netmask = 0.0.0.0 2020-08-29 21:08:10 us=91399 server_bridge_pool_start = 0.0.0.0 2020-08-29 21:08:10 us=91399 server_bridge_pool_end = 0.0.0.0 2020-08-29 21:08:10 us=91399 ifconfig_pool_defined = DISABLED 2020-08-29 21:08:10 us=91399 ifconfig_pool_start = 0.0.0.0 2020-08-29 21:08:10 us=91399 ifconfig_pool_end = 0.0.0.0 2020-08-29 21:08:10 us=91399 ifconfig_pool_netmask = 0.0.0.0 2020-08-29 21:08:10 us=91399 ifconfig_pool_persist_filename = '[UNDEF]' 2020-08-29 21:08:10 us=91399 ifconfig_pool_persist_refresh_freq = 600 2020-08-29 21:08:10 us=91399 ifconfig_ipv6_pool_defined = DISABLED 2020-08-29 21:08:10 us=91399 ifconfig_ipv6_pool_base = :: 2020-08-29 21:08:10 us=91399 ifconfig_ipv6_pool_netbits = 0 2020-08-29 21:08:10 us=91399 n_bcast_buf = 256 2020-08-29 21:08:10 us=91399 tcp_queue_limit = 64 2020-08-29 21:08:10 us=91399 real_hash_size = 256 2020-08-29 21:08:10 us=91399 virtual_hash_size = 256 2020-08-29 21:08:10 us=91399 client_connect_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 learn_address_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 client_disconnect_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 client_config_dir = '[UNDEF]' 2020-08-29 21:08:10 us=91399 ccd_exclusive = DISABLED 2020-08-29 21:08:10 us=91399 tmp_dir = 'C:\Users\User\AppData\Local\Temp\' 2020-08-29 21:08:10 us=91399 push_ifconfig_defined = DISABLED 2020-08-29 21:08:10 us=91399 push_ifconfig_local = 0.0.0.0 2020-08-29 21:08:10 us=91399 push_ifconfig_remote_netmask = 0.0.0.0 2020-08-29 21:08:10 us=91399 push_ifconfig_ipv6_defined = DISABLED 2020-08-29 21:08:10 us=91399 push_ifconfig_ipv6_local = ::/0 2020-08-29 21:08:10 us=91399 push_ifconfig_ipv6_remote = :: 2020-08-29 21:08:10 us=91399 enable_c2c = DISABLED 2020-08-29 21:08:10 us=91399 duplicate_cn = DISABLED 2020-08-29 21:08:10 us=91399 cf_max = 0 2020-08-29 21:08:10 us=91399 cf_per = 0 2020-08-29 21:08:10 us=91399 max_clients = 1024 2020-08-29 21:08:10 us=91399 max_routes_per_client = 256 2020-08-29 21:08:10 us=91399 auth_user_pass_verify_script = '[UNDEF]' 2020-08-29 21:08:10 us=91399 auth_user_pass_verify_script_via_file = DISABLED 2020-08-29 21:08:10 us=91399 auth_token_generate = DISABLED 2020-08-29 21:08:10 us=91399 auth_token_lifetime = 0 2020-08-29 21:08:10 us=91399 auth_token_secret_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 vlan_tagging = DISABLED 2020-08-29 21:08:10 us=91399 vlan_accept = all 2020-08-29 21:08:10 us=91399 vlan_pvid = 1 2020-08-29 21:08:10 us=91399 client = ENABLED 2020-08-29 21:08:10 us=91399 pull = ENABLED 2020-08-29 21:08:10 us=91399 auth_user_pass_file = '[UNDEF]' 2020-08-29 21:08:10 us=91399 show_net_up = DISABLED 2020-08-29 21:08:10 us=91399 route_method = 3 2020-08-29 21:08:10 us=91399 block_outside_dns = DISABLED 2020-08-29 21:08:10 us=91399 ip_win32_defined = DISABLED 2020-08-29 21:08:10 us=91399 ip_win32_type = 1 2020-08-29 21:08:10 us=91399 dhcp_masq_offset = 0 2020-08-29 21:08:10 us=91399 dhcp_lease_time = 31536000 2020-08-29 21:08:10 us=91399 tap_sleep = 0 2020-08-29 21:08:10 us=91399 dhcp_options = DISABLED 2020-08-29 21:08:10 us=91399 dhcp_renew = DISABLED 2020-08-29 21:08:10 us=91399 dhcp_pre_release = DISABLED 2020-08-29 21:08:10 us=91399 domain = '[UNDEF]' 2020-08-29 21:08:10 us=91399 netbios_scope = '[UNDEF]' 2020-08-29 21:08:10 us=91399 netbios_node_type = 0 2020-08-29 21:08:10 us=91399 disable_nbt = DISABLED 2020-08-29 21:08:10 us=91399 OpenVPN 2.5_beta1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 14 2020 2020-08-29 21:08:10 us=91399 Windows version 10.0 (Windows 10 or greater) 64bit 2020-08-29 21:08:10 us=91399 library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.10 Enter Management Password: 2020-08-29 21:08:10 us=91399 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 2020-08-29 21:08:10 us=91399 Need hold release from management interface, waiting... 2020-08-29 21:08:10 us=597127 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 2020-08-29 21:08:10 us=721347 MANAGEMENT: CMD 'state on' 2020-08-29 21:08:10 us=721347 MANAGEMENT: CMD 'log all on' 2020-08-29 21:08:10 us=871425 MANAGEMENT: CMD 'echo all on' 2020-08-29 21:08:10 us=871425 MANAGEMENT: CMD 'bytecount 5' 2020-08-29 21:08:10 us=871425 MANAGEMENT: CMD 'hold off' 2020-08-29 21:08:10 us=889797 MANAGEMENT: CMD 'hold release' 2020-08-29 21:08:10 us=889797 Note: cannot open openvpn-status.log for WRITE 2020-08-29 21:08:10 us=889797 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6. 2020-08-29 21:08:10 us=889797 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2020-08-29 21:08:10 us=889797 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2020-08-29 21:08:10 us=889797 Control Channel MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ] 2020-08-29 21:08:10 us=889797 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ] 2020-08-29 21:08:10 us=889797 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client' 2020-08-29 21:08:10 us=889797 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server' 2020-08-29 21:08:10 us=889797 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.1:443 2020-08-29 21:08:10 us=889797 Socket Buffers: R=[65536->65536] S=[65536->65536] 2020-08-29 21:08:10 us=889797 Attempting to establish TCP connection with [AF_INET]192.168.1.1:443 [nonblock] 2020-08-29 21:08:10 us=889797 MANAGEMENT: >STATE:1598746090,TCP_CONNECT,,,,,, 2020-08-29 21:08:12 us=70744 TCP connection established with [AF_INET]192.168.1.1:443 2020-08-29 21:08:12 us=70744 TCP_CLIENT link local: (not bound) 2020-08-29 21:08:12 us=70744 TCP_CLIENT link remote: [AF_INET]192.168.1.1:443 2020-08-29 21:08:12 us=70744 MANAGEMENT: >STATE:1598746092,WAIT,,,,,, 2020-08-29 21:08:12 us=87341 MANAGEMENT: >STATE:1598746092,AUTH,,,,,, 2020-08-29 21:08:12 us=87341 TLS: Initial packet from [AF_INET]192.168.1.1:443, sid=32ea48bc 3e35a40f 2020-08-29 21:08:12 us=297516 VERIFY OK: depth=1, Removed 2020-08-29 21:08:12 us=297516 VERIFY KU OK 2020-08-29 21:08:12 us=297516 Validating certificate extended key usage 2020-08-29 21:08:12 us=297516 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2020-08-29 21:08:12 us=297516 VERIFY EKU OK 2020-08-29 21:08:12 us=297516 VERIFY OK: depth=0, Removed 2020-08-29 21:08:12 us=459102 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 2020-08-29 21:08:12 us=459102 [VenturusTMBconc] Peer Connection Initiated with [AF_INET]192.168.1.1:443 2020-08-29 21:08:13 us=663219 MANAGEMENT: >STATE:1598746093,GET_CONFIG,,,,,, 2020-08-29 21:08:13 us=663219 SENT CONTROL [VenturusTMBconc]: 'PUSH_REQUEST' (status=1) 2020-08-29 21:08:13 us=679932 PUSH: Received control message: 'PUSH_REPLY,route 194.145.17.0 255.255.255.0,route-gateway 20.20.0.1,topology subnet,ping 90,ping-restart 600,socket-flags TCP_NODELAY,ifconfig 20.20.0.2 255.255.0.0' 2020-08-29 21:08:13 us=679932 OPTIONS IMPORT: timers and/or timeouts modified 2020-08-29 21:08:13 us=679932 OPTIONS IMPORT: --socket-flags option modified 2020-08-29 21:08:13 us=679932 Socket flags: TCP_NODELAY=1 succeeded 2020-08-29 21:08:13 us=679932 OPTIONS IMPORT: --ifconfig/up options modified 2020-08-29 21:08:13 us=679932 OPTIONS IMPORT: route options modified 2020-08-29 21:08:13 us=679932 OPTIONS IMPORT: route-related options modified 2020-08-29 21:08:13 us=679932 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key 2020-08-29 21:08:13 us=679932 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6. 2020-08-29 21:08:13 us=679932 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication 2020-08-29 21:08:13 us=704131 Incoming Data Channel: Cipher 'BF-CBC' initialized with 128 bit key 2020-08-29 21:08:13 us=704131 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6. 2020-08-29 21:08:13 us=704131 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication 2020-08-29 21:08:13 us=704131 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks. 2020-08-29 21:08:13 us=704131 interactive service msg_channel=556 2020-08-29 21:08:13 us=718428 ROUTE_GATEWAY 192.168.100.1/255.255.255.0 I=14 HWADDR=08:00:27:ab:ee:ad 2020-08-29 21:08:13 us=718428 open_tun 2020-08-29 21:08:13 us=734327 Ring buffers registered via service 2020-08-29 21:08:13 us=734327 wintun device [OpenVPN Wintun] opened 2020-08-29 21:08:13 us=734327 do_ifconfig, ipv4=1, ipv6=0 2020-08-29 21:08:13 us=734327 MANAGEMENT: >STATE:1598746093,ASSIGN_IP,,20.20.0.2,,,, 2020-08-29 21:08:13 us=734327 IPv4 MTU set to 1500 on interface 25 using service 2020-08-29 21:08:15 us=119935 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up 2020-08-29 21:08:15 us=119935 MANAGEMENT: >STATE:1598746095,ADD_ROUTES,,,,,, 2020-08-29 21:08:15 us=133749 C:\Windows\system32\route.exe ADD 194.145.17.0 MASK 255.255.255.0 20.20.0.1 2020-08-29 21:08:15 us=151818 Route addition via service succeeded 2020-08-29 21:08:15 us=151818 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2020-08-29 21:08:15 us=151818 Initialization Sequence Completed 2020-08-29 21:08:15 us=151818 MANAGEMENT: >STATE:1598746095,CONNECTED,SUCCESS,20.20.0.2,192.168.1.1,443,192.168.100.106,54911 2020-08-29 21:08:28 us=292163 TCP/UDP: Closing socket 2020-08-29 21:08:28 us=292163 C:\Windows\system32\route.exe DELETE 194.145.17.0 MASK 255.255.255.0 20.20.0.1 2020-08-29 21:08:28 us=292163 Route deletion via service succeeded 2020-08-29 21:08:28 us=292163 Closing TUN/TAP interface 2020-08-29 21:08:28 us=292163 Deleting IPv4 dns servers on 'OpenVPN Wintun' (if_index = 25) using service 2020-08-29 21:08:28 us=492870 IPv4 dns servers deleted using service 2020-08-29 21:08:28 us=516105 SIGTERM[hard,] received, process exiting 2020-08-29 21:08:28 us=516105 MANAGEMENT: >STATE:1598746108,EXITING,SIGTERM,,,,,
Hello tincanteksup, Thanks for sharing. I didn't know that wiki. I'll double check and see if I'm missing something. Actually, I haven't compiled the code, I was just trying the installer from the link below: https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi Anyway, I'll pull the code, build it and see what happens. BR Gava On Sat, Aug 29, 2020 at 4:28 PM tincanteksup <tincanteksup@gmail.com> wrote: > Hi, > > sorry to interrupt, Rafael could you please confirm if you find this > document to be correct/incorrect for your use case: > https://community.openvpn.net/openvpn/wiki/CipherNegotiation > > Also note, this patch has been merged so make sure your binary has been > compiled with it. > > > On 29/08/2020 20:19, Rafael Gava wrote: > > Hi Arne, > > > > This thread has a could days but I'm testing the version 2.5-beta2 and > I'm > > getting the following error: > > > > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher > > with server. Add the server's cipher ('BF-CBC') to --data-ciphers > > (currently 'BF-CBC') if you want to connect to this server. > > > > I have added the data-ciphers and also the data-ciphers-fallback to the > > client's config file and in all attempts I'm getting the same error > message. > > > > data-ciphers BF-CBC > > data-ciphers-fallback BF-CBC > > > > I know that you guys are trying to get rid of the BF-CBC but my question > > is, should it still work if we set these parameters in the config file or > > am I missing or doing something wrong? :-) > > > > BR > > > > Gava > > > > > > > > > > On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe <arne@rfc2549.org> wrote: > > > >> OpenVPN 2.5 clients do not correctly do a fallback to the server server. > >> This commit fixes that logic and also fixes --data-ciphers-fallback to > >> be used in situations other than no OCC cipher. > >> > >> To reproduce the error use a client with only --data-ciphers set against > >> a server without NCP. > >> > >> OPTIONS ERROR: failed to negotiate cipher with server. > >> Add the server's cipher ('AES-256-CBC') to --data-ciphers > >> (currently 'AES-256-CBC') if you want to connect to this > server. > >> > >> Reported by: Richard Bonhomme <tincanteksup@gmail.com> > >> > >> Signed-off-by: Arne Schwabe <arne@rfc2549.org> > >> --- > >> src/openvpn/ssl_ncp.c | 9 +++++---- > >> 1 file changed, 5 insertions(+), 4 deletions(-) > >> > >> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c > >> index f522b8f0..c9ab85ce 100644 > >> --- a/src/openvpn/ssl_ncp.c > >> +++ b/src/openvpn/ssl_ncp.c > >> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int > >> found) > >> } > >> /* If the server did not push a --cipher, we will switch to the > >> * remote cipher if it is in our ncp-ciphers list */ > >> - bool useremotecipher = tls_poor_mans_ncp(&c->options, > >> - > >> c->c2.tls_multi->remote_ciphername); > >> - > >> + if(tls_poor_mans_ncp(&c->options, > c->c2.tls_multi->remote_ciphername)) > >> + { > >> + return true; > >> + } > >> > >> /* We could not figure out the peer's cipher but we have fallback > >> * enabled */ > >> - if (!useremotecipher && c->options.enable_ncp_fallback) > >> + if (!c->c2.tls_multi->remote_ciphername && > >> c->options.enable_ncp_fallback) > >> { > >> return true; > >> } > >> -- > >> 2.26.2 > >> > >> > >> > >> _______________________________________________ > >> Openvpn-devel mailing list > >> Openvpn-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > >> > > > > > > > > _______________________________________________ > > Openvpn-devel mailing list > > Openvpn-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > > > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > <div dir="ltr"><div>Hello tincanteksup,</div><div><br></div><div>Thanks for sharing. I didn't know that wiki. I'll double check and see if I'm missing something.</div><div><br></div><div>Actually, I haven't compiled the code, I was just trying the installer from the link below:</div><div><br></div><div><a href="https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi" rel="noreferrer" target="_blank">https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi</a> <br></div><div><br></div><div>Anyway, I'll pull the code, build it and see what happens.</div><div><br></div><div>BR</div><div><br></div><div>Gava</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 29, 2020 at 4:28 PM tincanteksup <<a href="mailto:tincanteksup@gmail.com">tincanteksup@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> sorry to interrupt, Rafael could you please confirm if you find this <br> document to be correct/incorrect for your use case:<br> <a href="https://community.openvpn.net/openvpn/wiki/CipherNegotiation" rel="noreferrer" target="_blank">https://community.openvpn.net/openvpn/wiki/CipherNegotiation</a><br> <br> Also note, this patch has been merged so make sure your binary has been <br> compiled with it.<br> <br> <br> On 29/08/2020 20:19, Rafael Gava wrote:<br> > Hi Arne,<br> > <br> > This thread has a could days but I'm testing the version 2.5-beta2 and I'm<br> > getting the following error:<br> > <br> > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher<br> > with server. Add the server's cipher ('BF-CBC') to --data-ciphers<br> > (currently 'BF-CBC') if you want to connect to this server.<br> > <br> > I have added the data-ciphers and also the data-ciphers-fallback to the<br> > client's config file and in all attempts I'm getting the same error message.<br> > <br> > data-ciphers BF-CBC<br> > data-ciphers-fallback BF-CBC<br> > <br> > I know that you guys are trying to get rid of the BF-CBC but my question<br> > is, should it still work if we set these parameters in the config file or<br> > am I missing or doing something wrong? :-)<br> > <br> > BR<br> > <br> > Gava<br> > <br> > <br> > <br> > <br> > On Fri, Aug 14, 2020 at 5:06 AM Arne Schwabe <<a href="mailto:arne@rfc2549.org" target="_blank">arne@rfc2549.org</a>> wrote:<br> > <br> >> OpenVPN 2.5 clients do not correctly do a fallback to the server server.<br> >> This commit fixes that logic and also fixes --data-ciphers-fallback to<br> >> be used in situations other than no OCC cipher.<br> >><br> >> To reproduce the error use a client with only --data-ciphers set against<br> >> a server without NCP.<br> >><br> >> OPTIONS ERROR: failed to negotiate cipher with server.<br> >> Add the server's cipher ('AES-256-CBC') to --data-ciphers<br> >> (currently 'AES-256-CBC') if you want to connect to this server.<br> >><br> >> Reported by: Richard Bonhomme <<a href="mailto:tincanteksup@gmail.com" target="_blank">tincanteksup@gmail.com</a>><br> >><br> >> Signed-off-by: Arne Schwabe <<a href="mailto:arne@rfc2549.org" target="_blank">arne@rfc2549.org</a>><br> >> ---<br> >> src/openvpn/ssl_ncp.c | 9 +++++----<br> >> 1 file changed, 5 insertions(+), 4 deletions(-)<br> >><br> >> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c<br> >> index f522b8f0..c9ab85ce 100644<br> >> --- a/src/openvpn/ssl_ncp.c<br> >> +++ b/src/openvpn/ssl_ncp.c<br> >> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int<br> >> found)<br> >> }<br> >> /* If the server did not push a --cipher, we will switch to the<br> >> * remote cipher if it is in our ncp-ciphers list */<br> >> - bool useremotecipher = tls_poor_mans_ncp(&c->options,<br> >> -<br> >> c->c2.tls_multi->remote_ciphername);<br> >> -<br> >> + if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername))<br> >> + {<br> >> + return true;<br> >> + }<br> >><br> >> /* We could not figure out the peer's cipher but we have fallback<br> >> * enabled */<br> >> - if (!useremotecipher && c->options.enable_ncp_fallback)<br> >> + if (!c->c2.tls_multi->remote_ciphername &&<br> >> c->options.enable_ncp_fallback)<br> >> {<br> >> return true;<br> >> }<br> >> --<br> >> 2.26.2<br> >><br> >><br> >><br> >> _______________________________________________<br> >> Openvpn-devel mailing list<br> >> <a href="mailto:Openvpn-devel@lists.sourceforge.net" target="_blank">Openvpn-devel@lists.sourceforge.net</a><br> >> <a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/openvpn-devel</a><br> >><br> > <br> > <br> > <br> > _______________________________________________<br> > Openvpn-devel mailing list<br> > <a href="mailto:Openvpn-devel@lists.sourceforge.net" target="_blank">Openvpn-devel@lists.sourceforge.net</a><br> > <a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/openvpn-devel</a><br> > <br> <br> <br> _______________________________________________<br> Openvpn-devel mailing list<br> <a href="mailto:Openvpn-devel@lists.sourceforge.net" target="_blank">Openvpn-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/openvpn-devel</a><br> </blockquote></div></div>
Hi, On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote: > Actually, I was testing Samuli's 2.5-beta2 installer from the link below: > Note sure if it's with the patch for data-ciphers but I guess so. > I'll pull the 2.5-beta2 code and build it in order to check if it's > working properly. > > https://build.openvpn.net/downloads/releases/OpenVPN-2.5-beta2-I601-amd64.msi The installer has the right binary, *but* the binary has the same "ingrained" windows version number, so when going from beta1 to beta2, the .msi will just not upgrade openvpn.exe. Known bug (now), being worked on. [..] > On Sat, Aug 29, 2020 at 4:47 PM Gert Doering <gert@greenie.muc.de> wrote: > > Which combination of client/server is this exactly? 2.5-beta2 on > > the client, what is on the server? Can we have some more log file, > > including the "PUSH_REPLY", please? > > The server version is 2.3.18. > The client: > > 2020-08-29 16:02:50 us=235805 OpenVPN 2.5_beta2 x86_64-w64-mingw32 [SSL > (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 27 2020 > 2020-08-29 16:02:50 us=235805 Windows version 10.0 (Windows 10 or greater) > 64bit > 2020-08-29 16:02:50 us=235805 library versions: OpenSSL 1.1.1g 21 Apr > 2020, LZO 2.10 Mmmh. Now, 2.3.18 is just a little bit oldish. But still, 2.5_beta2 *should* work nicely with a 2.3 server, after adding "data-ciphers BF-CBC" to your local config. If it still doesn't do that, you found a new bug :-) (Is the server compiled with --enable-small, which means "no OCC"?) > I falled back to the 2.5-beta1 using the same configuration and it worked. > Attached are both logs and the client config. Uh. So: 2.5-beta1 --> 2.3.18 *works* 2.5-beta2 --> 2.3.18 *fails* is that correct? (Seems beta1 might have accidentially worked, while a fallback code path for "no NCP, no OCC" was disallowed in beta2 and might be breaking this) Arne? > 2020-08-29 16:02:50 us=235805 OpenVPN 2.5_beta2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 27 2020 [..] > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'BF-CBC') if you want to connect to this server. This is very clearly "beta2", and the error message looks most silly... [..] > 2020-08-29 21:08:10 us=91399 OpenVPN 2.5_beta1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Aug 14 2020 [..] > 2020-08-29 21:08:13 us=679932 PUSH: Received control message: 'PUSH_REPLY,route 194.145.17.0 255.255.255.0,route-gateway 20.20.0.1,topology subnet,ping 90,ping-restart 600,socket-flags TCP_NODELAY,ifconfig 20.20.0.2 255.255.0.0' [..] > 2020-08-29 21:08:13 us=679932 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key So... something is still not right here. And I need to extend my testbed with server configs that match this (2.3, 2.3-enable-small, 2.4). gert
Am 29.08.20 um 21:19 schrieb Rafael Gava: > Hi Arne, > > This thread has a could days but I'm testing the version 2.5-beta2 and > I'm getting the following error: > > 2020-08-29 16:02:53 us=643016 OPTIONS ERROR: failed to negotiate cipher > with server. Add the server's cipher ('BF-CBC') to --data-ciphers > (currently 'BF-CBC') if you want to connect to this server. > > I have added the data-ciphers and also the data-ciphers-fallback to the > client's config file and in all attempts I'm getting the same error message. > > data-ciphers BF-CBC > data-ciphers-fallback BF-CBC > > I know that you guys are trying to get rid of the BF-CBC but my question > is, should it still work if we set these parameters in the config file > or am I missing or doing something wrong? :-) Can you try if the following works for you? cipher AES-128-CBC data-ciphers "AES-256-GCM:AES-128-GCM:BF-CBC" That helps me knowing if you have the bug I found or if it is something else. Arne
Hi, On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote: > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote: [..] > If it still doesn't do that, you found a new bug :-) So - patch has been merged, and I think I have set up an appropriate testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled). With Arne's (v2) patch it is no longer failing. Can you re-test your scenarios, please? gert
Hi Gert, thanks for the prompt fix. Our server is an old appliance and I really don't know if it was compiled with "enable-small". I'll try to figure that. :-) Sure, I'll try the fix and let you know ASAP. BR Gava On Sun, Aug 30, 2020 at 5:37 PM Gert Doering <gert@greenie.muc.de> wrote: > Hi, > > On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote: > > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote: > [..] > > If it still doesn't do that, you found a new bug :-) > > So - patch has been merged, and I think I have set up an appropriate > testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled). > > With Arne's (v2) patch it is no longer failing. > > Can you re-test your scenarios, please? > > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > gert@greenie.muc.de > <div dir="ltr">Hi Gert, <div><br></div><div>thanks for the prompt fix.</div><div><br></div><div>Our server is an old appliance and I really don't know if it was compiled with "enable-small". I'll try to figure that. :-)</div><div><br></div><div>Sure, I'll try the fix and let you know ASAP.</div><div><br></div><div>BR</div><div><br></div><div>Gava</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at 5:37 PM Gert Doering <<a href="mailto:gert@greenie.muc.de">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote:<br> > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote:<br> [..]<br> > If it still doesn't do that, you found a new bug :-)<br> <br> So - patch has been merged, and I think I have set up an appropriate<br> testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled).<br> <br> With Arne's (v2) patch it is no longer failing.<br> <br> Can you re-test your scenarios, please?<br> <br> gert<br> <br> -- <br> "If was one thing all people took for granted, was conviction that if you <br> feed honest figures into a computer, honest figures come out. Never doubted <br> it myself till I met a computer with a sense of humor."<br> Robert A. Heinlein, The Moon is a Harsh Mistress<br> <br> Gert Doering - Munich, Germany <a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a><br> </blockquote></div>
Hi Gert, Good news, it worked beautifully with tun and tap interfaces! Thank you very much!!!! BR Gava On Sun, Aug 30, 2020 at 5:37 PM Gert Doering <gert@greenie.muc.de> wrote: > Hi, > > On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote: > > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote: > [..] > > If it still doesn't do that, you found a new bug :-) > > So - patch has been merged, and I think I have set up an appropriate > testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled). > > With Arne's (v2) patch it is no longer failing. > > Can you re-test your scenarios, please? > > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > gert@greenie.muc.de > <div dir="ltr">Hi Gert,<div><br></div><div>Good news, it worked beautifully with tun and tap interfaces! </div><div><br></div><div>Thank you very much!!!!</div><div><br></div><div>BR</div><div><br></div><div>Gava</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at 5:37 PM Gert Doering <<a href="mailto:gert@greenie.muc.de">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Sun, Aug 30, 2020 at 02:07:03PM +0200, Gert Doering wrote:<br> > On Sat, Aug 29, 2020 at 09:42:46PM -0300, Rafael Gava wrote:<br> [..]<br> > If it still doesn't do that, you found a new bug :-)<br> <br> So - patch has been merged, and I think I have set up an appropriate<br> testbed to verify this (2.5/master talking to 2.3.18 with OCC enabled).<br> <br> With Arne's (v2) patch it is no longer failing.<br> <br> Can you re-test your scenarios, please?<br> <br> gert<br> <br> -- <br> "If was one thing all people took for granted, was conviction that if you <br> feed honest figures into a computer, honest figures come out. Never doubted <br> it myself till I met a computer with a sense of humor."<br> Robert A. Heinlein, The Moon is a Harsh Mistress<br> <br> Gert Doering - Munich, Germany <a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a><br> </blockquote></div>
Hi, On Sun, Aug 30, 2020 at 09:26:10PM -0300, Rafael Gava wrote: > Good news, it worked beautifully with tun and tap interfaces! > > Thank you very much!!!! Cool, thanks for testing. I have just tagged 2.5_beta3, and lev/mattock will go about building a beta3 .msi with it (and hopefully lots of other windows specific fixes :-) ). gert
Hi Gert, Glad that we could help! :-) If you guys need anything else that we can help, please let us know. BR Gava On Mon, Aug 31, 2020 at 10:23 AM Gert Doering <gert@greenie.muc.de> wrote: > Hi, > > On Sun, Aug 30, 2020 at 09:26:10PM -0300, Rafael Gava wrote: > > Good news, it worked beautifully with tun and tap interfaces! > > > > Thank you very much!!!! > > Cool, thanks for testing. I have just tagged 2.5_beta3, and lev/mattock > will go about building a beta3 .msi with it (and hopefully lots of other > windows specific fixes :-) ). > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > gert@greenie.muc.de > <div dir="ltr"><div>Hi Gert, </div><div><br></div><div>Glad that we could help! :-)</div><div><br></div><div>If you guys need anything else that we can help, please let us know.</div><div><br></div><div>BR</div><div><br></div><div>Gava</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 10:23 AM Gert Doering <<a href="mailto:gert@greenie.muc.de">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Sun, Aug 30, 2020 at 09:26:10PM -0300, Rafael Gava wrote:<br> > Good news, it worked beautifully with tun and tap interfaces!<br> > <br> > Thank you very much!!!!<br> <br> Cool, thanks for testing. I have just tagged 2.5_beta3, and lev/mattock<br> will go about building a beta3 .msi with it (and hopefully lots of other<br> windows specific fixes :-) ).<br> <br> gert<br> -- <br> "If was one thing all people took for granted, was conviction that if you <br> feed honest figures into a computer, honest figures come out. Never doubted <br> it myself till I met a computer with a sense of humor."<br> Robert A. Heinlein, The Moon is a Harsh Mistress<br> <br> Gert Doering - Munich, Germany <a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a><br> </blockquote></div>
Hi Guys, I just tested beta3 on Win10. I am getting the exact same error with wintun as before. TAP works normally. I tried with the GUI and by cli. 2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and therefore should be used with interactive service. If you want to use openvpn from command line, you need to do SYSTEM elevation yourself (for example with psexec). 2020-09-09 16:23:20 us=991306 Exiting due to fatal error Marvin On Mon, Aug 31, 2020 at 7:13 AM Rafael Gava <gava100@gmail.com> wrote: > Hi Gert, > > Glad that we could help! :-) > > If you guys need anything else that we can help, please let us know. > > BR > > Gava > > On Mon, Aug 31, 2020 at 10:23 AM Gert Doering <gert@greenie.muc.de> wrote: > >> Hi, >> >> On Sun, Aug 30, 2020 at 09:26:10PM -0300, Rafael Gava wrote: >> > Good news, it worked beautifully with tun and tap interfaces! >> > >> > Thank you very much!!!! >> >> Cool, thanks for testing. I have just tagged 2.5_beta3, and lev/mattock >> will go about building a beta3 .msi with it (and hopefully lots of other >> windows specific fixes :-) ). >> >> gert >> -- >> "If was one thing all people took for granted, was conviction that if you >> feed honest figures into a computer, honest figures come out. Never >> doubted >> it myself till I met a computer with a sense of humor." >> Robert A. Heinlein, The Moon is a Harsh >> Mistress >> >> Gert Doering - Munich, Germany >> gert@greenie.muc.de >> > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > <div dir="ltr">Hi Guys,<div><br></div><div>I just tested beta3 on Win10. I am getting the exact same error with wintun as before. TAP works normally. I tried with the GUI and by cli.</div><div><br></div><div>2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and therefore should be used with interactive service. If you want to use openvpn from command line, you need to do SYSTEM elevation yourself (for example with psexec).<br>2020-09-09 16:23:20 us=991306 Exiting due to fatal error<br></div><div><br></div><div>Marvin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 7:13 AM Rafael Gava <<a href="mailto:gava100@gmail.com">gava100@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Gert, </div><div><br></div><div>Glad that we could help! :-)</div><div><br></div><div>If you guys need anything else that we can help, please let us know.</div><div><br></div><div>BR</div><div><br></div><div>Gava</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 10:23 AM Gert Doering <<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Sun, Aug 30, 2020 at 09:26:10PM -0300, Rafael Gava wrote:<br> > Good news, it worked beautifully with tun and tap interfaces!<br> > <br> > Thank you very much!!!!<br> <br> Cool, thanks for testing. I have just tagged 2.5_beta3, and lev/mattock<br> will go about building a beta3 .msi with it (and hopefully lots of other<br> windows specific fixes :-) ).<br> <br> gert<br> -- <br> "If was one thing all people took for granted, was conviction that if you <br> feed honest figures into a computer, honest figures come out. Never doubted <br> it myself till I met a computer with a sense of humor."<br> Robert A. Heinlein, The Moon is a Harsh Mistress<br> <br> Gert Doering - Munich, Germany <a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a><br> </blockquote></div> _______________________________________________<br> Openvpn-devel mailing list<br> <a href="mailto:Openvpn-devel@lists.sourceforge.net" target="_blank">Openvpn-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/openvpn-devel</a><br> </blockquote></div>
Hi Marvin, This is the wrong thread, but... On Wed, Sep 9, 2020 at 7:54 PM Marvin <volleynbike@gmail.com> wrote: > Hi Guys, > > I just tested beta3 on Win10. I am getting the exact same error with > wintun as before. TAP works normally. I tried with the GUI and by cli. > The GUI never generated this error even before beta3, so not sure what you are doing wrong. Ensure that the interactive service is running (that's the default) and GUI is not started with admin privileges (do not start the GUI from an elevated command line or using run as admin). For cli you will get this error unless you use some utility like psexec to elevate to SYSTEM. For connections started at boot using OpenVPNService (not the same as the interactive service used by the GUI) beta3 should work. There was a bug that affected this use case which was fixed in beta3. > 2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges > and therefore should be used with interactive service. If you want to use > openvpn from command line, you need to do SYSTEM elevation yourself (for > example with psexec). > 2020-09-09 16:23:20 us=991306 Exiting due to fatal error > If you got this error running from the command line as SYSTEM please check the logs to be sure its beta3. Selva <div dir="ltr"><div dir="ltr">Hi Marvin,<div><br></div><div>This is the wrong thread, but...</div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 7:54 PM Marvin <<a href="mailto:volleynbike@gmail.com">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Guys,<div><br></div><div>I just tested beta3 on Win10. I am getting the exact same error with wintun as before. TAP works normally. I tried with the GUI and by cli.</div></div></blockquote><div><br></div><div>The GUI never generated this error even before beta3, so not sure what you are doing wrong. Ensure that the interactive service is running (that's the default) and GUI is not started with admin privileges (do not start the GUI from an elevated command line or using run as admin).</div><div><br></div><div>For cli you will get this error unless you use some utility like psexec to elevate to SYSTEM. </div><div><br></div><div>For connections started at boot using OpenVPNService (not the same as the interactive service used by the GUI) beta3 should work. There was a bug that affected this use case which was fixed in beta3.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and therefore should be used with interactive service. If you want to use openvpn from command line, you need to do SYSTEM elevation yourself (for example with psexec).<br>2020-09-09 16:23:20 us=991306 Exiting due to fatal error<br></div></div></blockquote><div><br></div><div>If you got this error running from the command line as SYSTEM please check the logs to be sure its beta3.</div><div><br></div><div>Selva</div><div><br></div></div></div>
Selva, Sorry for the wrong thread. I was replying to an earlier thread about this same error on Beta1 and beta2. So i am a bit confused by your statement that this error did not show up in earlier betas, because that's what started this thread. Marvin On Wed, Sep 9, 2020 at 5:14 PM Selva Nair <selva.nair@gmail.com> wrote: > Hi Marvin, > > This is the wrong thread, but... > > On Wed, Sep 9, 2020 at 7:54 PM Marvin <volleynbike@gmail.com> wrote: > >> Hi Guys, >> >> I just tested beta3 on Win10. I am getting the exact same error with >> wintun as before. TAP works normally. I tried with the GUI and by cli. >> > > The GUI never generated this error even before beta3, so not sure what you > are doing wrong. Ensure that the interactive service is running (that's the > default) and GUI is not started with admin privileges (do not start the > GUI from an elevated command line or using run as admin). > > For cli you will get this error unless you use some utility like psexec to > elevate to SYSTEM. > > For connections started at boot using OpenVPNService (not the same as the > interactive service used by the GUI) beta3 should work. There was a bug > that affected this use case which was fixed in beta3. > > >> 2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges >> and therefore should be used with interactive service. If you want to use >> openvpn from command line, you need to do SYSTEM elevation yourself (for >> example with psexec). >> 2020-09-09 16:23:20 us=991306 Exiting due to fatal error >> > > If you got this error running from the command line as SYSTEM please check > the logs to be sure its beta3. > > Selva > > <div dir="ltr">Selva,<div><br></div><div>Sorry for the wrong thread. I was replying to an earlier thread about this same error on Beta1 and beta2. So i am a bit confused by your statement that this error did not show up in earlier betas, because that's what started this thread.</div><div><br></div><div>Marvin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 5:14 PM Selva Nair <<a href="mailto:selva.nair@gmail.com">selva.nair@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Marvin,<div><br></div><div>This is the wrong thread, but...</div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 7:54 PM Marvin <<a href="mailto:volleynbike@gmail.com" target="_blank">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Guys,<div><br></div><div>I just tested beta3 on Win10. I am getting the exact same error with wintun as before. TAP works normally. I tried with the GUI and by cli.</div></div></blockquote><div><br></div><div>The GUI never generated this error even before beta3, so not sure what you are doing wrong. Ensure that the interactive service is running (that's the default) and GUI is not started with admin privileges (do not start the GUI from an elevated command line or using run as admin).</div><div><br></div><div>For cli you will get this error unless you use some utility like psexec to elevate to SYSTEM. </div><div><br></div><div>For connections started at boot using OpenVPNService (not the same as the interactive service used by the GUI) beta3 should work. There was a bug that affected this use case which was fixed in beta3.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and therefore should be used with interactive service. If you want to use openvpn from command line, you need to do SYSTEM elevation yourself (for example with psexec).<br>2020-09-09 16:23:20 us=991306 Exiting due to fatal error<br></div></div></blockquote><div><br></div><div>If you got this error running from the command line as SYSTEM please check the logs to be sure its beta3.</div><div><br></div><div>Selva</div><div><br></div></div></div> </blockquote></div>
Hi On Wed, Sep 9, 2020 at 8:30 PM Marvin <volleynbike@gmail.com> wrote: > Selva, > > Sorry for the wrong thread. I was replying to an earlier thread about > this same error on Beta1 and beta2. So i am a bit confused by your > statement that this error did not show up in earlier betas, because that's > what started this thread. > The GUI did not have this error unless run as administrator which you should not and will never work. What was fixed was the error generated even when run as SYSTEM from the automatic service or on command line using psexec or other tools that can elevate to SYSTEM. Selva > > Marvin > > On Wed, Sep 9, 2020 at 5:14 PM Selva Nair <selva.nair@gmail.com> wrote: > >> Hi Marvin, >> >> This is the wrong thread, but... >> >> On Wed, Sep 9, 2020 at 7:54 PM Marvin <volleynbike@gmail.com> wrote: >> >>> Hi Guys, >>> >>> I just tested beta3 on Win10. I am getting the exact same error with >>> wintun as before. TAP works normally. I tried with the GUI and by cli. >>> >> >> The GUI never generated this error even before beta3, so not sure what >> you are doing wrong. Ensure that the interactive service is running (that's >> the default) and GUI is not started with admin privileges (do not start >> the GUI from an elevated command line or using run as admin). >> >> For cli you will get this error unless you use some utility like psexec >> to elevate to SYSTEM. >> >> For connections started at boot using OpenVPNService (not the same as the >> interactive service used by the GUI) beta3 should work. There was a bug >> that affected this use case which was fixed in beta3. >> >> >>> 2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges >>> and therefore should be used with interactive service. If you want to use >>> openvpn from command line, you need to do SYSTEM elevation yourself (for >>> example with psexec). >>> 2020-09-09 16:23:20 us=991306 Exiting due to fatal error >>> >> >> If you got this error running from the command line as SYSTEM please >> check the logs to be sure its beta3. >> >> Selva >> >> <div dir="ltr"><div>Hi</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 8:30 PM Marvin <<a href="mailto:volleynbike@gmail.com">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Selva,<div><br></div><div>Sorry for the wrong thread. I was replying to an earlier thread about this same error on Beta1 and beta2. So i am a bit confused by your statement that this error did not show up in earlier betas, because that's what started this thread.</div></div></blockquote><div><br></div><div>The GUI did not have this error unless run as administrator which you should not and will never work. </div><div><br></div><div>What was fixed was the error generated even when run as SYSTEM from the automatic service or on command line using psexec or other tools that can elevate to SYSTEM.</div><div><br></div><div>Selva </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Marvin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 5:14 PM Selva Nair <<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Marvin,<div><br></div><div>This is the wrong thread, but...</div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 7:54 PM Marvin <<a href="mailto:volleynbike@gmail.com" target="_blank">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Guys,<div><br></div><div>I just tested beta3 on Win10. I am getting the exact same error with wintun as before. TAP works normally. I tried with the GUI and by cli.</div></div></blockquote><div><br></div><div>The GUI never generated this error even before beta3, so not sure what you are doing wrong. Ensure that the interactive service is running (that's the default) and GUI is not started with admin privileges (do not start the GUI from an elevated command line or using run as admin).</div><div><br></div><div>For cli you will get this error unless you use some utility like psexec to elevate to SYSTEM. </div><div><br></div><div>For connections started at boot using OpenVPNService (not the same as the interactive service used by the GUI) beta3 should work. There was a bug that affected this use case which was fixed in beta3.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and therefore should be used with interactive service. If you want to use openvpn from command line, you need to do SYSTEM elevation yourself (for example with psexec).<br>2020-09-09 16:23:20 us=991306 Exiting due to fatal error<br></div></div></blockquote><div><br></div><div>If you got this error running from the command line as SYSTEM please check the logs to be sure its beta3.</div><div><br></div><div>Selva</div><div><br></div></div></div> </blockquote></div> </blockquote></div></div>
Hi Selva, The GUI did not have this error unless run as administrator which you > should not and will never work. So you are saying that if OpenVPN is installed by a user who has admin privileges (as our case does) that v2.5 with wintun will not work? On Wed, Sep 9, 2020 at 6:03 PM Selva Nair <selva.nair@gmail.com> wrote: > Hi > > On Wed, Sep 9, 2020 at 8:30 PM Marvin <volleynbike@gmail.com> wrote: > >> Selva, >> >> Sorry for the wrong thread. I was replying to an earlier thread about >> this same error on Beta1 and beta2. So i am a bit confused by your >> statement that this error did not show up in earlier betas, because that's >> what started this thread. >> > > The GUI did not have this error unless run as administrator which you > should not and will never work. > > What was fixed was the error generated even when run as SYSTEM from the > automatic service or on command line using psexec or other tools that can > elevate to SYSTEM. > > Selva > >> >> Marvin >> >> On Wed, Sep 9, 2020 at 5:14 PM Selva Nair <selva.nair@gmail.com> wrote: >> >>> Hi Marvin, >>> >>> This is the wrong thread, but... >>> >>> On Wed, Sep 9, 2020 at 7:54 PM Marvin <volleynbike@gmail.com> wrote: >>> >>>> Hi Guys, >>>> >>>> I just tested beta3 on Win10. I am getting the exact same error with >>>> wintun as before. TAP works normally. I tried with the GUI and by cli. >>>> >>> >>> The GUI never generated this error even before beta3, so not sure what >>> you are doing wrong. Ensure that the interactive service is running (that's >>> the default) and GUI is not started with admin privileges (do not start >>> the GUI from an elevated command line or using run as admin). >>> >>> For cli you will get this error unless you use some utility like psexec >>> to elevate to SYSTEM. >>> >>> For connections started at boot using OpenVPNService (not the same as >>> the interactive service used by the GUI) beta3 should work. There was a bug >>> that affected this use case which was fixed in beta3. >>> >>> >>>> 2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges >>>> and therefore should be used with interactive service. If you want to use >>>> openvpn from command line, you need to do SYSTEM elevation yourself (for >>>> example with psexec). >>>> 2020-09-09 16:23:20 us=991306 Exiting due to fatal error >>>> >>> >>> If you got this error running from the command line as SYSTEM please >>> check the logs to be sure its beta3. >>> >>> Selva >>> >>> <div dir="ltr">Hi Selva,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The GUI did not have this error unless run as administrator which you should not and will never work. </blockquote><div>So you are saying that if OpenVPN is installed by a user who has admin privileges (as our case does) that v2.5 with wintun will not work?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 6:03 PM Selva Nair <<a href="mailto:selva.nair@gmail.com">selva.nair@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 8:30 PM Marvin <<a href="mailto:volleynbike@gmail.com" target="_blank">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Selva,<div><br></div><div>Sorry for the wrong thread. I was replying to an earlier thread about this same error on Beta1 and beta2. So i am a bit confused by your statement that this error did not show up in earlier betas, because that's what started this thread.</div></div></blockquote><div><br></div><div>The GUI did not have this error unless run as administrator which you should not and will never work. </div><div><br></div><div>What was fixed was the error generated even when run as SYSTEM from the automatic service or on command line using psexec or other tools that can elevate to SYSTEM.</div><div><br></div><div>Selva </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Marvin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 5:14 PM Selva Nair <<a href="mailto:selva.nair@gmail.com" target="_blank">selva.nair@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Marvin,<div><br></div><div>This is the wrong thread, but...</div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 7:54 PM Marvin <<a href="mailto:volleynbike@gmail.com" target="_blank">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Guys,<div><br></div><div>I just tested beta3 on Win10. I am getting the exact same error with wintun as before. TAP works normally. I tried with the GUI and by cli.</div></div></blockquote><div><br></div><div>The GUI never generated this error even before beta3, so not sure what you are doing wrong. Ensure that the interactive service is running (that's the default) and GUI is not started with admin privileges (do not start the GUI from an elevated command line or using run as admin).</div><div><br></div><div>For cli you will get this error unless you use some utility like psexec to elevate to SYSTEM. </div><div><br></div><div>For connections started at boot using OpenVPNService (not the same as the interactive service used by the GUI) beta3 should work. There was a bug that affected this use case which was fixed in beta3.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2020-09-09 16:23:20 us=991306 ERROR: Wintun requires SYSTEM privileges and therefore should be used with interactive service. If you want to use openvpn from command line, you need to do SYSTEM elevation yourself (for example with psexec).<br>2020-09-09 16:23:20 us=991306 Exiting due to fatal error<br></div></div></blockquote><div><br></div><div>If you got this error running from the command line as SYSTEM please check the logs to be sure its beta3.</div><div><br></div><div>Selva</div><div><br></div></div></div> </blockquote></div> </blockquote></div></div> </blockquote></div>
Hi, On Thu, Sep 10, 2020 at 12:19 AM Marvin <volleynbike@gmail.com> wrote: > Hi Selva, > > The GUI did not have this error unless run as administrator which you >> should not and will never work. > > So you are saying that if OpenVPN is installed by a user who has admin > privileges (as our case does) that v2.5 with wintun will not work? > You mean OpenVPN started using the GUI? If so, no, I'm not saying that. The GUI just works even with beta1 or with beta3. On Windows user's processes run with limited privileges even if the user is an "admin". At least that is the default because of UAC. Installation can be done when logged in as admin or as a limited user (provided you know admin credentials) as the installer prompts for elevation as required. That qualifier I added was because: the GUI running with privileges (admin) has been discouraged in 2.4 ever since we introduced the interactive service. And that continues with 2.5. It will work for some things and not for some other things. Same with running the GUI with interactive service disabled. As such uses are not supported, don't complain about it :) Selva <div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 12:19 AM Marvin <<a href="mailto:volleynbike@gmail.com" target="_blank">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Selva,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The GUI did not have this error unless run as administrator which you should not and will never work. </blockquote><div>So you are saying that if OpenVPN is installed by a user who has admin privileges (as our case does) that v2.5 with wintun will not work?</div></div></blockquote><div><br></div><div>You mean OpenVPN started using the GUI? If so, no, I'm not saying that. The GUI just works even with beta1 or with beta3. On Windows user's processes run with limited privileges even if the user is an "admin". At least that is the default because of UAC. </div><div> </div><div>Installation can be done when logged in as admin or as a limited user (provided you know admin credentials) as the installer prompts for elevation as required. </div><div><br></div><div>That qualifier I added was because: the GUI running with privileges (admin) has been discouraged in 2.4 ever since we introduced the interactive service. And that continues with 2.5. It will work for some things and not for some other things. Same with running the GUI with interactive service disabled. As such uses are not supported, don't complain about it :)</div><div><br></div><div>Selva</div></div></div>
Selva, Please allow me to back up a moment and restate this: 1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. 2. I only used the GUI as installed, with no elevation, to start OpenVPN. 3. With TAP selected in my .ovpn config file, everything works normally. 4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. Is 4. what you are saying is not supported? In our use, as we have done for the past decade, the client boxes are used for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file contains inline certificates) regardless if there is a user logged in or not as M2M monitoring occurs in the background. And if a user does login, most often it is with credentials that have admin privileges. I am trying to understand if what you’re telling me is that this will no longer work, or if we will need to do something different now? My testing used the GUI to see how things will work with wintun so we can continue testing. Do I need to NOT use the GUI to get wintun to work? Marvin > On Sep 9, 2020, at 9:56 PM, Selva Nair <selva.nair@gmail.com> wrote: > > Hi, > >> On Thu, Sep 10, 2020 at 12:19 AM Marvin <volleynbike@gmail.com> wrote: >> Hi Selva, >> >>> The GUI did not have this error unless run as administrator which you should not and will never work. >> So you are saying that if OpenVPN is installed by a user who has admin privileges (as our case does) that v2.5 with wintun will not work? > > You mean OpenVPN started using the GUI? If so, no, I'm not saying that. The GUI just works even with beta1 or with beta3. On Windows user's processes run with limited privileges even if the user is an "admin". At least that is the default because of UAC. > > Installation can be done when logged in as admin or as a limited user (provided you know admin credentials) as the installer prompts for elevation as required. > > That qualifier I added was because: the GUI running with privileges (admin) has been discouraged in 2.4 ever since we introduced the interactive service. And that continues with 2.5. It will work for some things and not for some other things. Same with running the GUI with interactive service disabled. As such uses are not supported, don't complain about it :) > > Selva <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Selva,<div><br></div><div>Please allow me to back up a moment and restate this:</div><div>1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. </div><div>2. I only used the GUI as installed, with no elevation, to start OpenVPN. </div><div>3. With TAP selected in my .ovpn config file, everything works normally. </div><div>4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. </div><div><br></div><div>Is 4. what you are saying is not supported? In our use, as we have done for the past decade, the client boxes are used for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file contains inline certificates) regardless if there is a user logged in or not as M2M monitoring occurs in the background. And if a user does login, most often it is with credentials that have admin privileges. I am trying to understand if what you’re telling me is that this will no longer work, or if we will need to do something different now? My testing used the GUI to see how things will work with wintun so we can continue testing. </div><div><br></div><div>Do I need to NOT use the GUI to get wintun to work? <br><br><div dir="ltr">Marvin </div><div dir="ltr"><br>On Sep 9, 2020, at 9:56 PM, Selva Nair <<a href="mailto:selva.nair@gmail.com">selva.nair@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 12:19 AM Marvin <<a href="mailto:volleynbike@gmail.com" target="_blank">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Selva,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The GUI did not have this error unless run as administrator which you should not and will never work. </blockquote><div>So you are saying that if OpenVPN is installed by a user who has admin privileges (as our case does) that v2.5 with wintun will not work?</div></div></blockquote><div><br></div><div>You mean OpenVPN started using the GUI? If so, no, I'm not saying that. The GUI just works even with beta1 or with beta3. On Windows user's processes run with limited privileges even if the user is an "admin". At least that is the default because of UAC. </div><div> </div><div>Installation can be done when logged in as admin or as a limited user (provided you know admin credentials) as the installer prompts for elevation as required. </div><div><br></div><div>That qualifier I added was because: the GUI running with privileges (admin) has been discouraged in 2.4 ever since we introduced the interactive service. And that continues with 2.5. It will work for some things and not for some other things. Same with running the GUI with interactive service disabled. As such uses are not supported, don't complain about it :)</div><div><br></div><div>Selva</div></div></div> </div></blockquote></div></body></html>
Hi, On Thu, Sep 10, 2020 at 12:10:25AM -0700, Marvin Adeff wrote: > Please allow me to back up a moment and restate this: As a matter of mailing list etiquette - could you please not post this with Subject: Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback I do try to figure out what is "patch related" and what is "new problems", and *this* is certainly not related to the NCP PATCH. > 1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. > 3. With TAP selected in my .ovpn config file, everything works normally. > 4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. Is the interactive service running? If tap is used, do you see "routes installed using service" or do you see netsh commands in the openvpn log? > Is 4. what you are saying is not supported? In our use, as we have done for the past decade, the client boxes are used for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file contains inline certificates) regardless if there is a user logged in or not as M2M monitoring occurs in the background. And if a user does login, most often it is with credentials that have admin privileges. I am trying to understand if what you???re telling me is that this will no longer work, or if we will need to do something different now? My testing used the GUI to see how things will work with wintun so we can continue testing. > > Do I need to NOT use the GUI to get wintun to work? Wintun needs SYSTEM privileges. To get such, you either need to run OpenVPN "at boot" via openvpnsrv2 (which has SYSTEM privileges), *or* you need to use the interactive service via the GUI. Due to some Vista-related quirks in the GUI, the GUI will not use the iservice if it's run elevated (run-as-admin). If I understand Selva right, it *should* work if you "just run it", even if the user has admin privs, as long as UAC is active (as Win10 runs user processes unprivileged, even if the user is part of the Admin group). The error message you have posted hints at "the interactive service is not being used" - which could be due to "it is not running" or "GUI is running elevated". gert
Hi Marvin, > 1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. > 3. With TAP selected in my .ovpn config file, everything works normally. > 4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. This doesn't look right. Could you provide a relevant part of a log file? For example, below is my recent connection log with beta3 and wintun: 2020-09-10 10:27:05 interactive service msg_channel=584 2020-09-10 10:27:05 ROUTE_GATEWAY 100.64.0.1/255.240.0.0 I=20 HWADDR=84:fd:d1:e8:1e:6c 2020-09-10 10:27:05 open_tun 2020-09-10 10:27:05 Ring buffers registered via service 2020-09-10 10:27:05 wintun device [OpenVPN Wintun] opened The first line means the openvpn-gui uses interactive service, which is used to open wintun device (which requires SYSTEM privileges) and setting up tun interface (which requires elevated privileges). Symptomes you mentioned are the same when GUI is run under elevated privileges and interactive service is not used, but it is impossible to say if this is the case without seeing logs.
Hi On Thu, Sep 10, 2020 at 3:10 AM Marvin Adeff <volleynbike@gmail.com> wrote: > Selva, > > Please allow me to back up a moment and restate this: > 1. I installed the beta3 msi from the web site logged in as a user that > has admin privileges. But no elevation was used to install it, just > double-click on the file. > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. > 3. With TAP selected in my .ovpn config file, everything works normally. > 4. I am reporting that (from the same login) if I change the .ovpn to use > wintun (all edits done through the GUI selection), it fails with the error > I showed below. > > Is 4. what you are saying is not supported? > This use case is fully supported and should work. If it's not working, as lev said, something is not right. Please share the full connection log with verb=4 and we may spot something. > In our use, as we have done for the past decade, the client boxes are used > for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file > contains inline certificates) regardless if there is a user logged in or > not as M2M monitoring occurs in the background. And if a user does login, > most often it is with credentials that have admin privileges. I am trying > to understand if what you’re telling me is that this will no longer work, > or if we will need to do something different now? My testing used the GUI > to see how things will work with wintun so we can continue testing. > > Do I need to NOT use the GUI to get wintun to work? > Connections started at boot using OpenVPNService will also work with wintun (2.5_beta3 and newer). You do not have to use the GUI. When an admin user logs in to Windows the elevated privileges in the token are disabled by default , so the user starting any process including OpenVPN-GUI will run in the *correct* unprivileged mode. Privileges are acquired only when/if a UAC prompt appears and the user consents to it, or when explicitly using run-as-admin. So, OpenVPN-GUi will run without enabling privileges for all users and that is the right way to run the GUI. So does a million other programs. This is the default behaviour of Windows since Vista and is a good thing. Selva <div dir="ltr"><div dir="ltr"><br></div>Hi<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 3:10 AM Marvin Adeff <<a href="mailto:volleynbike@gmail.com">volleynbike@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Selva,<div><br></div><div>Please allow me to back up a moment and restate this:</div><div>1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. </div><div>2. I only used the GUI as installed, with no elevation, to start OpenVPN. </div><div>3. With TAP selected in my .ovpn config file, everything works normally. </div><div>4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. </div><div><br></div><div>Is 4. what you are saying is not supported? </div></div></blockquote><div><br></div><div>This use case is fully supported and should work. If it's not working, as lev said, something is not right. Please share the full connection log with verb=4 and we may spot something.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>In our use, as we have done for the past decade, the client boxes are used for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file contains inline certificates) regardless if there is a user logged in or not as M2M monitoring occurs in the background. And if a user does login, most often it is with credentials that have admin privileges. I am trying to understand if what you’re telling me is that this will no longer work, or if we will need to do something different now? My testing used the GUI to see how things will work with wintun so we can continue testing. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div>Do I need to NOT use the GUI to get wintun to work? <br></div></div></blockquote><div><br></div><div>Connections started at boot using OpenVPNService will also work with wintun (2.5_beta3 and newer). You do not have to use the GUI.</div><div><br></div><div>When an admin user logs in to Windows the elevated privileges in the token are disabled by default , so the user starting any process including OpenVPN-GUI will run in the *correct* unprivileged mode. Privileges are acquired only when/if a UAC prompt appears and the user consents to it, or when explicitly using run-as-admin. So, OpenVPN-GUi will run without enabling privileges for all users and that is the right way to run the GUI. So does a million other programs. This is the default behaviour of Windows since Vista and is a good thing.</div><div><br></div><div>Selva</div></div></div></div>
To All 3, Thank you with your help I found the issue. UAC was disabled in the registry on this image. IIRC we had trouble updating some software by automated script and turning UAC off was required. After re-enabling UAC, wintun started normally. On Thu, Sep 10, 2020 at 12:33 AM Gert Doering <gert@greenie.muc.de> wrote: > Hi, > > On Thu, Sep 10, 2020 at 12:10:25AM -0700, Marvin Adeff wrote: > > Please allow me to back up a moment and restate this: > > As a matter of mailing list etiquette - could you please not post > this with > > Subject: Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback > > I do try to figure out what is "patch related" and what is "new problems", > and *this* is certainly not related to the NCP PATCH. > > > > 1. I installed the beta3 msi from the web site logged in as a user that > has admin privileges. But no elevation was used to install it, just > double-click on the file. > > 2. I only used the GUI as installed, with no elevation, to start > OpenVPN. > > 3. With TAP selected in my .ovpn config file, everything works > normally. > > 4. I am reporting that (from the same login) if I change the .ovpn to > use wintun (all edits done through the GUI selection), it fails with the > error I showed below. > > Is the interactive service running? > > If tap is used, do you see "routes installed using service" or do you > see netsh commands in the openvpn log? > > > Is 4. what you are saying is not supported? In our use, as we have done > for the past decade, the client boxes are used for M2M monitoring. OpenVPN > has to connect on bootup (.ovpn config file contains inline certificates) > regardless if there is a user logged in or not as M2M monitoring occurs in > the background. And if a user does login, most often it is with > credentials that have admin privileges. I am trying to understand if what > you???re telling me is that this will no longer work, or if we will need to > do something different now? My testing used the GUI to see how things will > work with wintun so we can continue testing. > > > > Do I need to NOT use the GUI to get wintun to work? > > Wintun needs SYSTEM privileges. > > To get such, you either need to run OpenVPN "at boot" via openvpnsrv2 > (which has SYSTEM privileges), *or* you need to use the interactive service > via the GUI. > > Due to some Vista-related quirks in the GUI, the GUI will not use the > iservice if it's run elevated (run-as-admin). If I understand Selva > right, it *should* work if you "just run it", even if the user has > admin privs, as long as UAC is active (as Win10 runs user processes > unprivileged, even if the user is part of the Admin group). > > > The error message you have posted hints at "the interactive service is > not being used" - which could be due to "it is not running" or "GUI is > running elevated". > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > gert@greenie.muc.de > <div dir="ltr">To All 3,<div>Thank you with your help I found the issue. UAC was disabled in the registry on this image. IIRC we had trouble updating some software by automated script and turning UAC off was required.</div><div><br></div><div>After re-enabling UAC, wintun started normally.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 10, 2020 at 12:33 AM Gert Doering <<a href="mailto:gert@greenie.muc.de">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Thu, Sep 10, 2020 at 12:10:25AM -0700, Marvin Adeff wrote:<br> > Please allow me to back up a moment and restate this:<br> <br> As a matter of mailing list etiquette - could you please not post<br> this with<br> <br> Subject: Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback<br> <br> I do try to figure out what is "patch related" and what is "new problems",<br> and *this* is certainly not related to the NCP PATCH.<br> <br> <br> > 1. I installed the beta3 msi from the web site logged in as a user that has admin privileges. But no elevation was used to install it, just double-click on the file. <br> > 2. I only used the GUI as installed, with no elevation, to start OpenVPN. <br> > 3. With TAP selected in my .ovpn config file, everything works normally. <br> > 4. I am reporting that (from the same login) if I change the .ovpn to use wintun (all edits done through the GUI selection), it fails with the error I showed below. <br> <br> Is the interactive service running?<br> <br> If tap is used, do you see "routes installed using service" or do you<br> see netsh commands in the openvpn log?<br> <br> > Is 4. what you are saying is not supported? In our use, as we have done for the past decade, the client boxes are used for M2M monitoring. OpenVPN has to connect on bootup (.ovpn config file contains inline certificates) regardless if there is a user logged in or not as M2M monitoring occurs in the background. And if a user does login, most often it is with credentials that have admin privileges. I am trying to understand if what you???re telling me is that this will no longer work, or if we will need to do something different now? My testing used the GUI to see how things will work with wintun so we can continue testing. <br> > <br> > Do I need to NOT use the GUI to get wintun to work? <br> <br> Wintun needs SYSTEM privileges.<br> <br> To get such, you either need to run OpenVPN "at boot" via openvpnsrv2<br> (which has SYSTEM privileges), *or* you need to use the interactive service<br> via the GUI.<br> <br> Due to some Vista-related quirks in the GUI, the GUI will not use the<br> iservice if it's run elevated (run-as-admin). If I understand Selva<br> right, it *should* work if you "just run it", even if the user has<br> admin privs, as long as UAC is active (as Win10 runs user processes<br> unprivileged, even if the user is part of the Admin group).<br> <br> <br> The error message you have posted hints at "the interactive service is<br> not being used" - which could be due to "it is not running" or "GUI is<br> running elevated".<br> <br> gert<br> -- <br> "If was one thing all people took for granted, was conviction that if you <br> feed honest figures into a computer, honest figures come out. Never doubted <br> it myself till I met a computer with a sense of humor."<br> Robert A. Heinlein, The Moon is a Harsh Mistress<br> <br> Gert Doering - Munich, Germany <a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a><br> </blockquote></div>
Hi, On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote: > To All 3, > Thank you with your help I found the issue. UAC was disabled in the > registry on this image. IIRC we had trouble updating some software by > automated script and turning UAC off was required. > > After re-enabling UAC, wintun started normally. Cool, thanks for digging into this and reporting back. Selva, is there any reasonable way to detect this? Or do we just go for "we always use the iservice if it is running, no matter what privs the GUI is running with"? gert
Hi, On Fri, Sep 11, 2020 at 1:58 AM Gert Doering <gert@greenie.muc.de> wrote: > Hi, > > On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote: > > To All 3, > > Thank you with your help I found the issue. UAC was disabled in the > > registry on this image. IIRC we had trouble updating some software by > > automated script and turning UAC off was required. > > > > After re-enabling UAC, wintun started normally. > > Cool, thanks for digging into this and reporting back. > > Selva, is there any reasonable way to detect this? Or do we just go > for "we always use the iservice if it is running, no matter what > privs the GUI is running with"? I think TokenElevationType will indicate whether using split token (UAC enabled) or not. Personally, I would like to show a warning when the GUI is started with privileges but some users may not like it. And we could make iservice a requirement for the GUI. The service is mature enough now and has become a necessity with wintun support. Although we don't have any reason not to connect to named pipes as admin in post-vista systems, the idea that the GUI should be run without elevated privileges appeals to me. Unless the user has taken deliberate steps to force running it as admin, it just works that way. Disabling UAC and then log in as admin for day to day work is like using root for browsing the web. That said, I won't object to a patch that removes the restriction when the runtime version is Win7 and newer. Selva <div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 1:58 AM Gert Doering <<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote:<br> > To All 3,<br> > Thank you with your help I found the issue. UAC was disabled in the<br> > registry on this image. IIRC we had trouble updating some software by<br> > automated script and turning UAC off was required.<br> > <br> > After re-enabling UAC, wintun started normally.<br> <br> Cool, thanks for digging into this and reporting back.<br> <br> Selva, is there any reasonable way to detect this? Or do we just go<br> for "we always use the iservice if it is running, no matter what <br> privs the GUI is running with"?</blockquote><div><br></div><div>I think TokenElevationType will indicate whether using split token (UAC enabled) or not.</div><div><br></div><div>Personally, I would like to show a warning when the GUI is started with privileges but some users may not like it. And we could make iservice a requirement for the GUI. The service is mature enough now and has become a necessity with wintun support.</div><div><br></div><div>Although we don't have any reason not to connect to named pipes as admin in post-vista systems, the idea that the GUI should be run without elevated privileges appeals to me. Unless the user has taken deliberate steps to force running it as admin, it just works that way. Disabling UAC and then log in as admin for day to day work is like using root for browsing the web. </div><div><br></div><div>That said, I won't object to a patch that removes the restriction when the runtime version is Win7 and newer.</div><div><br></div><div>Selva</div></div></div>
Hi Selva, I was wondering if it's possible to detect UAC during the installation. What do you think? BR Gava On Fri, Sep 11, 2020 at 1:48 PM Selva Nair <selva.nair@gmail.com> wrote: > Hi, > > On Fri, Sep 11, 2020 at 1:58 AM Gert Doering <gert@greenie.muc.de> wrote: > >> Hi, >> >> On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote: >> > To All 3, >> > Thank you with your help I found the issue. UAC was disabled in the >> > registry on this image. IIRC we had trouble updating some software by >> > automated script and turning UAC off was required. >> > >> > After re-enabling UAC, wintun started normally. >> >> Cool, thanks for digging into this and reporting back. >> >> Selva, is there any reasonable way to detect this? Or do we just go >> for "we always use the iservice if it is running, no matter what >> privs the GUI is running with"? > > > I think TokenElevationType will indicate whether using split token (UAC > enabled) or not. > > Personally, I would like to show a warning when the GUI is started with > privileges but some users may not like it. And we could make iservice a > requirement for the GUI. The service is mature enough now and has become a > necessity with wintun support. > > Although we don't have any reason not to connect to named pipes as admin > in post-vista systems, the idea that the GUI should be run without elevated > privileges appeals to me. Unless the user has taken deliberate steps to > force running it as admin, it just works that way. Disabling UAC and then > log in as admin for day to day work is like using root for browsing the > web. > > That said, I won't object to a patch that removes the restriction when the > runtime version is Win7 and newer. > > Selva > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > <div dir="ltr">Hi Selva, <div><br></div><div>I was wondering if it's possible to detect UAC during the installation. What do you think?</div><div><br></div><div>BR</div><div><br></div><div>Gava</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 1:48 PM Selva Nair <<a href="mailto:selva.nair@gmail.com">selva.nair@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 1:58 AM Gert Doering <<a href="mailto:gert@greenie.muc.de" target="_blank">gert@greenie.muc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> On Thu, Sep 10, 2020 at 06:10:17PM -0700, Marvin wrote:<br> > To All 3,<br> > Thank you with your help I found the issue. UAC was disabled in the<br> > registry on this image. IIRC we had trouble updating some software by<br> > automated script and turning UAC off was required.<br> > <br> > After re-enabling UAC, wintun started normally.<br> <br> Cool, thanks for digging into this and reporting back.<br> <br> Selva, is there any reasonable way to detect this? Or do we just go<br> for "we always use the iservice if it is running, no matter what <br> privs the GUI is running with"?</blockquote><div><br></div><div>I think TokenElevationType will indicate whether using split token (UAC enabled) or not.</div><div><br></div><div>Personally, I would like to show a warning when the GUI is started with privileges but some users may not like it. And we could make iservice a requirement for the GUI. The service is mature enough now and has become a necessity with wintun support.</div><div><br></div><div>Although we don't have any reason not to connect to named pipes as admin in post-vista systems, the idea that the GUI should be run without elevated privileges appeals to me. Unless the user has taken deliberate steps to force running it as admin, it just works that way. Disabling UAC and then log in as admin for day to day work is like using root for browsing the web. </div><div><br></div><div>That said, I won't object to a patch that removes the restriction when the runtime version is Win7 and newer.</div><div><br></div><div>Selva</div></div></div> _______________________________________________<br> Openvpn-devel mailing list<br> <a href="mailto:Openvpn-devel@lists.sourceforge.net" target="_blank">Openvpn-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/openvpn-devel" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/openvpn-devel</a><br> </blockquote></div>
Hi On Fri, Sep 11, 2020 at 1:45 PM RafaeHil Gava <gava100@gmail.com> wrote: > Hi Selva, > > I was wondering if it's possible to detect UAC during the installation. > What do you think? > There are many ways of running the GUI as admin and all involve some deliberate action on the part of the user. The best we can do is to warn them that the GUI is running as admin and its not recommended. That will also cover the initial launch of GUI on install with UAC disabled or from an elevated cmdline. Disabling UAC can be legit too if the admin knows what they are doing -- like, all users have limited privileges and admins login only to do tasks requiring elevation etc. Selva <div dir="ltr"><div>Hi</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 1:45 PM RafaeHil Gava <<a href="mailto:gava100@gmail.com">gava100@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Selva, <div><br></div><div>I was wondering if it's possible to detect UAC during the installation. What do you think?</div></div></blockquote><div><br></div><div>There are many ways of running the GUI as admin and all involve some deliberate action on the part of the user. The best we can do is to warn them that the GUI is running as admin and its not recommended. That will also cover the initial launch of GUI on install with UAC disabled or from an elevated cmdline.</div><div><br></div><div>Disabling UAC can be legit too if the admin knows what they are doing -- like, all users have limited privileges and admins login only to do tasks requiring elevation etc.</div><div><br></div><div>Selva</div></div></div>
diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c index f522b8f0..c9ab85ce 100644 --- a/src/openvpn/ssl_ncp.c +++ b/src/openvpn/ssl_ncp.c @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int found) } /* If the server did not push a --cipher, we will switch to the * remote cipher if it is in our ncp-ciphers list */ - bool useremotecipher = tls_poor_mans_ncp(&c->options, - c->c2.tls_multi->remote_ciphername); - + if(tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername)) + { + return true; + } /* We could not figure out the peer's cipher but we have fallback * enabled */ - if (!useremotecipher && c->options.enable_ncp_fallback) + if (!c->c2.tls_multi->remote_ciphername && c->options.enable_ncp_fallback) { return true; }
OpenVPN 2.5 clients do not correctly do a fallback to the server server. This commit fixes that logic and also fixes --data-ciphers-fallback to be used in situations other than no OCC cipher. To reproduce the error use a client with only --data-ciphers set against a server without NCP. OPTIONS ERROR: failed to negotiate cipher with server. Add the server's cipher ('AES-256-CBC') to --data-ciphers (currently 'AES-256-CBC') if you want to connect to this server. Reported by: Richard Bonhomme <tincanteksup@gmail.com> Signed-off-by: Arne Schwabe <arne@rfc2549.org> --- src/openvpn/ssl_ncp.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)