Re: [Openvpn-devel] [PATCH v4] Improve "recursive routing" warning message

[tincanteksup]

On 26/03/2021 01:09, tincanteksup wrote:

Hi,

On 25/03/2021 23:26, Antonio Quartulli wrote:

Hi,

On 30/10/2018 13:53, Lev Stipakov wrote:

From: Lev Stipakov 

+
+    msg(D_LOW, "Recursive routing detected, drop packet %s. Fix 
your routing or consider using --allow-recursive-routing option.", 
BSTR(_buf));


I would add "if you know what you are doing", otherwisethe average Joe
will think that he can just add "--allow-recursive-routing" to his
config and the problem is fixed.



"If you know what you are doing" is no help
because they all "_know what they are doing_" ...

My understanding is as follows:

Recursive-routing means that I send encrypted packets, which are
destined for the public IP of the peer address, over the tunnel.
Instead of over the internet (or other common network).

Considering the loops which the receiver will have to jump
though to accept these packets, I question the validity of
documenting this "feature" --allow-recursive-routing, at all.



Perhaps this would be better suited as:
./configure --enable-recursive-routing
make


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Improve "recursive routing" warning message

[tincanteksup]

Hi,

On 25/03/2021 23:26, Antonio Quartulli wrote:

Hi,

On 30/10/2018 13:53, Lev Stipakov wrote:

From: Lev Stipakov 

+
+msg(D_LOW, "Recursive routing detected, drop packet %s. Fix your routing or 
consider using --allow-recursive-routing option.", BSTR(_buf));


I would add "if you know what you are doing", otherwisethe average Joe
will think that he can just add "--allow-recursive-routing" to his
config and the problem is fixed.



"If you know what you are doing" is no help
because they all "_know what they are doing_" ...

My understanding is as follows:

Recursive-routing means that I send encrypted packets, which are
destined for the public IP of the peer address, over the tunnel.
Instead of over the internet (or other common network).

Considering the loops which the receiver will have to jump
though to accept these packets, I question the validity of
documenting this "feature" --allow-recursive-routing, at all.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Always disable SSL renegotiations

[tincanteksup]

Hi,

On 25/03/2021 23:15, Antonio Quartulli wrote:

Hi,

On 25/03/2021 18:44, Arne Schwabe wrote:

These have been troublesome in the past and also today's CVE-2021-3449
DOS is only exploitable if renegotiation is enabled.

Signed-off-by: Arne Schwabe 


What is the practical effect of this change?
With the current code (before this patch) when would OpenSSL/mbedTLS
start a renegotiation on its own?

May it have had any impact on the OpenVPN protocol until now?


Cheers,



---
  src/openvpn/ssl_mbedtls.c | 3 +++
  src/openvpn/ssl_openssl.c | 3 +++
  2 files changed, 6 insertions(+)

diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index 4626e9838..1628a02e3 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -1086,6 +1086,9 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
  {
  mbedtls_ssl_conf_curves(ks_ssl->ssl_config, ssl_ctx->groups);
  }
+/* Disable renegotiations. OpenVPN has its own mechanism to create whole
+ * new SSL session. And these have been problematic in the past */


This comment reads like so:

Disable "unspecified" renegotiations.
OpenVPN has "specific" renegotiation mechanism(s), which have been 
problematic in the past.




+mbedtls_ssl_conf_renegotiation(ks_ssl->ssl_config, 
MBEDTLS_SSL_RENEGOTIATION_DISABLED);
  
  /* Disable record splitting (for now).  OpenVPN assumes records are sent

   * unfragmented, and changing that will require thorough review and
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index d161f48b8..a11ca5b97 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -320,6 +320,9 @@ tls_ctx_set_options(struct tls_root_ctx *ctx, unsigned int 
ssl_flags)
  sslopt |= SSL_OP_CIPHER_SERVER_PREFERENCE;
  #endif
  sslopt |= SSL_OP_NO_COMPRESSION;
+/* Disable renegotiations. OpenVPN has its own mechanism to create whole
+ * new SSL session. And these have been probelmatic in the past */
+sslopt |= SSL_OP_NO_RENEGOTIATION;
  
  SSL_CTX_set_options(ctx->ctx, sslopt);
  






___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/2] Deprecate non TLS mode in OpenVPN

[tincanteksup]

Hi,

On 25/03/2021 07:59, Antonio Quartulli wrote:

Hi,

On 25/03/2021 08:49, Antonio Quartulli wrote:

That change (that was *Actually* made in 2.4) was exactly to remove this
ambiguity.


Forgive my hasty reply. This combination of option is actually
not-supported since 2.5 (in 2.4 we probably only introduced the
deprecation warning).


I think I know what you mean.

Deprecating `--secret` to be `--genkey secret` is on the wiki.
But the change *has* been made in 2.5 not pending for 2.7

Deprecating non-TLS mode VPNs is not on the wiki.

Deprecate non-TLS mode in 2.5
To be removed in 2.7
Replaced by peer-fingerprint option.

If that is correct then I can add "non-TLS mode" to the wiki.
Clear up the mess^D^D^D^D ambiguity ..

How does that sound ?
R


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/2] Deprecate non TLS mode in OpenVPN

[tincanteksup]

I made this change to the wiki:
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?action=diff=45


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Implement '--compress migrate' to migrate to non-compression setup

[tincanteksup]

I found a typo, so I double checked every comment.

On 24/03/2021 22:08, Arne Schwabe wrote:




diff --git a/src/openvpn/ssl_util.h b/src/openvpn/ssl_util.h
index 741a7782..472aa591 100644
--- a/src/openvpn/ssl_util.h
+++ b/src/openvpn/ssl_util.h
@@ -54,4 +54,19 @@ extract_var_peer_info(const char *peer_info,
   */
  unsigned int
  extract_iv_proto(const char *peer_info);
+
+/**
+ * Takes a locally produced OCC string for TLS server mode and modifies as
+ * if the option comp-lzo was enabled. This is to send a client in
+ * comp-lzo migrate mode the expected OCC string.
+ *
+ * Note: This function excpets the string to be in the locally generated


typo: excpets


+ * format and does not accept arbitrary strings.
+ *
+ * @param options   the locally generated OCC string
+ * @param gcgc_arena to allocate the returned string in
+ * @return  the modified string or options on error
+ */
+const char *
+options_string_compat_lzo(const char *options, struct gc_arena *gc);
  #endif
diff --git a/tests/unit_tests/openvpn/Makefile.am 
b/tests/unit_tests/openvpn/Makefile.am
index 50f3a02e..44b77cc5 100644
--- a/tests/unit_tests/openvpn/Makefile.am
+++ b/tests/unit_tests/openvpn/Makefile.am




--


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Do not print Diffy Hellman parameters file to log file

[tincanteksup]

How embarrassing ..

On 18/03/2021 07:12, Gert Doering wrote:

Your patch has been applied to the master and release/2.5 branch.

I've corrected the spelling of "Diffy" to "Diffie", according to

   https://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

I have not tested this further than "it compiles".

commit 4170da0778b926cea748c319163fdcfc7c6bc445 (master)
commit c8a72bbfbf16fa87c18c2e92c467587833b611e9 (release/2.5)
Author: Richard Bonhomme
Date:   Wed Mar 17 22:34:48 2021 +

  Do not print Diffy Hellman parameters file to log file

  Signed-off-by: Richard Bonhomme 
  Acked-by: Antonio Quartulli 
  Message-Id: <20210317223448.1278818-1-tincantek...@gmail.com>
  URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21688.html
  Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Indicate correct PUSH status in log

[tincanteksup]

Hi,

This:

2021-03-16 23:11:15 us=420944 w-c01/10.10.201.226:53237 SENT CONTROL 
[w-c01]: 'P
USH_REPLY,comp-lzo no,explicit-exit-notify 2,route 10.33.70.1,topology 
net30,pin
g 10,ping-restart 60,ifconfig 10.33.70.6 10.33.70.5,peer-id 0,cipher 
AES-256-GCM

' (status=1)
2021-03-16 23:11:15 us=453465 w-c01/10.10.201.226:53237 PUSH: Received 
control m

essage: 'PUSH_REQUEST'

is likely to cause some confusion..

It may be worth having the client confirm receiving the PUSH,
in the server log.

Or the server indicate an initial unrequested PUSH, technically
this is not a PUSH_REPLY.

So that the log looks relatively logical.

Food for thought..
R



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Require at least 20MB of mlock()-able memory if --mlock is used.

[tincanteksup]

On 09/03/2021 20:53, David Sommerseth wrote:

On 09/03/2021 21:04, tincanteksup wrote:
 >

I have swapping issues all the time and I can't add more RAM.
I don't want system wide disk encryption.
And I don't want an SSD either.

I do not have the money to keep up with modern hardware.

Having openvpn --mlock is exactly the right choice for my home
system.

Please, do not remove --mlock from openvpn.



How much memory does your OpenVPN process consume?  And if the process 
(or task in kernel lingo) is active (not idling), it generally will not 
be swapped out.  If it does, you are already running way to much on your 
host.  So you need to prioritize what that host should really run.


OpenVPN's --mlock does not save you.

And in fact, the kernel may as well swap out the memory pages containing 
the program itself and just keep the data pages allocated by the program 
in memory.  Which will result in a sluggish OpenVPN performance regardless.


This gives a brief overview which might help you see what happens:
<https://scoutapm.com/blog/understanding-page-faults-and-memory-swap-in-outs-when-should-you-worry> 



And even though you don't want SSD.  At least consider if you can get 
hold of a reasonably performing SSD with not too many GB and activate 
that device as a swap device on your host.  It will not be optimal, but 
at least the general swapping can go faster if you have a decent 
SATA/SAS controller.


 > Please try to put yourselves in the place of the average user,
 > for once.

The average users I know does not push their hardware beyond its limits 
so much it hurts the overall performance.  Those I know would start 
planning for an upgrade.  Or get an RPi4 and run OpenVPN on it, as it 
got a reasonable network performance: 
<https://notenoughtech.com/raspberry-pi/2019-raspberry-pi-network-speed-test/> 



But openvpn --mlock is never the solution to performance and swapping. 
Never ever.





As I Initially clarified, there *may* be a Small performance tweak by 
using --mlock.


The problem here is that by removing --mlock you shift the
burden of securing ephemeral key data to the under lying OS.

You may as well print the full private keys in the log (again)
and expect the user to delete them all and shred their disk.

As for how I must spend my money, that is no business of yours.

my2c


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Require at least 20MB of mlock()-able memory if --mlock is used.

[tincanteksup]

On 09/03/2021 18:52, David Sommerseth wrote:

On 08/03/2021 14:45, tincanteksup wrote:



On 08/03/2021 08:06, Arne Schwabe wrote:


Looking at this feature  from today's perspective, it feels like one of
OpenVPN's boutique features. Was probably useful at some point but
doesn't really make much sense today anymore. Esepcially with what is
written in the manpage. Today you rather would use full disk encryption
or disable swapping rather than to rely on OpenVPN's --mlock.

That being said I am against your patch, I am just wondering if that is
a feature we need to keep at all.



Having all openvpn data remain permanently in memory also offers
a (small) performance boost.

Your alternative offers would impact performance and be system wide.

Therefore, I for one disagree.


mlock() itself does not really have any impact your these arguments.

Yes, mlock() is about ensuring that OpenVPN can allocate a certain 
amount of memory which will stay entirely in RSS the memory pool as long 
as the memory pages has been locked.  But it is not a system wide knob; 
it's a per process knob and applications can even turn this on and off 
at will (given they have the needed privileges for it) during the 
lifetime of the process.


Due to this flexibility to when you can enable and disable memory 
locking, it is also clear it is not intended to be used as a performance 
knob.  It is designed to be more a security related feature, which in 
OpenVPN's context is there to avoid getting memory containing keying 
material being swapped out to disk.


On today's hardware even telling the kernel to not swap out a few 
hundred megabytes will also not result in much noticeable performance 
improvements.  To feel the difference, you would need to have some 
really ancient hardware.


If you care or have issues with performance related to swapping, you 
need to revisit your swap setup - or add more RAM.  A few hundred 
megabyte related to OpenVPN will not make things better or worse system 
wide on your system.  Fixing the real reason you have swapping issues will.





I have swapping issues all the time and I can't add more RAM.
I don't want system wide disk encryption.
And I don't want an SSD either.

I do not have the money to keep up with modern hardware.

Having openvpn --mlock is exactly the right choice for my home
system.

Please, do not remove --mlock from openvpn.

Please try to put yourselves in the place of the average user,
for once.

R


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Require at least 20MB of mlock()-able memory if --mlock is used.

[tincanteksup]

On 08/03/2021 08:06, Arne Schwabe wrote:


Looking at this feature  from today's perspective, it feels like one of
OpenVPN's boutique features. Was probably useful at some point but
doesn't really make much sense today anymore. Esepcially with what is
written in the manpage. Today you rather would use full disk encryption
or disable swapping rather than to rely on OpenVPN's --mlock.

That being said I am against your patch, I am just wondering if that is
a feature we need to keep at all.



Having all openvpn data remain permanently in memory also offers
a (small) performance boost.

Your alternative offers would impact performance and be system wide.

Therefore, I for one disagree.

--


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Require at least 20MB of mlock()-able memory if --mlock is used.

[tincanteksup]

On 07/03/2021 19:20, Selva Nair wrote:


Rereading my comment on Trac #1059 I recall testing this and concluding
100MB enough for clients. On modern machines that's a low amount of memory
--- not allowing swapout of 100MB should be acceptable.  For servers, I
think there is no reliable limit that we could come up with.

Selva



I recall, when testing with EC the min. required was 89MB.

R


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [vbox-dev] Oracle VirtualBox v6.1.19 Test Build 142917 - Not working on Windows 10 Insider Dev builds

[tincanteksup]

Copying to openvpn

I'm not sure if this will effect you, just something to look into..

The ticket is: https://www.virtualbox.org/ticket/20226

On 02/03/2021 15:50, Klaus Espenlaub wrote:
well, the mystery has been resolved (see the ticket). Thanks fth0 for 
looking closer than Microsoft's signature checking tools.


The latest dev build should work again, but the change in signing cert 
usage just buys about 6 weeks of time. After that we'll be in the same 
situation, because Microsoft dropped the cross-signing approach to sign 
kernel drivers. After that I fear the only way to make use of test 
builds is to set up test mode... really a pain, but outside our control.


Klaus

On 2021-02-26 22:22, Klaus Espenlaub wrote:

getting only more mysterious: https://www.virtualbox.org/ticket/20226

No mention there of Windows 10 Insider.

Klaus

On 2021-02-26 19:00, Klaus Espenlaub wrote:
very mysterious... we didn't change anything regarding code signing 
for VirtualBox 6.1 yet (it will come, the SHA2 cert is expiring in 
about 3 weeks.


Can you check/compare the installer signatures (using Explorer 
"Properties")? Both installers you're using the working and 
non-working one) should be dual signed with exactly the same certs.


Worst case I could provide you all 6.1 builds between r142777 and 
r142917. Just 8 builds, and all of the changes actually rather harmless.


Klaus

On 2021-02-26 00:09, Jacob Klein wrote:
Oracle VirtualBox v6.1.19 Test Build 142946 on Windows 10 Insider 
Dev Build 21322

... is having the same "Not valid kernel code signature." error.
Logs below.

Please advise, if able. I may test a "Windows 10 Release" install at 
some point. Thank you.


24ec.79c: SUPR3HardenedMain: Load Runtime...
24ec.79c: \Device\HarddiskVolume4\Program 
Files\Oracle\VirtualBox\VBoxRT.dll: Signature #1/2: info status: 24202
24ec.79c: \Device\HarddiskVolume4\Program 
Files\Oracle\VirtualBox\VBoxRT.dll: Signature #2/2: Unknown Status 
-5659 (0xe9e5) w/ timestamp=0x60379419/link.
24ec.79c: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 
hMod=7ff9c7ce 'C:\WINDOWS\system32\rsaenh.dll'
24ec.79c: supHardenedWinVerifyImageByHandle: -> -5659 
(\Device\HarddiskVolume4\Program Files\Oracle\VirtualBox\VBoxRT.dll) 
WinVerifyTrust

24ec.79c: Error (rc=0):
24ec.79c: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status 
-5659 (0xe9e5) fImage=1 fProtect=0x0 fAccess=0x0 
\Device\HarddiskVolume4\Program Files\Oracle\VirtualBox\VBoxRT.dll: 
Signature #2/2: Not valid kernel code signature.: 
\Device\HarddiskVolume4\Program Files\Oracle\VirtualBox\VBoxRT.dll
24ec.79c: supR3HardenedWinVerifyCacheInsert: 
\Device\HarddiskVolume4\Program Files\Oracle\VirtualBox\VBoxRT.dll

24ec.79c: Error (rc=0):
24ec.79c: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\Program 
Files\Oracle\VirtualBox\VBoxRT.dll' (C:\Program 
Files\Oracle\VirtualBox\VBoxRT.dll): rcNt=0xc190
24ec.79c: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0xc190 
'C:\Program Files\Oracle\VirtualBox\VBoxRT.dll'

24ec.79c: Error -610 in supR3HardenedMainInitRuntime! (enmWhat=4)
 


*From:* Jacob Klein
*Sent:* Wednesday, February 24, 2021 5:39 PM
*To:* vbox-...@virtualbox.org 
*Subject:* Oracle VirtualBox v6.1.19 Test Build 142917 - Not working 
on Windows 10 Insider Dev builds

Hello,

Oracle VirtualBox v6.1.19 Test Build 142917
... gets an error trying to start a VM after using Import Appliance, 
on Windows 10 Insider Dev builds.


The problem might be specific to changes in the Test Builds of your 
app:

Oracle VirtualBox v6.1.19 Test Build 142917 - Problem happens.
Oracle VirtualBox v6.1.19 Test Build 142777 - Problem does NOT happen.

I realize I'm using an Insider build, but because it was an upgrade 
of the VirtualBox Test Build (and Extension Pack) that made the 
problem start happening, I felt obligated to inform you. I don't 
expect an immediate fix. Again, I wanted to inform.


The error is:
Failed to open a session for the virtual machine MSEdge - Win10.
The virtual machine 'MSEdge - Win10' has terminated unexpectedly 
during startup with exit code 1 (0x1).  More details may be 
available in 'E:\VirtualBox VMs\MSEdge - Win10\Logs\VBoxHardening.log'.


VBoxHardening says the following:
27d8.39f0: SUPR3HardenedMain: Load Runtime...
27d8.39f0: \Device\HarddiskVolume4\Program 
Files\Oracle\VirtualBox\VBoxRT.dll: Signature #1/2: info status: 24202
27d8.39f0: \Device\HarddiskVolume4\Program 
Files\Oracle\VirtualBox\VBoxRT.dll: Signature #2/2: Unknown Status 
-5659 (0xe9e5) w/ timestamp=0x60353c8e/link.
27d8.39f0: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 
hMod=7ff9c7ce 'C:\WINDOWS\system32\rsaenh.dll'
27d8.39f0: supHardenedWinVerifyImageByHandle: -> -5659 
(\Device\HarddiskVolume4\Program Files\Oracle\VirtualBox\VBoxRT.dll) 
WinVerifyTrust

27d8.39f0: Error (rc=0):
27d8.39f0: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status 
-5659 (0xe9e5) 

Re: [Openvpn-devel] TLS Crypt v2 metadata name from openvpn

[tincanteksup]

Hi,

minor follow up.

This is not exactly a bug because it does work fine.

However, this is the 'metadata_file' name as presented to Windows:
metadata_file=C:\Users\IEUser\AppData\Local\Temp\\openvpn_tls_crypt_v2_metadata__3a06867f5bcca86b.tmp

Note: Temp\\openvpn_

R


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-devel/users] Debugging Windows based server scripts

[tincanteksup]

On 18/02/2021 19:13, Selva Nair wrote:

Hi,

On Wed, Feb 17, 2021 at 5:38 PM tincanteksup  wrote:


Hi,

due to not being allowed to have scripts "echo data" to the log file
under Windows, debugging scripts is next to impossible.

I presume there are no compile time options to enable "echo" under Windows
?

Could anybody provide me with a patch to enable "echo" just for the
purpose of debugging ?

I would like the patch to work for Openvpn 2.5

I understand the risks and I am not distributing OpenVPN binaries.

As justification I make these points:

* Any large distributor of Openvpn binaries could make the change to
enable "echo" under Windows.

* That distributor could then abuse it as they please.

* I am simply asking for help for the purpose of debugging Open Source
Software made for the community.



If it's for debugging, why not redirect the output of the scripts? There
are several ways of doing this like:

(i) replace the script by a wrapper

@echo off
rem this wrapper calls the actual up_script_orig.bat
call up_script_orig.bat >up_script.log 2>&1
exit /b

(ii) move the script to a function and call it, redirecting o/p

@echo off
call :do_work >up_script.log 2>&1
exit /b

:do_work
@echo on
@rem the original script follows..


@rem end of script
@echo off
exit /b

Selva




Hi Selva, thanks for the suggestions and, as it turns out, reminders! It 
has been quite some time since I picked a fight with Windows batch. I 
have now, at last, got past the first hurdle ..this "blackbox" is 
starting to look a little less opaque ;-)


R



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [Openvpn-devel/users] Debugging Windows based server scripts

[tincanteksup]

Hi,

due to not being allowed to have scripts "echo data" to the log file 
under Windows, debugging scripts is next to impossible.


I presume there are no compile time options to enable "echo" under Windows ?

Could anybody provide me with a patch to enable "echo" just for the 
purpose of debugging ?


I would like the patch to work for Openvpn 2.5

I understand the risks and I am not distributing OpenVPN binaries.

As justification I make these points:

* Any large distributor of Openvpn binaries could make the change to 
enable "echo" under Windows.


* That distributor could then abuse it as they please.

* I am simply asking for help for the purpose of debugging Open Source 
Software made for the community.


Thanks.
R


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [openvpn-devel] public man page

[tincanteksup]

hi,

i know it is hard to do but it has been done before

...


https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage


https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage


...

Please make the 2.5 manual page.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [openvpn-devel] Wiki Howto URL

[tincanteksup]

Hi,

in the Howto there was this URL:
https://community.openvpn.net/openvpn/wiki/HOWTO#ExpandingthescopeoftheVPNtoincludeadditionalmachinesoneithertheclientorserversubnet.

Note: There is a fullstop on the end.

I changed this URL to:
https://community.openvpn.net/openvpn/wiki/HOWTO#ExpandingthescopeoftheVPNtoincludeadditionalmachinesoneithertheclientorserversubnet

Note: There is no fullstop on the end.

There are no other URLs in that document which end with a fullstop.

The reason that URL ended with a fullstop is because of 
wiki:[[TOC(inline, depth=1)]]
This picked up the heading: "Expanding the scope of the VPN to include 
additional machines on either the client or server subnet."


I changed the heading to: "Expanding the scope of the VPN to include 
additional machines on either the client or server subnet"


I felt it was prudent to let you know of this change.

--


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Make OPENVPN_PLUGIN_ENABLE_PF failures FATAL

[tincanteksup]

feed back:

On 22/01/2021 07:02, Arne Schwabe wrote:

Am 21.01.21 um 14:39 schrieb Gert Doering:

Without this patch, if openpn is using a plugin that provides
OPENVPN_PLUGIN_ENABLE_PF but then fails (returns OPENVPN_PLUGIN_FUNC_ERROR),
OpenVPN will crash on a NULL pointer reference.

The underlying cause is (likely) the refactoring work regarding
CAS_SUCCEEDED etc., and that nobody adjusted the pf.c code accordingly
(it tries to sent itself a SIGUSR1, which tries to tear down the
client MI instance, but since it is not fully set up yet at this
point, things explode).  Full details on the call chain in Trac...

Since we intend to remove pf in 2.6, but we still do not want OpenVPN
to ever SIGSEGV, change the requirements for the plugins to "MUST SUCCEED",
so if the plugin ENABLE_PF call fails, abort openvpn with a M_FATAL
message.

Trac: #1377

Signed-off-by: Gert Doering 
---
  src/openvpn/pf.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/pf.c b/src/openvpn/pf.c
index f9bbfb50..3f472ef4 100644
--- a/src/openvpn/pf.c
+++ b/src/openvpn/pf.c
@@ -639,8 +639,17 @@ pf_init_context(struct context *c)
  }
  if (!c->c2.pf.enabled)
  {
-msg(M_WARN, "WARNING: failed to init PF plugin, rejecting 
client.");
-register_signal(c, SIGUSR1, "plugin-pf-init-failed");
+/* At some point in openvpn history, this code just printed a
+ * warning and signalled itself (SIGUSR1, "plugin-pf-init-failed")
+ * to terminate the client instance.  This got broken at one of
+ * the client auth state refactorings (leading to SIGSEGV crashes)
+ * and due to "pf will be removed anyway" reasons the easiest way
+ * to prevent crashes is to REQUIRE that plugins succeed - so if
+ * the plugin fails, we cleanly abort OpenVPN
+ *
+ * see also: https://community.openvpn.net/openvpn/ticket/1377
+ */
+msg(M_FATAL, "FATAL: failed to init PF plugin, must succeed.");
  return;
  }
  }



Acked-By: Arne Schwabe 

I agree to make this "fixed" in a way that doesn't involve refactoring
of pf code that is later removed anyway. I don't think the refactoring
early affects this. It has been probably broken even earlier.

Arne



I agree that a VPN should focus on its task and not try to be a firewall.

I do use the PF plugin but it is of little, if any, actual use, which is 
not handled better elsewhere.


I do not pretend to understand the intricacies of the code but if 
removing the packet filter plugin is relatively simple and clean then, 
from a user point-of-view, it makes more sense to drop it. Less 
complication overall.


No Ack: Just feed back.
--
tct
















___
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] Summary of the community meeting (20th January 2021)

[tincanteksup]

FYI, Full chatlog NOT attached

On 20/01/2021 11:34, Samuli Seppänen wrote:

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 20th January 2021
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

cron2, dazo, lev, mattock, ordex and plaisthos participated in this meeting.

---

Closed down the remaining HackerOne reports and set the awards.
Requested HackerOne to close down our project.

--

Noted that enabling IPv6 on the openvpn.net domain in CloudFlare is
progressing slowly. Some of the critical services that OpenVPN Inc. ops
were worried about have already moved to .com.

---

Full chatlog attached


___
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] Man sections: typo (No patch)

[tincanteksup]

Patchworks did not pick this up the way I expected.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Man sections: typo (No patch)

[tincanteksup]

Just FTR.



diff --git a/doc/man-sections/tls-options.rst 
b/doc/man-sections/tls-options.rst

