Hi,
On Mon, Jul 13, 2020 at 06:08:04PM +0200, Arne Schwabe wrote:
> >> The V2 API is simpler than the V1 API since there is no passing of
> >> data via files. This also means that with the current API the V2 API
> >> cannot support async notify via files. Adding a file just for async
> >> notify
Thank you I will try this.
Marvin
Sent from my iPhone
> On Jul 13, 2020, at 7:34 AM, Gert Doering wrote:
>
> Hi,
>
>> On Mon, Jul 13, 2020 at 07:23:59AM -0700, Marvin Adeff wrote:
>> I???m wondering if the opposite of this scenario has been tested, where the
>> server is running 2.3.18
Am 13.07.20 um 17:40 schrieb Gert Doering:
> Hi,
>
> On Sat, Jul 11, 2020 at 11:36:54AM +0200, Arne Schwabe wrote:
>> The V2 API is simpler than the V1 API since there is no passing of
>> data via files. This also means that with the current API the V2 API
>> cannot support async notify via
13.07.2020 18:23, Marvin Adeff пишет:
I’m wondering if the opposite of this scenario has been tested, where the
server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries
to connect?
No, I did not tried this, because we run 2.4.9 on servers now.
I know, I know, we
Hi,
On Sat, Jul 11, 2020 at 11:36:54AM +0200, Arne Schwabe wrote:
> The V2 API is simpler than the V1 API since there is no passing of
> data via files. This also means that with the current API the V2 API
> cannot support async notify via files. Adding a file just for async
> notify seems very
Hi,
On Sat, Jul 11, 2020 at 11:36:53AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> Uses the infrastructure provided and used in the previous patch to provide
> deferral support to the v1 client-connect plugin handler as well.
>
> Signed-off-by: Fabian Knittel
>
> PATCH V3: Modify
Hi,
On Sat, Jul 11, 2020 at 11:36:49AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> This patch moves the state, that was previously tracked within the
> multi_connection_established() function, into struct client_connect_state.
> The
> multi_connection_established() function can now
Am 13.07.20 um 16:23 schrieb Marvin Adeff:
> I’m wondering if the opposite of this scenario has been tested, where the
> server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows)
> tries to connect?
>
> I know, I know, we should upgrade. Unfortunately in this case OpenVPN
Hi,
On Mon, Jul 13, 2020 at 07:23:59AM -0700, Marvin Adeff wrote:
> I???m wondering if the opposite of this scenario has been tested, where the
> server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows)
> tries to connect?
It should work, but this is a "should". It's hard
I’m wondering if the opposite of this scenario has been tested, where the
server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries
to connect?
I know, I know, we should upgrade. Unfortunately in this case OpenVPN server
is running on an appliance that cannot be upgraded
Hi,
On Sat, Jul 11, 2020 at 11:36:48AM +0200, Arne Schwabe wrote:
> This deviates from Fabian's original patch that relied on the now
> removed connection_established bool as pointer being NULL or non NULL as
> implicit third state and makeing connection_established as a substate of
>
Because this is documentation I have been a little harder on grammar.
These are only suggestions to improve readability.
On 11/07/2020 10:36, Arne Schwabe wrote:
Patch V5: Fix typos, clarify man page section about deferred client-connect
script. Add section to Changes.rst
2x gram
On 11/07/2020 10:36, Arne Schwabe wrote:
From: Fabian Knittel
Uses the infrastructure provided and used in the previous patch to provide
deferral support to the v1 client-connect plugin handler as well.
Signed-off-by: Fabian Knittel
PATCH V3: Modify the API to also (optionally)
Hi,
On Sat, Jul 11, 2020 at 11:36:47AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> This patch changes the calling of the client-connect functions into an array
> of hooks and a block of code that calls them in a loop.
>
> Signed-off-by: Fabian Knittel
> Signed-off-by: Arne Schwabe
On 11/07/2020 10:36, Arne Schwabe wrote:
This make the code a bit better readable and also prepares resuing
resuing -> reusing
(Don't ask me why this is not re-using, which is how I would probably
spell it and my teacher would laugh at me)
Grammar:
This make the code more readable
the
5x typo 2x gram
On 11/07/2020 10:36, Arne Schwabe wrote:
From: Fabian Knittel
This patch introduces the concept of a return value file for the client-connect
handlers. (This is very similar to the auth value file used during deferred
authentication.) The file name is stored in the
1x typo + 1x gram (in comments)
On 11/07/2020 10:36, Arne Schwabe wrote:
From: Fabian Knittel
This patch moves the state, that was previously tracked within the
multi_connection_established() function, into struct client_connect_state. The
multi_connection_established() function can now be
1x grammar
On 11/07/2020 10:36, Arne Schwabe wrote:
From: Fabian Knittel
Refactor multi_client_connect_source_ccd(), so that options_server_import() (or
the success path in general) is only entered in one place within the function.
Signed-off-by: Fabian Knittel
Patch V5: Simplify the logic
spelling, 1x grammer:
On 11/07/2020 10:36, Arne Schwabe wrote:
From: Fabian Knittel
This patch splits up the multi_connection_established() function. Each new
helper function does a specific job. Functions that do a similar job receive a
similar calling interface.
The patch tries not to
Hi,
On Mon, Jul 13, 2020 at 01:30:11PM +0100, tincanteksup wrote:
> grammar:
>
> On 11/07/2020 10:36, Arne Schwabe wrote:
> > This allows to control the fallback cipher that is used when the
> > client/server do have any common cipher on a per client basis.
>
> client/server do not have any
Hi,
On Sat, Jul 11, 2020 at 11:36:46AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> This patch changes the way the client-connect helper functions communicate
> with
> the main function. Instead of updating cc_succeeded and cc_succeeded_count,
> they now return either
grammar:
On 11/07/2020 10:36, Arne Schwabe wrote:
This allows to control the fallback cipher that is used when the
client/server do have any common cipher on a per client basis.
client/server do not have any common cipher
The patch is similar to Steffan's
[PATCH v4] Allow changing cipher
1x typo
On 11/07/2020 10:36, Arne Schwabe wrote:
This deviates from Fabian's original patch that relied on the now
removed connection_established bool as pointer being NULL or non NULL as
implicit third state and makeing connection_established as a substate of
makeing -> making
Hi,
On 13/07/2020 13:29, Gert Doering wrote:
> instead, maybe this?
>
>> +const char *ccd_client =
>> + platform_gen_path(mi->context.options.client_config_dir,
>> + tls_common_name(mi->context.c2.tls_multi,
>> +
On Sat, Jul 11, 2020 at 11:36:45AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> This patch moves multi_client_connect_setenv into
> multi_client_connect_early_setup and makes sure that every client-connect
> handling function updates the virtual address selection.
>
> Background: This
Hi,
On Sat, Jul 11, 2020 at 11:36:44AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> Refactor multi_client_connect_source_ccd(), so that options_server_import()
> (or
> the success path in general) is only entered in one place within the function.
>
> Signed-off-by: Fabian Knittel
Hi,
On Sat, Jul 11, 2020 at 11:36:43AM +0200, Arne Schwabe wrote:
> From: Fabian Knittel
>
> This patch splits up the multi_connection_established() function. Each new
> helper function does a specific job. Functions that do a similar job receive
> a
> similar calling interface.
Tested on
Patch has been applied to the master branch.
The whitespace dragon spotted a "== NULL )" mishap, which was dutifully
corrected.
commit b15fcceb1dd8b4fc2bf89deff94832f2654c3ac3
Author: Gert Doering
Date: Mon Jul 13 11:32:52 2020 +0200
Handle connecting clients without NCP or OCC without
By default OpenSSL 1.1+ only allows signatures and ecdh/ecdhx from the
default list of X25519:secp256r1:X448:secp521r1:secp384r1. In
TLS1.3 key exchange is independent from the signature/key of the
certificates, so allowing all groups per default is not a sensible
choice anymore and instead a
Signed-off-by: Arne Schwabe
---
doc/doxygen/doc_control_processor.h | 6 +-
doc/doxygen/doc_key_generation.h| 6 +-
doc/doxygen/doc_protocol_overview.h | 2 +-
src/openvpn/forward.c | 2 +-
src/openvpn/helper.c| 5 -
src/openvpn/init.c
OpenSSL 1.0.1 was supported until 2016-12-31. Rhel6/Centos6 still
use this version but considering that RHEL7 and RHEL8 are already
out, these versions can also stay with OpenVPN 2.4.
All the supported Debian based distributions also come with at
least 1.0.2
This also allows the tls groups
This allows us to skip waiting for the first PUSH_REQUEST message from
the client to send the response.
Signed-off-by: Arne Schwabe
---
src/openvpn/multi.c | 12 ++--
src/openvpn/ssl.c | 15 +--
src/openvpn/ssl.h | 7 +++
3 files changed, 30 insertions(+), 4
Am 13.07.20 um 11:32 schrieb Gert Doering:
> ssl_ncp.c:ncp_get_best_cipher() would crash if a client connects without
> NCP (or with a NCP cipher list that does not contain the first NCP cipher
> in the server list) due to a NULL pointer strcmp().
>
> Work around / fix by just assigning an empty
ssl_ncp.c:ncp_get_best_cipher() would crash if a client connects without
NCP (or with a NCP cipher list that does not contain the first NCP cipher
in the server list) due to a NULL pointer strcmp().
Work around / fix by just assigning an empty string to remote_cipher here
("not NULL but will
Am 13.07.20 um 08:58 schrieb Gert Doering:
> Hi,
>
> On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
>> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
>>> Ouch. This is not good. My gut feeling is "2.3 with --enable-small =
>>> no OCC *and* no NCP = the server runs
Hi,
On Mon, Jul 13, 2020 at 11:12:30AM +0400, Dmitry Melekhov wrote:
> I just applied patch, now server works correctly with 2.3.18 client
> compiled with enable-small
>
> and with 2.5git with enable-small and ncp-disable in config.
>
> I.e. everything works as expected.
Thanks for testing
13.07.2020 10:58, Gert Doering пишет:
Hi,
On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
Ouch. This is not good. My gut feeling is "2.3 with --enable-small =
no OCC *and* no NCP = the server runs across a NULL
Hi,
On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
> > Ouch. This is not good. My gut feeling is "2.3 with --enable-small =
> > no OCC *and* no NCP = the server runs across a NULL pointer here".
>
> Bäm. Fully
Hi,
On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
> Ouch. This is not good. My gut feeling is "2.3 with --enable-small =
> no OCC *and* no NCP = the server runs across a NULL pointer here".
Bäm. Fully reproduceable here
Program received signal SIGSEGV, Segmentation fault.
Hi,
On Mon, Jul 13, 2020 at 10:07:38AM +0400, dm wrote:
> Forgot to add info from server console, last messages are:
>
> 2020-07-13 10:04:41 us=435946 10.1.1.17:53148 WARNING: 'version' is used
> inconsistently, local='version V4', remote='version V0 UNDEF'
> 2020-07-13 10:04:41 us=435976
Hi,
On Mon, Jul 13, 2020 at 09:36:45AM +0400, Dmitry Melekhov wrote:
> Then I compiled openvpn-2.3.18 on Centos 6.
>
> It connects if it is compiled by just using configure.
>
> But if I compile 2.3.18 with enable-small, then 2.5 server dies, always,
> even if there is no cipher in ccd and
13.07.2020 09:36, Dmitry Melekhov пишет:
12.07.2020 04:05, Arne Schwabe пишет:
Am 23.06.20 um 11:12 schrieb Dmitry Melekhov:
23.06.2020 13:02, Gert Doering пишет:
That patch is from Steffan, and review has been sitting in my lap for
way too long. Need to see if it still applies.
42 matches
Mail list logo
