Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi On Thu, Sep 10, 2020 at 3:10 AM Marvin Adeff 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 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 wrote: > > Hi, > >> On Thu, Sep 10, 2020 at 12:19 AM Marvin 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 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi, On Thu, Sep 10, 2020 at 12:19 AM Marvin 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 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi On Wed, Sep 9, 2020 at 8:30 PM Marvin 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 wrote: > >> Hi Marvin, >> >> This is the wrong thread, but... >> >> On Wed, Sep 9, 2020 at 7:54 PM Marvin 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 >> >> ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 wrote: > Hi Marvin, > > This is the wrong thread, but... > > On Wed, Sep 9, 2020 at 7:54 PM Marvin 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 > > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
Hi Marvin, This is the wrong thread, but... On Wed, Sep 9, 2020 at 7:54 PM Marvin 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 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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 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 >> g...@greenie.muc.de >> > ___ > 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
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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 > g...@greenie.muc.de > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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 > g...@greenie.muc.de > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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 > g...@greenie.muc.de > ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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
signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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
--
"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 g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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 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
> >>
> >> Signed-off-by: Arne Schwabe
> >> ---
> >> 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(>options,
> >> -
> >> c->c2.tls_multi->remote_ciphername);
> >> -
> >> +if(tls_poor_mans_ncp(>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
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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
> g...@greenie.muc.de
>
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
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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
--
"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 g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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
Signed-off-by: Arne Schwabe
---
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(>options,
-
c->c2.tls_multi->remote_ciphername);
-
+if(tls_poor_mans_ncp(>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
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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 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
>
> Signed-off-by: Arne Schwabe
> ---
> 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(>options,
> -
> c->c2.tls_multi->remote_ciphername);
> -
> +if(tls_poor_mans_ncp(>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
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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
Tested-by: Richard Bonhomme
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
Signed-off-by: Arne Schwabe
---
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(>options,
-
c->c2.tls_multi->remote_ciphername);
-
+ if(tls_poor_mans_ncp(>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-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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
>
> Signed-off-by: Arne Schwabe
> ---
> 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(>options,
> -
> c->c2.tls_multi->remote_ciphername);
> -
> +if(tls_poor_mans_ncp(>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
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback
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
Tested-by: Richard Bonhomme
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
Signed-off-by: Arne Schwabe
---
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(>options,
-
c->c2.tls_multi->remote_ciphername);
-
+if(tls_poor_mans_ncp(>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-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