index 5dd20013..28cf6f1e 100644
--- a/doc/man-sections/tls-options.rst
+++ b/doc/man-sections/tls-options.rst
@@ -422,13 +422,13 @@ certificates and keys: 
https://github.com/OpenVPN/easy-rsa

   :code:`DEFAULT:!EXP:!LOW:!MEDIUM:!kDH:!kECDH:!DSS:!PSK:!SRP:!kRSA` when
   using OpenSSL.

-  The default for `--tls-ciphersuites` is to use the crypto library's
-  default.
-
 --tls-ciphersuites l
   Same as ``--tls-cipher`` but for TLS 1.3 and up. mbed TLS has no
   TLS 1.3 support yet and only the ``--tls-cipher`` setting is used.

+  The default for `--tls-ciphersuites` is to use the crypto library's
+  default.
+
 --tls-client
   Enable TLS and assume client role during TLS handshake.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Clarify --block-ipv6 intent and direction.

[tincanteksup]

On 25/12/2020 16:42, Gert Doering wrote:

--block-ipv6 is a fairly special-purpose option, and only blocks packet
in the client->server option.  This is implied by not ever mentioning
the other direction in the existing documentation, but not written down.

Make this explicit, avoid confusion.

Also, point why this option exist (avoid IPv6 leakage from dual-stacked
clients around IPv4-only VPN offerings).

Trac: #1351

Signed-off-by: Gert Doering 
---
  doc/man-sections/vpn-network-options.rst | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index 26682789..711dfcc8 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -21,7 +21,8 @@ routing.
For this option to make sense you actually have to route traffic to the
tun interface. The following example config block would send all IPv6
traffic to OpenVPN and answer all requests with no route to host,
-  effectively blocking IPv6.
+  effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked
+  clients to leak around IPv4-only VPN services).
  
**Client config**

  ::
@@ -38,6 +39,12 @@ routing.
 --push "redirect-gateway ipv6"
 --block-ipv6
  
+  Note: this option does not influence traffic sent from the server

+  towards the client (neither on the server nor on the client side).
+  This is not seen as necessary, as such traffic can be most easily
+  avoided by not configuring IPv6 on the server tun, or setting up a
+  server-side firewall rule.
+
  --dev device
TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`,
:code:`null` or an arbitrary name string (:code:`X` can be omitted for



LGTM

Acked-by: Richard Bonhomme 


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Travis-ci is changing billing

[tincanteksup]

On 23/12/2020 18:03, Илья Шипицин wrote:

On Wed, Dec 23, 2020, 10:42 PM Gert Doering  wrote:


Hi,

On Wed, Dec 23, 2020 at 04:06:26PM +, tincanteksup wrote:

This may help shed some light:

https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing


I'm more confused than before.  So is what we do still free?  Do we
need to apply somewhere?



It is one time 1000 minutes free tier.
Once it is used the free game is over.

In theory we can contact and ask for permanent OSS free limit, but Travis
did not reply to anybody




Travis did claim "abuse" as their reasoning, which sounds feasible.

On the up-side, builds do seem to be faster :-)








Do we do MacOS builds?  If yes, we might consider removing them (we
do have a MacOS buildslave)...

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] Travis-ci is changing billing

[tincanteksup]

This may help shed some light:

https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

On 23/12/2020 05:44, Илья Шипицин wrote:

https://news.ycombinator.com/item?id=25338983

Actually, not many choices, either to drop Travis or to pay for it.




Ilya



___
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] wanted: mechanism to send text messages to client

[tincanteksup]

Gert,

using server side scripting, I can push *literally* anything I want to 
the server via --push-peer-info and setenv UV_*


Example:
setenv UV_PING 10
setenv UV_PINGRESTART 60

My server side script allows the client to effectively configure 
--keepalive (and a LOT more)


My guess would be to push some expected and custom variables to the 
client at logon.


And the user can fend for themselves.

No --up .. no --issue

I guess something like --pull-peer-info would be suitable. That way, 
what ever is received can be vetted.




If computers Did have sense of humour then you lot would probably have 
gone insane by now.




On 20/12/2020 10:54, Gert Doering wrote:

Hi,

I find myself looking for a mechanism by which I could send informational
messages ("your cert expires in two weeks, go refresh!" - "your openvpn
client needs an upgrade") from the openvpn server to incoming clients.

Of course this should work with all connecting clients, that is, "text
clients", windows GUI, Tunnelblick, iOS Connect, Android.

As far as I am aware, there is no such mechanism today.

Do we want to make one?


 From the server / openvpn core side, it could be something totally trivial:

   push "info-msg hey there!"

... and the client would then either print this on the console
(if !management) or dump it to management, where the GUI/Tunnelblick
could pick it up and create a popup window.

What do you think?

gert



___
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] Community meetings in December 2020

[tincanteksup]

Please discuss and resolve the fate of the OpenVPN-Legacy-Service for 
Windows.


Ref: https://community.openvpn.net/openvpn/ticket/1344

Official status of deprecation/removal requested.


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Man sections: typo (No patch)

[tincanteksup]

Sorry for lack of patch.

diff --git a/doc/man-sections/renegotiation.rst 
b/doc/man-sections/renegotiation.rst

index b817cfa8..c5484404 100644
--- a/doc/man-sections/renegotiation.rst
+++ b/doc/man-sections/renegotiation.rst
@@ -35,7 +35,7 @@ separate ephemeral encryption key which is rotated at 
regular intervals.

   pseudo-uniform-randomized between ``min`` and ``max``.

   With the default value of :code:`3600` this results in an effective per
-  session value in the range of :code:`3240`..:code:`3600` seconds for
+  session value in the range of :code:`3240` .. :code:`3600` seconds for
   servers, or just 3600 for clients.

   When using dual-factor authentication, note that this default value may


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 0/4] Allow setting up OpenVPN in TLS mode without CA

[tincanteksup]

On 09/09/2020 11:21, Arne Schwabe wrote:

Am 09.09.20 um 10:04 schrieb François Kooman:

On 9/8/20 6:38 PM, Arne Schwabe wrote:

I really wonder which large deployment want to do that instead of a CA.
I really understand the need for small and simple deployments. But for
larger deployments a CA + CRL seems more useful for everything that I
can come up with.


It would be more for the situation where you already have a "parallel
trust", e.g. through an OAuth API where a CA would be redundant. Just
having an API to register fingerprints (which would act as a CRL at the
same time by simply removing fingerprints) is easier than having a
complete CA with CRL.

Of course, all of this can also be done by using a CA, and something can
be said that if you operate on that scale you can also handle the extra
"cost" of a CA...


I am happy to review a patch that adds a allow_no_ca or similar flag to
the tls-verify option that allows this but I don't have a real
motivation to implement it myself.

Just allowing ca not set with tls-verify script being set is a bit too
dangerous for my taste.



I too would like to see an external list of fingerprints be made available.
https://community.openvpn.net/openvpn/ticket/1323#ticket


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] New man-section pages format

[tincanteksup]

On 04/09/2020 14:36, David Sommerseth wrote:

On 04/09/2020 15:21, tincanteksup wrote:

Hi,

this is just something to chew-over..

See:
https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/generic-options.rst


I noticed that generally the option names, eg: --auth-nocache, wrap and the
result is unpleasant.

However, further down that same page --daemon progname does not wrap and looks
much nicer.

I know which format I prefer, perhaps this can be changed..


Do you mean the wrapping in the HTML rendering on GitHub?  That can only be
changed by changing the number of characters in the option.  It's not
something we control, it's the GitHub .rst rendering.

$ echo -n "--daemon progname" | wc -c
17
$ echo -n "--auth-nocache" | wc -c
14

IIRC, the limit is more than 16 characters, and the option gets a cell on a
single line.

Now, if you find a setting we can tweak (even a .. notation in the .rst files)
where we can reduce this limit to 2 character (which means all options gets
its own line - which will be consistent all over), I'm open to consider that.
  I haven't had time to dig into it.

But I agree, the wrapping is not nice at all.  That said, we have had more
focus on ensuring the man/*roff rendering looks nice and reasonable more than
the HTML rendering on GitHub - in addition files which are more easy to edit
in a text editor.  After all, the HTML rendering was just a bonus over the .8
rendering [1] on GitHub before the .rst conversion.

[1] <https://github.com/OpenVPN/openvpn/blob/release/2.4/doc/openvpn.8>




Thanks David, I'll see what, if anything, can be done to wrestle github 
into submission ;-)





___
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] New man-section pages format

[tincanteksup]

Hi,

this is just something to chew-over..

See: 
https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/generic-options.rst


I noticed that generally the option names, eg: --auth-nocache, wrap and 
the result is unpleasant.


However, further down that same page --daemon progname does not wrap and 
looks much nicer.


I know which format I prefer, perhaps this can be changed..

BR
Richard


___
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

[tincanteksup]

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 v4 2/2] Implement generating data channel keys via EKM/RFC 5705

[tincanteksup]

This sentence is badly constructed, so, use some grammar to help it read 
correctly:



On 25/08/2020 08:36, Arne Schwabe wrote:


+ * When the client sends the IV_PROTO_TLS_KEY_EXPORT flag and the server 
replies
+ * with `key-derivation tls-ekm` the RFC5705 key material exporter with the
+ * label EXPORTER-OpenVPN-datakeys is used for the key data.
   *




> + * When the client sends the IV_PROTO_TLS_KEY_EXPORT flag and the 
server replies
> + * with `key-derivation tls-ekm` *then* the RFC5705 key material 
exporter, with the

> + * label EXPORTER-OpenVPN-datakeys, is used for the key data.
>*


Sorry to be a pain ..



___
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

[tincanteksup]

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] 2.5-beta-1 Windows installer problems

[tincanteksup]

Final update:

So, IPv4 not working was my own error .. sorry for the false alarm.

As for the non-admin user trying to install drivers, this does still happen.

However, what I think is happening is this:

1. Login as admin - install openvpn OK
2. logout/login as normal user
3. Openvpn does "Setting up personal settings for user foo"
4. The installer also asks the user to install TAP and wintun.
5. On Win7 the user is not prompted for admin password so no changes are 
made to the system.


Openvpn then works ipv4 and v6 Tap and wintun.


The same is true for W10 with the exception that: when openvpn is 
uninstalled only either the current user "personal settings" are removed 
or the admin "personal settings" are removed, depending on who is logged 
in at uninstall.


Then the next install does not need to do the "personal settings" for 
the "other" user because they are already there and so the installer 
does not erroneously try to install the drivers again when the user changes.


That is my best guess.

I don't think anybody needs to respond to this thread any further.

Regards
Richard




On 16/08/2020 14:05, tincanteksup wrote:

I tried this again on a completely fresh Win10 VM.

The experience was the same, IPv6 works v4 does not.

When installing as an admin user and then switching to a non-admin, the 
installation still continues but does ask for admin password.  But the 
result is still the same, no IPv4.


Uninstalling and then installing as a non-admin from scratch seems a lot 
smoother but the final result is the same, no IPv4.


Summary:

Win10 install from non-admin seems to be cleanly done but the result is 
no Ipv4.


Win10 install as admin user is not so clean.  OpenVPN installer seems to 
be left in an incomplete state until a non-admin user logs in.  In my 
opinion, this is not ideal considering the number of single user 
machines in use.  Microsoft do what they must to protect the system when 
a single user machine is in use, openvpn should not be so picky..


Win7 .. same result, no Ipv4.

Win7 install seems to have the same issues of who is allowed to install 
openvpn but does a bad job of it, no admin password prompt.


I know this is a beta so I'm not complaining, only offering feedback

Regards




On 15/08/2020 19:31, tincanteksup wrote:

Comment inline:

On 15/08/2020 19:29, tincanteksup wrote:

Hi,

I would like to document the very strange issues I had testing the 
2.5 MSI installers.


The first test was on a Win7-Ent/32bit VM with 32bit installer.  The 
second test was a real PC with Win7-HomePro/64bit (yeah, user did not 
want w10) 64bit installer. The third test was Win10/64bit VM 64bit 
installer.


The results were almost identical:

1. Logged in as admin user.
2. Installed over previous installation.
    Completed apparently OK ?
3. On testing the VPN I found that:
    IPv6 worked (could ping both ways)
    IPv4 did not (could not ping either way)
    Firewall disabled. Dual stack VPN.
4. Logged out/Logged in as normal user.
5. OpenVPN Installer forced a re-install of the TAP/wintun drivers.
    The user could select "do not install" but the installer was 
auto-run.


I did "Install" the drivers as non-admin user and was *not* prompted 
for admin password.




    The user was *not* prompted for admin password.
6. Using the same VPN config as above, the VPN now functions correctly.

The only difference was that on Win10 I could not test logging back 
in as a standard user because my VM could not be activated.


I do not know where would be the bast place to raise these issues and 
so sent my feedback to the list for further consideration.


Regards
Richard



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.5-beta-1 Windows installer problems

[tincanteksup]

I tried this again on a completely fresh Win10 VM.

The experience was the same, IPv6 works v4 does not.

When installing as an admin user and then switching to a non-admin, the 
installation still continues but does ask for admin password.  But the 
result is still the same, no IPv4.


Uninstalling and then installing as a non-admin from scratch seems a lot 
smoother but the final result is the same, no IPv4.


Summary:

Win10 install from non-admin seems to be cleanly done but the result is 
no Ipv4.


Win10 install as admin user is not so clean.  OpenVPN installer seems to 
be left in an incomplete state until a non-admin user logs in.  In my 
opinion, this is not ideal considering the number of single user 
machines in use.  Microsoft do what they must to protect the system when 
a single user machine is in use, openvpn should not be so picky..


Win7 .. same result, no Ipv4.

Win7 install seems to have the same issues of who is allowed to install 
openvpn but does a bad job of it, no admin password prompt.


I know this is a beta so I'm not complaining, only offering feedback

Regards




On 15/08/2020 19:31, tincanteksup wrote:

Comment inline:

On 15/08/2020 19:29, tincanteksup wrote:

Hi,

I would like to document the very strange issues I had testing the 2.5 
MSI installers.


The first test was on a Win7-Ent/32bit VM with 32bit installer.  The 
second test was a real PC with Win7-HomePro/64bit (yeah, user did not 
want w10) 64bit installer. The third test was Win10/64bit VM 64bit 
installer.


The results were almost identical:

1. Logged in as admin user.
2. Installed over previous installation.
    Completed apparently OK ?
3. On testing the VPN I found that:
    IPv6 worked (could ping both ways)
    IPv4 did not (could not ping either way)
    Firewall disabled. Dual stack VPN.
4. Logged out/Logged in as normal user.
5. OpenVPN Installer forced a re-install of the TAP/wintun drivers.
    The user could select "do not install" but the installer was 
auto-run.


I did "Install" the drivers as non-admin user and was *not* prompted for 
admin password.




    The user was *not* prompted for admin password.
6. Using the same VPN config as above, the VPN now functions correctly.

The only difference was that on Win10 I could not test logging back in 
as a standard user because my VM could not be activated.


I do not know where would be the bast place to raise these issues and 
so sent my feedback to the list for further consideration.


Regards
Richard



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.5-beta-1 Windows installer problems

[tincanteksup]

Comment inline:

On 15/08/2020 19:29, tincanteksup wrote:

Hi,

I would like to document the very strange issues I had testing the 2.5 
MSI installers.


The first test was on a Win7-Ent/32bit VM with 32bit installer.  The 
second test was a real PC with Win7-HomePro/64bit (yeah, user did not 
want w10) 64bit installer. The third test was Win10/64bit VM 64bit 
installer.


The results were almost identical:

1. Logged in as admin user.
2. Installed over previous installation.
    Completed apparently OK ?
3. On testing the VPN I found that:
    IPv6 worked (could ping both ways)
    IPv4 did not (could not ping either way)
    Firewall disabled. Dual stack VPN.
4. Logged out/Logged in as normal user.
5. OpenVPN Installer forced a re-install of the TAP/wintun drivers.
    The user could select "do not install" but the installer was auto-run.


I did "Install" the drivers as non-admin user and was *not* prompted for 
admin password.




    The user was *not* prompted for admin password.
6. Using the same VPN config as above, the VPN now functions correctly.

The only difference was that on Win10 I could not test logging back in 
as a standard user because my VM could not be activated.


I do not know where would be the bast place to raise these issues and so 
sent my feedback to the list for further consideration.


Regards
Richard



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] 2.5-beta-1 Windows installer problems

[tincanteksup]

Hi,

I would like to document the very strange issues I had testing the 2.5 
MSI installers.


The first test was on a Win7-Ent/32bit VM with 32bit installer.  The 
second test was a real PC with Win7-HomePro/64bit (yeah, user did not 
want w10) 64bit installer. The third test was Win10/64bit VM 64bit 
installer.


The results were almost identical:

1. Logged in as admin user.
2. Installed over previous installation.
   Completed apparently OK ?
3. On testing the VPN I found that:
   IPv6 worked (could ping both ways)
   IPv4 did not (could not ping either way)
   Firewall disabled. Dual stack VPN.
4. Logged out/Logged in as normal user.
5. OpenVPN Installer forced a re-install of the TAP/wintun drivers.
   The user could select "do not install" but the installer was auto-run.
   The user was *not* prompted for admin password.
6. Using the same VPN config as above, the VPN now functions correctly.

The only difference was that on Win10 I could not test logging back in 
as a standard user because my VM could not be activated.


I do not know where would be the bast place to raise these issues and so 
sent my feedback to the list for further consideration.


Regards
Richard


___
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

[tincanteksup]

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 v2 3/3] Implement generating data channel keys via EKM/RFC 5705

[tincanteksup]

typos/grammar

On 12/08/2020 15:01, Arne Schwabe wrote:

OpenVPN currently uses its own (based on TLS 1.0) key derivation
mechansim to generate the 256 bytes key data in key2 struct that


mechansim -> mechanism



are then used used to generate encryption/hmac/iv vectors. While
this mechanism is still secure, it is not state of the art.

Instead of modernisating our own approach, this commit implements


modernisating - > modernising



key derivation using the Keying Material Exporters API introduced
by RFC 5705.

We also use an opportunistic approach of negotiating the use of
EKM (exported key material) through an IV_PROTO flag and prefer
EKM to our own PRF if both client and server support it. The
use of EKM is pushed to the client as part of NCP as
key-derivation tls-ekm.

We still exchange the random data (112 bytes from client to server
and 64 byte from server to client) that for the OpenVPN PRF but


client) that for - unnecessary 'that'


do not use it. Removing that exchange would break the handshake
and make a key-method 3 or similar necessary.

Side note: this commit breaks the (not yet merged) WolfSSL support as it
claims to support EKM in the OpenSSL compat API but always returns an error
if you try to use it.

Signed-off-by: Arne Schwabe 

Patch V2: rebase/change to V2 of EKM refactoring
---
  Changes.rst  | 11 +++
  doc/doxygen/doc_key_generation.h | 15 --
  src/openvpn/crypto.h |  4 +++
  src/openvpn/init.c   |  1 +
  src/openvpn/multi.c  |  4 +++
  src/openvpn/options.c| 14 +
  src/openvpn/options.h|  3 ++
  src/openvpn/push.c   |  5 +++-
  src/openvpn/ssl.c| 50 ++--
  src/openvpn/ssl.h|  2 ++
  src/openvpn/ssl_backend.h|  2 ++
  src/openvpn/ssl_mbedtls.c|  7 ++---
  12 files changed, 107 insertions(+), 11 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index bacc98cd..2c28a399 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -1,3 +1,14 @@
+Overview of changes in 2.6
+==
+
+
+New features
+
+Keying Material Exporters (RFC 5705) based key generation
+As part of the cipher negotiation OpenVPN will automatically prefer
+the RFC5705 based key material generation to the current custom
+OpenVPN PRF. This feature requires OpenSSL or mbed TLS 2.18+.
+
  Overview of changes in 2.5
  ==
  
diff --git a/doc/doxygen/doc_key_generation.h b/doc/doxygen/doc_key_generation.h

index 4bb9c708..bbd6c0c5 100644
--- a/doc/doxygen/doc_key_generation.h
+++ b/doc/doxygen/doc_key_generation.h
@@ -58,6 +58,12 @@
   *
   * @subsection key_generation_method_2 Key method 2
   *
+ * There are two methods for generating key data when using key method 2
+ * the first is OpenVPN's traditional approach that exchanges random
+ * data and uses a PRF and the other is using the RFC5705 keying material
+ * exporter to generate the key material. For both methods the random
+ * data is exchange but only used in the traditional method.
+ *
   * -# The client generates random material in the following amounts:
   *- Pre-master secret: 48 bytes
   *- Client's PRF seed for master secret: 32 bytes
@@ -73,8 +79,13 @@
   *server's random material.
   *
   * %Key method 2 %key expansion is performed by the \c
- * generate_key_expansion() function.  Please refer to its source code for
- * details of the %key expansion process.
+ * generate_key_expansion_oepnvpn_prf() function.  Please refer to its source
+ * code for details of the %key expansion process.
+ *
+ * When the client sends the IV_PROTO_TLS_KEY_EXPORT and the server replies
+ * with `key-derivation tls-ekm` RFC5705 key material exporter with the label
+ * EXPORTER-OpenVPN-datakeys is used for the key data.


Grammar: split the sentence by a 'then'.

> + * When the client sends the IV_PROTO_TLS_KEY_EXPORT and the server 
replies
> + * with `key-derivation tls-ekm` then RFC5705 key material exporter 
with the label

> + * EXPORTER-OpenVPN-datakeys is used for the key data.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 1/3] Refactor key_state_export_keying_material functions

[tincanteksup]

typo

On 12/08/2020 15:01, Arne Schwabe wrote:

This refactors the common code between mbed SSL and OpenSSL into
export_user_keying_material and also prepares the backend functions
to export more than one key.

Also fix checking the return value of SSL_export_keying_material
only 1 is a sucess, -1 is also an error.


sucess -> success



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 2/2] Document different behaviour of dynamic cipher negotiation

[tincanteksup]

spelling/grammar and some questions ...


On 09/08/2020 15:19, Arne Schwabe wrote:

This adds a section in the man page that details the various behaviour
of older client/servers when using OpenVPN 2.5.

Signed-off-by: Arne Schwabe 
---
  Changes.rst | 23 +++
  doc/man-sections/cipher-negotiation.rst | 87 +
  doc/openvpn.8.rst   |  1 +
  3 files changed, 111 insertions(+)
  create mode 100644 doc/man-sections/cipher-negotiation.rst

diff --git a/Changes.rst b/Changes.rst
index 37792342..2cfd2ee2 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -29,6 +29,29 @@ Improved Data channel cipher negotiation
  ``data-ciphers ChaCha20-Poly1305:AES-256-GCM`` on the server that
  prefers ChaCha20-Poly1305 but uses it only if the client supports it.
  
+See the data channel negotiation section in the manual for more details.

+
+Removal of BF-CBC support in default configuration:
+By default OpenVPN 2.5 will only accept AES-256-GCM and AES-128-GCM as
+data ciphers. OpenVPN 2.4 allows AES-256-GCM,AES-128-GCM and BF-CBC when
+no --cipher and --ncp-ption were present. Accepting BF-CBC can be


--ncp-ption ??? --ncp-cipher



+enabled by adding
+
+data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
+
+and when you need to support very old peers also
+
+data-ciphers-fallback BF-CBC
+
+to offer backwards compatiblity with older config an *explicit*


compatibility



+
+cipher BF-CBC
+
+in the configuration will be automatically translated in adding BF-CBC
+to the data-ciphers option and setting data-ciphers-fallback to BF-CBC
+commands above. We strongly recommend to switching away from BF-CBC to a
+more secure cipher.
+
  Asynchronous (deferred) authentication support for auth-pam plugin.
  See src/plugins/auth-pam/README.auth-pam for details.
  
diff --git a/doc/man-sections/cipher-negotiation.rst b/doc/man-sections/cipher-negotiation.rst

new file mode 100644
index ..98ce1fec
--- /dev/null
+++ b/doc/man-sections/cipher-negotiation.rst
@@ -0,0 +1,87 @@
+Data channel cipher negotiation
+===
+
+OpenVPN 2.4 and higher have the capability to dynamically negotiate the data 
cipher that


Is "dynamically" required ?



+is used to encrypt data packets. This section describes the mechanism in more 
detail and the
+different backwards compatibility mechanism with older server and clients.
+
+OpenVPN 2.5 and higher behaviour
+
+When both client and server are at least running OpenVPN 2.5, that the order of
+the ciphers of the server's ``--data-ciphers`` is used to pick the the data 
cipher.
+That means that the first cipher in that last that is also in the client's


last -> list



+``--data-ciphers`` list is chosen. If no common cipher is found the client is 
rejected
+with a AUTH_FAILED message (as seen in client log):
+
+AUTH: Received control message: AUTH_FAILED,Data channel cipher 
negotiation failed (no shared cipher)
+
+OpenVPN 2.5 will only allow the ciphers specified in ``--data-ciphers``. To 
ensure
+backwards compatibility also if a cipher is specified using the ``--cipher`` 
option
+it is automatically added to this list. If both options are unset the default 
is
+:code:`AES-256-GCM:AES-128-GCM`.
+
+OpenVPN 2.4 clients
+---
+The negotiation support in OpenVPN 2.4 was a first implementation and still 
had some
+quirks. Its main goal was "upgrade to AES-256-GCM when possible".
+An OpenVPN 2.4 client that is build against a crypto library that supports AES 
in GCM


build -> built



+mode and does not have ``--ncp-disable`` will always announce support for
+`AES-256-GCM` and `AES-128-GCM` even if the ``--ncp-ciphers`` option does not 
inlcude


inlcude -> include



+those two ciphers. It is therefore recommended to add `AES-256-GCM` and 
`AES-128-GCM`
+to the ``--ncp-ciphers`` options to workaround this bug.
+
+
+OpenVPN 3 clients
+-
+Clients based on the OpenVPN 3.x library (https://github.com/openvpn/openvpn3/)
+do not have a configurable ``--ncp-ciphers`` or ``--data-cipher`` option. 
Instead
+these clients will announce support for all their supported AEAD ciphers
+(`AES-256-GCM`, `AES-128-GCM` and in newer versions also `Chacha20-Poly1305`).
+
+To support OpenVPN 3.x based clients at least one of these ciphers needs to be
+included in the ``--data-ciphers`` option.


in the server's ``--data-ciphers``
(for clarity)



+
+
+OpenVPN 2.3 clients and older (and clients with ``--ncp-disable``)
+--
+When a client without cipher negotiation support connects to a server the
+cipher specified with the ``--cipher`` option in the client configuration
+must be included in the ``--data-ciphers`` option of the server to allow
+the client to connect. Otherwise the client will be sent the ``AUTH_FAILED``
+message that 

Re: [Openvpn-devel] [PATCH v3 1/2] Rework NCP compability logic and drop BF-CBC support by default

[tincanteksup]

spelling/grammar

Couple of typos and some suggested grammar improvements.

On 09/08/2020 15:19, Arne Schwabe wrote:

This reworks the NCP logic to be more strict about what is
considered an acceptable result of an NCP negotiation. It also
us to finally drop BF-CBC support by default.


It is also used to




All new behaviour is currently limited to server/client
mode with pull enabled. P2p mode without pull does not change.

New Server behaviour:
- when a client announces its supported ciphers through either
   OCC or IV_CIPHER/IV_NCP we reject the client with a
   AUTH_FAILED message if we have no common cipher.

- When a client does not announce any cipher in either
   OCC or NCP we by reject it unless fallback-cipher is


we reject
(remove by)



   specified in either ccd or config.

New client behaviour:
- When no cipher is pushed (or a cipher we refused to support)
   and we also cannot support the server's server announced in
   OCC we fail the connection and log why


- When no cipher or only a cipher we refuse to support is pushed and we 
also cannot support the server's cipher announced in OCC then we fail 
the connection and log why





- If fallback-cipher is specified we will in the case that
   cipher is missing from occ use the fallback cipher instead
   of failing the connection

Both client and server behaviour:
- We only announce --cipher xyz in occ if we are willing
   to support that cipher.

   It means that we only announce the fallback-cipher if
   it is also contained in --data-ciphers

Compatiblity behaviour:


Compatibility




In 2.5 both client and server will automatically set
fallback-cipher xyz if --cipher xyz is in the config and
also add append the cipher to the end of data-ciphers.


In 2.5 both client and server will automatically set
fallback-cipher xyz. If --cipher xyz is in the config then
also append the cipher to the end of data-ciphers.




We log a warn user about this and point to --data-ciphers and
--fallback-cipher. This also happens if the configuration
contains an explicit --cipher BF-CBC.


We log and warn the user




If --cipher is not set, we only warn that previous versions
allowed BF-CBC and point how to reenable BF-CBC. This might


re-enable



break very few config where someone connects a very old


break a small number of configs
(reword)


client to a 2.5 server but at some point we need to drop
the BF-CBC and those affected use will already have a the


and those affected will
(remove use)

already have the
(remove a)


scary SWEET32 warning in their logs.

In short: If --cipher is explicitly set 2.6 will work the same as


set then 2.6
(insert then)



2.4 did. When --cipher is not set, BF-CBC support is dropped and
we warn about it.

Examples how breaking the default BF-CBC will be logged:

Client side:
  - Client connecting to server that does not push cipher but
has --cipher in OCC

 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's 
cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-CBC') if 
you want to connect to this server.

  - Client connecting to a server that does not support OCC:

OPTIONS ERROR: failed to negotioate cipher with server. Configure 
--fallback-cipher if you want connect to this server.


negotiate




Server Side:

- Server has a client only supporting BF-CBC connecting:

   styx/IP PUSH: No common cipher between server and client. Server 
data-ciphers: 
'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-256-CBC:AES-128-CBC', client 
supports cipher 'BF-CBC'.

  - Client without OCC:

styx/IP PUSH:No NCP or OCC cipher data received from peer.
styx/IP Use --fallback-cipher with the cipher the client is using if you 
want to allow the client to connect

In all reject cases on the client:


rejected




AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation 
failed (no shared cipher)

Signed-off-by: Arne Schwabe 

Patch V2: rename fallback-cipher to data-ciphers-fallback
   add all corrections from Steffan
   Ignore occ cipher for clients sending IV_CIPHERS
   move client side ncp in its own function
   do not print INSECURE cipher warning if BF-CBC is not allowed

Patch V3: fix minor style, add null check when client sends no peerinfo at
   all

Signed-off-by: Arne Schwabe 
---
  doc/man-sections/protocol-options.rst |  22 -
  src/openvpn/crypto.c  |   4 +-
  src/openvpn/init.c|  18 ++--
  src/openvpn/multi.c   | 135 --
  src/openvpn/options.c | 117 +-
  src/openvpn/options.h |   2 +
  src/openvpn/ssl.c |  17 ++--
  src/openvpn/ssl_ncp.c |  83 +---
  src/openvpn/ssl_ncp.h |  18 ++--
  tests/unit_tests/openvpn/test_ncp.c   |  29 --
  10 files changed, 315 insertions(+), 130 deletions(-)

diff --git 

Re: [Openvpn-devel] [PATCH v2] Rework NCP compability logic and drop BF-CBC support by default

[tincanteksup]

On 05/08/2020 21:25, Steffan Karger wrote:

Hi,

No full review yet, but this version does seem to address my previous
comments. Some minor nits I noticed on my first run through v2:

On 29-07-2020 13:38, Arne Schwabe wrote:

This reworks the NCP logic to be more strict about what is
considered an acceptable result of an NCP negotiation. It also
us to finally drop BF-CBC support by default.

All new behaviour is currently limited to server/client
mode with pull enabled. P2p mode without pull does not change.

New Server behaviour:
- when a client announces its supported ciphers through either
   OCC or IV_CIPHER/IV_NCP we reject the client with a
   AUTH_FAILED message if we have no common cipher.

- When a client does not announce any cipher in either
   OCC or NCP we by reject it unless fallback-cipher is
   specified in either ccd or config.

New client behaviour:
- When no cipher is pushed (or a cipher we refused to support)
   and we also cannot support the server's server announced in
   OCC we fail the connection and log why

- If fallback-cipher is specified we will in the case that
   cipher is missing from occ use the fallback cipher instead
   of failing the connection

Both client and server behaviour:
- We only announce --cipher xyz in occ if we are willing
   to support that cipher.

   It means that we only announce the fallback-cipher if
   it is also contained in --data-ciphers

Compatiblity behaviour:


Compatiblity -> Compatibility




In 2.5 both client and server will automatically set
fallback-cipher xyz if --cipher xyz is in the config and
also add append the cipher to the end of data-ciphers.

We log a warn user about this and point to --data-ciphers and
--fallback-cipher. This also happens if the configuration
contains an explicit --cipher BF-CBC.

If --cipher is not set, we only warn that previous versions
allowed BF-CBC and point how to reenable BF-CBC. This might
break very few config where someone connects a very old
client to a 2.5 server but at some point we need to drop
the BF-CBC and those affected use will already have a the
scary SWEET32 warning in their logs.

In short: If --cipher is explicitly set 2.6 will work the same as
2.4 did. When --cipher is not set, BF-CBC support is dropped and
we warn about it.

Examples how breaking the default BF-CBC will be logged:

Client side:
  - Client connecting to server that does not push cipher but
has --cipher in OCC

 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's 
cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-CBC') if 
you want to connect to this server.

  - Client connecting to a server that does not support OCC:

OPTIONS ERROR: failed to negotioate cipher with server. Configure 
--fallback-cipher if you want connect to this server.


negotioate -> *-)





Server Side:

- Server has a client only supporting BF-CBC connecting:

   styx/IP PUSH: No common cipher between server and client. Server 
data-ciphers: 
'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-256-CBC:AES-128-CBC', client 
supports cipher 'BF-CBC'.

  - Client without OCC:

styx/IP PUSH:No NCP or OCC cipher data received from peer.
styx/IP Use --fallback-cipher with the cipher the client is using if you 
want to allow the client to connect

In all reject cases on the client:

AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation 
failed (no shared cipher)

Signed-off-by: Arne Schwabe 

Patch V2: rename fallback-cipher to data-ciphers-fallback
   add all corrections from Steffan
   Ignore occ cipher for clients sending IV_CIPHERS
   move client side ncp in its own function
   do not print INSECURE cipher warning if BF-CBC is not allowed

Signed-off-by: Arne Schwabe 
---
  doc/man-sections/protocol-options.rst |  22 -
  src/openvpn/crypto.c  |   4 +-
  src/openvpn/init.c|  18 ++--
  src/openvpn/multi.c   | 135 --
  src/openvpn/options.c | 117 +-
  src/openvpn/options.h |   2 +
  src/openvpn/ssl.c |  17 ++--
  src/openvpn/ssl_ncp.c |  82 +---
  src/openvpn/ssl_ncp.h |  18 ++--
  tests/unit_tests/openvpn/test_ncp.c   |  26 +++--
  10 files changed, 311 insertions(+), 130 deletions(-)



No other spelling or grammar to worry about.















diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index 051f1d32..69d3bc67 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -57,6 +57,9 @@ configured in a compatible way between both the local and 
remote side.
http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
  
  --cipher alg

+  This option is deprecated for server-client mode and ``--data-ciphers``
+  or rarely `--data-ciphers-fallback`` should be used 

