Re: [Openvpn-devel] deferred client-connect - https://patchwork.openvpn.net/patch/607/

2020-05-15 Thread Gert Doering
Hi, On Fri, May 15, 2020 at 12:40:08PM -0700, Shreyas Heranjal wrote: > > I want to use client-connect plugin to assign IP addresses to the clients, > > and I want to do it asynchronously through my IPAM service. I was going > > through the openvpn-devel forum and found this patch. > > https://pat

Re: [Openvpn-devel] deferred client-connect - https://patchwork.openvpn.net/patch/607/

2020-05-15 Thread Shreyas Heranjal
> > Hi, > > I want to use client-connect plugin to assign IP addresses to the clients, > and I want to do it asynchronously through my IPAM service. I was going > through the openvpn-devel forum and found this patch. > https://patchwork.openvpn.net/patch/607/ > > Is this patch safe to use? Any reas

Re: [Openvpn-devel] [PATCH v2 5/5] Implement forwarding client CR_RESPONSE messages to management

2020-05-15 Thread David Sommerseth
On 09/11/2019 16:13, Arne Schwabe wrote: > When signalling the client that it should do Challenge response > without reconnecting (IV_SSO=crtext/INFOPRE=CR_TEXT), the server > needs forward the response via the management console. > > Signed-off-by: Arne Schwabe > --- > doc/management-notes.txt

[Openvpn-devel] [PATCH applied] Re: Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-05-15 Thread Gert Doering
Your patch has been applied to the master branch. Lightly tested on my side ("make check" with OpenSSL and mbedTLS builds). commit 14a57be4609fc23e4775072948bf722f21f25099 Author: Arne Schwabe Date: Thu May 7 15:25:34 2020 +0200 Do not write extra 0 byte for --gen-key with auth-token/tls-

Re: [Openvpn-devel] [PATCH v2 4/5] Implement sending SSO challenge to clients

2020-05-15 Thread Jan Just Keijser
On 15/05/20 17:40, David Sommerseth wrote: On 15/05/2020 17:36, David Sommerseth wrote: On 09/11/2019 16:13, Arne Schwabe wrote: This implements sending AUTH_PENDING and INFO_PRE messages to clients that indicate that the clients should be continue authentication with a second factor. This can

Re: [Openvpn-devel] [PATCH v2 4/5] Implement sending SSO challenge to clients

2020-05-15 Thread David Sommerseth
On 15/05/2020 17:36, David Sommerseth wrote: > On 09/11/2019 16:13, Arne Schwabe wrote: >> This implements sending AUTH_PENDING and INFO_PRE messages to clients >> that indicate that the clients should be continue authentication with >> a second factor. This can currently be out of band (openurl) o

Re: [Openvpn-devel] [PATCH v2 4/5] Implement sending SSO challenge to clients

2020-05-15 Thread David Sommerseth
On 09/11/2019 16:13, Arne Schwabe wrote: > This implements sending AUTH_PENDING and INFO_PRE messages to clients > that indicate that the clients should be continue authentication with > a second factor. This can currently be out of band (openurl) or a normal > challenge/response 2FA like TOTP (CR_

Re: [Openvpn-devel] [PATCH v2 3/5] Implement sending response to challenge via CR_RESPONSE

2020-05-15 Thread David Sommerseth
Hi, So I'm giving this one another look again. I started now by trying to use this feature manually, to see that each step works as expected. But this time I also discovered a few other details. On 09/11/2019 16:13, Arne Schwabe wrote: > When a client announces its support to support text bas

[Openvpn-devel] [PATCH v2] Allow repeated cycles through remotes when management-query-remote is in use

2020-05-15 Thread selva . nair
From: Selva Nair (i) Let the management-client predictably cycle through remote entries. This is done by not aborting after two cycles. The client can abort or restart the connection using signals (USR/HUP/TERM) as necessary. In the current behaviour, the daemon can unexpectedly exit when the

Re: [Openvpn-devel] [PATCH v4] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-05-15 Thread Steffan Karger
Hi, On 07-05-2020 15:25, Arne Schwabe wrote: > Change crypto_pem_encode to not put a nul-terminated terminated > string into the buffer. This was useful for printf but should > not be written into the file. > > Instead do not assume that the buffer is null terminated and > print only the number