Re: [Openvpn-devel] [PATCH 9/9] Rework NCP compability logic and drop BF-CBC support by default

[tincanteksup]

10x more wee pointers

On 28/07/2020 13:27, Steffan Karger wrote:

Hi,

This is awesome in many ways. Better behaviour, better code and a nice
way forward to really get rid of the BF-CBC default cipher.

It's also somewhat tricky, so here goes for a review purely based on
stare-at-code:

On 17-07-2020 15:47, Arne Schwabe wrote:

This reworks the NCP logic to be more strict about what is
considered an acceptable result of an NCP negotiation. It also
us to finally drop BF-CBC support by default.

All new behaviour is currently limited to server/client
mode with pull enabled. P2p mode without pull does not change.

New Server behaviour:
- when a client announces its supported ciphers through either
   OCC or IV_CIPHER/IV_NCP we reject the client with a
   AUTH_FAILED message if we have no common cipher.

- When a client does not announce any cipher in either
   OCC or NCP we by reject it unless fallback-cipher is
   specified in either ccd or config.

New client behaviour:
- When no cipher is pushed (or a cipher we refused to support)
   and we also cannot support the server's server announced in
   OCC we fail the connection and log why

- If fallback-cipher is specified we will in the case that
   cipher is missing from occ use the fallback cipher instead
   of failing the connection

Both client and server behaviour:
- We only announce --cipher xyz in occ if we are willing
   to support that cipher.

   It means that we only announce the fallback-cipher if
   it is also contained in --data-ciphers

Compatiblity behaviour:


Compatiblity -> Compatibility





In 2.5 both client and server will automatically set
fallback-cipher xyz if --cipher xyz is in the config and
also add append the cipher to the end of data-ciphers.

We log a warn user about this and point to --data-ciphers and
--fallback-cipher. This also happens if the configuration
contains an explicit --cipher BF-CBC.

If --cipher is not set, we only warn that previous versions
allowed BF-CBC and point how to reenable BF-CBC. This might


reenable -> re-enable
(technicality only)



break very few config where someone connects a very old
client to a 2.5 server but at some point we need to drop
the BF-CBC and those affected use will already have a the
scary SWEET32 warning in their logs.

In short: If --cipher is explicitly set 2.6 will work the same as
2.4 did. When --cipher is not set, BF-CBC support is dropped and
we warn about it.

Examples how breaking the default BF-CBC will be logged:

Client side:
  - Client connecting to server that does not push cipher but
has --cipher in OCC

 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's 
cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-CBC') if 
you want to connect to this server.

  - Client connecting to a server that does not support OCC:

OPTIONS ERROR: failed to negotioate cipher with server. Configure 
--fallback-cipher if you want connect to this server.


negotioate !!!




Server Side:

- Server has a client only supporting BF-CBC connecting:> diff --git 
a/doc/man-sections/protocol-options.rst

b/doc/man-sections/protocol-options.rst

[ Used the output of "git diff -w" to review, so pasting that here is
"original" too. ]


diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index 051f1d32..ab22b415 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -57,6 +57,9 @@ configured in a compatible way between both the local and 
remote side.
http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
  
  --cipher alg

+  This option is deprecated for server-client mode and ``--data-ciphers``
+  or rarely `--data-ciphers-fallback`` should be used instead.
+
Encrypt data channel packets with cipher algorithm ``alg``.
  
The default is :code:`BF-CBC`, an abbreviation for Blowfish in Cipher

@@ -183,8 +186,9 @@ configured in a compatible way between both the local and 
remote side.
``--server`` ), or if ``--pull`` is specified (client-side, implied by
setting --client).
  
-  If both peers support and do not disable NCP, the negotiated cipher will

-  override the cipher specified by ``--cipher``.
+  If no common cipher is found is found during cipher negotiation, the


Duplicate "is found".


+  connection is terminated. To support old clients/server that do not
+  provide any cipher support see ``data-ciphers-fallback``.
  
Additionally, to allow for more smooth transition, if NCP is enabled,

OpenVPN will inherit the cipher of the peer if that cipher is different
@@ -201,8 +205,18 @@ configured in a compatible way between both the local and 
remote side.
This list is restricted to be 127 chars long after conversion to OpenVPN
ciphers.
  
-  This option was called ``ncp-ciphers`` in OpenVPN 2.4 but has been renamed

-  to ``data-ciphers`` in OpenVPN 2.5 to more accurately reflect its meaning.
+  This option was called 

Re: [Openvpn-devel] [PATCH 2/2] Avoid sending push request after receving push reply

[tincanteksup]

a little help..

On 26/07/2020 00:48, Arne Schwabe wrote:

The introduction of IV_PROTO_REQUEST_PUSH (c290df55) sometimes causes the
server to reply before we setup the push timer. The push reply will then clear
a timer that has not been setup yet. We then start sending push
request after we have gone through the whole initialisation already.

This patch also clears the connestion_established timer that sets up the
push request timer. This lead to the

management_set_state(management,  OPENVPN_STATE_GET_CONFIG, ...)

function not being called. But a to display "waiting for configuration..." or


I think this was meant to read as (moved 'a'):

But to display a "waiting for configuration..."



sending a "getting config state" after "initialisation" does not make sense
anyway.

Also add the IV_PROTO_REQUEST_PUSH feature as new feature in Changes.rst

Signed-off-by: Arne Schwabe 
---
  Changes.rst   | 11 +++
  src/openvpn/forward.c |  3 +++
  src/openvpn/push.c|  1 +
  3 files changed, 15 insertions(+)

diff --git a/Changes.rst b/Changes.rst
index 8fbaf419..e377a36c 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -37,6 +37,13 @@ Deferred client-connect
  asynchronous/deferred return of the configuration file in the same way
  as the auth-plugin.
  
+Faster connection setup

+A client will signal in the ``IV_PROTO`` variable that is in pull


I think this is meant to read:
variable that is in pull ->
variable that it is in pull



+mode. This allows the server to push the configuration options to
+the client without waiting for a ``PULL_REQUEST`` message. The feature
+is automatically enabled if both client and server support it and
+reduces the of connection setup time by one round-trip time.
+
  Deprecated features
  ---
  For an up-to-date list of all deprecated options, see this wiki page:
@@ -72,6 +79,10 @@ User-visible Changes
  - Support for building with OpenSSL 1.0.1 has been removed. The minimum
supported OpenSSL version is now 1.0.2.
  
+- The GET_CONFIG management state is ommited if the server pushes


ommited -> ommitted



+  the client configuration almost immediately as result of the
+  faster connection setup feature.
+
  
  Overview of changes in 2.4

  ==
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 30a3fd46..759fdbe1 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -425,6 +425,9 @@ check_push_request_dowork(struct context *c)
   *
   * Options like --up-delay need to be triggered by this function which
   * checks for connection establishment.
+ *
+ * Note: The process_incoming_push_reply currently assumes that this function
+ * only sets ups the pull request timer when pull is enabled.


ups -> up



   */
  void
  check_connection_established(struct context *c)
diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 84193afe..9c720b42 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -358,6 +358,7 @@ incoming_push_message(struct context *c, const struct 
buffer *buffer)
  }
  }
  event_timeout_clear(>c2.push_request_interval);
+event_timeout_clear(>c2.wait_for_connect);
  }
  
  goto cleanup;





___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Refuse PUSH_REQUEST as client/refactor process_incoming_push_request

[tincanteksup]

Sanity check:

On 26/07/2020 00:51, Arne Schwabe wrote:

When a server sends a client a push request, the client will reply
with a push reply. The reply is bogus and almost empty since almost
all the options that are normally set (remote ip etc) are unset.

I checked 2.4 and master and this does not have any security implications
or other bugs but it is still better to refuse this.

This code also refactors the method to get rid of the ret variable to
make the code flow easier to understand.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/push.c | 40 ++--
  1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 1c4f2033..84193afe 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -733,13 +733,19 @@ push_remove_option(struct options *o, const char *p)
  int
  process_incoming_push_request(struct context *c)
  {
-int ret = PUSH_MSG_ERROR;
+/* if we receive a message a client we do not want to reply to it
+ * so limit this to multi server */


This sentence does not make sense, suggestion:

If a client receives a push request then ignore it.  Only multi server 
will reply to a push requests.


Something like that ..





+if (c->options.mode != MODE_SERVER)
+{
+return PUSH_MSG_ERROR;
+}
+
  
  if (tls_authentication_status(c->c2.tls_multi, 0) == TLS_AUTHENTICATION_FAILED || c->c2.context_auth == CAS_FAILED)

  {
  const char *client_reason = tls_client_reason(c->c2.tls_multi);
  send_auth_failed(c, client_reason);
-ret = PUSH_MSG_AUTH_FAILURE;
+return PUSH_MSG_AUTH_FAILURE;
  }
  else if (c->c2.context_auth == CAS_SUCCEEDED)
  {
@@ -748,29 +754,27 @@ process_incoming_push_request(struct context *c)
  openvpn_time();
  if (c->c2.sent_push_reply_expiry > now)
  {
-ret = PUSH_MSG_ALREADY_REPLIED;
+return PUSH_MSG_ALREADY_REPLIED;
  }
-else
-{
-/* per-client push options - peer-id, cipher, ifconfig, 
ipv6-ifconfig */
-struct push_list push_list = { 0 };
-struct gc_arena gc = gc_new();
  
-if (prepare_push_reply(c, , _list)

-&& send_push_reply(c, _list))
-{
-ret = PUSH_MSG_REQUEST;
-c->c2.sent_push_reply_expiry = now + 30;
-}
-gc_free();
+int ret = PUSH_MSG_ERROR;
+/* per-client push options - peer-id, cipher, ifconfig, ipv6-ifconfig 
*/
+struct push_list push_list = { 0 };
+struct gc_arena gc = gc_new();
+
+if (prepare_push_reply(c, , _list)
+&& send_push_reply(c, _list))
+{
+ret = PUSH_MSG_REQUEST;
+c->c2.sent_push_reply_expiry = now + 30;
  }
+gc_free();
+return ret;
  }
  else
  {
-ret = PUSH_MSG_REQUEST_DEFERRED;
+return PUSH_MSG_REQUEST_DEFERRED;
  }
-
-return ret;
  }
  
  static void





___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Regarding deprecation of --route-nopull

[tincanteksup]

Hi,

thanks for the list!

On 24/07/2020 11:00, Arne Schwabe wrote:

To emulate pull-filter with pull-filter you need to block this list:

redirect-private
redirect-gateway
block-ipv6
client-nat
route
route-ipv6
route-gateway
route-metric
ip-win32
dhcp-option
dhcp-renew
register-dns
tap-sleep
block-outside-dns

but not block

route-gateway
route-dealy

And without looking at the source code you will be hard pressed to come
up with the same list.


Noted:
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--route-nopull


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/3] Refactor/Reformat tls_pre_decrypt

[tincanteksup]

3x minor typos

On 22/07/2020 10:30, Arne Schwabe wrote:

- Extract data packet handling to its own function
- Replace two instances of
   if (x) { code }
   with
   if (!x) return; code

- Remove extra curly braces that were used for pre C99 code style
   to be able to declare variables in the middle of a block

This patch is easier to review with "ignore white space" as the
diff is then a lot smaller in that case and the changes more obvious.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/ssl.c | 791 --
  1 file changed, 410 insertions(+), 381 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 06dc9f8f..6d146a63 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -3166,6 +3166,102 @@ nohard:
   * to implement a multiplexed TLS channel over the TCP/UDP port.
   */
  
+static inline void

+handle_data_channel_paket(struct tls_multi *multi,
+  const struct link_socket_actual *from,
+  struct buffer *buf,
+  struct crypto_options **opt,
+  bool floated,
+  const uint8_t **ad_start)
+{
+struct gc_arena gc = gc_new();
+
+uint8_t c = *BPTR(buf);
+int op = c >> P_OPCODE_SHIFT;
+int key_id = c & P_KEY_ID_MASK;
+
+/* data channel packet */
+for (int i = 0; i < KEY_SCAN_SIZE; ++i)
+{
+struct key_state *ks = multi->key_scan[i];
+
+/*
+ * This is the basic test of TLS state compatibility between a local 
OpenVPN
+ * instance and its remote peer.
+ *
+ * If the test fails, it tells us that we are getting a packet from a 
source
+ * which claims reference to a prior negotiated TLS session, but the 
local
+ * OpenVPN instance has no memory of such a negotiation.
+ *
+ * It almost always occurs on UDP sessions when the passive side of the
+ * connection is restarted without the active side restarting as well 
(the
+ * passive side is the server which only listens for the connections, 
the
+ * active side is the client which initiates connections).
+ */
+if (DECRYPT_KEY_ENABLED(multi, ks)
+&& key_id == ks->key_id
+&& (ks->authenticated == KS_AUTH_TRUE)
+&& (floated || link_socket_actual_match(from, >remote_addr)))
+{
+if (!ks->crypto_options.key_ctx_bi.initialized)
+{
+msg(D_MULTI_DROPPED,
+"Key %s [%d] not initialized (yet), dropping packet.",
+print_link_socket_actual(from, ), key_id);
+goto error_lite;
+}
+
+/* return appropriate data channel decrypt key in opt */
+*opt = >crypto_options;
+if (op == P_DATA_V2)
+{
+*ad_start = BPTR(buf);
+}
+ASSERT(buf_advance(buf, 1));
+if (op == P_DATA_V1)
+{
+*ad_start = BPTR(buf);
+}
+else if (op == P_DATA_V2)
+{
+if (buf->len < 4)
+{
+msg(D_TLS_ERRORS, "Protocol error: received P_DATA_V2 from %s but 
length is < 4",
+print_link_socket_actual(from, ));
+goto error;
+}
+ASSERT(buf_advance(buf, 3));
+}
+
+++ks->n_packets;
+ks->n_bytes += buf->len;
+dmsg(D_TLS_KEYSELECT,
+ "TLS: tls_pre_decrypt, key_id=%d, IP=%s",
+ key_id, print_link_socket_actual(from, ));
+gc_free();
+return;
+}
+}
+
+msg(D_TLS_ERRORS,
+"TLS Error: local/remote TLS keys are out of sync: %s [%d]",
+print_link_socket_actual(from, ), key_id);
+goto error_lite;
+
+
+done:
+buf->len = 0;
+*opt = NULL;
+gc_free();
+return;
+
+error:
+++multi->n_soft_errors;
+error_lite:
+tls_clear_error();
+goto done;
+}
+
  /*
   *
   * When we are in TLS mode, this is the first routine which sees
@@ -3199,440 +3295,374 @@ tls_pre_decrypt(struct tls_multi *multi,
  bool floated,
  const uint8_t **ad_start)
  {
+
+if (buf->len <= 0)
+{
+buf->len = 0;
+*opt = NULL;
+return false;
+}
+
  struct gc_arena gc = gc_new();
  bool ret = false;
  
-if (buf->len > 0)

+/* get opcode  */
+uint8_t pkt_firstbyte = *BPTR(buf);
+int op = pkt_firstbyte >> P_OPCODE_SHIFT;
+
+if ((op == P_DATA_V1) || (op == P_DATA_V2))
  {
-int i;
-int op;
-int key_id;
+handle_data_channel_paket(multi, from, buf, opt, floated, ad_start);
+return false;
+}
  
-/* get opcode and key ID */

+/* get key_id */
+int key_id = pkt_firstbyte & P_KEY_ID_MASK;
+
+/* 

Re: [Openvpn-devel] [PATCH v6 4/9] Implement tls-groups option to specify eliptic curves/groups

[tincanteksup]

8x fix - 2x suggestion

On 21/07/2020 16:49, Arne Schwabe wrote:

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 shorter list is reasonable.

However, when using certificates with exotic curves that are not on
the group list, the signatures of these certificates will no longer
be accepted.

The tls-groups  option allows to modify the group list to account
for these corner cases.


The tls-groups  option ->
The tls-groups option



Patch V2: Uses local gc_arena instead of malloc/free, reword commit
   message. Fix other typos/clarify messages

Patch V3: Style fixes, adjust code to changes from mbed tls session
   fix


mbed tls ->
mbedTLS



Patch V5: Fix compilation with OpenSSL 1.0.2

Patch V6: Redo the 'while((token = strsep(_groups, ":"))' change
   that accidently got lost.


that accidently ->
which accidentally



Signed-off-by: Arne Schwabe 
---
  README.ec   |  7 ++--
  configure.ac|  1 +
  doc/man-sections/encryption-options.rst |  6 +--
  doc/man-sections/tls-options.rst| 27 +++-
  src/openvpn/openssl_compat.h|  6 +++
  src/openvpn/options.c   | 10 -
  src/openvpn/options.h   |  1 +
  src/openvpn/ssl.c   |  6 +++
  src/openvpn/ssl_backend.h   | 10 +
  src/openvpn/ssl_mbedtls.c   | 45 
  src/openvpn/ssl_mbedtls.h   |  1 +
  src/openvpn/ssl_ncp.c   |  5 +--
  src/openvpn/ssl_openssl.c   | 55 -
  13 files changed, 168 insertions(+), 12 deletions(-)

diff --git a/README.ec b/README.ec
index 32938017..61f23b2e 100644
--- a/README.ec
+++ b/README.ec
@@ -12,14 +12,15 @@ OpenVPN 2.4.0 and newer automatically initialize ECDH 
parameters. When ECDSA is
  used for authentication, the curve used for the server certificate will be 
used
  for ECDH too. When autodetection fails (e.g. when using RSA certificates)
  OpenVPN lets the crypto library decide if possible, or falls back to the
-secp384r1 curve.
+secp384r1 curve. The list of groups/curves that the crypto library will choose
+from can be set with the --tls-groups  option.
  
  An administrator can force an OpenVPN/OpenSSL server to use a specific curve

  using the --ecdh-curve  option with one of the curves listed as
-available by the --show-curves option. Clients will use the same curve as
+available by the --show-groups option. Clients will use the same curve as
  selected by the server.
  
-Note that not all curves listed by --show-curves are available for use with TLS;

+Note that not all curves listed by --show-groups are available for use with 
TLS;
  in that case connecting will fail with a 'no shared cipher' TLS error.
  
  Authentication (ECDSA)

diff --git a/configure.ac b/configure.ac
index 02cb0567..f8279924 100644
--- a/configure.ac
+++ b/configure.ac
@@ -929,6 +929,7 @@ if test "${with_crypto_library}" = "openssl"; then
OpenSSL_version \
SSL_CTX_get_default_passwd_cb \
SSL_CTX_get_default_passwd_cb_userdata \
+   SSL_CTX_set1_groups \
SSL_CTX_set_security_level \
X509_get0_notBefore \
X509_get0_notAfter \
diff --git a/doc/man-sections/encryption-options.rst 
b/doc/man-sections/encryption-options.rst
index a59f636c..ee34f14e 100644
--- a/doc/man-sections/encryption-options.rst
+++ b/doc/man-sections/encryption-options.rst
@@ -27,9 +27,9 @@ SSL Library information
(Standalone) Show currently available hardware-based crypto acceleration
engines supported by the OpenSSL library.
  
---show-curves

-  (Standalone) Show all available elliptic curves to use with the
-  ``--ecdh-curve`` option.
+--show-groups
+  (Standalone) Show all available elliptic curves/groups to use with the
+  ``--ecdh-curve`` and ``tls-groups`` options.
  
  Generating key material

  ---
diff --git a/doc/man-sections/tls-options.rst b/doc/man-sections/tls-options.rst
index 92b832cd..ccc90ac9 100644
--- a/doc/man-sections/tls-options.rst
+++ b/doc/man-sections/tls-options.rst
@@ -338,6 +338,31 @@ certificates and keys: https://github.com/OpenVPN/easy-rsa
Use ``--tls-crypt`` instead if you want to use the key file to not only
authenticate, but also encrypt the TLS control channel.
  
+--tls-groups list

+A list of allowable groups/curves in order of preference.
+
+Set the allowed elictipic curves/groups for the TLS session.


elictipic ->
elliptic


+These groups are  allowed to be used in signatures and key exchange.
+
+mbed TLS currently 

Re: [Openvpn-devel] [PATCH 1/9 v3] Indicate that a client is in pull mode in IV_PROTO

[tincanteksup]

1x spelling 1x grammar

On 21/07/2020 17:38, Arne Schwabe wrote:

This allows us to skip waiting for the first PUSH_REQUEST message from
the client to send the response.

This changes the interpretation of IV_PROTO from a scalar to a bitfield
Since we only have IV_PROTO=2 defined so far and will support DATA_V2
this should not make any problem. This avoid adding another IV_xxx variable
that takes valuable space in the protocol frame.

Signed-off-by: Arne Schwabe 

Patch V2: Use bitmask for IV_PROTO_DATA_V2 and add more documentation.

Patch V3: Rewrite IV_PROTO paragraph in man page, incoperate spelling fixes
   by tincanteksup.


incoperate -> incorporate =]

Please feel free use my full details:
Richard Bonhomme 



Signed-off-by: Arne Schwabe 
---
  doc/man-sections/server-options.rst | 10 --
  src/openvpn/multi.c | 12 ++--
  src/openvpn/ssl.c   | 15 +--
  src/openvpn/ssl.h   | 16 
  4 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/doc/man-sections/server-options.rst 
b/doc/man-sections/server-options.rst
index c8e9fc61..babf33d3 100644
--- a/doc/man-sections/server-options.rst
+++ b/doc/man-sections/server-options.rst
@@ -464,8 +464,14 @@ fast hardware. SSL/TLS authentication must be used in this 
mode.
:code:`IV_LZ4=1`
  If the client supports LZ4 compressions.
  
-  :code:`IV_PROTO=2`

-If the client supports peer-id floating mechanism
+  :code:`IV_PROTO`
+Details about protocol extensions that the peer supports. The
+variable is a bitfield and the bits are defined as follows
+(starting a bit 0 for the first (unused) bit:
+
+- bit 1: The peer supports peer-id floating mechanism
+- bit 2: The client expects a push-reply and the server may
+  send this reply without waiting for a push-request first.
  
:code:`IV_NCP=2`

  Negotiable ciphers, client supports ``--cipher`` pushed by
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 2ae9c03e..b83a0f06 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1792,10 +1792,18 @@ multi_client_set_protocol_options(struct context *c)
  {
  int proto = 0;
  int r = sscanf(optstr, "IV_PROTO=%d", );
-if ((r == 1) && (proto >= 2))
+if (r == 1)
  {
-tls_multi->use_peer_id = true;
+if (proto & IV_PROTO_DATA_V2)
+{
+tls_multi->use_peer_id = true;
+}
+if (proto & IV_PROTO_REQUEST_PUSH)
+{
+c->c2.push_request_received = true;
+}
  }
+
  }
  
  /* Select cipher if client supports Negotiable Crypto Parameters */

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 54a23011..04d78a81 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2299,8 +2299,19 @@ push_peer_info(struct buffer *buf, struct tls_session 
*session)
  buf_printf(, "IV_PLAT=win\n");
  #endif
  
-/* support for P_DATA_V2 */

-buf_printf(, "IV_PROTO=2\n");
+/* support for P_DATA_V2*/
+int iv_proto = IV_PROTO_DATA_V2;
+
+/* support for receiving push_reply before sending
+ * push request, also signal that the client wants
+ * to get push-reply messages without without requiring a round
+ * trip for a push request message*/
+if(session->opt->pull)
+{
+iv_proto |= IV_PROTO_REQUEST_PUSH;
+}
+
+buf_printf(, "IV_PROTO=%d\n", iv_proto);
  
  /* support for Negotiable Crypto Parameters */

  if (session->opt->ncp_enabled
diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
index 58a9b0d4..0da16974 100644
--- a/src/openvpn/ssl.h
+++ b/src/openvpn/ssl.h
@@ -99,6 +99,22 @@
  /* Maximum length of OCC options string passed as part of auth handshake */
  #define TLS_OPTIONS_LEN 512
  
+/* Definitions of the bits in the IV_PROTO bitfield

+ *
+ * In older OpenVPN versions this used in a comparison


In older OpenVPN versions this used in a comparison ->
In older OpenVPN versions this is used in a comparison



+ * IV_PROTO >= 2 to determine if DATA_V2 is supported.
+ * Therefore any client announcing any of the flags must
+ * also announce IV_PROTO_DATA_V2. We also treat bit 0
+ * as reserved for this reason */
+
+/** Support P_DATA_V2 */
+#define IV_PROTO_DATA_V2(1<<1)
+
+/** Assume client will send a push request and server does not need
+ * to wait for a push-request to send a push-reply */
+#define IV_PROTO_REQUEST_PUSH   (1<<2)
+
+
  /* Default field in X509 to be username */
  #define X509_USERNAME_FIELD_DEFAULT "CN"
  




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 5/9] Remove key-method 1

[tincanteksup]

1x typo

On 21/07/2020 11:01, Arne Schwabe wrote:

Key-method 1 is only needed to talk to pre OpenVPN 2.0 clients.

Patch V2: Fix style. Make V1 op codes illegal, remove all code handling
   v1 op codes and give a good warning message if we encounter
   them in the legal op codes pre-check.

Patch V3: Add a bit more comments in the existing methods.

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  |   1 -
  src/openvpn/options.c   |  35 +---
  src/openvpn/options.h   |   4 -
  src/openvpn/ssl.c   | 240 +---
  src/openvpn/ssl.h   |  19 +--
  src/openvpn/ssl_common.h|   1 -
  11 files changed, 53 insertions(+), 268 deletions(-)

diff --git a/doc/doxygen/doc_control_processor.h 
b/doc/doxygen/doc_control_processor.h
index f87324cc..1bbf2d2d 100644
--- a/doc/doxygen/doc_control_processor.h
+++ b/doc/doxygen/doc_control_processor.h
@@ -175,11 +175,7 @@
   *appropriate messages to be sent.
   *
   * @par Functions which control data channel key generation
- *  - Key method 1 key exchange functions:
- * - \c key_method_1_write(), generates and processes key material to
- *   be sent to the remote OpenVPN peer.
- * - \c key_method_1_read(), processes key material received from the
- *   remote OpenVPN peer.
+ *  - Key method 1 key exchange functions were removed from OpenVPN 2.5
   *  - Key method 2 key exchange functions:
   * - \c key_method_2_write(), generates and processes key material to
   *   be sent to the remote OpenVPN peer.
diff --git a/doc/doxygen/doc_key_generation.h b/doc/doxygen/doc_key_generation.h
index efe61155..4bb9c708 100644
--- a/doc/doxygen/doc_key_generation.h
+++ b/doc/doxygen/doc_key_generation.h
@@ -131,11 +131,7 @@ S_ACTIVE   
 S_ACTIVE
   * control_processor Control Channel Processor module's\endlink \c
   * tls_process() function and control the %key generation and exchange
   * process as follows:
- * - %Key method 1:
- *   - \c key_method_1_write(): generate random material locally, and load
- * as "sending" keys.
- *   - \c key_method_1_read(): read random material received from remote
- * peer, and load as "receiving" keys.
+ * - %Key method 1 has been removed in OpenVPN 2.5
   * - %Key method 2:
   *   - \c key_method_2_write(): generate random material locally, and if
   * in server mode generate %key expansion.
diff --git a/doc/doxygen/doc_protocol_overview.h 
b/doc/doxygen/doc_protocol_overview.h
index 3f48b18a..08212223 100644
--- a/doc/doxygen/doc_protocol_overview.h
+++ b/doc/doxygen/doc_protocol_overview.h
@@ -150,7 +150,7 @@
   *
   * @subsection network_protocol_control_plaintext Structure of plaintext 
control channel messages
   *
- *  - %Key method 1:
+ *  - %Key method 1 (support removed in OpenVPN 2.5):
   * - Cipher %key length in bytes (1 byte).
   * - Cipher %key (n bytes).
   * - HMAC %key length in bytes (1 byte).
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 5c4370a8..698451d1 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1100,7 +1100,7 @@ process_incoming_link_part1(struct context *c, struct 
link_socket_info *lsi, boo
  floated, _start))
  {
  /* Restore pre-NCP frame parameters */
-if (is_hard_reset(opcode, c->options.key_method))
+if (is_hard_reset_method2(opcode))
  {
  c->c2.frame = c->c2.frame_initial;
  #ifdef ENABLE_FRAGMENT
diff --git a/src/openvpn/helper.c b/src/openvpn/helper.c
index 6e9cc63c..a1d03070 100644
--- a/src/openvpn/helper.c
+++ b/src/openvpn/helper.c
@@ -490,11 +490,6 @@ helper_client_server(struct options *o)
   */
  if (o->client)
  {
-if (o->key_method != 2)
-{
-msg(M_USAGE, "--client requires --key-method 2");
-}
-
  o->pull = true;
  o->tls_client = true;
  }
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index e9c01629..b96d1471 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2852,7 +2852,6 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
  to.ssl_ctx = c->c1.ks.ssl_ctx;
  to.key_type = c->c1.ks.key_type;
  to.server = options->tls_server;
-to.key_method = options->key_method;
  to.replay = options->replay;
  to.replay_window = options->replay_window;
  to.replay_time = options->replay_time;
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 7da04b6f..14d4c911 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -881,7 +881,6 @@ 

Re: [Openvpn-devel] [PATCH v7] client-connect: Add documentation for the deferred client connect feature

[tincanteksup]

1x typo, 3x suggestions

On 20/07/2020 15:27, Arne Schwabe wrote:

Signed-off-by: David Sommerseth 
Signed-off-by: Arne Schwabe 

Patch V5: Fix typos, clarify man page section about deferred client-connect
   script. Add section to Changes.rst

Patch V6: Convert manpage to rst

   It also incoroporates suggested changes from Richard Bonhomme


incoroporates -> incorporates



 [0]

[0] Message-ID: <82c2d70f-e2f9-f810-2c55-788358a0c...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20331.html

Patch V7: Reinclude the changes of Changes.rst and openvpn-plugin.h


Reinclude -> Re-include (or maybe "Restore the lost changes of..")


   Clarify some parts of the documentation.
---
  Changes.rst  |  5 +
  doc/man-sections/generic-options.rst | 11 ++
  doc/man-sections/script-options.rst  | 33 
  include/openvpn-plugin.h.in  | 21 +-
  4 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 34abcd97..78a66650 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -25,6 +25,11 @@ Improved Data channel cipher negotiation
  Asynchronous (deferred) authentication support for auth-pam plugin.
  See src/plugins/auth-pam/README.auth-pam for details.
  
+Deferred client-connect

+The ``--client-connect`` option and the connect plugin API allow
+asynchronous/deferred return of the configuration file in the same way
+as the auth-plugin.
+
  Deprecated features
  ---
  For an up-to-date list of all deprecated options, see this wiki page:
diff --git a/doc/man-sections/generic-options.rst 
b/doc/man-sections/generic-options.rst
index d44dc05f..a07fe7e7 100644
--- a/doc/man-sections/generic-options.rst
+++ b/doc/man-sections/generic-options.rst
@@ -394,11 +394,14 @@ which mode OpenVPN is configured as.
  
This directory will be used by in the following cases:
  
-  * ``--client-connect`` scripts to dynamically generate client-specific

-configuration files.
+  * ``--client-connect`` scripts and :code:`OPENVPN_PLUGIN_CLIENT_CONNECT`
+plug-in hook to dynamically generate client-specific configuration
+:code:`client_connect_config_file` and return success/failure via
+:code:`client_connect_deferred_file` when using deferred client connect
+method
  
-  * :code:`OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY` plugin hook to return

-success/failure via ``auth_control_file`` when using deferred auth
+  * :code:`OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY` plug-in hooks returns
+success/failure via :code:`auth_control_file` when using deferred auth
  method
  
* :code:`OPENVPN_PLUGIN_ENABLE_PF` plugin hook to pass filtering rules

diff --git a/doc/man-sections/script-options.rst 
b/doc/man-sections/script-options.rst
index ddc1363c..a1d489b8 100644
--- a/doc/man-sections/script-options.rst
+++ b/doc/man-sections/script-options.rst
@@ -137,6 +137,13 @@ SCRIPT HOOKS
returns a non-zero error status, it will cause the client to be
disconnected.
  
+  If a ``--client-connect`` wants to defer the generating of the

+  configuration then the script should use the
+  :code:`client_connect_deferred_file` and
+  :code:`client_connect_config_file` environment variables. And write
+  status accordingly into these files.  See the `Environmental Variables`_
+  section for more details.
+
  --client-disconnect cmd
Like ``--client-connect`` but called on client instance shutdown. Will
not be called unless the ``--client-connect`` script and plugins (if
@@ -512,6 +519,32 @@ instances.
  Total number of bytes sent to client during VPN session. Set prior to
  execution of the ``--client-disconnect`` script.
  
+:code:`client_connect_config_file`

+The path to the configuration file that should be written by the


suggest:
should be written by the ->
should be written to by the



+``--client-connect`` script.  The content of this environment variable
+is identical to the file as an argument of the called
+``--client-connect`` script.
+
+:code:`client_connect_deferred_file`
+This file can be optionally written to to communicate a status code of


suggest:
written to to communicate
written to in order to communicate



+the ``--client-connect`` script.  The first character in the file must
+be either :code:`1` to indicate normal script execution, :code:`0`
+indicates an error (in the same way that a non zero exit status does)
+or :code:`2` to indicate that the script deferred returning the config
+file. When the script defers returning the configuration, it must also
+write :code:`2` to the file to indicate the deferral.
+
+A background process or similar must then take care of writing the
+configuration to the file indicated by the
+:code:`client_connect_config_file` environment variable and when
+finished, write the a :code:`1` to 

Re: [Openvpn-devel] [PATCH v2 1/9] Indicate that a client is in pull mode in IV_PROTO

[tincanteksup]

Hi,

On 20/07/2020 10:17, Arne Schwabe wrote:

This allows us to skip waiting for the first PUSH_REQUEST message from
the client to send the response.

This changes the interpretation of IV_PROTO from a scalar to a bitfield
Since we only have IV_PROTO=2 defined so far and will support DATA_V2
this should not make any problem. This avoid adding another IV_xxx variable
that takes valuable space in the protocol frame.

Signed-off-by: Arne Schwabe 

Patch V2: Use bitmask for IV_PROTO_DATA_V2 and add more documentation.

Signed-off-by: Arne Schwabe 
---
  doc/man-sections/server-options.rst |  6 +-
  src/openvpn/multi.c | 12 ++--
  src/openvpn/ssl.c   | 15 +--
  src/openvpn/ssl.h   | 16 
  4 files changed, 44 insertions(+), 5 deletions(-)

diff --git a/doc/man-sections/server-options.rst 
b/doc/man-sections/server-options.rst
index c8e9fc61..e24cb135 100644
--- a/doc/man-sections/server-options.rst
+++ b/doc/man-sections/server-options.rst
@@ -464,9 +464,13 @@ fast hardware. SSL/TLS authentication must be used in this 
mode.
:code:`IV_LZ4=1`
  If the client supports LZ4 compressions.
  
-  :code:`IV_PROTO=2`

+  :code:`IV_PROTO=2` (bit 2)
  If the client supports peer-id floating mechanism
  
+  :code:`IV_PROTO=4` (bit 3)

+When the client expects a push-reply and the server may
+send this reply without waiting for a push-request first.
+
:code:`IV_NCP=2`
  Negotiable ciphers, client supports ``--cipher`` pushed by
  the server, a value of 2 or greater indicates client supports
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index d9456f34..cb950db5 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1792,10 +1792,18 @@ multi_client_set_protocol_options(struct context *c)
  {
  int proto = 0;
  int r = sscanf(optstr, "IV_PROTO=%d", );
-if ((r == 1) && (proto >= 2))
+if (r == 1)
  {
-tls_multi->use_peer_id = true;
+if (proto & IV_PROTO_DATA_V2)
+{
+tls_multi->use_peer_id = true;
+}
+if (proto & IV_PROTO_REQUEST_PUSH)
+{
+c->c2.push_request_received = true;
+}
  }
+
  }
  
  /* Select cipher if client supports Negotiable Crypto Parameters */

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 54a23011..04d78a81 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2299,8 +2299,19 @@ push_peer_info(struct buffer *buf, struct tls_session 
*session)
  buf_printf(, "IV_PLAT=win\n");
  #endif
  
-/* support for P_DATA_V2 */

-buf_printf(, "IV_PROTO=2\n");
+/* support for P_DATA_V2*/
+int iv_proto = IV_PROTO_DATA_V2;
+
+/* support for receiving push_reply before sending
+ * push request, also signal that the client wants
+ * to get push-reply messages without without requiring a round
+ * trip for a push request message*/
+if(session->opt->pull)
+{
+iv_proto |= IV_PROTO_REQUEST_PUSH;
+}
+
+buf_printf(, "IV_PROTO=%d\n", iv_proto);
  
  /* support for Negotiable Crypto Parameters */

  if (session->opt->ncp_enabled
diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
index 58a9b0d4..81f8810e 100644
--- a/src/openvpn/ssl.h
+++ b/src/openvpn/ssl.h
@@ -99,6 +99,22 @@
  /* Maximum length of OCC options string passed as part of auth handshake */
  #define TLS_OPTIONS_LEN 512
  
+/* Definitions of the bits in the IV_PROTO bitfield

+ *
+ * In older OpenVPN versions this used as comparision


comparision -> comparison

Also, paragraph are not make sense to me .. ?



+ * IV_PROTO >= 2 to determine if DATA_V2 is supported.
+ * Therefore any client announcing any of the flags must
+ * also announce IV_PROTO_DATA_V2. We also treat bit 0
+ * as reserved for this reason */
+
+/** Support P_DATA_V2 */
+#define IV_PROTO_DATA_V2(1<<1)
+
+/** Assume client will send a push request and server does not need
+ * to wait for a push-request to send a push-reply */
+#define IV_PROTO_REQUEST_PUSH   (1<<2)
+
+
  /* Default field in X509 to be username */
  #define X509_USERNAME_FIELD_DEFAULT "CN"
  




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v8 2/5] client-connect: Add deferred support to the client-connect script handler

[tincanteksup]

4x typo

On 19/07/2020 18:34, 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 client_connect_state struct.

In addition, the patch also allows the storage of the client config file name
in struct client_connect_state.

Both changes are used by the client-connect script handler to support deferred
client-connection handling.  The deferred return value file (deferred_ret_file)
is passed to the actual script via the environment.  If the script succeeds and
writes the value for deferral into the deferred_ret_file, the handler knows to
indicate deferral.  Later on, the deferred handler checks whether the value of
the deferred_ret_file has been updated to success or failure.

Signed-off-by: Fabian Knittel 
Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c | 229 +---
  src/openvpn/multi.h |  12 +++
  2 files changed, 228 insertions(+), 13 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index aab15cf7..165a3209 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1851,6 +1851,171 @@ multi_client_set_protocol_options(struct context *c)
  }
  }
  
+/**

+ * Delete the temporary file for the return value of client connect
+ * It also removes it from it from client_connect_defer_state and
+ * environment
+ */
+static void
+ccs_delete_deferred_ret_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+if (!ccs->deferred_ret_file)
+{
+return;
+}
+
+setenv_del(mi->context.c2.es, "client_connect_deferred_file");
+if (!platform_unlink(ccs->deferred_ret_file))
+{
+msg(D_MULTI_ERRORS, "MULTI: problem deleting temporary file: %s",
+ccs->deferred_ret_file);
+}
+free(ccs->deferred_ret_file);
+ccs->deferred_ret_file = NULL;
+}
+
+/**
+ * Create a temporary file for the return value of client connect
+ * and puts it into the client_connect_defer_state and environment
+ * as "client_connect_deferred_file"
+ *
+ * @return boolean value if creation was successfull


successfull -> successful



+ */
+static bool
+ccs_gen_deferred_ret_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+struct gc_arena gc = gc_new();
+const char *fn;
+
+/* Delete file if it already exists */
+ccs_delete_deferred_ret_file(mi);
+
+fn = platform_create_temp_file(mi->context.options.tmp_dir, "ccr", );
+if (!fn)
+{
+gc_free();
+return false;
+}
+ccs->deferred_ret_file = string_alloc(fn, NULL);
+
+setenv_str(mi->context.c2.es, "client_connect_deferred_file",
+   ccs->deferred_ret_file);
+
+gc_free();
+return true;
+}
+
+/**
+ * Tests whether the deferred return value file exists and returns the
+ * contained return value.
+ *
+ * @return CC_RET_SKIPPED if the file does not exist or is empty.
+ * CC_RET_DEFERRED, CC_RET_SUCCEEDED or CC_RET_FAILED depending on
+ * the value stored in the file.
+ */
+static enum client_connect_return
+ccs_test_deferred_ret_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+FILE *fp = fopen(ccs->deferred_ret_file, "r");
+if (!fp)
+{
+return CC_RET_SKIPPED;
+}
+
+enum client_connect_return ret = CC_RET_SKIPPED;
+const int c = fgetc(fp);
+switch (c)
+{
+case '0':
+ret = CC_RET_FAILED;
+break;
+
+case '1':
+ret = CC_RET_SUCCEEDED;
+break;
+
+case '2':
+ret = CC_RET_DEFERRED;
+break;
+
+case EOF:
+if (feof(fp))
+{
+ret = CC_RET_SKIPPED;
+break;
+}
+
+/* Not EOF, but other error fall through to error state */
+default:
+/* We received an unknown/unexpected value.  Assume failure. */
+msg(M_WARN, "WARNING: Unknown/unexcepted value in deferred"


unexcepted -> unexpected or unaccepted



+"client-connect resultfile");
+ret = CC_RET_FAILED;
+}
+fclose(fp);
+
+return ret;
+}
+
+/**
+ * Deletes the temporary file for the config directives of the  client connect
+ * script and removes it into the client_connect_defer_state and environment
+ *
+ */
+static void
+ccs_delete_config_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+if (ccs->config_file)
+{
+setenv_del(mi->context.c2.es, "client_connect_config_file");
+if (!platform_unlink(ccs->config_file))
+{
+msg(D_MULTI_ERRORS, "MULTI: problem deleting temporary file: %s",
+ 

Re: [Openvpn-devel] [PATCH 12/16] doc/man: Misc grammar and typo fixes

[tincanteksup]

Hi,

I recognise all these changes as my own.

Even so, I do not understand why these two variant are present:

EG:
+   entry is tried. Specifying ``n`` as :code:`1` would try

See --connect-retry-max here:
https://gitlab.com/dazo/openvpn/-/blob/dev/man-reformatting/doc/man-sections/client-options.rst


I am still happy to ACK this particular patch, hope it helps.

Acked-by: Richard Bonhomme 


On 15/07/2020 23:30, David Sommerseth wrote:

From: Richard Bonhomme 

Signed-off-by: Richard Bonhomme 
Signed-off-by: David Sommerseth 
---
  doc/man-sections/advanced-options.rst|  4 +--
  doc/man-sections/client-options.rst  | 17 +-
  doc/man-sections/connection-profiles.rst |  2 +-
  doc/man-sections/encryption-options.rst  |  8 ++---
  doc/man-sections/examples.rst|  2 +-
  doc/man-sections/pkcs11-options.rst  |  2 +-
  doc/man-sections/plugin-options.rst  |  4 +--
  doc/man-sections/protocol-options.rst| 18 +--
  doc/man-sections/script-options.rst  | 18 +--
  doc/man-sections/server-options.rst  | 40 
  doc/man-sections/signals.rst |  2 +-
  doc/man-sections/tls-options.rst |  6 ++--
  doc/man-sections/unsupported-options.rst |  4 +--
  doc/man-sections/vpn-network-options.rst |  4 +--
  doc/man-sections/windows-options.rst |  4 +--
  15 files changed, 67 insertions(+), 68 deletions(-)

diff --git a/doc/man-sections/advanced-options.rst 
b/doc/man-sections/advanced-options.rst
index 262e568c..dbf7799c 100644
--- a/doc/man-sections/advanced-options.rst
+++ b/doc/man-sections/advanced-options.rst
@@ -60,7 +60,7 @@ used when debugging or testing out special usage scenarios.
needs.
  
  --rcvbuf size

-  Set the TCP/UDP socket receive buffer size. Defaults to operation system
+  Set the TCP/UDP socket receive buffer size. Defaults to operating system
default.
  
  --shaper n

@@ -88,7 +88,7 @@ used when debugging or testing out special usage scenarios.
OpenVPN allows ``n`` to be between 100 bytes/sec and 100 Mbytes/sec.
  
  --sndbuf size

-  Set the TCP/UDP socket send buffer size. Defaults to operation system
+  Set the TCP/UDP socket send buffer size. Defaults to operating system
default.
  
  --tcp-queue-limit n

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index 966ede1e..98b80cb1 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -26,9 +26,9 @@ configuration.
pass over this token as the password instead of the password the user
provided. The authentication token can only be reset by a full reconnect
where the server can push new options to the client. The password the
-  user entered is never preserved once an authentication token have been
-  set. If the OpenVPN server side rejects the authentication token, the
-  client will receive an ``AUTH_FAIL`` and disconnect.
+  user entered is never preserved once an authentication token has been
+  set. If the OpenVPN server side rejects the authentication token then
+  the client will receive an ``AUTH_FAIL`` and disconnect.
  
The purpose of this is to enable two factor authentication methods, such

as HOTP or TOTP, to be used without needing to retrieve a new OTP code
@@ -130,7 +130,7 @@ configuration.
Set ``--verb 6`` for debugging info showing the transformation of
src/dest addresses in packets.
  
---connect-retry args

+--connect-retry n
Wait ``n`` seconds between connection attempts (default :code:`5`).
Repeated reconnection attempts are slowed down after 5 retries per
remote by doubling the wait time after each unsuccessful attempt. An
@@ -139,8 +139,8 @@ configuration.
  
  --connect-retry-max n

``n`` specifies the number of times each ``--remote`` or
-   entry is tried. Specifying ``n`` as one would try each
-  entry exactly once. A successful connection resets the counter.
+   entry is tried. Specifying ``n`` as :code:`1` would try
+  each entry exactly once. A successful connection resets the counter.
(default *unlimited*).
  
  --connect-timeout n

@@ -331,9 +331,8 @@ configuration.
  
  --server-poll-timeout n

When connecting to a remote server do not wait for more than ``n``
-  seconds waiting for a response before trying the next server. The
-  default value is 120s. This timeout includes proxy and TCP connect
-  timeouts.
+  seconds for a response before trying the next server. The default value
+  is 120s. This timeout includes proxy and TCP connect timeouts.
  
  --static-challenge args

Enable static challenge/response protocol
diff --git a/doc/man-sections/connection-profiles.rst 
b/doc/man-sections/connection-profiles.rst
index f72db56e..fd3382b2 100644
--- a/doc/man-sections/connection-profiles.rst
+++ b/doc/man-sections/connection-profiles.rst
@@ -4,7 +4,7 @@ CONNECTION PROFILES
  Client configuration files may contain multiple remote servers which
  it will 

Re: [Openvpn-devel] [PATCH v6 8/14] client-connect: Add CC_RET_DEFERRED and cope with deferred client-connect

[tincanteksup]

typo

On 15/07/2020 15:16, Arne Schwabe wrote:

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 exited and re-entered as
many times as necessary - without losing the client-connect handling state.

The patch also adds the new return value CC_RET_DEFERRED which indicates that
the handler couldn't complete immediately, and needs to be called later.  At
that point multi_connection_established() will exit without indicating
completion.

Each client-connect handler now has an (optional) additional call-back:  The
call-back for handling the deferred case.  If the main call-back returns
CC_RET_DEFERRED, the next call to the handler will be through the deferred
call-back.

Signed-off-by: Fabian Knittel 

Patch V3: Use a static struct in multi_instance instead of using
   malloc/free and use two states (deffered with and without


deffered -> deferred


   result) instead of one to eliminate the counter that was
   only tested for > 0.

Patch V5: Use new states in context_auth instead of the extra state
   that the patch series previously used.

Patch V6: Restructure code to make it a bit more readable, rebase on
   master.

Signed-off-by: Arne Schwabe 
---



No further Red lines except for code and a contraction or two. eg: auth.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5 14/14] client-connect: Add documentation for the deferred client connect feature

[tincanteksup]

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

Signed-off-by: Arne Schwabe 
---
  Changes.rst |  4 +++
  doc/openvpn.8   | 55 +++--
  include/openvpn-plugin.h.in | 21 ++
  3 files changed, 71 insertions(+), 9 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 42f0d190..47fa6883 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -3,6 +3,10 @@ Overview of changes in 2.5
  
  New features

  
+Deferred client-connect
+client-connect and the connect plugin API allow now asynchronous/deferred


allow now -> now allow



+return of the configuration file in the same way as the auth-plugin.
+
  Client-specific tls-crypt keys (``--tls-crypt-v2``)
  ``tls-crypt-v2`` adds the ability to supply each client with a unique
  tls-crypt key.  This allows large organisations and VPN providers to 
profit
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 03ae5ac5..7a0080bf 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -3422,6 +3422,13 @@ is significant.  If
  .B script
  returns a non\-zero error status, it will cause the client
  to be disconnected.
+
+If a
+.B \-\-client\-connect cmd
+wants to defer the generating of the configuration the script, should


wants to defer the generating of the configuration then the script should



+use the client_connect_deferred_file and client_connect_config_file
+environment variables and write status accordingly into these files


environment variables. And write status accordingly into these files


+(See the environment section below for more details).
  .\"*
  .TP
  .B \-\-client\-disconnect cmd
@@ -3505,12 +3512,18 @@ This directory will be used by in the following cases:
  
  *

  .B \-\-client\-connect
-scripts to dynamically generate client\-specific
-configuration files.
+scripts and
+.B OPENVPN_PLUGIN_CLIENT_CONNECT
+plugin hook
+to dynamically generate client\-specific configuration files
+and return success/failure via client_connect_deferred_file
+when using deferred client connect method
  
  *

  .B OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY
-plugin hook to return success/failure via auth_control_file
+and
+
+plugin hook to return success/failure via auth_control_file/
  when using deferred auth method
  
  *

@@ -6654,6 +6667,42 @@ Set prior to execution of the
  script.
  .\"*
  .TP
+.B client_connect_config_file
+The path to the configuration file that should be written by
+the
+.B \-\-client\-connect
+script. The content of this environment variable is identical
+to the file as a argument of the called


as an argument


+.B \-\-client\-connect
+script.
+.\"*
+.TP
+.B client_connect_deferred_file
+This file can be optionally written to communicate a status
+code of the
+.TP
+.B \-\-client\-connect
+script. If used for deferring, this file must be written
+before the
+.B \-\-client\-connect
+script exits. The first character in the file has to be


must be either:



+'1' is to indicate normal script execution, '0' indicates an
+error (in the same way that a non zero exit status does) and
+'2' indicates that the script deferred returning the config
+file. When the script defers returning the configuration, it
+must also write '2' to to the file to indicate the deferral.
+A background process or similar must then take care of writing the
+configuration to the file indicated by the
+.B
+client_connect_config_file
+environment variable and when finished, write the a '1' to this
+file (or '0' in case of an error).
+
+The absence of any character in the file when the script finishes
+executing is interpreted the same as '1'. This allows script that


This allows scripts


+are not written to support the defer mechanism to be used unmodified.
+.\"*
+.TP
  .B common_name
  The X509 common name of an authenticated client.
  Set prior to execution of
diff --git a/include/openvpn-plugin.h.in b/include/openvpn-plugin.h.in
index 38fbe097..64b20886 100644
--- a/include/openvpn-plugin.h.in
+++ b/include/openvpn-plugin.h.in
@@ -557,12 +557,21 @@ OPENVPN_PLUGIN_DEF openvpn_plugin_handle_t 
OPENVPN_PLUGIN_FUNC(openvpn_plugin_op
   * OPENVPN_PLUGIN_FUNC_SUCCESS on success, OPENVPN_PLUGIN_FUNC_ERROR on 
failure
   *
   * In addition, OPENVPN_PLUGIN_FUNC_DEFERRED may be returned by
- * OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY.  This enables asynchronous
- * authentication where the plugin (or one of its agents) may indicate
- * authentication success/failure some number of seconds after the return
- * of the 

Re: [Openvpn-devel] [PATCH v5 12/14] client-connect: Add deferred support to the client-connect plugin v1 handler

[tincanteksup]

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) call the plugin on a deferred
call. This allows the plugin authors to be more flexible and make the V1 API
more similar to the V2 API.

Signed-off-by: Arne Schwabe 
---
  include/openvpn-plugin.h.in | 29 +--
  src/openvpn/multi.c | 97 -
  src/openvpn/plugin.c|  3 ++
  3 files changed, 93 insertions(+), 36 deletions(-)

diff --git a/include/openvpn-plugin.h.in b/include/openvpn-plugin.h.in
index 103844f7..99aa1678 100644
--- a/include/openvpn-plugin.h.in
+++ b/include/openvpn-plugin.h.in
@@ -116,20 +116,21 @@ extern "C" {
   * FUNC: openvpn_plugin_client_destructor_v1 (top-level "generic" client)
   * FUNC: openvpn_plugin_close_v1
   */
-#define OPENVPN_PLUGIN_UP0
-#define OPENVPN_PLUGIN_DOWN  1
-#define OPENVPN_PLUGIN_ROUTE_UP  2
-#define OPENVPN_PLUGIN_IPCHANGE  3
-#define OPENVPN_PLUGIN_TLS_VERIFY4
-#define OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY 5
-#define OPENVPN_PLUGIN_CLIENT_CONNECT6
-#define OPENVPN_PLUGIN_CLIENT_DISCONNECT 7
-#define OPENVPN_PLUGIN_LEARN_ADDRESS 8
-#define OPENVPN_PLUGIN_CLIENT_CONNECT_V2 9
-#define OPENVPN_PLUGIN_TLS_FINAL 10
-#define OPENVPN_PLUGIN_ENABLE_PF 11
-#define OPENVPN_PLUGIN_ROUTE_PREDOWN 12
-#define OPENVPN_PLUGIN_N 13
+#define OPENVPN_PLUGIN_UP0
+#define OPENVPN_PLUGIN_DOWN  1
+#define OPENVPN_PLUGIN_ROUTE_UP  2
+#define OPENVPN_PLUGIN_IPCHANGE  3
+#define OPENVPN_PLUGIN_TLS_VERIFY4
+#define OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY 5
+#define OPENVPN_PLUGIN_CLIENT_CONNECT6
+#define OPENVPN_PLUGIN_CLIENT_DISCONNECT 7
+#define OPENVPN_PLUGIN_LEARN_ADDRESS 8
+#define OPENVPN_PLUGIN_CLIENT_CONNECT_V2 9
+#define OPENVPN_PLUGIN_TLS_FINAL10
+#define OPENVPN_PLUGIN_ENABLE_PF11
+#define OPENVPN_PLUGIN_ROUTE_PREDOWN12
+#define OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER 13
+#define OPENVPN_PLUGIN_N14
  
  /*

   * Build a mask out of a set of plug-in types.
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 09a25a58..08eb44ba 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2008,56 +2008,109 @@ ccs_gen_config_file(struct multi_instance *mi)
  static enum client_connect_return
  multi_client_connect_call_plugin_v1(struct multi_context *m,
  struct multi_instance *mi,
-unsigned int *option_types_found)
+unsigned int *option_types_found,
+bool deferred)
  {
  enum client_connect_return ret = CC_RET_SKIPPED;
  #ifdef ENABLE_PLUGIN
  ASSERT(m);
  ASSERT(mi);
  ASSERT(option_types_found);
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
  
  /* deprecated callback, use a file for passing back return info */

  if (plugin_defined(mi->context.plugins, OPENVPN_PLUGIN_CLIENT_CONNECT))
  {
  struct argv argv = argv_new();
-struct gc_arena gc = gc_new();
-const char *dc_file =
-platform_create_temp_file(mi->context.options.tmp_dir, "cc", );
+int call;
  
-if (!dc_file)

+if (!deferred)
  {
-ret = CC_RET_FAILED;
-goto cleanup;
+call = OPENVPN_PLUGIN_CLIENT_CONNECT;
+if (!ccs_gen_config_file(mi)
+|| !ccs_gen_deferred_ret_file(mi))
+{
+ret = CC_RET_FAILED;
+goto cleanup;
+}
+}
+else
+{
+call = OPENVPN_PLUGIN_CLIENT_CONNECT_DEFER;
+/* the initial call should have created these files */
+ASSERT(ccs->config_file);
+ASSERT(ccs->deferred_ret_file);
  }
  
-argv_printf(, "%s", dc_file);

-if (plugin_call(mi->context.plugins, OPENVPN_PLUGIN_CLIENT_CONNECT,
-, NULL, mi->context.c2.es)
-!= OPENVPN_PLUGIN_FUNC_SUCCESS)
+argv_printf(, "%s", ccs->config_file);
+int plug_ret = plugin_call(mi->context.plugins, call,
+   , NULL, mi->context.c2.es);
+if (plug_ret == OPENVPN_PLUGIN_FUNC_SUCCESS)
  {
-msg(M_WARN, "WARNING: client-connect plugin call failed");
-ret = CC_RET_FAILED;
+multi_client_connect_post(m, mi, ccs->config_file,
+  option_types_found);

Re: [Openvpn-devel] [PATCH v5 10/14] client-connect: Move adding inotify watch into its own function

[tincanteksup]

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 function for client-connect return files

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c | 43 ---
  1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 271d09d8..dafc85f1 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2828,6 +2828,32 @@ multi_schedule_context_wakeup(struct multi_context *m, 
struct multi_instance *mi
 compute_wakeup_sigma(>context.c2.timeval));
  }
  
+#if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH)

+static void
+add_inotify_file_watch(struct multi_context *m, struct multi_instance *mi,
+   int inotify_fd, const char *file)
+{
+/* watch acf file */
+long watch_descriptor = inotify_add_watch(inotify_fd, file,
+  IN_CLOSE_WRITE | IN_ONESHOT);
+if (watch_descriptor >= 0)
+{
+if (mi->inotify_watch != -1)
+{
+hash_remove(m->inotify_watchers,
+(void *) (unsigned long)mi->inotify_watch);
+}
+hash_add(m->inotify_watchers, (const uintptr_t *)watch_descriptor,
+ mi, true);
+mi->inotify_watch = watch_descriptor;
+}
+else
+{
+msg(M_NONFATAL | M_ERRNO, "MULTI: inotify_add_watch error");
+}
+}
+#endif /* if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH) */
+
  /*
   * Figure instance-specific timers, convert
   * earliest to absolute time in mi->wakeup,
@@ -2865,21 +2891,8 @@ multi_process_post(struct multi_context *m, struct 
multi_instance *mi, const uns
  if (ks && ks->auth_control_file && was_unauthenticated
  && (ks->authenticated == KS_AUTH_DEFERRED))
  {
-/* watch acf file */
-long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, 
ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT);
-if (watch_descriptor >= 0)
-{
-if (mi->inotify_watch != -1)
-{
-hash_remove(m->inotify_watchers, (void *) (unsigned 
long)mi->inotify_watch);
-}
-hash_add(m->inotify_watchers, (const uintptr_t 
*)watch_descriptor, mi, true);
-mi->inotify_watch = watch_descriptor;
-}
-else
-{
-msg(M_NONFATAL | M_ERRNO, "MULTI: inotify_add_watch error");
-}
+add_inotify_file_watch(m, mi, m->top.c2.inotify_fd,
+   ks->auth_control_file);
  }
  #endif
  




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5 09/14] client-connect: Add deferred support to the client-connect script handler

[tincanteksup]

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 client_connect_state struct.

In addition, the patch also allows the storage of the client config file name
in struct client_connect_state.

Both changes are used by the client-connect script handler to support deferred
client-connection handling.  The deferred return value file (deferred_ret_file)
is passed to the actual script via the environment.  If the script succeeds and
writes the value for deferral into the deferred_ret_file, the handler knows to
indicate deferral.  Later on, the deferred handler checks whether the value of
the deferred_ret_file has been updated to success or failure.

Signed-off-by: Fabian Knittel 
Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c | 230 +---
  src/openvpn/multi.h |  12 +++
  2 files changed, 227 insertions(+), 15 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index ce73f8a1..271d09d8 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1843,6 +1843,168 @@ multi_client_set_protocol_options(struct context *c)
  }
  }
  
+/**

+ * Delete the temporary file for the return value of client connect
+ * It also removes it from it from client_connect_defer_state and


 it from it from - 2x "it from"



+ * environment
+ */
+static void
+ccs_delete_deferred_ret_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+if (ccs->deferred_ret_file)
+{
+setenv_del(mi->context.c2.es, "client_connect_deferred_file");
+if (!platform_unlink(ccs->deferred_ret_file))
+{
+msg(D_MULTI_ERRORS, "MULTI: problem deleting temporary file: %s",
+ccs->deferred_ret_file);
+}
+free(ccs->deferred_ret_file);
+ccs->deferred_ret_file = NULL;
+}
+}
+
+/**
+ * Create a temporary file for the return value of client connect
+ * and puts it into the client_connect_defer_state and environment
+ * as "client_connect_deferred_file"
+ *
+ * @return boolean value if creation was successfull


successfull -> successful



+ */
+static bool
+ccs_gen_deferred_ret_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+struct gc_arena gc = gc_new();
+const char *fn;
+
+if (ccs->deferred_ret_file)
+{
+ccs_delete_deferred_ret_file(mi);
+}
+
+fn = platform_create_temp_file(mi->context.options.tmp_dir, "ccr", );
+if (!fn)
+{
+gc_free();
+return false;
+}
+ccs->deferred_ret_file = string_alloc(fn, NULL);
+
+setenv_str(mi->context.c2.es, "client_connect_deferred_file",
+   ccs->deferred_ret_file);
+
+gc_free();
+return true;
+}
+
+/**
+ * Tests whether the deferred return value file exists and returns the
+ * contained return value.
+ *
+ * @return CC_RET_SKIPPED if the file does not exist or is empty.
+ * CC_RET_DEFERRED, CC_RET_SUCCEEDED or CC_RET_FAILED depending on
+ * the value stored in the file.
+ */
+static enum client_connect_return
+ccs_test_deferred_ret_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+enum client_connect_return ret = CC_RET_SKIPPED;
+FILE *fp = fopen(ccs->deferred_ret_file, "r");
+if (fp)
+{
+const int c = fgetc(fp);
+switch (c)
+{
+case '0':
+ret = CC_RET_FAILED;
+break;
+
+case '1':
+ret = CC_RET_SUCCEEDED;
+break;
+
+case '2':
+ret = CC_RET_DEFERRED;
+break;
+
+case EOF:
+if (feof(fp))
+{
+ret = CC_RET_SKIPPED;
+break;
+}
+
+/* Not EOF, but other error fall through to error state */


Not EOF but other error, fall through to error state

(Commas are important)


+default:
+/* We received an unknown/unexpected value.  Assume failure. */
+msg(M_WARN, "WARNING: Unknown/unexcepted value in deferred"


unexcepted -> either: unexpected orunaccepted



+"client-connect resultfile");
+ret = CC_RET_FAILED;
+}
+fclose(fp);
+}
+return ret;
+}
+
+/**
+ * Deletes the temporary file for the config directives of the  client connect
+ * script and removes it into the client_connect_defer_state and environment
+ *
+ */
+static void
+ccs_delete_config_file(struct multi_instance *mi)
+{
+struct client_connect_defer_state *ccs = &(mi->client_connect_defer_state);
+if 

Re: [Openvpn-devel] [PATCH v5 08/14] client-connect: Add CC_RET_DEFERRED and cope with deferred client-connect

[tincanteksup]

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 exited and re-entered as
many times as necessary - without losing the client-connect handling state.

The patch also adds the new return value CC_RET_DEFERRED which indicates that
the handler couldn't complete immediately, and needs to be called later.  At
that point multi_connection_established() will exit without indicating
completion.

Each client-connect handler now has an (optional) additional call-back:  The
call-back for handling the deferred case.  If the main call-back returns
CC_RET_DEFERRED, the next call to the handler will be through the deferred
call-back.

Signed-off-by: Fabian Knittel 

Patch V3: Use a static struct in multi_instance instead of using
   malloc/free and use two states (deffered with and without


deffered -> deferred



   result) instead of one to eliminate the counter that was
   only tested for > 0.

Patch V5: Use new states in context_auth instead of the extra state
   that the patch series previously used.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c   | 171 +++---
  src/openvpn/multi.h   |  15 +++-
  src/openvpn/openvpn.h |   9 +++
  3 files changed, 150 insertions(+), 45 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f9b8af80..ce73f8a1 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2218,32 +2218,51 @@ multi_client_connect_source_ccd(struct multi_context *m,
  return ret;
  }
  
-static inline bool

-cc_check_return(int *cc_succeeded_count,
-enum client_connect_return ret)
+typedef enum client_connect_return (*multi_client_connect_handler)
+(struct multi_context *m, struct multi_instance *mi,
+unsigned int *option_types_found);
+
+struct client_connect_handlers
+{
+multi_client_connect_handler main;
+multi_client_connect_handler deferred;
+};
+
+static enum client_connect_return
+multi_client_connect_fail(struct multi_context *m, struct multi_instance *mi,
+  unsigned int *option_types_found)
  {
-if (ret == CC_RET_SUCCEEDED)
+/* Called null call-back.  This should never happen. */
+return CC_RET_FAILED;
+}
+
+static const struct client_connect_handlers client_connect_handlers[] = {
  {
-(*cc_succeeded_count)++;
-return true;
-}
-else if (ret == CC_RET_FAILED)
+.main = multi_client_connect_source_ccd,
+.deferred = multi_client_connect_fail
+},
  {
-return false;
-}
-else if (ret == CC_RET_SKIPPED)
+.main = multi_client_connect_call_plugin_v1,
+.deferred = multi_client_connect_fail
+},
  {
-return true;
-}
-else
+.main = multi_client_connect_call_plugin_v2,
+.deferred = multi_client_connect_fail
+},
+{
+.main = multi_client_connect_call_script,
+.deferred = multi_client_connect_fail
+},
  {
-ASSERT(0);
+.main = multi_client_connect_mda,
+.deferred = multi_client_connect_fail
+},
+{
+.main = NULL,
+.deferred = NULL
+/* End of list sentinel.  */
  }
-}
-
-typedef enum client_connect_return (*multi_client_connect_handler)
-(struct multi_context *m, struct multi_instance *mi,
- unsigned int *option_types_found);
+};
  
  /*

   * Called as soon as the SSL/TLS connection is authenticated.
@@ -2273,27 +2292,83 @@ multi_connection_established(struct multi_context *m, 
struct multi_instance *mi)
  return;
  }
  
-multi_client_connect_handler handlers[] = {

-multi_client_connect_source_ccd,
-multi_client_connect_call_plugin_v1,
-multi_client_connect_call_plugin_v2,
-multi_client_connect_call_script,
-multi_client_connect_mda,
-NULL
-};
-
-unsigned int option_types_found = 0;
+/* We are only called for the CAS_PENDING_x states, so we
+ * can ignore other states here */
+bool from_deferred = (mi->context.c2.context_auth != CAS_PENDING);
  
-int cc_succeeded = true; /* client connect script status */

-int cc_succeeded_count = 0;
  enum client_connect_return ret;
  
-multi_client_connect_early_setup(m, mi);

+struct client_connect_defer_state *defer_state =
+&(mi->client_connect_defer_state);
  
-for (int i = 0; cc_succeeded && handlers[i]; i++)

+/* We are called for the first time */
+if (!from_deferred)
  {
-ret = handlers[i](m, mi, _types_found);
-cc_succeeded = cc_check_return(_succeeded_count, ret);
+defer_state->cur_handler_index = 0;
+defer_state->option_types_found 

Re: [Openvpn-devel] [PATCH v5 03/14] client-connect: Refactor multi_client_connect_source_ccd

[tincanteksup]

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 even further to make more easy to understand.


grammar: to make it more easy




Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c | 43 +--
  1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 3c4ceeb5..35e0bd10 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2164,15 +2164,30 @@ multi_client_connect_source_ccd(struct multi_context *m,
  if (mi->context.options.client_config_dir)
  {
  struct gc_arena gc = gc_new();
-const char *ccd_file;
+const char *ccd_file = NULL;
+
+const char *ccd_client = 
platform_gen_path(mi->context.options.client_config_dir,
+   
tls_common_name(mi->context.c2.tls_multi,
+   false),
+   );
+
+const char *ccd_default = 
platform_gen_path(mi->context.options.client_config_dir,
+CCD_DEFAULT,
+);
  
-ccd_file = platform_gen_path(mi->context.options.client_config_dir,

- tls_common_name(mi->context.c2.tls_multi,
- false),
- );
  
  /* try common-name file */

-if (platform_test_file(ccd_file))
+if (platform_test_file(ccd_client))
+{
+ccd_file = ccd_client;
+}
+/* try default file */
+else if (platform_test_file(ccd_default))
+{
+ccd_file = ccd_default;
+}
+
+if (ccd_file)
  {
  options_server_import(>context.options,
ccd_file,
@@ -2181,22 +2196,6 @@ multi_client_connect_source_ccd(struct multi_context *m,
option_types_found,
mi->context.c2.es);
  }
-else /* try default file */
-{
-ccd_file = platform_gen_path(mi->context.options.client_config_dir,
- CCD_DEFAULT,
- );
-
-if (platform_test_file(ccd_file))
-{
-options_server_import(>context.options,
-  ccd_file,
-  D_IMPORT_ERRORS|M_OPTERR,
-  CLIENT_CONNECT_OPT_MASK,
-  option_types_found,
-  mi->context.c2.es);
-}
-}
  gc_free();
  }
  }




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5 02/14] client-connect: Split multi_connection_established into separate functions

[tincanteksup]

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 reindent code, so that the real changes are as clearly


Technically: reindent -> re-indent
(that is how I would spell it)



visible as possible.  (A follow-up patch will only do indentation changes.)

Signed-off-by: Fabian Knittel 

PATCH v3: Since the code has changed enough from the time the original patch
to the current master, the splitting has been redone from the current code.



Also some style and minor code changes have been added doing this patch.
This elimininates and the big reformatting done before eliminates the follow


elimininates -> eliminates

The grammer:

This elimininates >and< the big reformatting ..

I don't know how to re-word this paragraph to make sense.



up patch with indentation changes.

The original patch already replaces some instances of option_permission_mask
with CLIENT_CONNECT_OPT_MASK. The V3 version does this more consistenly.


consistenly -> consistently


I found no further issues with the patch.



Patch v4: Move config -> mi->cc_config into its own commit

Patch v5: Clean up some minor issues, add one missing check on
temporary file deletion, rebase on latest master.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c | 588 ++--
  src/openvpn/multi.h |   4 +-
  2 files changed, 350 insertions(+), 242 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index a2af071a..3c4ceeb5 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1638,7 +1638,6 @@ static void
  multi_client_connect_post(struct multi_context *m,
struct multi_instance *mi,
const char *dc_file,
-  unsigned int option_permissions_mask,
unsigned int *option_types_found)
  {
  /* Did script generate a dynamic config file? */
@@ -1647,7 +1646,7 @@ multi_client_connect_post(struct multi_context *m,
  options_server_import(>context.options,
dc_file,
D_IMPORT_ERRORS|M_OPTERR,
-  option_permissions_mask,
+  CLIENT_CONNECT_OPT_MASK,
option_types_found,
mi->context.c2.es);
  
@@ -1671,7 +1670,6 @@ static void

  multi_client_connect_post_plugin(struct multi_context *m,
   struct multi_instance *mi,
   const struct plugin_return *pr,
- unsigned int option_permissions_mask,
   unsigned int *option_types_found)
  {
  struct plugin_return config;
@@ -1689,7 +1687,7 @@ multi_client_connect_post_plugin(struct multi_context *m,
  options_string_import(>context.options,
config.list[i]->value,
D_IMPORT_ERRORS|M_OPTERR,
-  option_permissions_mask,
+  CLIENT_CONNECT_OPT_MASK,
option_types_found,
mi->context.c2.es);
  }
@@ -1716,7 +1714,6 @@ multi_client_connect_post_plugin(struct multi_context *m,
  static void
  multi_client_connect_mda(struct multi_context *m,
   struct multi_instance *mi,
- unsigned int option_permissions_mask,
   unsigned int *option_types_found)
  {
  if (mi->cc_config)
@@ -1729,7 +1726,7 @@ multi_client_connect_mda(struct multi_context *m,
  options_string_import(>context.options,
opt,
D_IMPORT_ERRORS|M_OPTERR,
-  option_permissions_mask,
+  CLIENT_CONNECT_OPT_MASK,
option_types_found,
mi->context.c2.es);
  }
@@ -1843,160 +1840,46 @@ multi_client_set_protocol_options(struct context *c)
  }
  }
  
-/**

- * Generates the data channel keys
- */
-static bool
-multi_client_generate_tls_keys(struct context *c)
-{
-struct frame *frame_fragment = NULL;
-#ifdef ENABLE_FRAGMENT
-if (c->options.ce.fragment)
-{
-frame_fragment = >c2.frame_fragment;
-}
-#endif
-struct tls_session *session = >c2.tls_multi->session[TM_ACTIVE];
-if (!tls_session_update_crypto_params(session, >options,
-  >c2.frame, frame_fragment))
-{
-msg(D_TLS_ERRORS, "TLS Error: initializing data channel failed");

Re: [Openvpn-devel] [PATCH v5 01/14] Allow changing fallback cipher from ccd files/client-connect

[tincanteksup]

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 from a ccd file.

Steffan's old patch also moves the cipher negotiation to
multi_established_connection() which I independently discovered and
implemented in


implemented in:

(otherwise it looks like you forgot "in what" - That is if my 
interpretation is correct)




Extract process_incoming_push_reply from process_incoming_push_msg
(#FIXME add commitsh when commited to master)

Signed-off-by: Arne Schwabe 
---
  src/openvpn/options.c | 2 +-
  src/openvpn/options.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index b93fd4fe..bf2760e1 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -7892,7 +7892,7 @@ add_option(struct options *options,
  }
  else if (streq(p[0], "cipher") && p[1] && !p[2])
  {
-VERIFY_PERMISSION(OPT_P_NCP);
+VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
  options->ciphername = p[1];
  }
  else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index c83a46aa..c37006d3 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -677,7 +677,7 @@ struct options
  #define OPT_P_MTU (1<<14) /* TODO */
  #define OPT_P_NICE(1<<15)
  #define OPT_P_PUSH(1<<16)
-#define OPT_P_INSTANCE(1<<17)
+#define OPT_P_INSTANCE(1<<17) /**< allowed in ccd, client-connect etc*/
  #define OPT_P_CONFIG  (1<<18)
  #define OPT_P_EXPLICIT_NOTIFY (1<<19)
  #define OPT_P_ECHO(1<<20)




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5 07/14] client-connect: Change cas_context from int to enum

[tincanteksup]

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



(cas_context == CAS_PENDING)

Signed-off-by: Arne Schwabe 

Patch V5: extend cas_context with two new states instead adding an
   extra mini state machine.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c   |  2 +-
  src/openvpn/multi.h   |  1 +
  src/openvpn/openvpn.h | 24 +---
  3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 83848fdc..f9b8af80 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2163,7 +2163,7 @@ multi_client_connect_early_setup(struct multi_context *m,
   * Try to source a dynamic config file from the
   * --client-config-dir directory.
   */
-enum client_connect_return
+static enum client_connect_return
  multi_client_connect_source_ccd(struct multi_context *m,
  struct multi_instance *mi,
  unsigned int *option_types_found)
diff --git a/src/openvpn/multi.h b/src/openvpn/multi.h
index 4fb4d0b6..1d30dcc6 100644
--- a/src/openvpn/multi.h
+++ b/src/openvpn/multi.h
@@ -62,6 +62,7 @@ struct deferred_signal_schedule_entry
  struct timeval wakeup;
  };
  
+

  /**
   * Server-mode state structure for one single VPN tunnel.
   *
diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h
index a1308852..7c469b01 100644
--- a/src/openvpn/openvpn.h
+++ b/src/openvpn/openvpn.h
@@ -210,6 +210,21 @@ struct context_1
  #endif
  };
  
+

+/* client authentication state, CAS_SUCCEEDED must be 0 since
+ * non multi code path still checks this variable but does not initialise it
+ * so the code depends on zero initialisation */
+enum client_connect_status {
+CAS_SUCCEEDED=0,
+CAS_PENDING,
+CAS_FAILED,
+CAS_PARTIAL,/**< Variant of CAS_FAILED: at least one
+ * client-connect script/plugin succeeded
+ * while a later one in the chain failed
+ * (we still need cleanup compared to FAILED)
+ */
+};
+
  /**
   * Level 2 %context containing state that is reset on both \c SIGHUP and
   * \c SIGUSR1 restarts.
@@ -444,13 +459,8 @@ struct context_2
  int push_ifconfig_ipv6_netbits;
  struct in6_addr push_ifconfig_ipv6_remote;
  
-/* client authentication state, CAS_SUCCEEDED must be 0 */

-#define CAS_SUCCEEDED 0
-#define CAS_PENDING   1
-#define CAS_FAILED2
-#define CAS_PARTIAL   3  /* at least one client-connect script/plugin
-  * succeeded while a later one in the chain failed */
-int context_auth;
+
+enum client_connect_status context_auth;
  
  struct event_timeout push_request_interval;

  int n_sent_push_requests;




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 5/8] Generate data channel keys after connect options have been parsed

[tincanteksup]

possible white-space error ?

On 09/07/2020 11:16, Arne Schwabe wrote:

The simplify the control flow, it makes more sense to generate the
data keys when all the prerequisites for generating the data channel
keys (ncp cipher selection etc) are met instead of delaying it to the
next incoming PUSH_REQUEST message.

This also eliminates the need for the hack introduced by commit
3b06b57d9 to generate the data channel keys on the async file close
event.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c | 54 ++---
  src/openvpn/push.c  | 27 ---
  2 files changed, 35 insertions(+), 46 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f04c4c90..810e489a 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1843,6 +1843,30 @@ multi_client_set_protocol_options(struct context *c)
  }
  }
  
+/**

+ * Generates the data channel keys
+ */
+static bool
+multi_client_generate_tls_keys(struct context *c)
+{
+struct frame *frame_fragment = NULL;
+#ifdef ENABLE_FRAGMENT
+if (c->options.ce.fragment)
+{
+frame_fragment = >c2.frame_fragment;
+}
+#endif
+struct tls_session *session = >c2.tls_multi->session[TM_ACTIVE];
+if (!tls_session_update_crypto_params(session, >options,
+  >c2.frame, frame_fragment))
+{
+msg(D_TLS_ERRORS, "TLS Error: initializing data channel failed");
+register_signal(c, SIGUSR1, "process-push-msg-failed");
+return false;
+}
+
+return true;
+}
  
  /*

   * Called as soon as the SSL/TLS connection authenticates.
@@ -2149,7 +2173,13 @@ script_failed:
  /* authentication complete, calculate dynamic client specific options 
*/
  multi_client_set_protocol_options(>context);
  
-/* send push reply if ready*/

+/* Generate data channel keys */
+if (!multi_client_generate_tls_keys(>context))
+{
+mi->context.c2.context_auth = CAS_FAILED;
+}
+
+/* send push reply if ready */
  if (mi->context.c2.push_request_received)
  {
  process_incoming_push_request(>context);
@@ -2205,28 +2235,6 @@ multi_process_file_closed(struct multi_context *m, const 
unsigned int mpp_flags)
  {
  /* continue authentication, perform NCP negotiation and send 
push_reply */
  multi_process_post(m, mi, mpp_flags);
-
-/* With NCP and deferred authentication, we perform cipher 
negotiation and
- * data channel keys generation on incoming push request, 
assuming that auth
- * succeeded. When auth succeeds in between push requests and 
async push is used,
- * we send push reply immediately. Above multi_process_post() 
call performs
- * NCP negotiation and here we do keys generation. */
-
-struct context *c = >context;
-struct frame *frame_fragment = NULL;
-#ifdef ENABLE_FRAGMENT
-if (c->options.ce.fragment)
-{
-frame_fragment = >c2.frame_fragment;
-}
-#endif
-struct tls_session *session = 
>c2.tls_multi->session[TM_ACTIVE];
-if (!tls_session_update_crypto_params(session, >options,
-  >c2.frame, 
frame_fragment))
-{
-msg(D_TLS_ERRORS, "TLS Error: initializing data channel 
failed");
-register_signal(c, SIGUSR1, "init-data-channel-failed");
-}
  }
  else
  {
diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 92a28a14..5bc4328c 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -359,30 +359,11 @@ incoming_push_message(struct context *c, const struct 
buffer *buffer)
  }
  event_timeout_clear(>c2.push_request_interval);
  }
-else if (status == PUSH_MSG_REQUEST)
-{
-if (c->options.mode == MODE_SERVER)
-{
-struct frame *frame_fragment = NULL;
-#ifdef ENABLE_FRAGMENT
-if (c->options.ce.fragment)
-{
-frame_fragment = >c2.frame_fragment;
-}
-#endif
-struct tls_session *session = >c2.tls_multi->session[TM_ACTIVE];
-if (!tls_session_update_crypto_params(session, >options,
-  >c2.frame, 
frame_fragment))
-{
-msg(D_TLS_ERRORS, "TLS Error: initializing data channel 
failed");
-goto error;
-}
-}
-}
  
  goto cleanup;

+
  error:
-register_signal(c, SIGUSR1, "process-push-msg-failed");
+  register_signal(c, SIGUSR1, "process-push-msg-failed");


White-space ? just making a note of it



  cleanup:
  gc_free();
  }
@@ -748,7 +729,6 @@ 

Re: [Openvpn-devel] [PATCH 2/8] Make key_state->authenticated more state machine like

[tincanteksup]

typo x3

On 09/07/2020 11:15, Arne Schwabe wrote:

This order the states from unauthenticated to authenticated and also
changes the comparison for KS_AUTH_FALSE from != to >

It also add comments and documents part using the state machine
better.

Remove a now obsolete comment and two obsolete ifdefs. While
keeping the ifdef in ssl_verify would save a few bytes of code,
this is too minor to justify keeping the ifdef

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c  | 12 +---
  src/openvpn/ssl.c|  7 ---
  src/openvpn/ssl_common.h | 22 --
  src/openvpn/ssl_verify.c | 18 +++---
  4 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f1ced9b7..f1332c8d 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2352,12 +2352,12 @@ multi_process_post(struct multi_context *m, struct 
multi_instance *mi, const uns
  if (!IS_SIG(>context) && ((flags & MPP_PRE_SELECT) || ((flags & 
MPP_CONDITIONAL_PRE_SELECT) && !ANY_OUT(>context
  {
  #if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH)
-bool was_authenticated = false;
+bool was_unauthenticated = true;
  struct key_state *ks = NULL;
  if (mi->context.c2.tls_multi)
  {
  ks = 
>context.c2.tls_multi->session[TM_ACTIVE].key[KS_PRIMARY];
-was_authenticated = ks->authenticated;
+was_unauthenticated = (ks->authenticated == KS_AUTH_FALSE);
  }
  #endif
  
@@ -2366,7 +2366,13 @@ multi_process_post(struct multi_context *m, struct multi_instance *mi, const uns

  pre_select(>context);
  
  #if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH)

-if (ks && ks->auth_control_file && ks->auth_deferred && 
!was_authenticated)
+/*
+ * if we see the state transition from unauthenticated to deferred
+ * and a auth_control_file, we assume it got just added and add


and aN auth_control_file



+ * inotify watch to that file
+ */
+if (ks && ks->auth_control_file && was_unauthenticated
+&& (ks->authenticated == KS_AUTH_DEFERRED))
  {
  /* watch acf file */
  long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, 
ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT);
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 9df7552d..f3fe0ecf 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2466,7 +2466,7 @@ key_method_2_write(struct buffer *buf, struct tls_session 
*session)
  if (session->opt->server && !(session->opt->ncp_enabled
&& session->opt->mode == MODE_SERVER && 
ks->key_id <= 0))
  {
-if (ks->authenticated != KS_AUTH_FALSE)
+if (ks->authenticated > KS_AUTH_FALSE)
  {
  if (!tls_session_generate_data_channel_keys(session))
  {
@@ -2659,7 +2659,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
  secure_memzero(up, sizeof(*up));
  
  /* Perform final authentication checks */

-if (ks->authenticated != KS_AUTH_FALSE)
+if (ks->authenticated > KS_AUTH_FALSE)
  {
  verify_final_auth_checks(multi, session);
  }
@@ -2684,7 +2684,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
   * Call OPENVPN_PLUGIN_TLS_FINAL plugin if defined, for final
   * veto opportunity over authentication decision.
   */
-if ((ks->authenticated != KS_AUTH_FALSE)
+if ((ks->authenticated > KS_AUTH_FALSE)
  && plugin_defined(session->opt->plugins, OPENVPN_PLUGIN_TLS_FINAL))
  {
  key_state_export_keying_material(>ks_ssl, session);
@@ -2715,6 +2715,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
  return true;
  
  error:

+ks->authenticated = KS_AUTH_FALSE;
  secure_memzero(ks->key_src, sizeof(*ks->key_src));
  if (up)
  {
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index fdf589b5..dd82b77d 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -127,10 +127,23 @@ struct key_source2 {
  struct key_source server;   /**< Random provided by server. */
  };
  
+

+/**
+ * This refelects the (server side) state auf authentication after the TLS
+ * session  has been established and key_method_2_read is called. If async auth
+ * is enabled the state will first move to KS_AUTH_DEFERRED before eventually
+ * being set to KS_AUTH_TRUE or KS_AUTH_FALSE
+ * Only KS_AUTH_TRUE is fully authenticated
+ */
  enum ks_auth_state {
-  KS_AUTH_FALSE,
-  KS_AUTH_TRUE,
-  KS_AUTH_DEFERRED
+  KS_AUTH_FALSE,  /**< Key state is not authenticated  */
+  KS_AUTH_DEFERRED,   /**< Key state authentication is being deferred,
+* by async auth */
+  KS_AUTH_TRUE/**< Key state is 

Re: [Openvpn-devel] [PATCH 4/8] Move protocol option negotiation from push_prepare to new function

[tincanteksup]

typo

On 09/07/2020 11:15, Arne Schwabe wrote:

This clean ups the code and removes the surprising side effects
of preparing a push reply to also select protocol options.

We also remember if we have seen a push request without async
push. This improves reaction time if deferred auth is involved
like managment interface deferred auth.  The other benefit is
removing a number of ifdefs.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/forward.c |  4 +--
  src/openvpn/multi.c   | 81 ---
  src/openvpn/openvpn.h |  2 --
  src/openvpn/push.c| 66 +--
  4 files changed, 88 insertions(+), 65 deletions(-)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 885cf126..5c4370a8 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1123,8 +1123,8 @@ process_incoming_link_part1(struct context *c, struct 
link_socket_info *lsi, boo
  }
  
  /*

- * Drop non-TLS packet if client-connect script/plugin has not
- * yet succeeded.
+ * Drop non-TLS packet if client-connect script/plugin and cipher 
selection
+ * has not yet succeeded.
   */
  if (c->c2.context_auth != CAS_SUCCEEDED)
  {
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f1332c8d..f04c4c90 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -824,8 +824,8 @@ multi_create_instance(struct multi_context *m, const struct 
mroute_addr *real)
  mi->did_cid_hash = true;
  #endif
  
-#ifdef ENABLE_ASYNC_PUSH

  mi->context.c2.push_request_received = false;
+#ifdef ENABLE_ASYNC_PUSH
  mi->inotify_watch = -1;
  #endif
  
@@ -1772,6 +1772,78 @@ multi_client_connect_setenv(struct multi_context *m,

  gc_free();
  }
  
+/**

+ * Calculates the options that depend on the client capabilities
+ * based on local options and available peer info
+ * - choosen cipher
+ * - peer id
+ */
+static void
+multi_client_set_protocol_options(struct context *c)
+{
+
+const char *optstr = NULL;
+struct tls_multi *tls_multi = c->c2.tls_multi;
+const char *const peer_info = tls_multi->peer_info;
+struct options *o = >options;
+
+/* Send peer-id if client supports it */
+optstr = peer_info ? strstr(peer_info, "IV_PROTO=") : NULL;
+if (optstr)
+{
+int proto = 0;
+int r = sscanf(optstr, "IV_PROTO=%d", );
+if ((r == 1) && (proto >= 2))
+{
+tls_multi->use_peer_id = true;
+}
+}
+
+/* Select cipher if client supports Negotiable Crypto Parameters */
+if (o->ncp_enabled)
+{
+/* if we have already created our key, we cannot *change* our own
+ * cipher -> so log the fact and push the "what we have now" cipher
+ * (so the client is always told what we expect it to use)
+ */
+const struct tls_session *session = _multi->session[TM_ACTIVE];
+if (session->key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized)
+{
+msg( M_INFO, "PUSH: client wants to negotiate cipher (NCP), but "
+ "server has already generated data channel keys, "
+ "re-sending previously negotiated cipher '%s'",
+ o->ciphername );
+}
+else
+{
+/*
+ * Push the first cipher from --ncp-ciphers to the client that
+ * the client announces to be supporting.
+ */
+char *push_cipher = ncp_get_best_cipher(o->ncp_ciphers, 
o->ciphername,
+peer_info,
+
tls_multi->remote_ciphername,
+>gc);
+
+if (push_cipher)
+{
+o->ciphername = push_cipher;
+}
+else
+{
+struct gc_arena gc = gc_new();
+const char *peer_ciphers = tls_peer_ncp_list(peer_info, );
+msg(M_INFO, "PUSH: No common cipher between server and client."
+"Expect this connection not to work. "
+"Server ncp-ciphers: '%s', client supported ciphers '%s'",
+o->ncp_ciphers, peer_ciphers);
+gc_free();
+}
+}
+}
+}
+
+
  /*
   * Called as soon as the SSL/TLS connection authenticates.
   *
@@ -2074,13 +2146,14 @@ script_failed:
  /* set context-level authentication flag */
  mi->context.c2.context_auth = CAS_SUCCEEDED;
  
-#ifdef ENABLE_ASYNC_PUSH

-/* authentication complete, send push reply */
+/* authentication complete, calculate dynamic client specific options 
*/
+multi_client_set_protocol_options(>context);
+
+/* send push reply if ready*/
  if (mi->context.c2.push_request_received)
  {
  process_incoming_push_request(>context);
  }
-#endif
  }

Re: [Openvpn-devel] [PATCH 2/8] Make key_state->authenticated more state machine like

[tincanteksup]

Typo

On 09/07/2020 11:15, Arne Schwabe wrote:

This order the states from unauthenticated to authenticated and also
changes the comparison for KS_AUTH_FALSE from != to >

It also add comments and documents part using the state machine
better.

Remove a now obsolete comment and two obsolete ifdefs. While
keeping the ifdef in ssl_verify would save a few bytes of code,
this is too minor to justify keeping the ifdef

Signed-off-by: Arne Schwabe 
---
  src/openvpn/multi.c  | 12 +---
  src/openvpn/ssl.c|  7 ---
  src/openvpn/ssl_common.h | 22 --
  src/openvpn/ssl_verify.c | 18 +++---
  4 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f1ced9b7..f1332c8d 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2352,12 +2352,12 @@ multi_process_post(struct multi_context *m, struct 
multi_instance *mi, const uns
  if (!IS_SIG(>context) && ((flags & MPP_PRE_SELECT) || ((flags & 
MPP_CONDITIONAL_PRE_SELECT) && !ANY_OUT(>context
  {
  #if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH)
-bool was_authenticated = false;
+bool was_unauthenticated = true;
  struct key_state *ks = NULL;
  if (mi->context.c2.tls_multi)
  {
  ks = 
>context.c2.tls_multi->session[TM_ACTIVE].key[KS_PRIMARY];
-was_authenticated = ks->authenticated;
+was_unauthenticated = (ks->authenticated == KS_AUTH_FALSE);
  }
  #endif
  
@@ -2366,7 +2366,13 @@ multi_process_post(struct multi_context *m, struct multi_instance *mi, const uns

  pre_select(>context);
  
  #if defined(ENABLE_ASYNC_PUSH) && defined(ENABLE_DEF_AUTH)

-if (ks && ks->auth_control_file && ks->auth_deferred && 
!was_authenticated)
+/*
+ * if we see the state transition from unauthenticated to deferred
+ * and a auth_control_file, we assume it got just added and add
+ * inotify watch to that file
+ */
+if (ks && ks->auth_control_file && was_unauthenticated
+&& (ks->authenticated == KS_AUTH_DEFERRED))
  {
  /* watch acf file */
  long watch_descriptor = inotify_add_watch(m->top.c2.inotify_fd, 
ks->auth_control_file, IN_CLOSE_WRITE | IN_ONESHOT);
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 9df7552d..f3fe0ecf 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2466,7 +2466,7 @@ key_method_2_write(struct buffer *buf, struct tls_session 
*session)
  if (session->opt->server && !(session->opt->ncp_enabled
&& session->opt->mode == MODE_SERVER && 
ks->key_id <= 0))
  {
-if (ks->authenticated != KS_AUTH_FALSE)
+if (ks->authenticated > KS_AUTH_FALSE)
  {
  if (!tls_session_generate_data_channel_keys(session))
  {
@@ -2659,7 +2659,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
  secure_memzero(up, sizeof(*up));
  
  /* Perform final authentication checks */

-if (ks->authenticated != KS_AUTH_FALSE)
+if (ks->authenticated > KS_AUTH_FALSE)
  {
  verify_final_auth_checks(multi, session);
  }
@@ -2684,7 +2684,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
   * Call OPENVPN_PLUGIN_TLS_FINAL plugin if defined, for final
   * veto opportunity over authentication decision.
   */
-if ((ks->authenticated != KS_AUTH_FALSE)
+if ((ks->authenticated > KS_AUTH_FALSE)
  && plugin_defined(session->opt->plugins, OPENVPN_PLUGIN_TLS_FINAL))
  {
  key_state_export_keying_material(>ks_ssl, session);
@@ -2715,6 +2715,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
  return true;
  
  error:

+ks->authenticated = KS_AUTH_FALSE;
  secure_memzero(ks->key_src, sizeof(*ks->key_src));
  if (up)
  {
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index fdf589b5..dd82b77d 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -127,10 +127,23 @@ struct key_source2 {
  struct key_source server;   /**< Random provided by server. */
  };
  
+

+/**
+ * This refelects the (server side) state auf authentication after the TLS


refelects -> reflects




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Patch] New man page corrections - windows-options.rst

[tincanteksup]

BTW: This is only round 1 of spelling and grammar checking. I have had 
to really hold off from getting nasty with commas etc.

I have tried to only fix the most obvious faux-pars ... ;-)

On 02/07/2020 14:50, tincanteksup wrote:

Hi Jonathan,

these are going to the new manpage, see:
https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting

They don't really need an ACK because dazo will review them first anyway 
but thanks all the same :)


Regards


On 02/07/2020 14:41, Jonathan K. Bullard wrote:

Improves English diction and/or grammar of man page.

Acked-by: Jonathan K. Bullard 

On Tue, Jun 30, 2020 at 9:11 PM Richard Bonhomme 
 wrote:


Signed-off-by: Richard Bonhomme 
---
  doc/man-sections/windows-options.rst | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/man-sections/windows-options.rst 
b/doc/man-sections/windows-options.rst

index 5ae7116c..72424d6b 100644
--- a/doc/man-sections/windows-options.rst
+++ b/doc/man-sections/windows-options.rst
@@ -231,7 +231,7 @@ Windows-Specific Options
    directive is not specified, OpenVPN will use the SystemRoot 
environment

    variable.

-  This option have changed behaviour in OpenVPN 2.3. Earlier you had to
+  This option has changed behaviour since OpenVPN 2.3. Earlier you 
had to

    define ``--win-sys env`` to use the SystemRoot environment variable,
    otherwise it defaulted to :code:`C:\\WINDOWS`. It is not needed 
to use
    the ``env`` keyword any more, and it will just be ignored. A 
warning is

@@ -239,7 +239,7 @@ Windows-Specific Options

  --windows-driver drv
    Specifies which tun driver to use. Values are :code:`tap-windows6`
-  (default) and :code:`wintun`.  This is Windows-only option.
+  (default) and :code:`wintun`.  This is a Windows-only option.
    :code:`wintun`" requires ``--dev tun`` and the OpenVPN process to 
run

    elevated, or be invoked using the Interactive Service.

--
2.17.1



___
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] New man page corrections - windows-options.rst

[tincanteksup]

Hi Jonathan,

these are going to the new manpage, see:
https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting

They don't really need an ACK because dazo will review them first anyway 
but thanks all the same :)


Regards


On 02/07/2020 14:41, Jonathan K. Bullard wrote:

Improves English diction and/or grammar of man page.

Acked-by: Jonathan K. Bullard 

On Tue, Jun 30, 2020 at 9:11 PM Richard Bonhomme  wrote:


Signed-off-by: Richard Bonhomme 
---
  doc/man-sections/windows-options.rst | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/man-sections/windows-options.rst 
b/doc/man-sections/windows-options.rst
index 5ae7116c..72424d6b 100644
--- a/doc/man-sections/windows-options.rst
+++ b/doc/man-sections/windows-options.rst
@@ -231,7 +231,7 @@ Windows-Specific Options
directive is not specified, OpenVPN will use the SystemRoot environment
variable.

-  This option have changed behaviour in OpenVPN 2.3. Earlier you had to
+  This option has changed behaviour since OpenVPN 2.3. Earlier you had to
define ``--win-sys env`` to use the SystemRoot environment variable,
otherwise it defaulted to :code:`C:\\WINDOWS`. It is not needed to use
the ``env`` keyword any more, and it will just be ignored. A warning is
@@ -239,7 +239,7 @@ Windows-Specific Options

  --windows-driver drv
Specifies which tun driver to use. Values are :code:`tap-windows6`
-  (default) and :code:`wintun`.  This is Windows-only option.
+  (default) and :code:`wintun`.  This is a Windows-only option.
:code:`wintun`" requires ``--dev tun`` and the OpenVPN process to run
elevated, or be invoked using the Interactive Service.

--
2.17.1



___
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] New man page corrections - encryption-options.rst

[tincanteksup]

Comment inline:

On 26/06/2020 15:29, Richard Bonhomme wrote:

Signed-off-by: Richard Bonhomme 
---
  doc/man-sections/encryption-options.rst | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/man-sections/encryption-options.rst 
b/doc/man-sections/encryption-options.rst
index 42c80eb8..076b5fd3 100644
--- a/doc/man-sections/encryption-options.rst
+++ b/doc/man-sections/encryption-options.rst
@@ -86,5 +86,5 @@ Generating key material
  
* Generating *TLS Crypt v2 Server key*

-Generate a ``--tls-crypt-v2`` key tp be used by an OpenVPN server.
+Generate a ``--tls-crypt-v2`` key to be used by an OpenVPN server.
  The key is stored in ``keyfile``.
  
@@ -127,7 +127,7 @@ Generating key material
  
  *Note:*

-   This file should be kept secret to the server as anyone that
-   access to this file will be to generate auth tokens that the OpenVPN
-   server will accept as valid.
+   This file should be kept secret to the server as anyone that has


I don't know if this is correct or if it should read:
   This file should be kept secret from the server ..


+   access to this file will be able to generate auth tokens that the
+   OpenVPN server will accept as valid.
  
  .. include:: renegotiation.rst





___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[tincanteksup]

I have tested this fix all the way to ensuring that tls-cypt-v2.keys are 
created successfully and do allow successful VPN connection.


I have not tested auth-tokens.

Tested-by: Richard Bonhomme 

On 06/04/2020 14:00, Arne Schwabe wrote:

crypto_pem_encode put a nul-terminated terminated string into the
buffer. This is useful for printf but should not be written into
the file.

Also for static keys, we were missing the nul termination when priting
it to stadout but since the buffer was cleared before, there was always
a NULL byte in the right place. Make it explicit instead.

Signed-off-by: Arne Schwabe 
---
  src/openvpn/crypto.c| 11 +--
  src/openvpn/tls_crypt.c | 10 --
  2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index 453cb20a..7af48df0 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -1477,6 +1477,7 @@ write_key_file(const int nkeys, const char *filename)
  /* write key file to stdout if no filename given */
  if (!filename || strcmp(filename, "")==0)
  {
+buf_null_terminate();
  printf("%s\n", BPTR());
  }
  /* write key file, now formatted in out, to file */
@@ -1888,9 +1889,15 @@ write_pem_key_file(const char *filename, const char 
*pem_name)
  {
  printf("%s\n", BPTR(_key_pem));
  }
-else if (!buffer_write_file(filename, _key_pem))
+else
  {
-msg(M_ERR, "ERROR: could not write key file");
+/* crypto_pem_encode null terminates the buffer, do
+ * not write this to the file */
+buf_inc_len(_key_pem, -1);
+if (!buffer_write_file(filename, _key_pem))
+{
+msg(M_ERR, "ERROR: could not write key file");
+}
  goto cleanup;
  }
  
diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c

index e9f9cc2a..85f2862b 100644
--- a/src/openvpn/tls_crypt.c
+++ b/src/openvpn/tls_crypt.c
@@ -706,9 +706,15 @@ tls_crypt_v2_write_client_key_file(const char *filename,
  client_filename = INLINE_FILE_TAG;
  client_inline = (const char *)BPTR(_key_pem);
  }
-else if (!buffer_write_file(filename, _key_pem))
+else
  {
-msg(M_FATAL, "ERROR: could not write client key file");
+/* crypto_pem_encode null terminates the buffer, do
+ * not write this to the file */
+buf_inc_len(_key_pem, -1);
+if (!buffer_write_file(filename, _key_pem))
+{
+msg(M_FATAL, "ERROR: could not write client key file");
+}
  goto cleanup;
  }
  




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (16th January 2020)

[tincanteksup]

Correction below.

On 17/01/2020 12:28, tincanteksup wrote:

The following information is also applicable to *Nix.


In order to use the upgrade, simply copy your EasyRSA-2 PKI (Generally 
found in ./Keys directory under Easy-rsa directory) to Easyrsa3 
directory and run:

'./easyrsa upgrade pki'


The upgrade also requires that 'vars' or 'vars.bat' be copied to the 
./easyrsa3 directory, in order to verify the CA is correct.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (16th January 2020)

[tincanteksup]

The following information is also applicable to *Nix.

With regard to packaging EasyRSA-3 with Windows in the future.

The reason EasyRSA-3 has not been the default package for Windows is due 
to EasyRSA-2 PKI not being suitable for use in EasyRSA-3, due to the layout.


This issue now has a solution: "Easyrsa-upgrade"

Please see:
* https://community.openvpn.net/openvpn/wiki/easyrsa-upgrade
  A work in progress detailing the upgrade procedure.

* 
https://github.com/OpenVPN/easy-rsa/commit/07ec923be13d45d1592e93f08a0157dbc7ed3b4c

  The upgrade script.

In order to use the upgrade, simply copy your EasyRSA-2 PKI (Generally 
found in ./Keys directory under Easy-rsa directory) to Easyrsa3 
directory and run:

'./easyrsa upgrade pki'

Depending on how Easyrsa-3 is packaged, this procedure could be automated.

The Easyrsa-upgrade is currently only available in git/master.
We are planning a standard release quite soon. (Version 3.x.x to be 
confirmed)


Questions and feedback welcome.

Thanks
Richard
--


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v7 2/2] Add support for OpenSSL TLS 1.3 when using management-external-key

[tincanteksup]

Tiny grammar concern:

On 22/11/2019 14:33, Arne Schwabe wrote:

For TLS 1.0 to 1.2 and OpenSSL 1.1.0 calls us and requires a PKCS1
padded response. As TLS 1.3 mandates RSA-PSS padding support and also
requires an TLS 1.3 implementation to support RSA-PSS for older TLS
version, OpenSSL will query us to sign an already RSA-PSS padded
string.

This patch adds an 'unpadded' and 'pkcs1' parameter to the
management-external-key option to signal that the client is
able to support pkcs1 as well as unpadded signature requests.

Since clients that implement the management-external-key interface
are usually rather tightly integrated solutions (OpenVPN Connect in the
past, OpenVPN for Android), it is reasonable to expect that
upgrading the OpenSSL library can be done together with
management interface changes. Therefore we provide no backwards
compatbility for mangement-interface clients not supporting
OpenSSL 1.1.1.

Using the management api client version instead might seem like the
more logical way but since we only now that version very late,
it would extra logic and complexity to deal with this asynchronous
behaviour. Instead just give an error early if OpenSSL 1.1.1 and
management-external-key without nopadding is detected.

The interface is prepared for signalling PCKS1 and RSA-PSS support
instead of signalling unpadded support.

Patch v3: fix overlong lines and few other style patches. Note
   two overlong lines concerning mbedtls are not fixed as they
   are removed/shortend by the mbed tls patch to avoid conflicts

Patch v4: Setting minimum TLS version proved to be not enough and
   instead of implementing a whole compability layer we require
   mangement-clients to implement the new feature when they want
   to use OpenSSL 1.1.1

   Add a padding=ALGORITHM argument to pk-sig to indicate the
   algorithm. Drop adding PKCS1 ourselves.

Patch v5: Send the right version of the patch
Patch v6: rebase on master
Patch v7: change style and reword documentation. Make thing more consistent

Signed-off-by: Arne Schwabe 
---
  doc/management-notes.txt  | 21 -
  doc/openvpn.8 |  7 +++--
  src/openvpn/manage.c  | 20 +---
  src/openvpn/manage.h  | 19 +++-
  src/openvpn/options.c | 36 +-
  src/openvpn/ssl_mbedtls.c |  8 +++--
  src/openvpn/ssl_openssl.c | 64 ++-
  7 files changed, 143 insertions(+), 32 deletions(-)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index 17645c1d..c64e594d 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -816,6 +816,7 @@ actual private key. When the SSL protocol needs to perform 
a sign
  operation, the data to be signed will be sent to the management interface
  via a notification as follows:
  
+>PK_SIGN:[BASE64_DATA],[ALG] (if client announces support for management version > 2)

  >PK_SIGN:[BASE64_DATA] (if client announces support for management version > 
1)
  >RSA_SIGN:[BASE64_DATA] (only older clients will be prompted like this)
  
@@ -823,7 +824,7 @@ The management interface client should then create an appropriate signature of

  the (decoded) BASE64_DATA using the private key and return the SSL signature 
as
  follows:
  
-pk-sig   (or rsa-sig)

+pk-sig (or rsa-sig)
  [BASE64_SIG_LINE]
  .
  .
@@ -833,6 +834,12 @@ END
  Base 64 encoded output of RSA_private_encrypt for RSA or ECDSA_sign()
  for EC using OpenSSL or mbedtls_pk_sign() using mbed TLS will provide a
  correct signature.
+The rsa-sig interfaces expects PKCS1 padded signatures for RSA keys
+(RSA_PKCS1_PADDING). EC signatures are always unpadded.
+
+The padding field is only present when pk-sig is used and
+currently the following values can be requested PCKS1 and NOPADDING for RSA
+certificates and NOPADDING for EC certificates.
  
  This capability is intended to allow the use of arbitrary cryptographic

  service providers with OpenVPN via the management interface.
@@ -840,6 +847,18 @@ service providers with OpenVPN via the management 
interface.
  New and updated clients are expected to use the version command to announce
  a version > 1 and handle '>PK_SIGN' prompt and respond with 'pk-sig'.
  
+The signature algorithm is indicated in the PK_SIGN request only if the

+management client-version is >= 2.  In particular, to support TLS1.3 and
+TLS1.2 using OpenSSL 1.1.1, not padded signature support is required  and this



"not padded" -> "unpadded"



+can be indicated in the signing request only if the client version is > 2"
+
+The currently defined padding algorithm are:
+
+ - RSA_PKCS1_PADDING  -  PKCS1 padding and RSA signature
+ - RSA_NO_PADDING -  No padding may be added for the signature
+ - ECDSA  -  EC signature.
+
+
  COMMAND -- certificate (OpenVPN 2.4 or higher)
  --
  Provides support for external storage of the certificate. Requires the
diff --git a/doc/openvpn.8 

Re: [Openvpn-devel] [PATCH v2] Fix ACL_CHECK_ADD_COMPILE_FLAGS to work with clang

[tincanteksup]

Typo below,

On 19/11/2019 17:03, selva.n...@gmail.com wrote:

From: Selva Nair 

Some compilers (e.g., clang) only issue a warning for
unsupported options unless an additional flag such
as -Werror is used to convert the warning to an error.

The behaviour is unchanged when using gcc as it either
errors or ignores unknown options whether or not -Werror
is present.

Signed-off-by: Selva Nair 
---
v2: Do not extend the macro to take an extra argument.
Instead, add -Werror while doing the test.

The commit message and comment changed to match this.

  configure.ac | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 807804e5..f4a947d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1275,11 +1275,14 @@ if test "${enable_pkcs11}" = "yes"; then
)
  fi
  
+# When testing a compiler option, we add -Werror to force

+# an error when the option is unsupported. This is not
+# required for gcc, but come compilers such as clang needs it.



come compilers --> some compilers





  AC_DEFUN([ACL_CHECK_ADD_COMPILE_FLAGS], [
  old_cflags="$CFLAGS"
-CFLAGS="$1 $CFLAGS"
-AC_MSG_CHECKING([whether the compiler acceppts $1])
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], [AC_MSG_RESULT([yes])],
+CFLAGS="$1 -Werror $CFLAGS"
+AC_MSG_CHECKING([whether the compiler accepts $1])
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], [AC_MSG_RESULT([yes])]; CFLAGS="$1 
$old_cflags",
  [AC_MSG_RESULT([no]); CFLAGS="$old_cflags"])]
  )
  




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: VLAN: add basic VLAN tagging support

[tincanteksup]

Hi,

On 07/11/2019 12:42, Lev Stipakov wrote:

Hi,



I'm a bit unhappy with that one, as it changes behaviour for all
non-windows
builds (including all the openssl build output even if it succeeds).



The only place it changes behavior is this

  install:
- if [ ! -z "${CHOST}" ]; then unset CC; fi
-  - .travis/build-deps.sh > build-deps.log 2>&1 || (cat build-deps.log &&
exit 1)
+  - .travis/build-deps.sh

I don't see it as an issue to print output when building dependencies. The
reason why
it is done is that travis aborts build if there is no output for more than
10 minutes.



Can travis be instructed to wait longer ?


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v6] openvpnserv: enable interactive service to open tun

[tincanteksup]

Looks like a typo below:

On 23/07/2019 10:21, Lev Stipakov wrote:

From: Lev Stipakov 

This patch enables interactive service to open tun device.
This is mostly needed by Wintun, which could be opened
only by privileged process.

When interactive service is used, instead of calling
CreateFile() directly by openvpn process we pass tun device path
into service process. There we open device, duplicate handle
and pass it back to openvpn process.

Signed-off-by: Lev Stipakov 
---
  v6:
   - simplify and strengthen guid check with wcsspn()
   - fix doxygen comment

  v5:
   - further strengthen security by passing only device guid from client process
   to service, validating guid and constructing device path on service side

  v4:
   - strengthen security by adding basic validation to device path
   - reorder fields in msg_open_tun_device_result for backward compatibility

  v3:
   - ensure that device path passed by client is null-terminated
   - support for multiple openvpn processes
   - return proper error code when device handle is invalid

  v2:
   - introduce send_msg_iservice_ex() instead of changing
   signature of existing send_msg_iservice()
   - use wchar_t strings in interactive service code

  include/openvpn-msg.h | 12 +++
  src/openvpn/tun.c | 83 ++-
  src/openvpn/win32.c   |  9 -
  src/openvpn/win32.h   | 30 +---
  src/openvpnserv/interactive.c | 78 ++--
  5 files changed, 188 insertions(+), 24 deletions(-)

diff --git a/include/openvpn-msg.h b/include/openvpn-msg.h
index 66177a2..5dbdca5 100644
--- a/include/openvpn-msg.h
+++ b/include/openvpn-msg.h
@@ -39,6 +39,8 @@ typedef enum {
  msg_del_block_dns,
  msg_register_dns,
  msg_enable_dhcp,
+msg_open_tun_device,
+msg_open_tun_device_result,
  } message_type_t;
  
  typedef struct {

@@ -117,4 +119,14 @@ typedef struct {
  interface_t iface;
  } enable_dhcp_message_t;
  
+typedef struct {

+message_header_t header;
+char device_guid[36+2+1]; /* length of guid with dashes + braces + nul 
terminator */
+} open_tun_device_message_t;
+
+typedef struct {
+message_header_t header;
+int error_number;
+HANDLE handle;
+} open_tun_device_result_message_t;
  #endif /* ifndef OPENVPN_MSG_H_ */
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 8f8f7c6..df26ccf 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5248,6 +5248,43 @@ out:
  return ret;
  }
  
+static HANDLE

+service_open_tun_device(const HANDLE pipe, const char* device_guid)
+{
+open_tun_device_result_message_t result_msg;
+struct gc_arena gc = gc_new();
+open_tun_device_message_t open_tun_device = {
+.header = {
+msg_open_tun_device,
+sizeof(open_tun_device_message_t),
+0
+}
+};
+result_msg.handle = INVALID_HANDLE_VALUE;
+
+strncpynt(open_tun_device.device_guid, device_guid, 
sizeof(open_tun_device.device_guid));
+
+if (!send_msg_iservice_ex(pipe, _tun_device, sizeof(open_tun_device),
+_msg, sizeof(result_msg), "Open_tun_device"))
+{
+goto out;
+}
+
+if (result_msg.error_number != NO_ERROR)
+{
+msg(D_TUNTAP_INFO, "TUN: opening tun handle using service failed: %s 
[status=%u device_path=%s]",
+strerror_win32(result_msg.error_number, ), 
result_msg.error_number, device_guid);
+}
+else
+{
+msg(M_INFO, "Opened tun device %s using service", device_guid);
+}
+
+out:
+gc_free();
+return result_msg.handle;
+}
+
  /*
   * Return a TAP name for netsh commands.
   */
@@ -5591,15 +5628,22 @@ open_tun(const char *dev, const char *dev_type, const 
char *dev_node, struct tun
   device_guid,
   TAP_WIN_SUFFIX);
  
-tt->hand = CreateFile(

-device_path,
-GENERIC_READ | GENERIC_WRITE,
-0,/* was: FILE_SHARE_READ */
-0,
-OPEN_EXISTING,
-FILE_ATTRIBUTE_SYSTEM | FILE_FLAG_OVERLAPPED,
-0
+if (tt->options.msg_channel)
+{
+tt->hand = service_open_tun_device(tt->options.msg_channel, 
device_guid);
+}
+else
+{
+tt->hand = CreateFile(
+device_path,
+GENERIC_READ | GENERIC_WRITE,
+0,/* was: FILE_SHARE_READ */
+0,
+OPEN_EXISTING,
+FILE_ATTRIBUTE_SYSTEM | FILE_FLAG_OVERLAPPED,
+0
  );
+}
  
  if (tt->hand == INVALID_HANDLE_VALUE)

  {
@@ -5631,15 +5675,22 @@ open_tun(const char *dev, const char *dev_type, const 
char *dev_node, struct tun
   

Re: [Openvpn-devel] New OpenVPN 2.4.7 installers with tap-windows6 and other componets

[tincanteksup]

Tested and working, 32bit Win7 install over a previous install.

On 20/04/2019 10:16, Samuli Seppänen wrote:

Hi all,

Here are completely untested OpenVPN 2.4.7 installers which I wanted to
get out for testing a.s.a.p.:




As the name implies, there is a different version for Windows 7 (plus
8/8.1/Server 2012r2) and for Windows 10 (all versions). This is
necessary due to code signatures in the tap-windows6 driver.

The above installers bundle the following components:

- tap-windows6 9.23.2 (many improvements incl. arm64 support)
- openvpn-gui 11 (latest from Git master)
- openvpnserv2 1.4.0.0 (latest from Git master)

If you want to just test the tap-windows6 installers they're here:




The latter installer _might_ work on Windows 10-based ARM64 devices, but
that has not been tested at all.

I will run my pre-release tests as soon as I can, but probably not
today. Any help in testing these would be most welcome!



___
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] Improve the documentation for --dhcp-option

[tincanteksup]

Correcion

>From: Selva Nair 
>
>Make clear that --dhcp-option is not processed on
>non-Windows clients


This thread was _initially_ about pushing DNS to Linux clients.


I mean "non-windows" clients.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Improve the documentation for --dhcp-option

[tincanteksup]

On 20/03/2019 18:12, tincanteksup wrote:

bonjour

On 20/03/2019 17:25, Selva Nair wrote:

On Wed, Mar 20, 2019 at 10:52 AM tincanteksup 
wrote:




On 20/03/2019 13:25, Selva Nair wrote:

Hi,

On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli  
wrote:


Hi,

On 18/03/2019 22:30, tincanteksup wrote:

Hi,

this situation has been hanging around for so long is this brief note
really enough? Considering that the manual has numerous other URLs 
why

not include this URL here:
https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients

We already have this:
https://community.openvpn.net/openvpn/wiki/SWEET32



the problem with URLs is that they become obsolete and we need to
re-patch the manual in order to update them (or ensure the URL always
work/redirect to something).



I have the same opinion about URLs. On top of that the wiki
description is inadequate and inaccurate. But that's a different
topic.


Inadequate:
Compared to NOTHING, the page is at least a step toward documentation.

Inaccurate:
Please expand ..


The wiki states that on Windows using version 2.4, 
OpenVPN-GUI+interactive

service required for processing this option. Not so.


I am actively promoting 2.4 use, I am not re-writing the manual.


Just as in 2.3, it works if run as admin. In fact, several setups run
OpenVPN on boot using OpenVPNService, and --dhcp-option does work for 
them.

With 2.4, it also works as limited user if started using the interactive
service (for example, using OpenVPN-GUI).


I am actively demoting 2.3 use, I am not re-writing the manual.

In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 
method

(adaptive or dynamic is required and the latter is the
default).



I am actively promoting the use of the Interactive Service.
I am not rewriting the manual ..

If a problem arises from using Openvpn as the page describes then,
depending on the cause, a resolution can be pursued ..

thanks
tct



This thread was _initially_ about pushing DNS to Linux clients.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Improve the documentation for --dhcp-option

[tincanteksup]

bonjour

On 20/03/2019 08:00, Antonio Quartulli wrote:

Hi,

On 18/03/2019 22:30, tincanteksup wrote:

Hi,

this situation has been hanging around for so long is this brief note
really enough? Considering that the manual has numerous other URLs why
not include this URL here:
https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients

We already have this:
https://community.openvpn.net/openvpn/wiki/SWEET32



Reinserted from my original post:

Please consider adding it.





the problem with URLs is that they become obsolete and we need to
re-patch the manual in order to update them (or ensure the URL always
work/redirect to something).


However, I was thinking that a WARNING in the log when parsing a
dhcp-option without any script configured (on non-windows platform) may
also be beneficial.

Not many people will read it, but at least it will be there to be seen
at the first attempt of understanding what's wrong.

What do you think?



The argument against using URLs in the Manual has these facts to refute:
* URLs are already in use in the manual
* I cited another example of using a URL in the manual.
* Some URLS in use in the manual are external to openvpn.net
* Using URLs in online documentation is The standard practice.
* There are even URLs in the Openvpn log files ..

It is easier to maintain linked documentation than it is to have to
patch the source so, given that the link is under the openvpn.net wing,
this seems perfectly reasonable to me.


Adding a warning for this problem in the log file is unsuitable:
* When the situation changes the source will have to be maintained.
* The situation will change.
* It is easier to maintain linked documentation to account for change.
* Log files are for diagnosing problems and should not have any URLs..
(Except for one URL to ${help}.openvpn, a URL which is unlikely to 
change and can therefore be easily maintained by OpenVPN Inc and remove

that burden from the FOSS Openvpn development team)

my2c thanks
tct




This said, the warning could/should be implemented as a separate patch.

Regards,




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Improve the documentation for --dhcp-option

[tincanteksup]

bonjour

On 20/03/2019 17:25, Selva Nair wrote:

On Wed, Mar 20, 2019 at 10:52 AM tincanteksup 
wrote:




On 20/03/2019 13:25, Selva Nair wrote:

Hi,

On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli  wrote:


Hi,

On 18/03/2019 22:30, tincanteksup wrote:

Hi,

this situation has been hanging around for so long is this brief note
really enough? Considering that the manual has numerous other URLs why
not include this URL here:
https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients

We already have this:
https://community.openvpn.net/openvpn/wiki/SWEET32



the problem with URLs is that they become obsolete and we need to
re-patch the manual in order to update them (or ensure the URL always
work/redirect to something).



I have the same opinion about URLs. On top of that the wiki
description is inadequate and inaccurate. But that's a different
topic.


Inadequate:
Compared to NOTHING, the page is at least a step toward documentation.

Inaccurate:
Please expand ..


The wiki states that on Windows using version 2.4, OpenVPN-GUI+interactive
service required for processing this option. Not so.


I am actively promoting 2.4 use, I am not re-writing the manual.


Just as in 2.3, it works if run as admin. In fact, several setups run
OpenVPN on boot using OpenVPNService, and --dhcp-option does work for them.
With 2.4, it also works as limited user if started using the interactive
service (for example, using OpenVPN-GUI).


I am actively demoting 2.3 use, I am not re-writing the manual.


In both 2.3 and 2.4, the critical piece is not overriding --ipwin32 method
(adaptive or dynamic is required and the latter is the
default).



I am actively promoting the use of the Interactive Service.
I am not rewriting the manual ..

If a problem arises from using Openvpn as the page describes then,
depending on the cause, a resolution can be pursued ..

thanks
tct



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Improve the documentation for --dhcp-option

[tincanteksup]

On 20/03/2019 13:25, Selva Nair wrote:

Hi,

On Wed, Mar 20, 2019 at 4:02 AM Antonio Quartulli  wrote:


Hi,

On 18/03/2019 22:30, tincanteksup wrote:

Hi,

this situation has been hanging around for so long is this brief note
really enough? Considering that the manual has numerous other URLs why
not include this URL here:
https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients

We already have this:
https://community.openvpn.net/openvpn/wiki/SWEET32



the problem with URLs is that they become obsolete and we need to
re-patch the manual in order to update them (or ensure the URL always
work/redirect to something).



I have the same opinion about URLs. On top of that the wiki
description is inadequate and inaccurate. But that's a different
topic.


Inadequate:
Compared to NOTHING, the page is at least a step toward documentation.

Inaccurate:
Please expand ..



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Improve the documentation for --dhcp-option

[tincanteksup]

Hi,

this situation has been hanging around for so long is this brief note
really enough? Considering that the manual has numerous other URLs why
not include this URL here:
https://community.openvpn.net/openvpn/wiki/Pushing-DNS-to-clients

We already have this:
https://community.openvpn.net/openvpn/wiki/SWEET32

Please consider adding it.
Thanks
tct


On 18/03/2019 21:16, selva.n...@gmail.com wrote:

From: Selva Nair 

Make clear that --dhcp-option is not processed on
non-Windows clients and the user is expected to handle
it using an --up script.

Signed-off-by: Selva Nair 
---
  doc/openvpn.8 | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index ce44044..993c8bd 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -6026,13 +6026,21 @@ scope IDs. The Scope ID becomes a part of the NetBIOS 
name, making the name uniq
  .B DISABLE\-NBT \-\-
  Disable Netbios\-over\-TCP/IP.
  
-Note that if

+Note that
+.B \-\-dhcp\-option
+is processed only on Windows clients. If
  .B \-\-dhcp\-option
-is pushed via
+is used directly on or pushed via
  .B \-\-push
-to a non\-windows client, the option will be saved in the client's
-environment before the up script is called, under
-the name "foreign_option_{n}".
+to a non\-windows client, the option is
+.B only
+saved in the client's
+environment before the
+.B \-\-up
+script is called, under the name "foreign_option_{n}".
+The user has to arrange an
+.B \-\-up
+script to pick up those parameters and act on them as required.
  .\"*
  .TP
  .B \-\-tap\-sleep n




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

On 02/01/2019 18:46, Gert Doering wrote:

Hi,

On Wed, Jan 02, 2019 at 04:37:33PM +, Simon Rozman wrote:

Even though there are errors reported the VPN still works for both
IPv4 and 6 with both versions of the binary.


Probably a patch between 2.4.6 from 26/Apr/2018 and 2.4.6-m4 from 1/Jan/2019 
introduced an error-level check after the netsh.exe interface ipv6 add route 
call.


Not that I'm aware of (re-read "git log release/2.4" to be sure).   We added
"turn on dhcp via iservice" support, but that's not "add route".

So it's likely something else.  Need to look at the details in the log
(what is pushed, how is netsh called, what is failing?).


Sorry, this was probably my own fault ..

My best guess is this may have been something to do with me
saving/restoring the VM.

I re-installed your m4 and then tried with my git_master and cannot
reproduce the route failures.  Tried a few re-installs etc ..

While testing different installs I found that the installer failed to
uninstall the openvpn Legacy service once, but I tried so many different
combinations of uninstall/new install vs install over a running process
that one small glitch, which err'd out correctly with user press cancel,
that I don't think it is worth worrying about.
(I was trying to break it deliberately)

Overall, the 32b installer from .exe seems to work well.


Sorry about the VM thing :-)


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

Hi,

On 02/01/2019 14:11, tincanteksup wrote:

Successfully install 32bit from .exe



However, there appears to be a problem ..

https://paste.fedoraproject.org/paste/Ih2LYl0cR8YoKnI2lNwhcQ

Part 1 is the client log *with* errors using the binary from your
installer 2.4.6-m4 dated 1/Jan/2019

Part 2 is the routing before and after part 1

Part 3 is the client log *without* errors using the binary from
the official installer 2.4.6 dated 26/Apr/2018

Both logs are for the same config file on the same machine
Windows 7 32bit VM -- Fully upto date with MS.

Even though there are errors reported the VPN still works for both
IPv4 and 6 with both versions of the binary.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

Successfully install 32bit from .exe


On 01/01/2019 23:34, Simon Rozman wrote:

Hi,

I have found and fixed the issue with the installer: all 32-bit MSI packages 
were affected - didn't notice it myself as all my testing machines turned out 
to be 64-bit :(. New version of the installer is available at 
https://github.com/rozmansi/openvpn/releases.

Best regards,
Simon

On 21.12.2018, 05:48, "Simon Rozman"  wrote:

 Hi,
 
 > This may be a false alarm because Windows has decided this VM needs

 > "some" updates .. I'll update after the reboot dance. *yawn*
 
 Actually, setup should work with a vanilla non-updated Windows 7 too. Though

 we should encourage our users to run up-to-date Windows.
 
 Thank you very much for your report. I am downloading the IE11-Win7 image as

 we speak and will test _before_ and _after_ the updates.
 
 Regards,

 Simon
 




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Ubuntu 18.04 packages available for testing

[tincanteksup]

Hi,

On 30/12/2018 14:56, Samuli Seppänen wrote:

Hi,

Il 29/12/18 22:06, tincanteksup ha scritto:





  debian/rules clean
dh clean
make: dh: Command not found


Package "debhelper" is missing. When using Vagrant debhelper gets
installed in the provisioning script:

   https://github.com/mattock/openvpn-vagrant/blob/sbuild/sbuild.sh

That provisioning script should run fine on any Ubuntu 18.04 VM, not
just inside Vagrant/Virtualbox.


Yes, it all works now.



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Ubuntu 18.04 packages available for testing

[tincanteksup]

On 28/12/2018 14:21, tincanteksup wrote:

Hi,

On 27/12/2018 18:11, Samuli Seppänen wrote:

>>


Also, if you can, please review these PRs which enable anyone to build
the Ubuntu/Debian packages, including ones for Ubuntu 18.04:

https://github.com/OpenVPN/sbuild_wrapper/pull/1
https://github.com/OpenVPN/openvpn-vagrant/pull/6



Working on it ..



Tested and working but with one note.

scripts/prepare-all.sh
```
dpkg-buildpackage -d -S -uc -us
```
does not work.

The failure is:
```
tct@home:~/openvpn/pkg-bsys$ sudo scripts/prepare-all.sh
--2018-12-29 16:04:53-- 
http://build.openvpn.net/downloads/releases/openvpn-2.4.6.tar.gz
Resolving build.openvpn.net (build.openvpn.net)... 52.52.118.245, 
2600:1f1c:702:ae00:f27c:d805:3b80:a45d
Connecting to build.openvpn.net (build.openvpn.net)|52.52.118.245|:80... 
connected.

HTTP request sent, awaiting response... 200 OK
Length: 1431971 (1.4M) [application/octet-stream]
Saving to: ‘openvpn-2.4.6.tar.gz’

openvpn-2.4.6.tar.gz 
100%[>] 
  1.37M   159KB/sin 7.4s


2018-12-29 16:05:00 (190 KB/s) - ‘openvpn-2.4.6.tar.gz’ saved 
[1431971/1431971]


cp: 'debian/patches/series' and 'debian/patches/series' are the same file
dpkg-buildpackage: info: source package openvpn
dpkg-buildpackage: info: source version 2.4.6-bionic0
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: source changed by Samuli Seppänen 


 dpkg-source --before-build openvpn-2.4.6
dpkg-source: info: applying move_log_dir.patch
dpkg-source: info: applying auth-pam_libpam_so_filename.patch
dpkg-source: info: applying debian_nogroup_for_sample_files.patch
dpkg-source: info: applying openvpn-pkcs11warn.patch
dpkg-source: info: applying kfreebsd_support.patch
dpkg-source: info: applying match-manpage-and-command-help.patch
 debian/rules clean
dh clean
make: dh: Command not found
debian/rules:16: recipe for target 'clean' failed
make: *** [clean] Error 127
dpkg-buildpackage: error: debian/rules clean subprocess returned exit 
status 2


```

Change scripts/prepare-all.sh
```
dpkg-buildpackage -nc -d -S -uc -us
```
Works, tested on two independent systems.

The output is now:
```
tct@home:~/openvpn/pkg-bsys$ sudo scripts/prepare-all.sh
--2018-12-29 19:25:52-- 
http://build.openvpn.net/downloads/releases/openvpn-2.4.6.tar.gz
Resolving build.openvpn.net (build.openvpn.net)... 52.52.118.245, 
2600:1f1c:702:ae00:f27c:d805:3b80:a45d
Connecting to build.openvpn.net (build.openvpn.net)|52.52.118.245|:80... 
connected.

HTTP request sent, awaiting response... 200 OK
Length: 1431971 (1.4M) [application/octet-stream]
Saving to: ‘openvpn-2.4.6.tar.gz’

openvpn-2.4.6.tar.gz 
100%[>] 
  1.37M   308KB/sin 5.0s


2018-12-29 19:25:57 (282 KB/s) - ‘openvpn-2.4.6.tar.gz’ saved 
[1431971/1431971]


cp: 'debian/patches/series' and 'debian/patches/series' are the same file
dpkg-buildpackage: info: source package openvpn
dpkg-buildpackage: info: source version 2.4.6-bionic0
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: source changed by Samuli Seppänen 


 dpkg-source --before-build openvpn-2.4.6
dpkg-source: info: applying move_log_dir.patch
dpkg-source: info: applying auth-pam_libpam_so_filename.patch
dpkg-source: info: applying debian_nogroup_for_sample_files.patch
dpkg-source: info: applying openvpn-pkcs11warn.patch
dpkg-source: info: applying kfreebsd_support.patch
dpkg-source: info: applying match-manpage-and-command-help.patch
dpkg-buildpackage: warning: building a source package without cleaning 
up as you asked; it might contain undesired files

 dpkg-source -b openvpn-2.4.6
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building openvpn using existing 
./openvpn_2.4.6.orig.tar.gz

dpkg-source: info: building openvpn in openvpn_2.4.6-bionic0.debian.tar.xz
dpkg-source: info: building openvpn in openvpn_2.4.6-bionic0.dsc
 dpkg-genbuildinfo --build=source
 dpkg-genchanges --build=source >../openvpn_2.4.6-bionic0_source.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build openvpn-2.4.6
dpkg-source: info: unapplying match-manpage-and-command-help.patch
dpkg-source: info: unapplying kfreebsd_support.patch
dpkg-source: info: unapplying openvpn-pkcs11warn.patch
dpkg-source: info: unapplying debian_nogroup_for_sample_files.patch
dpkg-source: info: unapplying auth-pam_libpam_so_filename.patch
dpkg-source: info: unapplying move_log_dir.patch
dpkg-buildpackage: info: full upload (original source is included)

```



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Ubuntu 18.04 packages available for testing

[tincanteksup]

Hi,

On 27/12/2018 18:11, Samuli Seppänen wrote:

Hi,

I've produced OpenVPN 2.4.6 packages for Ubuntu 18.04 and they're now
available here:

https://build.openvpn.net/downloads/temp/

The Debian packaging files are taken from Ubuntu's own 18.04 openvpn
package. They already used our openvpn-client@.service and
openvpn-server@.service so I only need to make a few enhancements:

- Restart active VPN client and server instances on upgrade
- Stop activate VPN client and server instances on uninstall

I also tested upgrading from Ubuntu's own openvpn package and that
worked fine.

Let me know if these packages work for you or if they don't. I'd like to
get the to our official apt repositories soon.



Successfully installed openvpn_2.4.6-bionic0_amd64.deb in Ubuntu 18.04,
tested newly installed openvpn-client@.service which worked correctly.



Also, if you can, please review these PRs which enable anyone to build
the Ubuntu/Debian packages, including ones for Ubuntu 18.04:

https://github.com/OpenVPN/sbuild_wrapper/pull/1
https://github.com/OpenVPN/openvpn-vagrant/pull/6



Working on it ..





Samuli



___
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] [Help required] Testing MSI installations

[tincanteksup]

On 20/12/2018 14:22, tincanteksup wrote:



On 20/12/2018 14:00, tincanteksup wrote:



On 20/12/2018 13:52, tincanteksup wrote:



On 20/12/2018 13:46, tincanteksup wrote:

Hi,

On 19/12/2018 21:55, Simon Rozman wrote:

Hi,



Remember: Test it to fail!

Any feedback kindly appreciated.



I just tested this on a "fresh" Win7 VM and it failed.

By "fresh" I mean this:

   The Win7 VM is from:
   https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

   Credit the find to:
   https://easylinuxtipsproject.blogspot.com/p/virtualbox.html

   The VM i used is IE11-Win7 x86





This may be a false alarm because Windows has decided this VM needs
"some" updates .. I'll update after the reboot dance. *yawn*



Even more updates later, the same "apparent" problem persists.

log:

=== Logging started: 20/12/2018  06:41:08 ===
Action 06:41:08: INSTALL.
Action start 06:41:08: INSTALL.
Action 06:41:08: SetDefaultUIFontVista.
Action start 06:41:08: SetDefaultUIFontVista.
Action ended 06:41:08: SetDefaultUIFontVista. Return value 1.
Action 06:41:08: SetDlgStrongFontVista.
Action start 06:41:08: SetDlgStrongFontVista.
Action ended 06:41:08: SetDlgStrongFontVista. Return value 1.
Action 06:41:08: SetDlgTitleFontVista.
Action start 06:41:08: SetDlgTitleFontVista.
Action ended 06:41:08: SetDlgTitleFontVista. Return value 1.
Action 06:41:08: PreparePage.
Action start 06:41:08: PreparePage.
Info 2898. For DefaultUIFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 20 pixels height.
Info 2898. For DlgTitleFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 25 pixels height.

Action 06:41:08: PreparePage. Dialog created
Action ended 06:41:08: PreparePage. Return value 1.
Action 06:41:08: FindRelatedProducts. Searching for related applications
Action start 06:41:08: FindRelatedProducts.
Action ended 06:41:08: FindRelatedProducts. Return value 1.
Action 06:41:08: FindTAPInterfaces. Searching for TAP interfaces
Action start 06:41:08: FindTAPInterfaces.
CustomAction FindTAPInterfaces returned actual error code 1154 (note 
this may not be 100% accurate if translation happened inside sandbox)
Error 1723. There is a problem with this Windows Installer package. A 
DLL required for this install to complete could not be run. Contact your 
support personnel or package vendor.  Action FindTAPInterfaces, entry: 
FindTAPInterfaces, library: C:\Users\IEUser\AppData\Local\Temp\MSIE9C3.tmp
MSI (c) (DC:E4) [06:41:16:156]: Product: OpenVPN 2.4.6m3-I603 x86 -- 
Error 1723. There is a problem with this Windows Installer package. A 
DLL required for this install to complete could not be run. Contact your 
support personnel or package vendor.  Action FindTAPInterfaces, entry: 
FindTAPInterfaces, library: C:\Users\IEUser\AppData\Local\Temp\MSIE9C3.tmp


Action ended 06:41:16: FindTAPInterfaces. Return value 3.
Action 06:41:16: FatalErrorPage.
Action start 06:41:16: FatalErrorPage.
Action 06:41:16: FatalErrorPage. Dialog created
Action ended 06:41:18: FatalErrorPage. Return value 2.
Action ended 06:41:18: INSTALL. Return value 3.
Property(C): InstallMode = Typical
Property(C): UpgradeCode = {1195A47B-A37A-4055-9D34-B7A691F7E97B}
Property(C): DesktopFolder = C:\Users\Public\Desktop\
Property(C): InstallModeRB = Change
Property(C): ErrorDialog = ErrorDialog
Property(C): LOGAPPEND = 0
Property(C): DISABLESAVEPWD = #0
Property(C): ADMINGROUP = OpenVPN Administrators
Property(C): PRIORITY = NORMAL_PRIORITY_CLASS
Property(C): DefaultUIFont = DefaultUIFontVista
Property(C): DlgStrongFont = {\DlgStrongFontVista}
Property(C): DlgTitleFont = {\DlgTitleFontVista}
Property(C): ProgramFilesFolder = C:\Program Files\
Property(C): ProgramMenuFolder = C:\ProgramData\Microsoft\Windows\Start 
Menu\Programs\

Property(C): SourceDir = C:\Users\IEUser\AppData\Local\Temp\7zS87C46480\
Property(C): VersionNT = 601
Property(C): ALLUSERS = 1
Property(C): ARPPRODUCTICON = openvpn.ico
Property(C): ARPURLINFOABOUT = https://openvpn.net/index.php/open-source/
Property(C): ARPURLUPDATEINFO = 
https://openvpn.net/index.php/open-source/downloads.html

Property(C): SimpleProductName = OpenVPN
Property(C): DisplayVersion = 2.4.6m3-I603
Property(C): MSICHECKCRCS = 1
Property(C): PROMPTROLLBACKCOST = P
Property(C): EDITOR = notepad.exe
Property(C): INSTALLLEVEL = 2
Property(C): Manufacturer = OpenVPN Technologies, Inc.
Property(C): ProductCode = {45521BD6-AC59-4050-A7A9-4B4EDDD3DC3D}
Property(C): ProductLanguage = 1033
Property(C): ProductName = OpenVPN 2.4.6m3-I603 x86
Property(C): ProductVersion = 2.4.603
Property(C): Setup = Setup
Property(C): ButtonTextInstall =  Now
Property(C): TitleCustomize = Custom Installation
Property(C): Progress1 = Installing
Property(C): Progress2 = Setup
Property(C): SecureCustomProperties = 
ACTIVETAPINTERFACES;DRIVERCERTIFICATION;NETFRAMEWORK40FULL;TAPINTERFACES;WIX_DOWNGRADE_DETECTED;WIX_UPGRADE_DETECTED
Property(C): MsiH

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

On 20/12/2018 14:00, tincanteksup wrote:



On 20/12/2018 13:52, tincanteksup wrote:



On 20/12/2018 13:46, tincanteksup wrote:

Hi,

On 19/12/2018 21:55, Simon Rozman wrote:

Hi,



Remember: Test it to fail!

Any feedback kindly appreciated.



I just tested this on a "fresh" Win7 VM and it failed.

By "fresh" I mean this:

   The Win7 VM is from:
   https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

   Credit the find to:
   https://easylinuxtipsproject.blogspot.com/p/virtualbox.html

   The VM i used is IE11-Win7 x86





This may be a false alarm because Windows has decided this VM needs
"some" updates .. I'll update after the reboot dance. *yawn*



Some 5349 patches later .. the error message is still the same.

But the log has more data:

=== Logging started: 20/12/2018  06:16:38 ===
Action 06:16:38: INSTALL.
Action start 06:16:38: INSTALL.
Action 06:16:38: SetDefaultUIFontVista.
Action start 06:16:38: SetDefaultUIFontVista.
Action ended 06:16:38: SetDefaultUIFontVista. Return value 1.
Action 06:16:38: SetDlgStrongFontVista.
Action start 06:16:38: SetDlgStrongFontVista.
Action ended 06:16:38: SetDlgStrongFontVista. Return value 1.
Action 06:16:38: SetDlgTitleFontVista.
Action start 06:16:38: SetDlgTitleFontVista.
Action ended 06:16:38: SetDlgTitleFontVista. Return value 1.
Action 06:16:38: PreparePage.
Action start 06:16:38: PreparePage.
Info 2898. For DefaultUIFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 20 pixels height.
Info 2898. For DlgTitleFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 25 pixels height.

Action 06:16:38: PreparePage. Dialog created
Action ended 06:16:38: PreparePage. Return value 1.
Action 06:16:38: FindRelatedProducts. Searching for related applications
Action start 06:16:38: FindRelatedProducts.
Action ended 06:16:38: FindRelatedProducts. Return value 1.
Action 06:16:38: FindTAPInterfaces. Searching for TAP interfaces
Action start 06:16:38: FindTAPInterfaces.
CustomAction FindTAPInterfaces returned actual error code 1154 (note 
this may not be 100% accurate if translation happened inside sandbox)
Error 1723. There is a problem with this Windows Installer package. A 
DLL required for this install to complete could not be run. Contact your 
support personnel or package vendor.  Action FindTAPInterfaces, entry: 
FindTAPInterfaces, library: C:\Users\IEUser\AppData\Local\Temp\MSI9064.tmp
MSI (c) (B4:E4) [06:16:48:804]: Product: OpenVPN 2.4.6m3-I603 x86 -- 
Error 1723. There is a problem with this Windows Installer package. A 
DLL required for this install to complete could not be run. Contact your 
support personnel or package vendor.  Action FindTAPInterfaces, entry: 
FindTAPInterfaces, library: C:\Users\IEUser\AppData\Local\Temp\MSI9064.tmp


Action ended 06:16:48: FindTAPInterfaces. Return value 3.
Action 06:16:48: FatalErrorPage.
Action start 06:16:48: FatalErrorPage.
Action 06:16:48: FatalErrorPage. Dialog created
Action ended 06:16:50: FatalErrorPage. Return value 2.
Action ended 06:16:50: INSTALL. Return value 3.
Property(C): InstallMode = Typical
Property(C): UpgradeCode = {1195A47B-A37A-4055-9D34-B7A691F7E97B}
Property(C): DesktopFolder = C:\Users\Public\Desktop\
Property(C): InstallModeRB = Change
Property(C): ErrorDialog = ErrorDialog
Property(C): LOGAPPEND = 0
Property(C): DISABLESAVEPWD = #0
Property(C): ADMINGROUP = OpenVPN Administrators
Property(C): PRIORITY = NORMAL_PRIORITY_CLASS
Property(C): DefaultUIFont = DefaultUIFontVista
Property(C): DlgStrongFont = {\DlgStrongFontVista}
Property(C): DlgTitleFont = {\DlgTitleFontVista}
Property(C): ProgramFilesFolder = C:\Program Files\
Property(C): ProgramMenuFolder = C:\ProgramData\Microsoft\Windows\Start 
Menu\Programs\

Property(C): SourceDir = C:\Users\IEUser\AppData\Local\Temp\7zS02ECCC21\
Property(C): VersionNT = 601
Property(C): ALLUSERS = 1
Property(C): ARPPRODUCTICON = openvpn.ico
Property(C): ARPURLINFOABOUT = https://openvpn.net/index.php/open-source/
Property(C): ARPURLUPDATEINFO = 
https://openvpn.net/index.php/open-source/downloads.html

Property(C): SimpleProductName = OpenVPN
Property(C): DisplayVersion = 2.4.6m3-I603
Property(C): MSICHECKCRCS = 1
Property(C): PROMPTROLLBACKCOST = P
Property(C): EDITOR = notepad.exe
Property(C): INSTALLLEVEL = 2
Property(C): Manufacturer = OpenVPN Technologies, Inc.
Property(C): ProductCode = {45521BD6-AC59-4050-A7A9-4B4EDDD3DC3D}
Property(C): ProductLanguage = 1033
Property(C): ProductName = OpenVPN 2.4.6m3-I603 x86
Property(C): ProductVersion = 2.4.603
Property(C): Setup = Setup
Property(C): ButtonTextInstall =  Now
Property(C): TitleCustomize = Custom Installation
Property(C): Progress1 = Installing
Property(C): Progress2 = Setup
Property(C): SecureCustomProperties = 
ACTIVETAPINTERFACES;DRIVERCERTIFICATION;NETFRAMEWORK40FULL;TAPINTERFACES;WIX_DOWNGRADE_DETECTED;WIX_UPGRADE_DETECTED
Property(C): MsiHiddenProperties = 
AddMachine

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

On 20/12/2018 13:52, tincanteksup wrote:



On 20/12/2018 13:46, tincanteksup wrote:

Hi,

On 19/12/2018 21:55, Simon Rozman wrote:

Hi,



Remember: Test it to fail!

Any feedback kindly appreciated.



I just tested this on a "fresh" Win7 VM and it failed.

By "fresh" I mean this:

   The Win7 VM is from:
   https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

   Credit the find to:
   https://easylinuxtipsproject.blogspot.com/p/virtualbox.html

   The VM i used is IE11-Win7 x86





This may be a false alarm because Windows has decided this VM needs
"some" updates .. I'll update after the reboot dance. *yawn*



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

On 20/12/2018 13:46, tincanteksup wrote:

Hi,

On 19/12/2018 21:55, Simon Rozman wrote:

Hi,



Remember: Test it to fail!

Any feedback kindly appreciated.



I just tested this on a "fresh" Win7 VM and it failed.

By "fresh" I mean this:

   The Win7 VM is from:
   https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

   Credit the find to:
   https://easylinuxtipsproject.blogspot.com/p/virtualbox.html

   The VM i used is IE11-Win7 x86


The error message reported is:
"There is a problem with this Windows Installer package.
A DLL required for this installer to complete could not be run.
Contact your support personnel or package vendor"
[OK]

Followed by
"The installer failed, your system has not been changed yadda .."

I notice the error message says "could not be run" not "not found"
Permissions ?
I logged in as local admin.
Openvpn 2.4.6 running from the GUI+interactive service at the time.



The %TEMP%/openvpn-install.log is:

=== Logging started: 20/12/2018  05:28:59 ===
Action 05:28:59: INSTALL.
Action start 05:28:59: INSTALL.
Action 05:28:59: SetDefaultUIFontVista.
Action start 05:28:59: SetDefaultUIFontVista.
Action ended 05:28:59: SetDefaultUIFontVista. Return value 1.
Action 05:28:59: SetDlgStrongFontVista.
Action start 05:28:59: SetDlgStrongFontVista.
Action ended 05:28:59: SetDlgStrongFontVista. Return value 1.
Action 05:28:59: SetDlgTitleFontVista.
Action start 05:28:59: SetDlgTitleFontVista.
Action ended 05:28:59: SetDlgTitleFontVista. Return value 1.
Action 05:28:59: PreparePage.
Action start 05:28:59: PreparePage.
Info 2898. For DefaultUIFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 20 pixels height.
Info 2898. For DlgTitleFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 25 pixels height.

Action 05:28:59: PreparePage. Dialog created
Action ended 05:28:59: PreparePage. Return value 1.
Action 05:28:59: FindRelatedProducts. Searching for related applications
Action start 05:28:59: FindRelatedProducts.
Action ended 05:28:59: FindRelatedProducts. Return value 1.
Action 05:28:59: FindTAPInterfaces. Searching for TAP interfaces
Action start 05:28:59: FindTAPInterfaces.
CustomAction FindTAPInterfaces returned actual error code 1154 (note 
this may not be 100% accurate if translation happened inside sandbox)



regards
richard



I should mention I tested the .exe installer.


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Help required] Testing MSI installations

[tincanteksup]

Hi,

On 19/12/2018 21:55, Simon Rozman wrote:

Hi,



Remember: Test it to fail!

Any feedback kindly appreciated.



I just tested this on a "fresh" Win7 VM and it failed.

By "fresh" I mean this:

  The Win7 VM is from:
  https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

  Credit the find to:
  https://easylinuxtipsproject.blogspot.com/p/virtualbox.html

  The VM i used is IE11-Win7 x86


The error message reported is:
"There is a problem with this Windows Installer package.
A DLL required for this installer to complete could not be run.
Contact your support personnel or package vendor"
[OK]

Followed by
"The installer failed, your system has not been changed yadda .."

I notice the error message says "could not be run" not "not found"
Permissions ?
I logged in as local admin.
Openvpn 2.4.6 running from the GUI+interactive service at the time.



The %TEMP%/openvpn-install.log is:

=== Logging started: 20/12/2018  05:28:59 ===
Action 05:28:59: INSTALL.
Action start 05:28:59: INSTALL.
Action 05:28:59: SetDefaultUIFontVista.
Action start 05:28:59: SetDefaultUIFontVista.
Action ended 05:28:59: SetDefaultUIFontVista. Return value 1.
Action 05:28:59: SetDlgStrongFontVista.
Action start 05:28:59: SetDlgStrongFontVista.
Action ended 05:28:59: SetDlgStrongFontVista. Return value 1.
Action 05:28:59: SetDlgTitleFontVista.
Action start 05:28:59: SetDlgTitleFontVista.
Action ended 05:28:59: SetDlgTitleFontVista. Return value 1.
Action 05:28:59: PreparePage.
Action start 05:28:59: PreparePage.
Info 2898. For DefaultUIFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 20 pixels height.
Info 2898. For DlgTitleFontVista textstyle, the system created a 'Segoe 
UI' font, in 1 character set, of 25 pixels height.

Action 05:28:59: PreparePage. Dialog created
Action ended 05:28:59: PreparePage. Return value 1.
Action 05:28:59: FindRelatedProducts. Searching for related applications
Action start 05:28:59: FindRelatedProducts.
Action ended 05:28:59: FindRelatedProducts. Return value 1.
Action 05:28:59: FindTAPInterfaces. Searching for TAP interfaces
Action start 05:28:59: FindTAPInterfaces.
CustomAction FindTAPInterfaces returned actual error code 1154 (note 
this may not be 100% accurate if translation happened inside sandbox)



regards
richard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] tls-crypt-v2: fix client reconnect bug

[tincanteksup]

Tested this with Ubuntu client, patched applied &
Arch server, current master and it worked correctly.

Client did not crash when trying to "reconnect" to a server
when the server had been changed from TLS Crypt V2 to V1.

When the server was changed back to V2 the client connected
successfully.  The client ran the same instance throughout.

(Would test on Windows but can't since my old rig died)

Tested-by: Richard Bonhomme 


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Correct error message for --tls-crypt-v2-genkey client

[tincanteksup]

Correct error message for --tls-crypt-v2-genkey client

Signed-off-by: Richard Bonhomme 
---
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 882337b2..39e8ca5f 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1087,7 +1087,7 @@ do_genkey(const struct options *options)
 {
 if (!options->tls_crypt_v2_file)
 {
-msg(M_USAGE, "--tls-crypt-v2-gen-client-key requires a 
server key to be set via --tls-crypt-v2");
+msg(M_USAGE, "--tls-crypt-v2-genkey requires a server 
key to be set via --tls-crypt-v2 to create a client key");

 }


tls_crypt_v2_write_client_key_file(options->tls_crypt_v2_genkey_file,
--
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel