Re: [Openvpn-devel] [PATCH 09/11] Implement deferred auth for scripts

2021-01-21 Thread David Sommerseth

On 30/09/2020 15:13, Arne Schwabe wrote:

Signed-off-by: Arne Schwabe 
---
  Changes.rst |  9 +
  doc/man-sections/script-options.rst | 14 +++-
  src/openvpn/ssl_verify.c| 56 -
  3 files changed, 70 insertions(+), 9 deletions(-)



Only glared at the code here too.  In addition to prior merge conflicts, 
commit bbcada8abb410 seems to add even more confusion when applying this 
patch.



diff --git a/Changes.rst b/Changes.rst
index f67e1d76..7e60eb64 100644
--- a/Changes.rst
+++ b/Changes.rst


Ignoring merge conflicts here though.  Not important in this round.


diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index fc3a1116..5e15fa32 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1189,14 +1189,14 @@ tls_authenticate_key(struct tls_multi *multi, const 
unsigned int mda_key_id, con
  /*
   * Verify the user name and password using a script
   */
-static bool
+static int
  verify_user_pass_script(struct tls_session *session, struct tls_multi *multi,
  const struct user_pass *up)
  {
  struct gc_arena gc = gc_new();
  struct argv argv = argv_new();
  const char *tmp_file = "";
-bool ret = OPENVPN_PLUGIN_FUNC_ERROR;
+int retval = OPENVPN_PLUGIN_FUNC_ERROR;


Good fixing this mistake from previous round, but incorrect indenting.

  
  /* Is username defined? */

  if ((session->opt->ssl_flags & SSLF_AUTH_USER_PASS_OPTIONAL) || 
strlen(up->username))
@@ -1247,10 +1247,45 @@ verify_user_pass_script(struct tls_session *session, 
struct tls_multi *multi,
  argv_parse_cmd(, session->opt->auth_user_pass_verify_script);
  argv_printf_cat(, "%s", tmp_file);
  
+/* Add files needed for deferred auth */

+key_state_gen_auth_control_files(>key[KS_PRIMARY],
+ session->opt);
+
  /* call command */
-ret = openvpn_run_script(, session->opt->es, 0,
- "--auth-user-pass-verify");
+int script_ret = openvpn_run_script(, session->opt->es, 
S_EXITCODE,
+"--auth-user-pass-verify");


Perhaps move the retval declaration down here, as we're touching it 
anyhow?  This switch() is the first place we use it, unless I'm 
overlooking something.



+switch (script_ret)
+{
+   case 0:
+   retval = OPENVPN_PLUGIN_FUNC_SUCCESS;
+   break;
+   case 2:
+   retval = OPENVPN_PLUGIN_FUNC_DEFERRED;
+   break;
+   default:
+   retval = OPENVPN_PLUGIN_FUNC_ERROR;
+   break;
+   }

[...snip...]
  
  /*

@@ -1406,7 +1441,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
   struct tls_session *session)
  {
  int s1 = OPENVPN_PLUGIN_FUNC_SUCCESS;
-bool s2 = true;
+int s2 = OPENVPN_PLUGIN_FUNC_SUCCESS;


Indenting issues?

[...snip...]


@@ -1499,7 +1534,11 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  #ifdef PLUGIN_DEF_AUTH
   || s1 == OPENVPN_PLUGIN_FUNC_DEFERRED
  #endif
- ) && s2
+ ) &&
+((s2 == OPENVPN_PLUGIN_FUNC_SUCCESS)
+#ifdef ENABLE_DEF_AUTH
+ || s2 ==  OPENVPN_PLUGIN_FUNC_DEFERRED)
+#endif
  #ifdef MANAGEMENT_DEF_AUTH
  && man_def_auth != KMDA_ERROR
  #endif


Yikes!  This if() statement is unreadable.  Since you are doing changes 
here, could we improve this whole logic.  Perhaps using a helper macro 
like this (incorrect code-style, for e-mail readability)


 #define PLUGIN_AUTH_RESULT_PASS(s) \
  (OPENVPN_PLUGIN_FUNC_SUCCESS == s\
   || OPENVPN_PLUGIN_FUNC_DEFERRED == s)

 [...]
 if (PLUGIN_AUTH_RESULT_PASS(s1)
 && PLUGIN_AUTH_RESULT_PASS(s2)
 && tls_lock_username(multi, up->username))
 {
#ifdef ENABLE_MANGEMENT
if (KMDA_ERROR == man_def_auth)
{
/* ... error handling ... */
goto error;
}
if (KMDA_UNDEF == man_def_auth)
{
ks->authenticated = KS_AUTH_DEFERRED;
}
#endif  // ENABLE_MANAGEMENT

/* ... rest of the if block content ... */

return;  // Success
  }

error:
 /* ... existing error handling from if-else block... */


This is just a quick draft skeleton.  Right now the code is pretty 
messy, and we should improve the code quality on such critical code 
paths such as user authentication.




--
kind regards,

David Sommerseth
OpenVPN Inc



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


Re: [Openvpn-devel] [PATCH 08/11] Allow pending auth to be send from a auth plugin

2021-01-21 Thread David Sommerseth

On 30/09/2020 15:13, Arne Schwabe wrote:

Signed-off-by: Arne Schwabe 
---
  doc/man-sections/generic-options.rst |   3 +-
  include/openvpn-plugin.h.in  |   8 ++
  src/openvpn/ssl.c|   2 +-
  src/openvpn/ssl_common.h |   1 +
  src/openvpn/ssl_verify.c | 165 ---
  src/openvpn/ssl_verify.h |   2 +-
  6 files changed, 165 insertions(+), 16 deletions(-)



So far just glared at the code, but the change below needs to be fixed 
first.  This patchset has also aged so much it does no longer apply on 
top of latest git master.



[...snip...]

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index e7e62afa..fc3a1116 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c[...snip...]
@@ -1067,7 +1196,7 @@ verify_user_pass_script(struct tls_session *session, 
struct tls_multi *multi,
  struct gc_arena gc = gc_new();
  struct argv argv = argv_new();
  const char *tmp_file = "";
-bool ret = false;
+bool ret = OPENVPN_PLUGIN_FUNC_ERROR;


This is wrong.  OPENVPN_PLUGIN_FUNC_ERROR is 1, which means "true".  I 
see this is being corrected again in the next patch; but lets make it 
correct from the beginning to avoid making a potential bisect in the 
future more confusing than needed.



The rest of the code looks reasonable.  I've not tested it yet, as there 
are some merge conflicts now.  Since the surrounding code has changed a 
bit since this patch series , I consider it a bit risky to conclude on 
testing this on a older code base without many of the fixes in between 
in place.


Most of the merge conflicts is probably related to commit 99d217b20064 
(removing --disable-def-auth), but there are other AUTH related changes 
as well.  This needs to be carefully tested with all these auth changes 
in place too.



--
kind regards,

David Sommerseth
OpenVPN Inc



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


Re: [Openvpn-devel] [PATCH 10/11] Implement --client-crresponse script options and plugin interface

2021-01-21 Thread David Sommerseth

On 30/09/2020 15:13, Arne Schwabe wrote:

This is allows scripts and pluginsto parse/react to a
CR_RESPONSE message

Signed-off-by: Arne Schwabe 
---
  Changes.rst |  7 
  doc/man-sections/script-options.rst | 28 -
  include/openvpn-plugin.h.in |  7 +++-
  src/openvpn/init.c  |  1 +
  src/openvpn/options.c   | 15 +++
  src/openvpn/options.h   |  1 +
  src/openvpn/push.c  |  4 ++
  src/openvpn/ssl_common.h|  1 +
  src/openvpn/ssl_verify.c| 63 +
  src/openvpn/ssl_verify.h| 23 +++
  10 files changed, 147 insertions(+), 3 deletions(-)



Only glared at the code here too.

[...snip...]


diff --git a/doc/man-sections/script-options.rst 
b/doc/man-sections/script-options.rst
index e0cc10c2..66bf3662 100644
--- a/doc/man-sections/script-options.rst
+++ b/doc/man-sections/script-options.rst

[...snip...]
@@ -123,6 +128,25 @@ SCRIPT HOOKS
   For a sample script that performs PAM authentication, see
   :code:`sample-scripts/auth-pam.pl` in the OpenVPN source distribution.

+--client-crresponse
+Executed when the client sends a text based challenge response.
+
+Valid syntax:
+::
+
+client-crresponse cmd method
+

[...snip...]


diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 3df803db..703927da 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c

[...snip...]

@@ -7070,6 +7075,16 @@ add_option(struct options *options,
  set_user_script(options, >client_connect_script,
  p[1], "client-connect", true);
  }
+else if (streq(p[0], "client-crresponse") && p[1])
+{
+VERIFY_PERMISSION(OPT_P_SCRIPT);
+if (!no_more_than_n_args(msglevel, p, 2, NM_QUOTE_HINT))
+{
+goto err;
+}
+set_user_script(options, >client_crresponse_script,
+p[1], "client-crresponse", true);
+}


Either the doc is wrong, or the option parser is lacking parsing of 
"method".


[...snip...]


diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index 877e9396..a63a1967 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -440,6 +440,7 @@ struct options
  const char *client_connect_script;
  const char *client_disconnect_script;
  const char *learn_address_script;
+const char *client_crresponse_script;


Indentation.

[...snip...]

diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 58e20baa..e5c92e17 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -227,6 +227,10 @@ receive_cr_response(struct context *c, const struct buffer 
*buffer)
  
  
  management_notify_client_cr_response(key_id, mda, es, m);

+#endif
+#if ENABLE_PLUGIN
+verify_crresponse_plugin(c->c2.tls_multi, m);
+verify_crresponse_script(c->c2.tls_multi, m);


Any reason the script feature is insdie the ENABLE_PLUGIN fence?

[...snip...]

diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index 98afc88c..87877c88 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -314,6 +314,7 @@ struct tls_options
  
  /* used for username/password authentication */

  const char *auth_user_pass_verify_script;
+const char *client_crresponse_script;


Indentation.

I've not looked that carefully at the rest of the code, as I would like 
to test those code paths when completing the review.  It looks 
reasonable though at a first glance, but might be I stumble across 
something during testing.



--
kind regards,

David Sommerseth
OpenVPN Inc



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


[Openvpn-devel] OpenVPN 3 Linux client - v13 beta released

2020-12-10 Thread David Sommerseth

Hi,

The OpenVPN 3 Linux v13 beta is now ready.

The highlights of this release includes:

* Feature: IPv6 and TCP protocol support in
  OpenVPN Data Channel Off-load (DCO) kernel module
  
  -
  ## WARNING ## TECH-PREVIEW FEATURE ##
  -

  The DCO feature is currently a tech-preview feature.  It is not
  targeted for production usage in its current shape.  As this is
  still under heavy development, we currently only support the latest
  Fedora releases (Fedora 32 and newer), Ubuntu 20.04 and Ubuntu 20.10.
  This currently requires Linux kernel 5.4 and newer.

  This release includes an updated ovpn-dco implementation which adds both
  TCP and IPv6 protocols to be used for the transport between client and server.

  If you are testing the DCO feature, also be sure you use the updated
  kmod-ovpn-dco package or build the ovpn-dco module based on git
  commit 8f04ed862539f0.

  Please see the information at the end how to enable the DCO feature.

* Bugfix: Misleading argument count when options are missing arguments
  If an option requring a certain minimum amount of arguments was missing one
  or more arguments, for example using just --keepalive 30, the error would be:

 ERR_PROFILE_OPTION: option_error: option 'keepalive' must have at least 3 
arguments

  This is incorrect.  The correct number should be "2 arguments".  This has
  been fixed in the OpenVPN 3 Core library which generated this error string.

* Bugfix: Multi-factor authentication broke with v12_beta
  With the v12_beta release, web based authentication was added.  This also
  added signalling support for the CR_TEXT authentication method which was not
  intended to be added.  This resulted in many multi-factor authentication
  configurations to fail, in particular those connecting to OpenVPN Access
  Server.  This has been corrected and openvpn3-linux does no longer signal
  CR_TEXT authentication method support.


Supported Linux distributions:

  - Debian 9, 10 (x86_64)
  - CentOS 7 and 8 (x86_64, aarch64)
  - Fedora 32, 33 and Rawhide (x86_64, aarch64, s390x)
  - Red Hat Enterprise Linux 7 and 8 (x86_64, aarch64)
  - Ubuntu 16.04, 18.04, 19.10 and 20.04 (x86_64)
  - Tech-preview: Ubuntu 20.10 [grovy] (x86_64)

  Ubuntu 20.10 is expected to be fully supported as of the next release.

Instructions how to install OpenVPN 3 Linux can be found here:
<https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux>


-- 
kind regards,

David Sommerseth
OpenVPN Inc


 Tech preview: Enable OpenVPN Data Channel Offload --

  -
  ## WARNING ## TECH-PREVIEW FEATURE ##
  -

  The ovpn-dco kernel module is under heavy development.
  This means that the API used between the kernel space
  and OpenVPN user space processes may change.  Therefore
  the kernel module version must be the same which
  OpenVPN 3 Linux has been compiled against.  Once
  the API is has become stable, this restriction will no
  longer be needed.

  Currently the DCO feature is only available for testing on Fedora 32,
  Fedora 33, Fedora Rawhide, Ubuntu 20.04 and Ubuntu 20.10.

  On Fedora, with the openvpn3 Copr repository enabled:

  # yum install kmod-ovpn-dco

  On Ubuntu, with the openvpn3 apt repository configured:

  # apt install kmod-ovpn-dco

  With the kernel module installed, the configuration file must be
  be imported:

  $ openvpn3 config-import --config CONFIG_FILENAME \
 --name CFGNAME \
 --persistent

  Then the imported configuration profile must get the DCO feature
  enabled:

  $ openvpn3 config-manage --show --config CFGNAME --dco true

  To preserve this setting through reboots, --persistent was added
  when importing the configuration file via 'openvpn3 config-import'.

  Now everything is ready and a VPN session can be started:

  $ openvpn3 session-start --config CFGNAME

  In the log data generated by OpenVPN 3 Linux, you should see
  an UDPv4-DCO, UDPv6-DCO, TCPv4-DCO or TCPv6-DCO reference similar
  to this line:

  [...] CONNECTED servername:port (x.x.x.x) via /UDPv4-DCO [...]


 Source tarballs 
* OpenVPN 3 Linux v11 beta

  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-13_beta.tar.xz>
  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-13_beta.tar.xz.asc>

 SHA256 Checksums ---

3eb1ea7166f21525c23ff37d971ac71916e4b476df7ddd6c50dc3684e864e738  
openvpn3-linux-13_beta.tar.xz
fa69dedbeaf754eac298e55f7b3b490959cc34b183ee777cd8651533b403241e  
openvpn3-linux-13_beta.tar.xz.asc

 git references -

git repositories:
<https://gitlab.com/openvpn/openvpn3-linux&g

[Openvpn-devel] OpenVPN 3 Linux client - v12 beta released

2020-11-30 Thread David Sommerseth
Hi,

The OpenVPN 3 Linux v12 beta is now ready.

The highlights of this release includes:

* Feature: Web-based authentication
  For servers allowing web based authentication, OpenVPN 3 Linux
  will now pick up this authentication type request and handle
  it.  If the openvpn2 or openvpn3 user-front-end applications
  are able to open a browser window with the given URL, it will
  do so.  If not, it will present the URL needed for the further
  authentication process.  In addition, any VPN sessions awaiting
  web based authentication is also presented via the
  `openvpn3 sessions-list` command together with the authentication
  URL.

* Bugfix: OpenVPN 3 Linux configuration manager could crash
  If the openvpn3-service-configmgr program was started with the
  --state-dir argument pointing at an unreadable or non-existing
  directory, it would crash.  This has been fixed to provide a
  better error message and exit gracefully.  Front-end
  applications will still report that the net.openvpn.v3.configruations
  service is unavailable, this fix is not visible for end-users - just
  improving the behaviour of openvpn3-service-configmgr.

* Bugfix: Properly handle restart of paused sessions
  VPN sessions being paused (like via
  `openvpn3 session-manage --pause`) would not recover properly if
  it was recovered by using the `restart` method instead of `resume`.
  When trying to pause the session again, it would not do so as the
  session was considered paused already.  Resuming a VPN session
  via both the `resume` and the `restart` method are considered
  appropriate and is now handled correctly.

* Bugfix: openvpn2 running in the foreground could exit with an error
  If the openvpn2 front-end was used to start a VPN session and it
  was running in the foreground (no use of --daemon), it would present
  and error message when closing the session *if* the VPN session
  was closed via another channel (such as `openvpn3 session-manage`).
  This has been fixed and it will now exit properly if this situation
  appears, without any additional error messages.

* Bugfix: openvpn2 would misinterpret --keepalive
  The OpenVPN option parser in the Python 3 openvpn module would not
  properly parse a few arguments which used multiple arguments - such
  as --keepalive.  This has been fixed.

* Enhancements: openvpn2 now understands --tls-version-{min,max}
  In prior releases, the Python 3 openvpn module did not understand
  the --tls-version-min and --tls-version-max options.  This has been
  resolved and these options are forwarded properly to the
  configuration manager.


-- 
kind regards,

David Sommerseth
OpenVPN Inc


[0] <https://gitlab.com/openvpn/openvpn3-linux>
<https://github.com/OpenVPN/openvpn3-linux>

 Source tarballs 
* OpenVPN 3 Linux v11 beta

  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-12_beta.tar.xz>
  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-12_beta.tar.xz.asc>

 SHA256 Checksums ---

899a4211e883682f5d1fb50dad4425c743283c117b068d3af3d1189f65c2e0ce  
openvpn3-linux-12_beta.tar.xz
7b592b652daa7f4119019d9764005a019765bc4a2ab5de65cf5faf982d0617f4  
openvpn3-linux-12_beta.tar.xz.asc

 git references -

git tag: v12_beta
git commit: be65151677fa854080a563a52d1a96b38ab29544

 Changes from v11 to v12 --------

David Sommerseth (11):
  client: Properly reset the paused flag on session restart
  python: Improve parsing of options with multiple arguments
  python: Extend argument parser with support for --tls-version-min/max
  dbus: Add web-auth constant to ClientAttentionGroup
  client: Enable web-auth support and URL extraction
  python: Add support for handling web-auth in openvpn2
  python: Resolve error in openvpn2 on disconnect with pre-closed sessions
  common: Implement function for opening up URIs on the host
  ovpn3cli: Add support web auth via openvpn3
  ovpn3cli: Improve 'sessions-list' for sessions awaiting web auth
  configmgr: Abort properly if --state-dir processing fails

-




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN 3 Linux client - v11 beta released

2020-11-03 Thread David Sommerseth
On 02/11/2020 19:22, Gert Doering wrote:
> Hi,
> 
> On Mon, Nov 02, 2020 at 03:00:58PM +0100, David Sommerseth wrote:
>>>   Then the imported configuration profile must get the DCO feature
>>>   enabled:
>>>
>>>   $ openvpn3 config-manage --show --name CFGNAME --dco true
>>
>> So I managed to introduce a typo here, this config-manage operation
>> should use --config instead of --name:
>>
>> $ openvpn3 config-manage --show --name CFGNAME --dco true
> 
> Yeah, right.  The difference is quite obvious :-)

Gah!  If this fails, I'm giving completely up! :)

 $ openvpn3 config-manage --show --config CFGNAME --dco true

Hopefully, I didn't mess up again :-D


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN 3 Linux client - v11 beta released

2020-11-02 Thread David Sommerseth
On 02/11/2020 14:30, David Sommerseth wrote:
>   With the kernel module installed, the configuration file must be
>   be imported:
> 
>   $ openvpn3 config-import --config CONFIG_FILENAME \
>  --name CFGNAME \
>  --persistent
> 
>   Then the imported configuration profile must get the DCO feature
>   enabled:
> 
>   $ openvpn3 config-manage --show --name CFGNAME --dco true

So I managed to introduce a typo here, this config-manage operation
should use --config instead of --name:

$ openvpn3 config-manage --show --name CFGNAME --dco true

Thanks to Lev for spotting this.  It is correct in the wiki page and
Fedora Copr repository page.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] OpenVPN 3 Linux client - v11 beta released

2020-11-02 Thread David Sommerseth
ctedly.  This was an error related to the
  argument alias processing and has been fixed to avoid this issue.

* Enhancements: The openvpn2 bash-completion support is extended
  In prior versions, the openvpn2 command did not provide any shell
  completion help to the --config option.  This has been resolved.

* OpenVPN Access Server configuration import improvements
  The 'openvpn3-as' utility now signals to the Access Server the
  downloaded configuration profile is intended to be imported into
  a local storage.

-- 
kind regards,

David Sommerseth
OpenVPN Inc


[0] <https://gitlab.com/openvpn/openvpn3-linux>
<https://github.com/OpenVPN/openvpn3-linux>

 Source tarballs 
* OpenVPN 3 Linux v11 beta

  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-11_beta.tar.xz>
  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-11_beta.tar.xz.asc>

 SHA256 Checksums ---

1207fa09f32d887cbbe8abc13ea589d0aa67126b70f6e9d1508006d67cedf12d  
openvpn3-linux-11_beta.tar.xz
5af11fd30a8a73f8151eb062a4bb85bbd0e416d9816b835a585b892b3ccc53c1  
openvpn3-linux-11_beta.tar.xz.asc

 git references -

git tag: v11_beta
git commit: 087393e775fb5b58b28147819ffc55a30b1d29ff

 Changes from v10 to v11 

Arne Schwabe (1):
  Indicate that the openvpn-as imports a config

David Sommerseth (13):
  configmgr: Better handling of incorrect configuration profiles
  docs: Fix incorrect attribute header - user-auth:password
  core: Update client and aws service to use new Core process init
  common/cmdargparser: Fix lacking alias initialization
  netcfg: Rename the tun device properly on non-DCO builds
  configmgr: Add DCO device naming hack
  Update to latest OpenVPN 3 Core library
  dco: Update ovpn-dco submodule to get the latest header files
  docs: Update README with related to the new DCO feature
  docs/man: Add missing options in openvpn3-config-manage man page
  build: Fix out-of-tree builds when --enable-bash-completion is enabled
  shell: Improve openvpn2 --config bash completion
  core/ovpn-dco: Sync up DCO API changes

Lev Stipakov (16):
  openvpn3-service-client: add debug option to specify client path
  build: Define OPENVPN_USE_SITNL in configure.ac
  core: Update to latest openvpn3 Core library
  common: adapt to Core library changes in core JSON extensions
  tests: add missing include in netcfg cli
  Add ovpn-dco submodule
  build: Add ovpn-dco build options
  configmgr: Add support for "dco" config property
  client/netcfg: Initial support for ovpn-dco
  netcfg: Implement crypto key passing for ovpn-dco
  netcfg: Implement ovpn-dco tun establish()
  client/netcfg: Handle ovpn-dco device creation error
  netcfg: Implement ovpn-dco crypto key swapping
  netcfg: Implement setting peer properties for ovpn-dco
  Jenkinsfile: add ovpn-dco support
  ovpn-dco: explicitly subscribe for genl packets

-




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] build: Fix missing install of man page in certain environments

2020-10-29 Thread David Sommerseth
It turns out the logic for dist_man_MANS was incorrectly put inside the
HAVE_PYDOCUTILS block.  This results in the man page being installed
only if python-docutils is installed and available.

The solution is simple, move the dist_man_MANS part outside the
python-docutils block.  The openvpn.8 file is prebuilt in source
tarballs and will thus be available.

Reported-By: Philip Brown 
Tested-By: Philip Brown 
Signed-off-by: David Sommerseth 
---

Note: This may have a negative impact on hosts running 'make install'
(which also happens via 'make distcheck') when using the git tree or
otherwise not having a pre-built doc/openvpn.8 file available.
---
 doc/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 340dd553..df2f54a3 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -67,10 +67,11 @@ dist_html_DATA = openvpn.8.html
 CLEANFILES = \
 openvpn.8 openvpn.8.html
 
+endif
+
 if WIN32
 else
 dist_man_MANS = openvpn.8
 endif
-endif
 
 dist-hook : openvpn.8 openvpn.8.html
-- 
2.26.0



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


Re: [Openvpn-devel] [PATCH] Avoid passing NULL to argv_printf_cat() in temp_file error case.

2020-10-15 Thread David Sommerseth
On 13/10/2020 22:47, Gert Doering wrote:
> To pass username + password to verify_user_pass_script(), OpenVPN
> can either put both into environment, or create a temp file, and
> pass that file name to the "user-pass-verify" script.  The file
> name is initialized as "", so if no file is desired, it's well
> defined - but if the file can not be created, the pointer is NULL
> afterwards.
> 
> Change the sequence of events, setting up the argv before the
> "if (file)" conditional, and add the file name only inside that
> clause, if creating the temp file succeeded.
> 
> commit a4eeef17b2 did not create the problem, but modified the
> code enough so that the static analyzer in gcc 9.2.0 *now* noticed
> and issued a warning.
> 
>  ssl_verify.c:1132:5: warning: '%s' directive argument is null
>   1132 | argv_printf_cat(, "%s", tmp_file);
> 
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/ssl_verify.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
I've glared at the code and related code paths, plus (only) compile
tested this change.  And it looks reasonable.

There are also at least two other ways to fix this issue, where this
approach is a bit more intrusive.  One would be to add an "if
(tmp_file)" wrapping around the argv_printf_cat() call, another would be
to set tmp_file to an empty string in the else block with the error
message at line 1122.

But after all, the chosen approach gives a reasonable code execution
flow and I consider it cleaner.  I don't see any reasons why it would be
beneficial to format the command line only after creating the temp file.

So ...

Acked-By: David Sommerseth 

-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH applied] Re: Support X509 field list to be username

2020-10-08 Thread David Sommerseth
On 05/10/2020 12:36, Gert Doering wrote:
> After quite some deliberation I've decided that this is "new feature"
> and "too late for 2.5", so not applied to release/2.5 - it was not 
> an easy decision, as this could indeed be a very useful feature for
> server operators running "distribution provided" binaries, which 
> usually is "2.5".  OTOH, at some point we want to get 2.5.0 *out*,
> and if we keep adding features, we need more RCs, and then we'll
> never get there.  OTOH, again, this is a fairly isolated change - so
> if enough users yell at me that THEY MUST HAVE THIS, we could put
> it in 2.5.1 or 2.5.2 ("small and isolated new features can be done
> in small-numbered subreleases").

I agree, this is not 2.5 stuff.  If it is not a new feature, it is at
least a feature extension - not a bug, security or stability fix which
is what we should focus on now in the 2.5_rc phase.

> Also, we do want 2.6.0 to happen "soonish" this time, like "in one
> year, not in four years".  Let's see...

Yeah, lets get 2.6 out sooner - with lesser new features on the plate,
and rather save some goodies for post 2.6 releases - to help the overall
development/release cycles go faster.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Add --up-pre with the same functionality as --down-pre

2020-10-01 Thread David Sommerseth
On 01/10/2020 18:36, Simon Matter wrote:
>> From what I recall from the last review years ago, the behavior was also
>> not
>> well defined in restart scenarios (--up-restart) - where the script might
>> be
>> run with different privileges, the --chroot might also change things.
>> Which
>> makes this patch very fragile for users.
>>
>> All of these issues are avoided with the --management and
>> --management-hold.
>
> How do all these issues affect --up-pre but not the existing --down-pre?
> Why was --down-pre never removed over all the years if it makes things so
> fragile for users?

Several reasons.  We don't want to break backwards compatibility.  So removing
an option which has existed since 2004 is not acceptable unless it is really
security sensitive (see the discussion on this list regarding another patch
where I suggested, to remove --udp-mtu - which was also rejected).

Secondly, --down-pre has a deterministic behavior.  If you use --chroot and/or
--user/--group, the --down script is run under the same conditions whether you
use --up-restart or not.

And, since we still have not heard any convincing arguments why --management
with --management-hold cannot work for your use case, nothing has changed
since the Trac discussions years ago.  We don't want to easily add a feature
only 3 people have requested during a time span of 7 years, where one of them
already confirmed the management approach worked [1].

<https://community.openvpn.net/openvpn/ticket/284#comment:17>

Adding new options and features means we need to commit to support them for
quite a long time; regardless of the patch complexity.  So a new feature or
option really needs to have a reasonable amount of users and solves a problem
which cannot be solved through other reasonable ways.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Add --up-pre with the same functionality as --down-pre

2020-10-01 Thread David Sommerseth
On 01/10/2020 17:03, Simon Matter wrote:
> I really can't understand why this small patch was refused for years and I
> still feel nobody ever really looked at it.

Perhaps this also an indication of the corner case this patch is covering?

This patch started 7 years ago.  There has been 2 other users being supportive
in the Trac ticket, where at least one of them do have another functional
alternative (--management with --management-hold).

From what I recall from the last review years ago, the behavior was also not
well defined in restart scenarios (--up-restart) - where the script might be
run with different privileges, the --chroot might also change things.  Which
makes this patch very fragile for users.

All of these issues are avoided with the --management and --management-hold.

And if you still require more flexibility when starting client configurations,
you should rather consider OpenVPN 3 Linux - which can be much more fine
grained controlled via an API.  OpenVPN 3 Linux can also be used by
unprivileged users out-of-the-box, resulting in better security for what is
being executed and when it is being executed.

There are several examples in Python, but any language with D-Bus support will
work:
<https://github.com/OpenVPN/openvpn3-linux/tree/master/src/tests/python>
<https://github.com/OpenVPN/openvpn3-linux/tree/master/src/python>


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Add --up-pre with the same functionality as --down-pre

2020-10-01 Thread David Sommerseth
On 01/10/2020 14:10, Arne Schwabe wrote:
> Am 22.11.17 um 17:58 schrieb Simon Matter:
>> Hi,
>>
>> In our situation we have the requirement to run scripts before tun/tap is
>> opened, not after. While this could be hacked into the init script, the
>> proper way seems to add it to openvpn as --up-pre option. That's
>> independent from any init scripts / systemd service file and works the
>> same way as --down-pre, only for the up status.
>>
>> My initial feature wish, posted 5 years ago, was turned down as won't fix:
>> https://community.openvpn.net/openvpn/ticket/284
>>
>> But there are people who wish it and they have good reasons to wish it.
>> Just yesterday someone asked again:
>> https://community.openvpn.net/openvpn/ticket/284#comment:10
>>
>> Without going into much details
> 
> This patch currently misses a commit message anyway but a good commit
> should explain why this change is a good one.
> 
>> just one thing why --up + --up-pre is
>> better than hacking around outside of openvpn: the command called with
>> --up also gets additional run time information from openvpn by parameters
>> and environmental variables. You don't get all those information when
>> calling anything from outside of openvpn before openvpn actually starts.
>>
>> If you feel there are good reasons to still refuse this patch, please let
>> me know.
> 
> I am just looking at this patch since it is still in the review queue.
> 
> - Missing documentation.
> - pre-up flag is wrong in terms of scripts. If we add this, it needs to
> be a different script because otherwise you will break use cases that
> also need the --up script.
> 
> Also having down and down-pre but then only not also up/up-pre but a up
> with flag breaks the symmetry and is confusing.
This patch has been lingering here on the list since 2017.  And I still
haven't changed my opinion about it, as I lack to see a proper use-case (or
"user story", which is the appropriate term for the 2020s).

My stance is pretty well covered in the ticket [1], and the only potential use
case which was provided does have, in my opinion, a better alternative by
using --management and --management-hold.

<https://community.openvpn.net/openvpn/ticket/284#comment:15>

So consider this a NAK from my side.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Improve documentation of --username-as-common-name

2020-09-28 Thread David Sommerseth
On 27/09/2020 20:46, selva.n...@gmail.com wrote:
> From: Selva Nair 
> 
> Trac #1079
> 
> Signed-off-by: Selva Nair 
> ---
>  doc/man-sections/server-options.rst | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/man-sections/server-options.rst 
> b/doc/man-sections/server-options.rst
> index c0b22a5..4b649b1 100644
> --- a/doc/man-sections/server-options.rst
> +++ b/doc/man-sections/server-options.rst
> @@ -668,9 +668,15 @@ fast hardware. SSL/TLS authentication must be used in 
> this mode.
>``--max-routes-per-client``
>  
>  --username-as-common-name
> -  For ``--auth-user-pass-verify`` authentication, use the authenticated
> -  username as the common name, rather than the common name from the client
> -  cert.
> +  Use the authenticated username as the common-name, rather than the
> +  common-name from the client certificate. Requires that some form of
> +  auth-user-pass verification is in effect. As the replacement happens after
> +  auth-user-pass verification, the verification script or plugin will still

The two occurrences of "auth-user-pass" should be: ``--auth-user-pass`` (with
"double-backwards-single-quotes" in both ends)

> +  receive the common-name from the certificate.
> +
> +  The common_name environment variable passed to scripts and plugins invoked
> +  after authentication (e.g, client-connect script) and file names parsed in
> +  client-config directory will match the username.

I have not verified the behavior described, but I trust Selva's understanding
and testing.  The extension of this part is valuable and makes both the man
entry and behavior clearer.

The fix I've touched above can be handled at commit-time, unless Gert objects.

Acked-By: David Sommerseth 

-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Added environment variable for IPv6 route metric.

2020-09-23 Thread David Sommerseth
On 23/09/2020 14:58, Jan Seeger wrote:
> --- a/doc/man-sections/script-options.rst
> +++ b/doc/man-sections/script-options.rst
> @@ -709,10 +709,10 @@ instances.
>  A set of variables which define each IPv6 route to be added, and are
>  set prior to **--up** script execution.
>  
> -``parm`` will be one of :code:`network` or :code:`gateway`
> +``parm`` will be one of :code:`network`, :code:`gateway`
>  (:code:`netmask` is contained as :code:`/nnn` in the
>  ``route_ipv6_network_{n}``, unlike IPv4 where it is passed in a
> -separate environment variable).
> +separate environment variable) or :code:`metric`.

I would suggest to rewrite this slightly, to make it clearer.  The () sentence
should be incorporated as a normal sentence.

So the (text/plain) result will be something like:

  param will be one of network, code or metric.  The netmask is contained
  as /nnn in the route_ipv6_network_{n}, unlike IPv4 where it is passed in
  a separate environment variable.

Or maybe even (why do we highlight IPv4 differences so much?):

  param will be one of network, code or metric.  The netmask is
  not provided and is preserved as /nnn in the IPv6 range in
  route_ipv6_network_{n}.

(These examples needs the proper :code:`value` and ``value`` highlighting,
removed here for clarity)


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v4] Add demo plugin that excercises "CLIENT_CONNECT" and "CLIENT_CONNECT_V2" paths

2020-09-17 Thread David Sommerseth
On 17/09/2020 18:19, Gert Doering wrote:
> This is a new "samples" plugin which does not do many useful things,
> besides
>  - show how a plugin is programmed
>  - how the various messages get dispatched
>  - how to pass back information from a client-connect/v2 plugin
>  - how to do async-cc plugins  [not yet implemented]
> 
> the operation of the plugin is controlled by UV_WANT_* environment variables
> controlled by the client ("--setenv UV_WANT_CC_FAIL 1 --push-peer-info"),
> to "fail CLIENT_CONNECT" or "use async-cc for CLIENT_CONNECT_V2" or
> "send 'disable' back from ...") - which is useful for automated testing
> of server success/defer/fail code paths for the CLIENT_CONNECT_* functions.
> 
> See samples/sample-plugins/client-connect/README for details how to do this.
> 
> v2:
>   - implement async / deferred operation both for CLIENT_CONNECT and
> CLIENT_CONNECT_V2 plugin calls
>   - implement returning openvpn-controlled (setenv) config snippets
> (so the client side can verify in automated testing that the plugin
> operated correctly, without hard-coding something in the plugin code)
> 
> v3:
>   - remove -Wno-unused-variable from Makefile
>   - remove unused "char ** argv" (commented out, but kept as reference)
> 
> v4:
>   - upgrade to use the build infra brought by commit 0b5141d8f946
>   - remove local Makefile
>   - include "config.h" to get what is needed to get rid of the strdup()
> warning
> ---
>  sample/sample-plugins/Makefile.plugins|   3 +-
>  sample/sample-plugins/README  |   6 +
>  sample/sample-plugins/client-connect/README   |  38 ++
>  .../client-connect/sample-client-connect.c| 612 ++
>  4 files changed, 658 insertions(+), 1 deletion(-)
>  create mode 100644 sample/sample-plugins/client-connect/README
>  create mode 100644 
> sample/sample-plugins/client-connect/sample-client-connect.c
> 

I've only glared at important code pieces, diffed against the v2 of this patch
and compiled it on RHEL-7 (gcc-4.8.5 and gcc-9.3.1/devtoolset-9).  Since
everything is as expected now (no compiler complaints, diff is good) and prior
review testing worked as expected ...

Acked-By: David Sommerseth 


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-09-16 Thread David Sommerseth
On 17/09/2020 00:05, Arne Schwabe wrote:
> This snippet in the configure.ac looks strange:
> 
>   if test -n "${WOLFSSL_DIR}"; then
>   wolfssldir="${WOLFSSL_DIR}"
>   else
>   wolfssldir="/usr/local/include/wolfssl"
>   fi
> 
> I am not sure hardcoding a /usr/local path is something we want/allow.
> The people better at autoconf might have a better idea on this.

I'll bite on this one.

You seem to install wolfssl.pc in an appropriate directory, so it should
really pull the default path using PKG_CHECK_MODULES instead.  Having
overrides. like we do with OpenSSL (with OPENSSL_LIBS and OPENSSL_CFLAGS), is
fine.

The main challenge with the pkg-config is that it must use the same directory
on the system as the rest of the development packages uses.  This is usually
not an issue for developers using a distro package of the library; these
packages install all these pkg-config files in the appropriate directory.  The
challenge is more for those compiling and installing unpackaged versions of
the library; which is where the WOLFSSL_LIBS and WOLFSSL_CFLAGS comes into play.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] build: Fix make distclean/distcheck

2020-09-16 Thread David Sommerseth
In commit 0b5141d8f94 the sample-plugins got partially migrated to
automake.  But since it was not fully integrated within the full
standard build, the sample/sample-plugins/Makefile was not removed
by 'make distclean', which annoys 'make distcheck'.

The simplest way is just to explicitly enlist this Makefile in the list
of files 'make distclean' should remove.

Signed-off-by: David Sommerseth 
---
 sample/Makefile.am | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sample/Makefile.am b/sample/Makefile.am
index 3be698e7..46d113ab 100644
--- a/sample/Makefile.am
+++ b/sample/Makefile.am
@@ -12,6 +12,9 @@
 MAINTAINERCLEANFILES = \
$(srcdir)/Makefile.in
 
+DISTCLEANFILES = \
+   $(builddir)/sample-plugins/Makefile
+
 EXTRA_DIST = \
sample-plugins \
sample-config-files \
-- 
2.26.0



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


Re: [Openvpn-devel] LD Errors / vpn_connect or vpn_init

2020-09-16 Thread David Sommerseth
On 16/09/2020 18:49, John A wrote:
> Hey y’all,
> 
> I am new to this list and have been on listservs/majordomos since themid-90s.
> I visit here today to ask and hopefullyreceivean answer.
> 
> I haveerrors of undefinedreferences such as:
> 
> /tmp/ccDkPqm5.ltrans7.ltrans.o: In function `vpn_init()':
> 
> :(.text+0x1051): undefined reference to
> `openvpn::ClientAPI::OpenVPNClient::OpenVPNClient()'
> 
> Isthere documentation somewhere that I can look over or an quick quip answer
> here of what obvious thing or stuff I am missing?

I would recommend you to have a look at the reference client implementation,
under test/ovpncli/cli.cpp.

But beware that the OpenVPN 3 Core library is designed to be a single
compilation unit (don't ask).  So you might need to do be careful how/where
you do the #include of the Core library, as well as being careful about how
you design your own compilation units.  In OpenVPN 3 linux, I do use multiple
compilation units, but needed to do some careful design around it.

> This in on CentOS 7 machine, x86_64, what more could I provide? Is there a
> slack group?

I've built both the cli reference client without any issues on CentOS 7, as
well as developing openvpn3-linux on RHEL-7 as the main development environment.

We're mostly on IRC, FreeNode in the #openvpn-devel room.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] sample-plugins: Partially autotoolize the sample-plugins build

2020-09-16 Thread David Sommerseth
[resent from proper address]

On 16/09/2020 15:48, Gert Doering wrote:
> Hi,
>
> On Tue, Sep 15, 2020 at 10:52:54PM +0200, David Sommerseth wrote:
>> ---
>> v2 - Process README files with correct instructions and details
>> v3 - Add missing -I$(top_srcdir)/include and explicitly state GNU Make
>>  requirement
>
> Unfortunately, we need a v4... stupid me...

Nah, we share the blame here ... I forgot about the builddir variant.  Which
is very well documented in the automake documentation.

> For in-tree builds, it is working:
>
> cc -c -o simple/simple.o -Wall -Wno-unused-parameter -Wno-unused-function -g
-O2 -std=c99 -I../.. -I../../include -fPIC simple/simple.c
> cc  -shared -fPIC -o simple/simple.so simple/simple.o
> rm simple/simple.o
>
> For out of tree builds, it is still failing:
>
> cc -c -o simple/simple.o -Wall -Wno-unused-parameter -Wno-unused-function -g
> -O2 -std=c99 -I../../../openvpn -I../../../openvpn/include -fPIC ../../..
> /openvpn/sample/sample-plugins/simple/simple.c
> ../../../openvpn/sample/sample-plugins/simple/simple.c:37:10: fatal error:
>   'openvpn-plugin.h' file not found
> #include "openvpn-plugin.h"
>  ^~
>
> because "openvpn-plugin.h" is not actually to be found in the source
> tree, but it's generated at compile time - so "-I../../include" will
> find it.
>
> The other -I should maybe also be "-I../.."?  What is it looking for
> in the $(top_builddir)?  The only .h file in $(top_builddir) is
> "config-msvc.h" - config.h is in "../.."
>

This is actually covered in the AM_CPPFLAGS docs here:
<https://www.gnu.org/software/automake/manual/html_node/Program-Variables.html>

I'll submit a v4 fixing this.


-- 
kind regards,

David Sommerseth
OpenVPN Inc





signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v4] sample-plugins: Partially autotoolize the sample-plugins build

2020-09-16 Thread David Sommerseth
The sample-plugins have their own set of build/winbuild scripts in each
of these plugin directories.  This does not give a good way to reuse
various macros the autoconf/automake/configure process enables; which
can contain important macros to make some code build without errors or
warnings.

Normally we would embrace the full autoconf/automake approach. But this
is sample code which we only want to build per request and the built
code should not be installed anywhere via 'make install'.  But since we
do use libtool other plug-ins being installed and automake gets kind of
cranky when it comes to define certain build targets not following the
expected use cases, we try to only embrace just enough of automake to
get our main goals achieved.

This changeset kicks out the build scripts and replaces them with a
single Makefile.plugins file, which defines the plugins we want to build
by default when running 'make from the sample-plugins directory.
Neither of these plugins are otherwise built by default.  No sample-plugins
are being installed.  But we have enough strings attached to automake
to grab the CFLAGS and LDFLAGS used by the rest of the code.  This also
makes it easy to use #include "config.h" in sample code, to also get
various macros defined by the ./configure run.

This patch does not touch the winbuild scripts, as it seems building
these sample-plugins on Windows requires a bit different compile and
linking steps than *nix systems in general.

Signed-off-by: David Sommerseth 

---
v2 - Process README files with correct instructions and details
v3 - Add missing -I$(top_srcdir)/include and explicitly state GNU Make
 requirement
v4 - Add missing $(top_builddir) references, preserve built .o files
---
 configure.ac  |  1 +
 sample/sample-plugins/Makefile.am | 35 ++
 sample/sample-plugins/Makefile.plugins| 36 ++
 sample/sample-plugins/README  | 37 +++
 sample/sample-plugins/defer/README| 16 
 sample/sample-plugins/defer/build | 15 
 .../keying-material-exporter-demo/build   | 15 
 sample/sample-plugins/log/build   | 15 
 sample/sample-plugins/simple/README   | 16 
 sample/sample-plugins/simple/build| 15 
 10 files changed, 109 insertions(+), 92 deletions(-)
 create mode 100644 sample/sample-plugins/Makefile.am
 create mode 100644 sample/sample-plugins/Makefile.plugins
 create mode 100644 sample/sample-plugins/README
 delete mode 100644 sample/sample-plugins/defer/README
 delete mode 100755 sample/sample-plugins/defer/build
 delete mode 100755 sample/sample-plugins/keying-material-exporter-demo/build
 delete mode 100755 sample/sample-plugins/log/build
 delete mode 100644 sample/sample-plugins/simple/README
 delete mode 100755 sample/sample-plugins/simple/build

diff --git a/configure.ac b/configure.ac
index f8279924..ebb32204 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1433,6 +1433,7 @@ AC_CONFIG_FILES([
doc/doxygen/Makefile
doc/doxygen/openvpn.doxyfile
include/Makefile
+   sample/sample-plugins/Makefile
src/Makefile
src/compat/Makefile
src/openvpn/Makefile
diff --git a/sample/sample-plugins/Makefile.am 
b/sample/sample-plugins/Makefile.am
new file mode 100644
index ..3d6bd2cc
--- /dev/null
+++ b/sample/sample-plugins/Makefile.am
@@ -0,0 +1,35 @@
+#
+#  OpenVPN -- An application to securely tunnel IP networks
+# over a single UDP port, with support for SSL/TLS-based
+# session authentication and key exchange,
+# packet encryption, packet authentication, and
+# packet compression.
+#
+#  Copyright (C) 2002-2020 OpenVPN Inc 
+#
+
+MAINTAINERCLEANFILES = \
+   $(srcdir)/Makefile.in
+
+AM_CPPFLAGS = -I$(top_srcdir) -I$(top_builddir) \
+   -I$(top_srcdir)/include -I$(top_builddir)/include
+
+# We don't want automake to pull in libtool for building these
+# sample-plugins.  Even though this breaks the conceptual ideas
+# around autoconf/automake/libtools ... these sample plug-ins
+# are just sample code, not to be installed or distributed outside
+# of the source tarball.  Not even built by default, by design.
+#
+# We only add this as a simple and convenient way to build all
+# these plug-ins with the same build parameters as the rest
+# of the OpenVPN code.
+#
+# All the plugins which will be built are processed in this
+# separate Makefile, which disconnects everything just enough
+# to achieve our goal.
+include Makefile.plugins
+
+
+dist-hook :
+   make -f Makefile.plugins clean
+
diff --git a/sample/sample-plugins/Makefile.plugins 
b/sample/sample-plugins/Makefile.plugins
new file mode 100644
index ..f550fc19
--- /dev/null
+++ b/sample/sample-plugins/Makefile.plugins
@@ -0,0 +1,36 @@
+#  SPDX-License-Identifier: GPL-2.0-only
+#
+#  Copyrigh

[Openvpn-devel] [PATCH v3] sample-plugins: Partially autotoolize the sample-plugins build

2020-09-15 Thread David Sommerseth
The sample-plugins have their own set of build/winbuild scripts in each
of these plugin directories.  This does not give a good way to reuse
various macros the autoconf/automake/configure process enables; which
can contain important macros to make some code build without errors or
warnings.

Normally we would embrace the full autoconf/automake approach. But this
is sample code which we only want to build per request and the built
code should not be installed anywhere via 'make install'.  But since we
do use libtool other plug-ins being installed and automake gets kind of
cranky when it comes to define certain build targets not following the
expected use cases, we try to only embrace just enough of automake to
get our main goals achieved.

This changeset kicks out the build scripts and replaces them with a
single Makefile.plugins file, which defines the plugins we want to build
by default when running 'make from the sample-plugins directory.
Neither of these plugins are otherwise built by default.  No sample-plugins
are being installed.  But we have enough strings attached to automake
to grab the CFLAGS and LDFLAGS used by the rest of the code.  This also
makes it easy to use #include "config.h" in sample code, to also get
various macros defined by the ./configure run.

This patch does not touch the winbuild scripts, as it seems building
these sample-plugins on Windows requires a bit different compile and
linking steps than *nix systems in general.

Signed-off-by: David Sommerseth 

---
v2 - Process README files with correct instructions and details
v3 - Add missing -I$(top_srcdir)/include and explicitly state GNU Make
 requirement
---
 configure.ac  |  1 +
 sample/sample-plugins/Makefile.am | 30 +++
 sample/sample-plugins/Makefile.plugins| 31 
 sample/sample-plugins/README  | 37 +++
 sample/sample-plugins/defer/README| 16 
 sample/sample-plugins/defer/build | 15 
 .../keying-material-exporter-demo/build   | 15 
 sample/sample-plugins/log/build   | 15 
 sample/sample-plugins/simple/README   | 16 
 sample/sample-plugins/simple/build| 15 
 10 files changed, 99 insertions(+), 92 deletions(-)
 create mode 100644 sample/sample-plugins/Makefile.am
 create mode 100644 sample/sample-plugins/Makefile.plugins
 create mode 100644 sample/sample-plugins/README
 delete mode 100644 sample/sample-plugins/defer/README
 delete mode 100755 sample/sample-plugins/defer/build
 delete mode 100755 sample/sample-plugins/keying-material-exporter-demo/build
 delete mode 100755 sample/sample-plugins/log/build
 delete mode 100644 sample/sample-plugins/simple/README
 delete mode 100755 sample/sample-plugins/simple/build

diff --git a/configure.ac b/configure.ac
index f8279924..ebb32204 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1433,6 +1433,7 @@ AC_CONFIG_FILES([
doc/doxygen/Makefile
doc/doxygen/openvpn.doxyfile
include/Makefile
+   sample/sample-plugins/Makefile
src/Makefile
src/compat/Makefile
src/openvpn/Makefile
diff --git a/sample/sample-plugins/Makefile.am 
b/sample/sample-plugins/Makefile.am
new file mode 100644
index ..657764a6
--- /dev/null
+++ b/sample/sample-plugins/Makefile.am
@@ -0,0 +1,30 @@
+#
+#  OpenVPN -- An application to securely tunnel IP networks
+# over a single UDP port, with support for SSL/TLS-based
+# session authentication and key exchange,
+# packet encryption, packet authentication, and
+# packet compression.
+#
+#  Copyright (C) 2002-2020 OpenVPN Inc 
+#
+
+MAINTAINERCLEANFILES = \
+   $(srcdir)/Makefile.in
+
+AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/include
+
+# We don't want automake to pull in libtool for building these
+# sample-plugins.  Even though this breaks the conceptual ideas
+# around autoconf/automake/libtools ... these sample plug-ins
+# are just sample code, not to be installed or distributed outside
+# of the source tarball.  Not even built by default, by design.
+#
+# We only add this as a simple and convenient way to build all
+# these plug-ins with the same build parameters as the rest
+# of the OpenVPN code.
+#
+# All the plugins which will be built are processed in this
+# separate Makefile, which disconnects everything just enough
+# to achieve our goal.
+include Makefile.plugins
+
diff --git a/sample/sample-plugins/Makefile.plugins 
b/sample/sample-plugins/Makefile.plugins
new file mode 100644
index ..d19aa5bb
--- /dev/null
+++ b/sample/sample-plugins/Makefile.plugins
@@ -0,0 +1,31 @@
+#  SPDX-License-Identifier: GPL-2.0-only
+#
+#  Copyright (C) 2020 OpenVPN Inc 
+#
+
+#
+# Plug-ins to build - listed entries should not carry any extensions
+#
+PLUGINS = \
+   defer/simple \
+   keying-material-exp

Re: [Openvpn-devel] [PATCH v2] sample-plugins: Partially autotoolize the sample-plugins build

2020-09-15 Thread David Sommerseth
On 15/09/2020 12:22, Gert Doering wrote:
> Hi,
> 
> On Mon, Sep 14, 2020 at 02:27:21PM +0200, David Sommerseth wrote:
>> The sample-plugins have their own set of build/winbuild scripts in each
>> of these plugin directories.  This does not give a good way to reuse
>> various macros the autoconf/automake/configure process enables; which
>> can contain important macros to make some code build without errors or
>> warnings.
> 
> This looks like a step in the right direction, but is not fully working
> yet - I tried both an "in-tree" and "out of tree" build, and it fails
> compilation with
> 
> sample-plugins$ gmake
> test -d `dirname defer/simple.o` || ../../../openvpn/./install-sh -c -d 
> `dirname defer/simple.o`; \
> cc -c -o defer/simple.o -Wall -Wno-unused-parameter -Wno-unused-function -g 
> -O2 -std=c99 -I../../../openvpn -fPIC 
> ../../../openvpn/sample/sample-plugins/defer/simple.c
> ../../../openvpn/sample/sample-plugins/defer/simple.c:58:10: fatal error: 
> 'openvpn-plugin.h' file
>   not found
> #include "openvpn-plugin.h"
>  ^~
> 1 error generated.
> 
> 
> openvpn-plugin.h is installed if you install openvpn first, but if
> you only build in tree, it seems to need an extra 
> 
>   -I$(top_srcdir)/include
> 
> to find openvpn-plugin.h

Hmmm ... I would have expected that to be picked up automatically, but clearly
didn't watch the compile arguments carefully enough.

> It also needs gmake - running "make" will do "nothing at all", which
> I found surprising, but did not investigate more closely.  This is likely
> due to implicit rules that need to be written differently for BSD make.

Yikes ... I see potentially two issues here.  BSD Make seems to lack support
for $(foreach ...) and it does not grok '%.so : %.o' (which is Make "macro
magic" to simplify rule writing).  To avoid this and make it BSD Make
compatible, we would probably need to go full-fledged automake - pulling in
libtools (and the awkward .libs directories, .la/.lo files, etc, etc).

So if we're fine with reducing this to GNU Make only, the change is trivial.

> I do not think this is a serious issue - just document it in the README,
> and it's still better than 4 individual "build" files, half of it who
> were missing the needed "-I" as well :-)

New updated patch coming very soon.

-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v2] sample-plugins: Partially autotoolize the sample-plugins build

2020-09-14 Thread David Sommerseth
The sample-plugins have their own set of build/winbuild scripts in each
of these plugin directories.  This does not give a good way to reuse
various macros the autoconf/automake/configure process enables; which
can contain important macros to make some code build without errors or
warnings.

Normally we would embrace the full autoconf/automake approach. But this
is sample code which we only want to build per request and the built
code should not be installed anywhere via 'make install'.  But since we
do use libtool other plug-ins being installed and automake gets kind of
cranky when it comes to define certain build targets not following the
expected use cases, we try to only embrace just enough of automake to
get our main goals achieved.

This changeset kicks out the build scripts and replaces them with a
single Makefile.plugins file, which defines the plugins we want to build
by default when running 'make from the sample-plugins directory.
Neither of these plugins are otherwise built by default.  No sample-plugins
are being installed.  But we have enough strings attached to automake
to grab the CFLAGS and LDFLAGS used by the rest of the code.  This also
makes it easy to use #include "config.h" in sample code, to also get
various macros defined by the ./configure run.

This patch does not touch the winbuild scripts, as it seems building
these sample-plugins on Windows requires a bit different compile and
linking steps than *nix systems in general.

Signed-off-by: David Sommerseth 

---
v2 - Process README files with correct instructions and details
---
 configure.ac  |  1 +
 sample/sample-plugins/Makefile.am | 28 ++
 sample/sample-plugins/Makefile.plugins| 31 
 sample/sample-plugins/README  | 37 +++
 sample/sample-plugins/defer/README| 16 
 sample/sample-plugins/defer/build | 15 
 .../keying-material-exporter-demo/build   | 15 
 sample/sample-plugins/log/build   | 15 
 sample/sample-plugins/simple/README   | 16 
 sample/sample-plugins/simple/build| 15 
 10 files changed, 97 insertions(+), 92 deletions(-)
 create mode 100644 sample/sample-plugins/Makefile.am
 create mode 100644 sample/sample-plugins/Makefile.plugins
 create mode 100644 sample/sample-plugins/README
 delete mode 100644 sample/sample-plugins/defer/README
 delete mode 100755 sample/sample-plugins/defer/build
 delete mode 100755 sample/sample-plugins/keying-material-exporter-demo/build
 delete mode 100755 sample/sample-plugins/log/build
 delete mode 100644 sample/sample-plugins/simple/README
 delete mode 100755 sample/sample-plugins/simple/build

diff --git a/configure.ac b/configure.ac
index f8279924..ebb32204 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1433,6 +1433,7 @@ AC_CONFIG_FILES([
doc/doxygen/Makefile
doc/doxygen/openvpn.doxyfile
include/Makefile
+   sample/sample-plugins/Makefile
src/Makefile
src/compat/Makefile
src/openvpn/Makefile
diff --git a/sample/sample-plugins/Makefile.am 
b/sample/sample-plugins/Makefile.am
new file mode 100644
index ..d02abe48
--- /dev/null
+++ b/sample/sample-plugins/Makefile.am
@@ -0,0 +1,28 @@
+#
+#  OpenVPN -- An application to securely tunnel IP networks
+# over a single UDP port, with support for SSL/TLS-based
+# session authentication and key exchange,
+# packet encryption, packet authentication, and
+# packet compression.
+#
+#  Copyright (C) 2002-2020 OpenVPN Inc 
+#
+
+MAINTAINERCLEANFILES = \
+   $(srcdir)/Makefile.in
+
+# We don't want automake to pull in libtool for building these
+# sample-plugins.  Even though this breaks the conceptual ideas
+# around autoconf/automake/libtools ... these sample plug-ins
+# are just sample code, not to be installed or distributed outside
+# of the source tarball.  Not even built by default, by design.
+#
+# We only add this as a simple and convenient way to build all
+# these plug-ins with the same build parameters as the rest
+# of the OpenVPN code.
+#
+# All the plugins which will be built are processed in this
+# separate Makefile, which disconnects everything just enough
+# to achieve our goal.
+include Makefile.plugins
+
diff --git a/sample/sample-plugins/Makefile.plugins 
b/sample/sample-plugins/Makefile.plugins
new file mode 100644
index ..76768dbe
--- /dev/null
+++ b/sample/sample-plugins/Makefile.plugins
@@ -0,0 +1,31 @@
+#  SPDX-License-Identifier: GPL-2.0-only
+#
+#  Copyright (C) 2020 OpenVPN Inc 
+#
+
+#
+# Plug-ins to build - listed entries should not carry any extensions
+#
+PLUGINS = \
+   defer/simple \
+   keying-material-exporter-demo/keyingmaterialexporter \
+   log/log log/log_v3 \
+   simple/base64 \
+   simple/simple
+
+# All the plugins to build - rewritten with .so

[Openvpn-devel] [PATCH] sample-plugins: Partially autotoolize the sample-plugins build

2020-09-14 Thread David Sommerseth
The sample-plugins have their own set of build/winbuild scripts in each
of these plugin directories.  This does not give a good way to reuse
various macros the autoconf/automake/configure process enables; which
can contain important macros to make some code build without errors or
warnings.

Normally we would embrace the full autoconf/automake approach. But this
is sample code which we only want to build per request and the built
code should not be installed anywhere via 'make install'.  But since we
do use libtool other plug-ins being installed and automake gets kind of
cranky when it comes to define certain build targets not following the
expected use cases, we try to only embrace just enough of automake to
get our main goals achieved.

This changeset kicks out the build scripts and replaces them with a
single Makefile.plugins file, which defines the plugins we want to build
by default when running 'make from the sample-plugins directory.
Neither of these plugins are otherwise built by default.  No sample-plugins
are being installed.  But we have enough strings attached to automake
to grab the CFLAGS and LDFLAGS used by the rest of the code.  This also
makes it easy to use #include "config.h" in sample code, to also get
various macros defined by the ./configure run.

This patch does not touch the winbuild scripts, as it seems building
these sample-plugins on Windows requires a bit different compile and
linking steps than *nix systems in general.

Signed-off-by: David Sommerseth 
---
 configure.ac  |  1 +
 sample/sample-plugins/Makefile.am | 28 +
 sample/sample-plugins/Makefile.plugins| 31 +++
 sample/sample-plugins/defer/build | 15 -
 .../keying-material-exporter-demo/build   | 15 -
 sample/sample-plugins/log/build   | 15 -
 sample/sample-plugins/simple/build| 15 -
 7 files changed, 60 insertions(+), 60 deletions(-)
 create mode 100644 sample/sample-plugins/Makefile.am
 create mode 100644 sample/sample-plugins/Makefile.plugins
 delete mode 100755 sample/sample-plugins/defer/build
 delete mode 100755 sample/sample-plugins/keying-material-exporter-demo/build
 delete mode 100755 sample/sample-plugins/log/build
 delete mode 100755 sample/sample-plugins/simple/build

diff --git a/configure.ac b/configure.ac
index f8279924..ebb32204 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1433,6 +1433,7 @@ AC_CONFIG_FILES([
doc/doxygen/Makefile
doc/doxygen/openvpn.doxyfile
include/Makefile
+   sample/sample-plugins/Makefile
src/Makefile
src/compat/Makefile
src/openvpn/Makefile
diff --git a/sample/sample-plugins/Makefile.am 
b/sample/sample-plugins/Makefile.am
new file mode 100644
index ..d02abe48
--- /dev/null
+++ b/sample/sample-plugins/Makefile.am
@@ -0,0 +1,28 @@
+#
+#  OpenVPN -- An application to securely tunnel IP networks
+# over a single UDP port, with support for SSL/TLS-based
+# session authentication and key exchange,
+# packet encryption, packet authentication, and
+# packet compression.
+#
+#  Copyright (C) 2002-2020 OpenVPN Inc 
+#
+
+MAINTAINERCLEANFILES = \
+   $(srcdir)/Makefile.in
+
+# We don't want automake to pull in libtool for building these
+# sample-plugins.  Even though this breaks the conceptual ideas
+# around autoconf/automake/libtools ... these sample plug-ins
+# are just sample code, not to be installed or distributed outside
+# of the source tarball.  Not even built by default, by design.
+#
+# We only add this as a simple and convenient way to build all
+# these plug-ins with the same build parameters as the rest
+# of the OpenVPN code.
+#
+# All the plugins which will be built are processed in this
+# separate Makefile, which disconnects everything just enough
+# to achieve our goal.
+include Makefile.plugins
+
diff --git a/sample/sample-plugins/Makefile.plugins 
b/sample/sample-plugins/Makefile.plugins
new file mode 100644
index ..76768dbe
--- /dev/null
+++ b/sample/sample-plugins/Makefile.plugins
@@ -0,0 +1,31 @@
+#  SPDX-License-Identifier: GPL-2.0-only
+#
+#  Copyright (C) 2020 OpenVPN Inc 
+#
+
+#
+# Plug-ins to build - listed entries should not carry any extensions
+#
+PLUGINS = \
+   defer/simple \
+   keying-material-exporter-demo/keyingmaterialexporter \
+   log/log log/log_v3 \
+   simple/base64 \
+   simple/simple
+
+# All the plugins to build - rewritten with .so extension
+all : $(foreach var, $(PLUGINS), $(var).so)
+
+# Compile step
+.c.o :
+   test -d `dirname $@` || $(MKDIR_P) `dirname $@`; \
+   $(CC) -c -o $@ $(CFLAGS) -I$(top_srcdir) -fPIC $<
+
+# Link step
+%.so : %.o
+   $(CC) $(LDFLAGS) -shared -fPIC -o $@ $<
+
+# Clean up all build object and shared object files
+clean :
+   rm -f $(foreach var, $(PLUGINS), $(var).o) \
+   $(foreac

Re: [Openvpn-devel] [PATCH v2] Add demo plugin that excercises "CLIENT_CONNECT" and "CLIENT_CONNECT_V2" paths

2020-09-14 Thread David Sommerseth
On 11/09/2020 23:39, Gert Doering wrote:
[...snip...]
>> I'm getting a lot of "warning: implicit declaration of function 
>> ???strdup???;" and
>>  "warning: assignment to ???char *??? from ???int??? makes pointer from 
>> integer
>> without a cast" compiler warning on all of these strdup() calls.
>>
>> We do use strdup() in the main openvpn code, but that code includes config.h,
>> which contains #define _GNU_SOURCE 1.  This removes this compiler warning.
>>
>> This is on RHEL-7 with both gcc-4.8 and gcc-9.3.
> 
> Not sure what you are hitting there.  According to "man strdup()", 
> inclusion of  should be fully sufficient, without any extra
> declarations.  But maybe it's a -std=... thing to tell GCC what
> C language level is desired?

Yes, I read somewhere that -std=c99 changes the behavior.  _POSIX_C_SOURCE is 
not defined with -std=c99 (nor c11), but is defined without -std= defined.
None of the compiler standards adds _XOPEN_SOURCE - and neither _SVID_SOURCE
nor _BSD_SOURCE (which is not really surprising)

> I developed and tested this on a gentoo linux, with gcc-9.2.0, and it's 
> *not* throwing strdup() warnings.

Without -std=c99 I get a clean compilation with GCC-9.3.1 (RHEL-7/devtoolset-9 
SCL).  But on stock RHEL-7 (GCC-4.8.5) this plugin does not compile without 
-std=c99 ...


client-connect/sample-client-connect.c: In function 
‘openvpn_plugin_client_connect’:
client-connect/sample-client-connect.c:356:9: error: ‘for’ loop initial 
declarations are only allowed in C99 mode
 for (int i = 0; argv[i]; i++)



-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Add demo plugin that excercises "CLIENT_CONNECT" and "CLIENT_CONNECT_V2" paths

2020-09-11 Thread David Sommerseth
On 11/08/2020 12:44, Gert Doering wrote:
> This is a new "samples" plugin which does not do many useful things,
> besides
>  - show how a plugin is programmed
>  - how the various messages get dispatched
>  - how to pass back information from a client-connect/v2 plugin
>  - how to do async-cc plugins  [not yet implemented]
> 
> the operation of the plugin is controlled by UV_WANT_* environment variables
> controlled by the client ("--setenv UV_WANT_CC_FAIL 1 --push-peer-info"),
> to "fail CLIENT_CONNECT" or "use async-cc for CLIENT_CONNECT_V2" or
> "send 'disable' back from ...") - which is useful for automated testing
> of server success/defer/fail code paths for the CLIENT_CONNECT_* functions.
> 
> See samples/sample-plugins/client-connect/README for details how to do this.
> 
> v2:
>   - implement async / deferred operation both for CLIENT_CONNECT and
> CLIENT_CONNECT_V2 plugin calls
>   - implement returning openvpn-controlled (setenv) config snippets
> (so the client side can verify in automated testing that the plugin
> operated correctly, without hard-coding something in the plugin code)
> ---
>  sample/sample-plugins/client-connect/Makefile |  16 +
>  sample/sample-plugins/client-connect/README   |  34 +
>  .../client-connect/sample-client-connect.c| 609 ++
>  3 files changed, 659 insertions(+)
>  create mode 100644 sample/sample-plugins/client-connect/Makefile
>  create mode 100644 sample/sample-plugins/client-connect/README
>  create mode 100644 
> sample/sample-plugins/client-connect/sample-client-connect.c
> 
> diff --git a/sample/sample-plugins/client-connect/Makefile 
> b/sample/sample-plugins/client-connect/Makefile
> new file mode 100644
> index ..ff187c43
> --- /dev/null
> +++ b/sample/sample-plugins/client-connect/Makefile
> @@ -0,0 +1,16 @@
> +all: sample-client-connect.so
> +
> +
> +sample-client-connect.o: sample-client-connect.c
> +
> +# This directory is where we will look for openvpn-plugin.h
> +CPPFLAGS=-I../../../include
> +
> +CC=gcc

If you don't set this; CC will normally be 'cc', which is normally linked to
gcc on Linux systems.

> +CFLAGS=-O2 -Wall -Wno-unused-variable -g

I would probably skip the -Wno-unused-variable and rather not declare unused
variables.

[...snip...]

> --- /dev/null
> +++ b/sample/sample-plugins/client-connect/sample-client-connect.c

[...snip...]

> +/* use v3 functions so we can use openvpn's logging and base64 etc. */
> +OPENVPN_EXPORT int
> +openvpn_plugin_open_v3(const int v3structver,
> +   struct openvpn_plugin_args_open_in const *args,
> +   struct openvpn_plugin_args_open_return *ret)
> +{
> +const char **argv = args->argv;

From a code-style point of view, I think declaring unused variables should be
avoided.  Since this is as an example, we could just comment this line out and
add a remark that we do not parse plug-in arguments in this example.

[...snip...]

> +int
> +openvpn_plugin_client_connect_v2(struct plugin_context *context,
> + struct plugin_per_client_context *pcc,
> + const char **envp,
> + struct openvpn_plugin_string_list 
> **return_list)
> +{

[...snip...]

> +rl->name = strdup("config");

I'm getting a lot of "warning: implicit declaration of function ‘strdup’;" and
 "warning: assignment to ‘char *’ from ‘int’ makes pointer from integer
without a cast" compiler warning on all of these strdup() calls.

We do use strdup() in the main openvpn code, but that code includes config.h,
which contains #define _GNU_SOURCE 1.  This removes this compiler warning.

This is on RHEL-7 with both gcc-4.8 and gcc-9.3.


Otherwise, the code looks reasonable and it works.  The log file does not
include the pushed echo statement (can be enabled in options.c:5286).  The
management interface shows the pushed echo message.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Handle NULL returns from calloc() in sample plugins.

2020-09-11 Thread David Sommerseth
On 09/09/2020 12:48, Gert Doering wrote:
> This is basic housekeeping, adding NULL checks to context initialization
> of the sample plugin collection which are missing it.  Realistically,
> this can never happen, but since these are supposed to be "good examples",
> not checking calloc() return isn't one.
> 
> Trac: #587
> 
> Reported-By: Dogbert (in Trac)
> Signed-off-by: Gert Doering 
> ---
>  sample/sample-plugins/defer/simple.c| 5 +
>  .../keying-material-exporter-demo/keyingmaterialexporter.c  | 6 ++
>  sample/sample-plugins/log/log.c | 5 +
>  sample/sample-plugins/log/log_v3.c  | 5 +
>  sample/sample-plugins/simple/simple.c   | 5 +
>  5 files changed, 26 insertions(+)
> 

I've just glared at the code and compiled all the sample plug-ins.  All looks
reasonable and good.

Acked-By: David Sommerseth 


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] man: Add missing --server-ipv6

2020-09-11 Thread David Sommerseth
During the conversion from .8 to .rst and further reorganizing of the
content into separate files, the --server-ipv6 entry got lost.  This
resurrects it again.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/server-options.rst | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/doc/man-sections/server-options.rst 
b/doc/man-sections/server-options.rst
index 2009953c..1c25d75a 100644
--- a/doc/man-sections/server-options.rst
+++ b/doc/man-sections/server-options.rst
@@ -639,6 +639,20 @@ fast hardware. SSL/TLS authentication must be used in this 
mode.
 mode server
 tls-server
 
+--server-ipv6 args
+  Convenience-function to enable a number of IPv6 related options at once,
+  namely ``--ifconfig-ipv6``, ``--ifconfig-ipv6-pool`` and
+  ``--push tun-ipv6``.
+
+  Valid syntax:
+  ::
+
+ server-ipv6 ipv6addr/bits
+
+  This is only accepted if ``--mode server`` or ``--server`` is set.
+  Pushing of the ``--tun-ipv6`` directive is done for older clients which
+  require an explicit ``--tun-ipv6`` in their configuration.
+
 --stale-routes-check args
   Remove routes which haven't had activity for ``n`` seconds (i.e. the ageing
   time).  This check is run every ``t`` seconds (i.e. check interval).
-- 
2.26.0



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


Re: [Openvpn-devel] [PATCH] Support for wolfSSL in OpenVPN

2020-09-11 Thread David Sommerseth
On 10/09/2020 14:16, Arne Schwabe wrote:
> Am 10.09.20 um 14:11 schrieb Juliusz Sosinowicz:
>> Hi Arne,
>>
>> I understand your concern and apologize for the delay. We have been busy
>> with the release of wolfSSL 4.5.0. I will make sure that the fixes
>> necessary for OpenVPN support will be prioritized.
>>
>> Sincerely
>> Juliusz
> 
> I think the best way forward is to include wolfSSL support into OpenVPN
> master now and if we have proper a proper support of wolfSSL that is
> kept up to from your side then it will be part of the next release. And
> otherwise we remove the support before the next release. That should our
> concerns of wanting to see ongoing support and also your concern of it
> not being included.

I completely agree.  This makes a lot of sense and is a reasonable way forward.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] man: Improve --remote entry

2020-09-09 Thread David Sommerseth
The --remote entry had a syntax mistake in the argument examples, which
was introduced during the .rst conversion.

In addition this section did not have a good flow.  So the text was
regrouped and re-organized a bit so related text pieces are now gathered
in the same context instead of being more spread out.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/client-options.rst | 60 -
 1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index ec1e3b11..af21fbcd 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -244,43 +244,51 @@ configuration.
   use :code:`ignore`.
 
 --remote args
-  Remote host name or IP address.  It supports two additional optional
-  arguments: ``port`` and ``proto``.  On the client, multiple ``--remote``
-  options may be specified for redundancy, each referring to a different
-  OpenVPN server. Specifying multiple ``--remote`` options for this
-  purpose is a special case of the more general connection-profile
-  feature. See the  documentation below.
+  Remote host name or IP address, port and protocol.
 
-  The OpenVPN client will try to connect to a server at ``host:port`` in
-  the order specified by the list of ``--remote`` options.
-
-  Examples:
+  Valid syntaxes:
   ::
 
- remote server.example.net
- remote server.example.net 1194
- remote server.example.net tcp
+ remote host
+ remote host port
+ remote host port proto
 
-  ``proto`` indicates the protocol to use when connecting with the remote,
-  and may be :code:`tcp` or :code:`udp`.
+  The ``port`` and ``proto`` arguments are optional. The OpenVPN client
+  will try to connect to a server at ``host:port``.  The ``proto`` argument
+  indicates the protocol to use when connecting with the remote, and may be
+  :code:`tcp` or :code:`udp`.  To enforce IPv4 or IPv6 connections add a
+  :code:`4` or :code:`6` suffix; like :code:`udp4` / :code:`udp6`
+  / :code:`tcp4` / :code:`tcp6`.
 
-  For forcing IPv4 or IPv6 connection suffix tcp or udp with 4/6 like
-  udp4/udp6/tcp4/tcp6.
+  On the client, multiple ``--remote`` options may be specified for
+  redundancy, each referring to a different OpenVPN server, in the order
+  specified by the list of ``--remote`` options. Specifying multiple
+  ``--remote`` options for this purpose is a special case of the more
+  general connection-profile feature. See the 
+  documentation below.
 
   The client will move on to the next host in the list, in the event of
   connection failure. Note that at any given time, the OpenVPN client will
   at most be connected to one server.
 
-  Note that since UDP is connectionless, connection failure is defined by
-  the ``--ping`` and ``--ping-restart`` options.
+  Examples:
+  ::
 
-  Note the following corner case: If you use multiple ``--remote``
-  options, AND you are dropping root privileges on the client with
-  ``--user`` and/or ``--group`` AND the client is running a non-Windows
-  OS, if the client needs to switch to a different server, and that server
-  pushes back different TUN/TAP or route settings, the client may lack the
-  necessary privileges to close and reopen the TUN/TAP interface. This
-  could cause the client to exit with a fatal error.
+ remote server1.example.net
+ remote server1.example.net 1194
+ remote server2.example.net 1194 tcp
+
+  *Note:*
+ Since UDP is connectionless, connection failure is defined by
+ the ``--ping`` and ``--ping-restart`` options.
+
+ Also, if you use multiple ``--remote`` options, AND you are dropping
+ root privileges on the client with ``--user`` and/or ``--group`` AND
+ the client is running a non-Windows OS, if the client needs to switch
+ to a different server, and that server pushes back different TUN/TAP
+ or route settings, the client may lack the necessary privileges to
+ close and reopen the TUN/TAP interface. This could cause the client
+ to exit with a fatal error.
 
   If ``--remote`` is unspecified, OpenVPN will listen for packets from any
   IP address, but will not act on those packets unless they pass all
-- 
2.26.0



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


Re: [Openvpn-devel] [PATCH] Fix --remote protocol can't be set without port argument

2020-09-09 Thread David Sommerseth
On 08/09/2020 21:01, Vladislav Grishenko wrote:
> Hi David,
> 
>> -Original Message-----
>> From: David Sommerseth 
>> Sent: Tuesday, September 8, 2020 6:23 PM
>> To: Vladislav Grishenko ; openvpn-
>> de...@lists.sourceforge.net
>> Subject: Re: [Openvpn-devel] [PATCH] Fix --remote protocol can't be set 
>> without
>> port argument
>>
>> On 03/09/2020 13:44, Vladislav Grishenko wrote:
>>> According client-options.rst additional argumets ``port`` and
>>> ``proto`` are both optional and it's allowed to have port absent and 
>>> protocol
>> set:
>>> --remote args
>>>   Examples:
>>>  remote server.example.net tcp
>>>
>>> But when protocol is set without preceeding port argument, it is being
>>> misparsed as a port with subsequent error:
>>> RESOLVE: Cannot resolve host address: server.example.net:tcp
>>> (Servname not supported for ai_socktype)
>>>
>>> Since protocol names are predefined and don't match service names, fix
>>> this behavior by checking second argument for valid protocol first.
>>>
>> Uhm ... I'm leaning towards a NAK to this patch and would rather suggest
>> updating the man page to be correct.  This is a mistake from my side when
>> converting the man page to .rst files.  The example should be:
>>
>>remote server.example.net 1194 tcp
>>
> 
> Hum. Initially all variants were supported, by checking numeric port and
> taking it as proto, if not numeric. Later port became string servname and
> optional logic was lost.

The man page history disagrees ... even though, it doesn't say this order is
explicit.

2.4 - <https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage#lbAG>
2.3 - <https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage#lbAG>
2.2 - <https://community.openvpn.net/openvpn/wiki/Openvpn22ManPage>
2.1 - <https://community.openvpn.net/openvpn/wiki/Openvpn21ManPage#lbAG>

> Man pages still has all of them since that time:
>>  remote server.exmaple.net
>>  remote server.exmaple.net 1194
>>  remote server.exmaple.net tcp

These lines comes from this commit:
<https://github.com/OpenVPN/openvpn/commit/f500c49c8e0a77ce665b11f6adbea4029cf3b85f>

Where the last line (missing port number) is incorrect.

I also don't see any commit changing the "remote" parsing in options.c in the
way you describe.  This section has just few changes over the years, but even
back to changes 7-12 years ago, the second argument has always been processed
as a port number and the third one protocol.  Both causing an error if it is
not a valid value.  So putting protocol in the second argument would trigger
an error in 2.1, 2.2, 2.3 and 2.4 as far as I can see.

> 
> At first look there is no need for proto w/o port set,  why it can be
> important? With support of server host & port discovery (DNS SRV RFC 2782),
> port info is not required, only host and protocol make sense. So I though
> about this one little step forward toward ~consistent syntax. Does it makes
> any sense?
I don't see why OpenVPN's --remote parsing needs to comply with DNS SRV RFC
standards.  How is that related at all?  I know we have patches for adding DNS
SRV query support, but that doesn't imply passing this information via
add_option(), does it?

If you use --remote vpn.example.com --proto tcp  that will already work.
What will not work is --remote vpn.example.com tcp

Also, this will work in config files:
---
port 5000
proto udp


remote vpn1.example.com


remote vpn2.example.com
proto tcp

---

All of these use cases makes sense, as it depends on a pre-set value.  What
does not make sense to me is to muddy a pretty clearly defined argument order
which has been the standard since the beginning of OpenVPN.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix --remote protocol can't be set without port argument

2020-09-08 Thread David Sommerseth
On 03/09/2020 13:44, Vladislav Grishenko wrote:
> According client-options.rst additional argumets ``port`` and ``proto``
> are both optional and it's allowed to have port absent and protocol set:
> --remote args
>   Examples:
>  remote server.example.net tcp
> 
> But when protocol is set without preceeding port argument, it is being
> misparsed as a port with subsequent error:
> RESOLVE: Cannot resolve host address: server.example.net:tcp
> (Servname not supported for ai_socktype)
> 
> Since protocol names are predefined and don't match service names, fix
> this behavior by checking second argument for valid protocol first.
> 
> Signed-off-by: Vladislav Grishenko 
Uhm ... I'm leaning towards a NAK to this patch and would rather suggest
updating the man page to be correct.  This is a mistake from my side when
converting the man page to .rst files.  The example should be:

   remote server.example.net 1194 tcp

The OpenVPN 2.4 and prior releases has this line:

   --remote host [port] [proto]

But this syntax was not supported by rst2man, so it was replaced with "args"
and the examples coming below; which carried an error.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Document that --push-remove is generally more suitable than --push-reset

2020-09-08 Thread David Sommerseth
On 08/09/2020 13:15, Gert Doering wrote:
> It's a long-standing and well-known problem that --push-reset removes
> "critical" options from the push list (like "topology subnet") which
> will then lead to non-working client configs.  This can not be
> reasonably fixed, because the list of "critical" options depends on
> overall server config.
> 
> So just document the fact, and point people towards --push-remove as
> a more selective tool.
> 
> Trac: #29
> 
> Signed-off-by: Gert Doering 
> ---
>  doc/man-sections/server-options.rst | 8 
>  1 file changed, 8 insertions(+)

Acked-By: David Sommerseth 

It would be good if --push-reset would actually not remove certain critical
options, but this is anyhow a good heads-up for our users.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] Fix best gateway selection over netlink

2020-09-08 Thread David Sommerseth
On 08/09/2020 14:36, Vladislav Grishenko wrote:
> On kernels earlier than 2.6.38 default routes are the last ones,
> so arbitrary host/net route w/o gateway is likely be returned as
> first, causing gateway to be invalid or empty.
> After refactoring in 2.6.38 kernel default routes are on top, so
> the problem with older kernels was hidden.

I haven't paid too much attention here, but I don't think I've seen this point
being brought up.  But do we really care about such old kernels at all?

AFAIK, RHEL-6 (which goes EOL in November this year and which is not planned
to be supported in OpenVPN 2.5+) is the only distro carrying such an old
kernel release (2.6.32 baseline).  Even an internal OpenWRT 19.07 box of mine
(which should be upgraded, I know!) ships with 4.14.  Unless I'm completely
clueless (which is a possibility), 2.4 and 2.6 kernels are mostly interesting
for boards with 4MB flash memory.  And I would suspect such boards with that
little flash memory to belong to that past.  (And OpenVPN 2.4 is perfectly
fine too for some time forward anyhow, which should work just fine).

If this fix has other qualities, then it's fine to consider such a patch.  But
I don't see the need for this if it is primarily to enable support for ancient
kernel releases which are no longer supported by the upstream kernel community
(where 4.4 is the oldest one).

I would lean on what Antonio says here as well, as he kinda owns the sitnl
implementation and API.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


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

2020-09-04 Thread David Sommerseth
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>


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] OpenVPN 3 Linux client - v10 beta released

2020-07-27 Thread David Sommerseth

Hi,

The OpenVPN 3 Linux v10 beta is now released.

This is available in our git repositories [0] and URLs for source tarballs
are listed later in this e-mail.  We have pre-built binaries for the
following Linux distributions:

* Fedora 31 and 32 (via Fedora Copr: x86_64, aarch64)
* RHEL/CentOS 7 and 8  (via Fedora Copr: x86_64, aarch64)
* Debian 9 and 10 (amd64)
* Ubuntu 16.04, 18.04, 19.10 and 20.04 (amd64)

A quick-start guide for OpenVPN 3 Linux can be found here:

<https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux>


The highlights of this release includes:

* Feature: systemd-resolved integration

  By default, OpenVPN 3 Linux will modify the /etc/resolv.conf file
  with DNS configurations pushed by the VPN server.  This release
  adds systemd-resolved as an alternative to this approach, where
  the systemd-resolved service will be in charge of querying the
  proper DNS resolvers and there will no longer be any fight over
  configuration files such as /etc/resolv.conf.

  In this release, pushed DNS configurations will be handled quite
  similar to how DNS queries has been handled before.  The DNS settings
  pushed by the VPN server will typically take precedence, but
  systemd-resolved may query other servers on other interfaces as well.
  That said, if the VPN server pushes "dhcp-options DOMAIN ", hosts
  under that domain will in this case only be queried via the VPN tunnel
  alone.  You may call this a partial DNS-split.

  In coming releases, we will evaluate further possibilities to configure
  how DNS requests would be handled by systemd-resolved.  This could
  include modes such as full split (only query for pushed DOMAIN via the
  DNS server provided by the VPN) or exclusive VPN (DNS queries should
  only go via the VPN tunnel).

  This systemd-resolved integration requires at least CentOS 8,
  Fedora 31, 32 or Rawhide, Red Hat Enterprise 8 or Ubuntu 20.04.  Other
  distributions may work as long as it uses systemd v243 or newer.

  To enable systemd-resolved, fully ensure that systemd-resolved is
  properly configured and activated on your system.  Currently only
  Ubuntu 20.04 does that somewhat out-of-the-box (there might be some
  additional changes to nsswitch.conf is required for optimal
  performance).  Please read the available systemd-resolved
  documentation for your Linux distribution.

  Once systemd-resolved is enabled and activated, run this command
  as root before starting any VPN tunnels:

 # openvpn3-admin netcfg-service --config-set systemd-resolved 1

  and wait until the openvpn3-service-netcfg has restarted.  With
  the log-level set to 5 or higher in netcfg-service, the log file will
  include this log line:

  Network Configuration VERB2: systemd-resolved DNS configuration backend

* Feature: openvpn3 log with --config will now wait for a not-started session

  When starting the end-user session logging, prior versions required the
  VPN session to already be running before a log client could be attached.

  With this release, if the session has not already been started, the
  openvpn3 log command will wait until it sees the appropriate VPN session
  has started and will attach to it instantly.  This allows to grab the
  first log lines of a starting VPN sessions for an end-user without
  other ways of accessing OpenVPN logs.

* Improvement: openvpn3-as indicates tls-crypt-v2 support to AS

  When downloading a VPN configuration profile from an OpenVPN Access
  Server, the openvpn3-as script will now signal to the server it is
  capable of handling configurations with --tls-crypt-v2.


* Bugfix: AWS integration failed to propagate routes in some AWS regions

  The openvpn3-service-aws process could in some AWS regions fail to push
  routes to the AWS-VPC, leading to a process crash.  Both the crash and
  the AWS service has been extended with more region CA certificates used
  for the request validations.  In addition it will now pick up more of
  system CA certificate file locations than before.


-- 
kind regards,

David Sommerseth
OpenVPN Inc


[0] <https://gitlab.com/openvpn/openvpn3-linux>
<https://github.com/OpenVPN/openvpn3-linux>


 Source tarballs 
* OpenVPN 3 Linux v10 beta

  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-10_beta.tar.xz>
  
<https://swupdate.openvpn.net/community/releases/openvpn3-linux-10_beta.tar.xz.asc>

 SHA256 Checksums ---

6fb565d2ec19331ee3203d027d90598e51dec3cb31888be25d15e1c9911dbcd1  
openvpn3-linux-10_beta.tar.xz
bc95ac62700e0924b43d7846a3ca7601d1ac2ef3efeb32f2f01d48d3b11d32f0  
openvpn3-linux-10_beta.tar.xz.asc

 git references -

git tag: v10_beta
git commit: ff27a9f83b29448797e72ce9f92abc498647202a

 Changes from v9 to v10---

Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers

2020-07-24 Thread David Sommerseth
ld still be a weighing of pros and cons.
> 
> For this specific option of ncp-ciphers/data-ciphers. This not just a
> fringe option. This is an option that affects one of the core things of
> OpenVPN, the chosen chipher. I want to make the transition to NCP as
> painless as possible and  keeping ncp-cipher as alias to data-cipher is
> just the better choice in my opinion.

I agree that --data-cipher is a better name for it; I have not rejected that.

But that doesn't mean we should have two thoughts active at the same time: a)
NCP improvements, and b) product life cycle, what we support and how we
support OpenVPN in the long run ... in this case they do impact each other.

But when we only focus on a) without properly considering b), that is the
point where I object.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers

2020-07-24 Thread David Sommerseth
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.
>> +
>>  --ncp-disable
>>Disable "Negotiable Crypto Parameters". This completely disables cipher
>>negotiation.
>> diff --git a/doc/man-sections/server-options.rst 
>> b/doc/man-sections/server-options.rst
>> index c24aec0b..74ad5e18 100644
>> --- a/doc/man-sections/server-options.rst
>> +++ b/doc/man-sections/server-options.rst
>> @@ -473,8 +473,8 @@ fast hardware. SSL/TLS authentication must be used in 
>> this mode.
>>  *AES-GCM-128* and *AES-GCM-256*.
>>  
>>:code:`IV_CIPHERS=`
>> -The client pushes the list of configured ciphers with the
>> -``--ciphers`` option to the server.
>> +The client announces the list of supported ciphers configured with 
>> the
>> +``--data-ciphers`` option to the server.
>>  
>>:code:`IV_GUI_VER= `
>>  The UI version of a UI if one is running, for example
>> diff --git a/sample/sample-config-files/client.conf 
>> b/sample/sample-config-files/client.conf
>> index 7f2f30a3..47ca4099 100644
>> --- a/sample/sample-config-files/client.conf
>> +++ b/sample/sample-config-files/client.conf
>> @@ -112,7 +112,7 @@ tls-auth ta.key 1
>>  # then you must also specify it here.
>>  # Note that v2.4 client/server will automatically
>>  # negotiate AES-256-GCM in TLS mode.
>> -# See also the ncp-cipher option in the manpage
>> +# See also the data-ciphers option in the manpage
>>  cipher AES-256-CBC
>>  
>>  # Enable compression on the VPN link.
>> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
>> index 88ba9db2..d2549bca 100644
>> --- a/src/openvpn/multi.c
>> +++ b/src/openvpn/multi.c
>> @@ -1827,7 +1827,7 @@ multi_client_set_protocol_options(struct context *c)
>>  else
>>  {
>>  /*
>> - * Push the first cipher from --ncp-ciphers to the client that
>> + * Push the first cipher from --data-ciphers to the client that
>>   * the client announces to be supporting.
>>   */
>>  char *push_cipher = ncp_get_best_cipher(o->ncp_ciphers, 
>> o->ciphername,
>> @@ -1847,7 +1847,7 @@ multi_client_set_protocol_options(struct context *c)
>>  {
>>  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'",
>> +"data-ciphers: '%s', client supported ciphers '%s'",
>>  o->ncp_ciphers, peer_ciphers);
>>  }
>>  else
>> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
>> index 31e33ae3..896abcde 100644
>> --- a/src/openvpn/options.c
>> +++ b/src/openvpn/options.c
>> @@ -536,7 +536,7 @@ static const char usage_message[] =
>>  "--cipher alg: Encrypt packets with cipher algorithm alg\n"
>>  "  (default=%s).\n"
>>  "  Set alg=none to disable encryption.\n"
>> -"--ncp-ciphers list : List of ciphers that are allowed to be 
>> negotiated.\n"
>> +"--data-ciphers list : List of ciphers that are allowed to be 
>> negotiated.\n"
>>  "--ncp-disable   : (DEPRECATED) Disable cipher negotiation.\n"
>>  "--prng alg [nsl] : For PRNG, use digest algorithm alg, and\n"
>>  "   nonce_secret_len=nsl.  Set alg=none to disable 
>> PRNG.\n"
>> @@ -7866,7 +7866,8 @@ add_option(struct options *options,
>>  VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
>>  options->ciphername = p[1];
>>  }
>> -else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
>> +else if ((streq(p[0], "data-ciphers") || streq(p[0], "ncp-ciphers"))
>> +&& p[1] && !p[2])
>>  {
>>  VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_INSTANCE);
>>  options->ncp_ciphers = p[1];
>> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
>> index e057a40b..6760884e 100644
>> --- a/src/openvpn/ssl_ncp.c
>> +++ b/src/openvpn/ssl_ncp.c
>> @@ -111,7 +111,7 @@ mutate_ncp_cipher_list(const char *list, struct gc_arena 
>> *gc)
>>  const cipher_kt_t *ktc = cipher_kt_get(token);
>>  if (!ktc)
>>  {
>> -msg(M_WARN, "Unsupported cipher in --ncp-ciphers: %s", token);
>> +msg(M_WARN, "Unsupported cipher in --data-ciphers: %s", token);
>>  error_found = true;
>>  }
>>  else
>> @@ -130,7 +130,7 @@ mutate_ncp_cipher_list(const char *list, struct gc_arena 
>> *gc)
>>  if (!(buf_forward_capacity(_list) >
>>strlen(ovpn_cipher_name) + 2))
>>  {
>> -msg(M_WARN, "Length of --ncp-ciphers is over the "
>> +msg(M_WARN, "Length of --data-ciphers is over the "
>>  "limit of 127 chars");
>>  error_found = true;
>>  }
>>
> 
> Thanks. Patch looks good, and passes manual tests.
> 
> Acked-by: Steffan Karger 

NAK.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


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

2020-07-24 Thread David Sommerseth
On 24/07/2020 02:35, Selva Nair wrote:
>> Also route-pull works in both OpenVPN 2.x and 3.x
>> clients while pull-filter is currently 2.x only.
> 
> Actually pull-filter cannot be compared with route-nopull as the
> former is customizable. The real question is whether there is any
> compelling reason to use it other than lack of alternatives in 2.3 and
> older. I didn't know 3.x does not support pull-filter. Why? It's easy
> to code (at least I know that for sure) so that can't be the reason.

This is on our todo-list.  We want pull-filter in OpenVPN 3.  The filter
itself is simple to implement, just hasn't surfaced on the more critical
issues we've needed to tackle.

-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers

2020-07-23 Thread David Sommerseth
roper OpenVPN 3
compatibility as well.

And if we cannot remove any options during the eternal life time of OpenVPN, I
will see no other alternative to being even more critical and rejective to add
new options.  We already have pretty close to 300 options in OpenVPN.  That is
an insane amount - where a typical common OpenVPN setup might need up to 20 of
these options, the rest are for all kinds of special cases.  And we have
several competing solutions which are far simpler in many aspects which new
users might just as well prefer.

Even though I highlight the number of options we have, I do NOT say that we
should swipe them all out and reduce the amount to 50 or so; for some users
they have a _real_ value and provides really useful features.  But I want us
to save the options which do have a REAL value, not because unsupported
OpenVPN versions might break or "10 bytes extra source code" is too heavy to
carry around for an alias option.  I'm arguing for keeping options covering
_REAL_ USE CASE for users.  And no, breaking unsupported OpenVPN releases is
NOT a real use case from my point of view.

But back to the deprecated options  ... If we cannot remove options, we also
need to consider bringing back the --tls-remote option, and --compat-names -
both with the capability to break client configs (in fact, it already did for
several Fedora EPEL users [2]).  The proposal to remove --remote-nopull needs
to be reconsidered, as well as --secret, --max-routes, and possibly even
--ncp-disable.  Maybe even more of these deprecated options needs to be
reconsidered [3].


We really need a proper and sane processes to allow the development of OpenVPN
to have a chance to move on and leave things behind when appropriate, to be
able to evolve and grow with the future - without being strangled by what
existed in the far past (meaning: no longer community supported releases).
Otherwise I do fear for the future of OpenVPN 2.x.

By having a clear strategy and adhering to a process of feature/option
management in OpenVPN, we give clearly defined time-window for stability and
functionality for our users.  This predictability is, in my experience, much
more important to users than if a specifically named option is supported or not.



[0] <https://community.openvpn.net/openvpn/wiki/SupportedVersions>
[1] <https://community.openvpn.net/openvpn/wiki/FRP>
[2]
<https://src.fedoraproject.org/rpms/openvpn/c/c738486b3576df4829c9cef5ccd12c10c4fb7b84?branch=epel7>
[3] <https://community.openvpn.net/openvpn/wiki/DeprecatedOptions>


-- 
kind regards,

David Sommerseth
OpenVPN Inc



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


Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers

2020-07-22 Thread David Sommerseth
On 17/07/2020 15:47, Arne Schwabe wrote:
> The change in name signals that data-ciphers is the preferred way to
> configure data channel (and not --cipher). The data prefix is chosen
> to avoid ambiguity and make it distinct from tls-cipher for the TLS
> ciphers.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  Changes.rst| 13 ++---
>  doc/man-sections/protocol-options.rst  | 11 +++
>  doc/man-sections/server-options.rst|  4 ++--
>  sample/sample-config-files/client.conf |  2 +-
>  src/openvpn/multi.c|  4 ++--
>  src/openvpn/options.c  |  5 +++--
>  src/openvpn/ssl_ncp.c  |  4 ++--
>  7 files changed, 27 insertions(+), 16 deletions(-)
> 
[...snip...]
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 31e33ae3..896abcde 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -536,7 +536,7 @@ static const char usage_message[] =
>  "--cipher alg: Encrypt packets with cipher algorithm alg\n"
>  "  (default=%s).\n"
>  "  Set alg=none to disable encryption.\n"
> -"--ncp-ciphers list : List of ciphers that are allowed to be 
> negotiated.\n"
> +"--data-ciphers list : List of ciphers that are allowed to be 
> negotiated.\n"
>  "--ncp-disable   : (DEPRECATED) Disable cipher negotiation.\n"
>  "--prng alg [nsl] : For PRNG, use digest algorithm alg, and\n"
>  "   nonce_secret_len=nsl.  Set alg=none to disable 
> PRNG.\n"
> @@ -7866,7 +7866,8 @@ add_option(struct options *options,
>  VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
>  options->ciphername = p[1];
>  }
> -else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
> +else if ((streq(p[0], "data-ciphers") || streq(p[0], "ncp-ciphers"))
> +&& p[1] && !p[2])

I do agree to using --data-ciphers instead of --ncp-ciphers, that is far more
user-friendly naming of this feature.  NCP is a more technical
"under-the-hood" terminology which users don't really need to relate to, where
--data-ciphers better explains what it is used for.

But I do reject NOT adding a deprecation path for --ncp-ciphers.  We should
support --ncp-ciphers for 1-2 major releases, but after that it should be
removed.  We have too many options and we certainly should avoid duplicating
options with the exact same functionality.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] options: Remove --udp-mtu

2020-07-22 Thread David Sommerseth
On 22/07/2020 14:01, Arne Schwabe wrote:
> Am 22.07.20 um 11:54 schrieb David Sommerseth:
>> Before --link-mtu, it was --udp-mtu.  This was changed in
>> OpenVPN 1.5_beta1 (release July 2003).  It should be safe now
>> to remove --udp-mtu, the transition period should have been long
>> enough.
>>
>> Signed-off-by: David Sommerseth 
>> ---
>>  src/openvpn/options.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)

[...snip...]

>
> I close to sending a NAK to this. Normally we just don't outright remove
> options but rather warn for a version or two. But adding the warning
> code here and later removing the option just to remove the complexity of
> '|| streq(p[0], "udp-mtu"'?

I don't follow your logic, really.  But I won't fight this much.  My reasons
for removing this so easily are:

 -  This option has not been in any documentation since OpenVPN 2.0_beta,
released  in November 2004.

 -  It got superseded by --link-mtu in OpenVPN 1.5_beta1 (July 2003)

I would really like to see that configuration file being in active use on a
system today.  OpenVPN 1.x generation was plain P2P mode capable, OpenVPN 2.0
was the first release enabling multiple clients to the same server process.

> I don't see a compelling reason to remove alias option. Normally we
> deprecate options because they
> 
> - are considered harmful in some way (no-iv)
> - complicate the code without a clear gain
> - are replaced by a better mechanism and the old option does not
> trivally translate to the new option.
> - are features that we do no longer want to maintain and to remove them
> to decrease complexity (--enable-client-only)

That is right.  And all of that falls into the category of "code creep", where
the code grows and requires maintenance.

But I see this from the angle of "option creep", where we add options and
never really clean up.  Which is why we have started to deprecate options.
Deprecating options due to code creep is one aspect.  But never clean up
options which has been deprecated or superseded in one way or another is, in
my view, equally bad to not removing "code creep".

I do agree we normally would have a deprecation process going for all options.
 But the --udp-mtu option falls into a very special category; being deprecated
almost 17 years ago and being removed from the documentation almost 16 years
ago + being superceded in an OpenVPN release generation which introduced TCP
support - all of this more than 16 years ago.

Over the years I have also criticized introduction of new options, trying to
reuse existing options as much as possible and not introduce new ones without
a good reason [0].  Our options.c file tackles close to 300 options [1]; where
we have documented 275 of them in our man page.  This is also not good, from a
user's perspective.

We might need a lot of options to handle the flexibility of OpenVPN.  But we
should really strive to not have overlapping options active for too long, as
that is just driving things more complex for the users - without good reason.
 And we certainly should avoid having multiple options doing exactly the same
thing; this is acceptable to me only in a transition phase where we move to a
better construct.

[0] For example, I questioned why we needed --tls-crypt-v2 instead of
reusing --tls-crypt
[1] $ git grep 'streq(p\[0\],' -- src/openvpn/options.c | wc -l
[2] $ git grep -E "^--\w+" -- doc/man-sections/*.rst | wc -l


> But with alias I feel we just removing them because we found a newer
> nicer name and as a user (especially another dev) removing an alias
> feels like they are removed because of pride/principle that since they
> are old they must be go away. 

This is really not my motivation, I do reject this sentiment and implicitly
pointing it like that towards me.  Lets keep the discussion on the technical
side, not imply anything on the personal side.

What I do believe in is our role of maintaining this project.  Which means we
need to clean up.  Some clean-ups are big.  Some are small.  This patch is a
small one.  Some times we keep options, some times we kick some out, some
times we migrate them to better alternatives.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] options: Remove --udp-mtu

2020-07-22 Thread David Sommerseth
Before --link-mtu, it was --udp-mtu.  This was changed in
OpenVPN 1.5_beta1 (release July 2003).  It should be safe now
to remove --udp-mtu, the transition period should have been long
enough.

Signed-off-by: David Sommerseth 
---
 src/openvpn/options.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index b1962ca4..3ebf033d 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -3645,7 +3645,6 @@ calc_options_string_link_mtu(const struct options *o, 
const struct frame *frame)
  * --dev tun|tap [unit number need not match]
  * --dev-type tun|tap
  * --link-mtu
- * --udp-mtu
  * --tun-mtu
  * --proto udp
  * --proto tcp-client [matched with --proto tcp-server
@@ -6007,7 +6006,7 @@ add_option(struct options *options,
 goto err;
 }
 }
-else if ((streq(p[0], "link-mtu") || streq(p[0], "udp-mtu")) && p[1] && 
!p[2])
+else if (streq(p[0], "link-mtu") && p[1] && !p[2])
 {
 VERIFY_PERMISSION(OPT_P_MTU|OPT_P_CONNECTION);
 options->ce.link_mtu = positive_atoi(p[1]);
-- 
2.26.0



___
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

2020-07-21 Thread David Sommerseth
On 21/07/2020 12: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(-)
> 

This LGTM now.  Thanks for the updates and adjustments!

I've done light local build testing (applying just this patch on git master
commit 08469ca1eccc).  Builds fine, 'make check' looks good.

Acked-By: David Sommerseth 


-- 
kind regards,

David Sommerseth
OpenVPN Inc



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


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

2020-07-20 Thread David Sommerseth
On 20/07/2020 15:22, Arne Schwabe wrote:
> Am 20.07.20 um 15:16 schrieb David Sommerseth:
>> On 17/07/2020 15:47, 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.
>>>
>>> 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   | 230 
>>>  src/openvpn/ssl.h   |  19 +--
>>>  src/openvpn/ssl_common.h|   1 -
>>>  11 files changed, 42 insertions(+), 269 deletions(-)
>>
>> [...snip...]
>>
>>> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
>>> index 00b97352..4144217d 100644
>>> --- a/src/openvpn/ssl.c
>>> +++ b/src/openvpn/ssl.c
>>
>> [...snip...]
>>
>>> @@ -2225,52 +2205,6 @@ read_string_alloc(struct buffer *buf)
>>>  return str;
>>>  }
>>>  
>>> -/*
>>> - * Handle the reading and writing of key data to and from
>>> - * the TLS control channel (cleartext).
>>> - */
>>
>> Is it needed to remove this comment?  Or move it after the push_peer_info()
>> function?
> 
> Yeah, we can move the comment.

Yes, please ... Since it's not a bad comment, I don't like loosing helpful
pointers in comments :)

>>
>>> -static bool
>>> -key_method_1_write(struct buffer *buf, struct tls_session *session)
>>> -{
>> [...snip...]
>>> -}
>>> -
>>>  static bool
>>>  push_peer_info(struct buffer *buf, struct tls_session *session)
>>>  {
>>> @@ -2312,7 +2246,7 @@ push_peer_info(struct buffer *buf, struct tls_session 
>>> *session)
>>>   * 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)
>>> +if (session->opt->pull)
>>>  {
>>>  iv_proto |= IV_PROTO_REQUEST_PUSH;
>>>  }
>>> @@ -2394,7 +2328,6 @@ key_method_2_write(struct buffer *buf, struct 
>>> tls_session *session)
>>
>> [...snip...]
>>
>>> @@ -3470,14 +3316,12 @@ tls_pre_decrypt(struct tls_multi *multi,
>>>  }
>>>  
>>>  /* hard reset ? */
>>> -if (is_hard_reset(op, 0))
>>> +if (is_hard_reset_method2(op))
>>>  {
>>>  /* verify client -> server or server -> client connection 
>>> */
>>> -if (((op == P_CONTROL_HARD_RESET_CLIENT_V1
>>> -  || op == P_CONTROL_HARD_RESET_CLIENT_V2
>>> +if (((op == P_CONTROL_HARD_RESET_CLIENT_V2
>>>|| op == P_CONTROL_HARD_RESET_CLIENT_V3) && 
>>> !multi->opt.server)
>>> -|| ((op == P_CONTROL_HARD_RESET_SERVER_V1
>>> - || op == P_CONTROL_HARD_RESET_SERVER_V2) && 
>>> multi->opt.server))
>>> +|| ((op == P_CONTROL_HARD_RESET_SERVER_V2) && 
>>> multi->opt.server))
>>>  {
>>>  msg(D_TLS_ERRORS,
>>>  "TLS Error: client->client or server->server 
>>> connection attempted from %s",
>>> @@ -3542,19 +3386,11 @@ tls_pre_decrypt(struct tls_multi *multi,
>>>   * Initial packet received.
>>>   */
>>>  
>>> -if (i == TM_SIZE && is_hard_reset(op, 0))
>>> +if (i == TM_SIZE && is_hard_reset_method2(op))
>>>  {
>>>  struct tls_session *session = >session[TM_ACTIVE];
>>>  struct key_state *ks = >key[KS_PRIMARY];
>>>  
>>> -if (!is_hard_r

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

2020-07-20 Thread David Sommerseth
on *session, where one is referring to
TM_ACTIVE vs TM_UNTRUSTED.

>  {
>  /*
>   * No match with existing sessions,
> @@ -3614,14 +3450,6 @@ tls_pre_decrypt(struct tls_multi *multi,
>  goto error;
>  }
>  
> -if (!is_hard_reset(op, multi->opt.key_method))
> -{
> -msg(D_TLS_ERRORS, "TLS ERROR: new session local/remote 
> key_method mismatch, local key_method=%d, op=%s",
> -multi->opt.key_method,
> -packet_opcode_name(op));
> -goto error;
> -}
> -
>  if (!read_control_auth(buf, >tls_wrap, from,
>     session->opt))
>  {

I had already started my own approach of removing --key-method when I was made
aware of this patch.  Considering the size of it, my own barely tested changes
is about 90% similar to this patch.  But this patch has some improvements I
didn't consider in my work.

I've done a quick 'make check' as well, and it works fine.  There are just a
couple of minor things to consider, otherwise I will happily ACK this patch.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Remove --ifconfig-pool-linear

2020-07-20 Thread David Sommerseth
This option has been deprecated since OpenVPN 2.1 and it has been
highlighted in the documentation and log files since OpenVPN 2.4.4.

Signed-off-by: David Sommerseth 
---
 Changes.rst   | 3 +++
 src/openvpn/options.c | 9 -
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index a1d88a71..57823806 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -42,6 +42,9 @@ https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
   This option will now cause server configurations to not start.  Use
   ``--verify-client-cert none`` instead.
 
+- ``--ifconfig-pool-linear`` has been removed
+  This option is removed.  Use ``--topology p2p`` instead.
+
 User-visible Changes
 
 - If multiple connect handlers are used (client-connect, ccd, connect
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 5a81b0c2..be763cfb 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -426,9 +426,6 @@ static const char usage_message[] =
 "  client instance.\n"
 "--ifconfig-pool start-IP end-IP [netmask] : Set aside a pool of subnets\n"
 "  to be dynamically allocated to connecting clients.\n"
-"--ifconfig-pool-linear : (DEPRECATED) Use individual addresses rather \n"
-"  than /30 subnets\n in tun mode.  Not compatible with\n"
-"  Windows clients.\n"
 "--ifconfig-pool-persist file [seconds] : Persist/unpersist 
ifconfig-pool\n"
 "  data to file, at seconds intervals (default=600).\n"
 "  If seconds=0, file will be treated as read-only.\n"
@@ -6847,12 +6844,6 @@ add_option(struct options *options,
 options->ifconfig_pool_persist_refresh_freq = positive_atoi(p[2]);
 }
 }
-else if (streq(p[0], "ifconfig-pool-linear") && !p[1])
-{
-VERIFY_PERMISSION(OPT_P_GENERAL);
-options->topology = TOP_P2P;
-msg(M_WARN, "DEPRECATED OPTION: --ifconfig-pool-linear, use --topology 
p2p instead");
-}
 else if (streq(p[0], "ifconfig-ipv6-pool") && p[1] && !p[2])
 {
 const int lev = M_WARN;
-- 
2.26.0



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


[Openvpn-devel] [PATCH v2] Remove --client-cert-not-required

2020-07-20 Thread David Sommerseth
This removes support for the --client-cert-not-required option.  To
avoid starting a server with this option just ignored, which would make
it impossible for existing clients to connect it will exit with
instructions to replace this option with --verify-client-cert none.

Signed-off-by: David Sommerseth 

---

v2 - Include update to Changes.rst
---
 Changes.rst  | 4 
 src/openvpn/options.c| 9 +++--
 src/plugins/auth-pam/README.auth-pam | 2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 34abcd97..a1d88a71 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -38,6 +38,10 @@ https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
   This option was made into a NOOP option with OpenVPN 2.4.  This has now
   been completely removed.
 
+- ``--client-cert-not-required`` has been removed
+  This option will now cause server configurations to not start.  Use
+  ``--verify-client-cert none`` instead.
+
 User-visible Changes
 
 - If multiple connect handlers are used (client-connect, ccd, connect
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 1d9e5e5f..5a81b0c2 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -446,8 +446,6 @@ static const char usage_message[] =
 "  Only valid in a client-specific config file.\n"
 "--disable   : Client is disabled.\n"
 "  Only valid in a client-specific config file.\n"
-"--client-cert-not-required : (DEPRECATED) Don't require client 
certificate, client\n"
-"  will authenticate using username/password.\n"
 "--verify-client-cert [none|optional|require] : perform no, optional or\n"
 "  mandatory client certificate verification.\n"
 "  Default is to require the client to supply a 
certificate.\n"
@@ -2476,7 +2474,7 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 }
 if (options->ssl_flags & 
(SSLF_CLIENT_CERT_NOT_REQUIRED|SSLF_CLIENT_CERT_OPTIONAL))
 {
-msg(M_USAGE, "--client-cert-not-required and --verify-client-cert 
require --mode server");
+msg(M_USAGE, "--verify-client-cert require --mode server");
 }
 if (options->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME)
 {
@@ -2539,7 +2537,7 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 if (options->ssl_flags & 
(SSLF_CLIENT_CERT_NOT_REQUIRED|SSLF_CLIENT_CERT_OPTIONAL))
 {
 msg(M_WARN, "WARNING: POTENTIALLY DANGEROUS OPTION "
-"--verify-client-cert none|optional (or 
--client-cert-not-required) "
+"--verify-client-cert none|optional "
 "may accept clients which do not present a certificate");
 }
 
@@ -6935,8 +6933,7 @@ add_option(struct options *options,
 else if (streq(p[0], "client-cert-not-required") && !p[1])
 {
 VERIFY_PERMISSION(OPT_P_GENERAL);
-options->ssl_flags |= SSLF_CLIENT_CERT_NOT_REQUIRED;
-msg(M_WARN, "DEPRECATED OPTION: --client-cert-not-required, use 
--verify-client-cert instead");
+msg(M_FATAL, "REMOVED OPTION: --client-cert-not-required, use 
'--verify-client-cert none' instead");
 }
 else if (streq(p[0], "verify-client-cert") && !p[2])
 {
diff --git a/src/plugins/auth-pam/README.auth-pam 
b/src/plugins/auth-pam/README.auth-pam
index 64b3ace7..e3ca027e 100644
--- a/src/plugins/auth-pam/README.auth-pam
+++ b/src/plugins/auth-pam/README.auth-pam
@@ -60,7 +60,7 @@ is to be answered with the constant value "mydomain.com":
 The following OpenVPN directives can also influence
 the operation of this plugin:
 
-  client-cert-not-required
+  verify-client-cert none
   username-as-common-name
   static-challenge
 
-- 
2.26.0



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


[Openvpn-devel] [PATCH] Remove --client-cert-not-required

2020-07-20 Thread David Sommerseth
This removes support for the --client-cert-not-required option.  To
avoid starting a server with this option just ignored, which would make
it impossible for existing clients to connect it will exit with
instructions to replace this option with --verify-client-cert none.

Signed-off-by: David Sommerseth 
---
 src/openvpn/options.c| 9 +++--
 src/plugins/auth-pam/README.auth-pam | 2 +-
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index a81336f2..ae7b8586 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -446,8 +446,6 @@ static const char usage_message[] =
 "  Only valid in a client-specific config file.\n"
 "--disable   : Client is disabled.\n"
 "  Only valid in a client-specific config file.\n"
-"--client-cert-not-required : (DEPRECATED) Don't require client 
certificate, client\n"
-"  will authenticate using username/password.\n"
 "--verify-client-cert [none|optional|require] : perform no, optional or\n"
 "  mandatory client certificate verification.\n"
 "  Default is to require the client to supply a 
certificate.\n"
@@ -2479,7 +2477,7 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 }
 if (options->ssl_flags & 
(SSLF_CLIENT_CERT_NOT_REQUIRED|SSLF_CLIENT_CERT_OPTIONAL))
 {
-msg(M_USAGE, "--client-cert-not-required and --verify-client-cert 
require --mode server");
+msg(M_USAGE, "--verify-client-cert require --mode server");
 }
 if (options->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME)
 {
@@ -2552,7 +2550,7 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 if (options->ssl_flags & 
(SSLF_CLIENT_CERT_NOT_REQUIRED|SSLF_CLIENT_CERT_OPTIONAL))
 {
 msg(M_WARN, "WARNING: POTENTIALLY DANGEROUS OPTION "
-"--verify-client-cert none|optional (or 
--client-cert-not-required) "
+"--verify-client-cert none|optional "
 "may accept clients which do not present a certificate");
 }
 
@@ -6953,8 +6951,7 @@ add_option(struct options *options,
 else if (streq(p[0], "client-cert-not-required") && !p[1])
 {
 VERIFY_PERMISSION(OPT_P_GENERAL);
-options->ssl_flags |= SSLF_CLIENT_CERT_NOT_REQUIRED;
-msg(M_WARN, "DEPRECATED OPTION: --client-cert-not-required, use 
--verify-client-cert instead");
+msg(M_FATAL, "REMOVED OPTION: --client-cert-not-required, use 
'--verify-client-cert none' instead");
 }
 else if (streq(p[0], "verify-client-cert") && !p[2])
 {
diff --git a/src/plugins/auth-pam/README.auth-pam 
b/src/plugins/auth-pam/README.auth-pam
index 64b3ace7..e3ca027e 100644
--- a/src/plugins/auth-pam/README.auth-pam
+++ b/src/plugins/auth-pam/README.auth-pam
@@ -60,7 +60,7 @@ is to be answered with the constant value "mydomain.com":
 The following OpenVPN directives can also influence
 the operation of this plugin:
 
-  client-cert-not-required
+  verify-client-cert none
   username-as-common-name
   static-challenge
 
-- 
2.26.0



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


[Openvpn-devel] [PATCH] travis: Fix make distcheck failure

2020-07-20 Thread David Sommerseth
Since commit f500c49c8e0, the man page and html documentation need to be
generated when building out of the git repository, as both openvpn.8 and
openvpn.8.html will be shipped pregenerated inside the tarball generated
by 'make dist'.

Travis was lacking the python-docutils package, which made the
'make distcheck' build test fail.

Signed-off-by: David Sommerseth 
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 925d09ea..b154277e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -111,7 +111,7 @@ jobs:
 addons:
   apt:
 update: true
-packages: [ liblzo2-dev, libpam0g-dev, liblz4-dev, linux-libc-dev, 
man2html, mingw-w64, clang-9, libcmocka-dev ]
+packages: [ liblzo2-dev, libpam0g-dev, liblz4-dev, linux-libc-dev, 
man2html, mingw-w64, clang-9, libcmocka-dev, python3-docutils ]
   homebrew:
 update: true
 packages: [ lzo, lz4, cmocka ]
-- 
2.26.0



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


[Openvpn-devel] [PATCH] doc/man: Do not install man *.rst files

2020-07-19 Thread David Sommerseth
When the man page got split up into several .rst files, these files got
listed into dist_doc_DATA=.  This variable will both distribute (package
in the source tarball) and install these files into /usr/share/doc.
This was not intended, and it duplicates the content and makes the doc
dir quite messy.

By moving these files to dist_noinst_DATA= instead, these files are
still distributed but not installed via 'make install'.

Signed-off-by: David Sommerseth 
---
 doc/Makefile.am | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index add92198..340dd553 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -15,7 +15,11 @@ MAINTAINERCLEANFILES = \
 SUBDIRS = doxygen
 
 dist_doc_DATA = \
-   management-notes.txt openvpn.8.rst \
+   management-notes.txt
+
+dist_noinst_DATA = \
+   README.plugins interactive-service-notes.rst \
+   openvpn.8.rst \
man-sections/advanced-options.rst \
man-sections/client-options.rst \
man-sections/connection-profiles.rst \
@@ -41,9 +45,6 @@ dist_doc_DATA = \
man-sections/vpn-network-options.rst \
man-sections/windows-options.rst
 
-dist_noinst_DATA = \
-   README.plugins interactive-service-notes.rst
-
 openvpn.8 :
 if HAVE_PYDOCUTILS
$(RST2MAN) $(srcdir)/$@.rst > $@
-- 
2.26.0



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


Re: [Openvpn-devel] [PATCH] Merge Makefile.am's AUTOMAKE_OPTIONS into configure.ac's AM_INIT_AUTOMAKE.

2020-07-17 Thread David Sommerseth
On 17/07/2020 19:19, Matthias Andree wrote:
> Else one location overwrites options from the other.
> 
> Signed-off-by: Matthias Andree 
> ---
>  Makefile.am  | 3 ---
>  configure.ac | 4 +++-
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 439120e4..d1c10fc5 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,9 +23,6 @@
>  #  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>  #
> 
> -# This option prevents autoreconf from overriding our COPYING and
> -# INSTALL targets:
> -AUTOMAKE_OPTIONS = foreign 1.9
>  ACLOCAL_AMFLAGS = -I m4
> 
>  MAINTAINERCLEANFILES = \
> diff --git a/configure.ac b/configure.ac
> index 45148892..8ed83bc2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -54,7 +54,9 @@ m4_define([serial_tests], [
>  awk '{split ($NF,a,"."); if (a[1] == 1 && a[2] >= 12) { 
> print "serial-tests" }}'
>  ])
>  ])
> -AM_INIT_AUTOMAKE(foreign serial_tests) dnl NB: Do not [quote] this parameter.
> +# This foreign option prevents autoreconf from overriding our COPYING and
> +# INSTALL targets:
> +AM_INIT_AUTOMAKE(foreign serial_tests 1.9) dnl NB: Do not [quote] this 
> parameter.
>  AC_CANONICAL_HOST
>  AC_USE_SYSTEM_EXTENSIONS
> 

Acked-By: David Sommerseth 

This works better than the previous attempt, this also passes 'make distcheck'.

I see this patch does not have the subdir-objects flag in the automake
options; which seems to be the reason why it failed on my RHEL-7 box last
round.  I'll try to see if I can better understand why.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Remove --no-iv

2020-07-17 Thread David Sommerseth
This finializes the depreacation started in OpenVPN 2.4, where --no-iv
was made into a NOOP option.

Signed-off-by: David Sommerseth 
---
 Changes.rst  | 3 +++
 doc/man-sections/server-options.rst  | 2 +-
 doc/man-sections/unsupported-options.rst | 2 +-
 src/openvpn/options.c| 5 -
 4 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index e279d360..7d4fdec6 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -39,6 +39,9 @@ https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
 adds a security weakness.  This was also highlighted during the
 `OpenVPN 2.4 security audit 
<https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits#OVPN-03-3:Insecureconfigurationoptions:--no-replay>`_.
 
+- ``no-iv`` has been removed
+  This option was made into a NOOP option with OpenVPN 2.4.  This has now
+  been completely removed.
 
 Overview of changes in 2.4
 ==
diff --git a/doc/man-sections/server-options.rst 
b/doc/man-sections/server-options.rst
index 2381f5c8..75d174ea 100644
--- a/doc/man-sections/server-options.rst
+++ b/doc/man-sections/server-options.rst
@@ -399,7 +399,7 @@ fast hardware. SSL/TLS authentication must be used in this 
mode.
   ``link-mtu``, ``tun-mtu``, ``proto``, ``ifconfig``,
   ``comp-lzo``, ``fragment``, ``keydir``, ``cipher``,
   ``auth``, ``keysize``, ``secret``,
-  ``no-iv``, ``tls-auth``, ``key-method``, ``tls-server``
+  ``tls-auth``, ``key-method``, ``tls-server``
   and ``tls-client``.
 
   This option requires that ``--disable-occ`` NOT be used.
diff --git a/doc/man-sections/unsupported-options.rst 
b/doc/man-sections/unsupported-options.rst
index 8aff5dd9..05ba3ca2 100644
--- a/doc/man-sections/unsupported-options.rst
+++ b/doc/man-sections/unsupported-options.rst
@@ -19,7 +19,7 @@ longer supported
 
 --no-iv
   Removed in OpenVPN 2.5.  This option should not be used as it weakens the
-  VPN tunnel security.
+  VPN tunnel security.  This has been a NOOP option since OpenVPN 2.4.
 
 --no-replay
   Removed in OpenVPN 2.5.  This option should not be used as it weakens the
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index e1658472..0f0b37d1 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -7985,11 +7985,6 @@ add_option(struct options *options,
 VERIFY_PERMISSION(OPT_P_GENERAL);
 options->mute_replay_warnings = true;
 }
-else if (streq(p[0], "no-iv") && !p[1])
-{
-msg(msglevel,
-"--no-iv is no longer supported. Remove it from client and server 
configs.");
-}
 else if (streq(p[0], "replay-persist") && p[1] && !p[2])
 {
 VERIFY_PERMISSION(OPT_P_GENERAL);
-- 
2.26.0



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


[Openvpn-devel] [PATCH] Remove --no-replay

2020-07-17 Thread David Sommerseth
The --no-replay feature is considered to be a security weakness, which
was also highlighed during the OpenVPN 2.4 security audit [0].  This
option was added to the DeprecatedOptions[1] list and has been reported
as deprecated since OpenVPN 2.4.

Now we remove it.

URL: [0] 
https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits#OVPN-03-3:Insecureconfigurationoptions:--no-replay
URL: [1] 
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--no-replay
Signed-off-by: David Sommerseth 
---
 Changes.rst |  5 
 doc/man-sections/link-options.rst   |  3 +--
 doc/man-sections/server-options.rst |  2 +-
 src/openvpn/crypto.c| 21 ++--
 src/openvpn/crypto.h|  5 +---
 src/openvpn/init.c  | 38 +
 src/openvpn/options.c   | 25 +--
 src/openvpn/options.h   |  1 -
 src/openvpn/ssl.c   | 13 --
 src/openvpn/ssl_common.h|  1 -
 10 files changed, 27 insertions(+), 87 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 18b03e47..e279d360 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -34,6 +34,11 @@ https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
 With the improved and matured data channel cipher negotiation, the use
 of ``ncp-disable`` should not be necessary anymore.
 
+- ``-no-replay`` has been removed
+This has been listed as a deprecated option since OpenVPN 2.4 and
+adds a security weakness.  This was also highlighted during the
+`OpenVPN 2.4 security audit 
<https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAudits#OVPN-03-3:Insecureconfigurationoptions:--no-replay>`_.
+
 
 Overview of changes in 2.4
 ==
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index c132a623..a4239644 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -311,8 +311,7 @@ the local and the remote host.
   order they were received to the TCP/IP protocol stack, provided they
   satisfy several constraints.
 
-  (a)   The packet cannot be a replay (unless ``--no-replay`` is
-specified, which disables replay protection altogether).
+  (a)   The packet cannot be a replay.
 
   (b)   If a packet arrives out of order, it will only be accepted if
 the difference between its sequence number and the highest sequence
diff --git a/doc/man-sections/server-options.rst 
b/doc/man-sections/server-options.rst
index c24aec0b..2381f5c8 100644
--- a/doc/man-sections/server-options.rst
+++ b/doc/man-sections/server-options.rst
@@ -398,7 +398,7 @@ fast hardware. SSL/TLS authentication must be used in this 
mode.
   Options that will be compared for compatibility include ``dev-type``,
   ``link-mtu``, ``tun-mtu``, ``proto``, ``ifconfig``,
   ``comp-lzo``, ``fragment``, ``keydir``, ``cipher``,
-  ``auth``, ``keysize``, ``secret``, ``no-replay``,
+  ``auth``, ``keysize``, ``secret``,
   ``no-iv``, ``tls-auth``, ``key-method``, ``tls-server``
   and ``tls-client``.
 
diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index 1ce98184..58d7980a 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -340,7 +340,7 @@ crypto_check_replay(struct crypto_options *opt,
 if (!(opt->flags & CO_MUTE_REPLAY_WARNINGS))
 {
 msg(D_REPLAY_ERRORS, "%s: bad packet ID (may be a replay): %s -- "
-"see the man page entry for --no-replay and --replay-window 
for "
+"see the man page entry for --replay-window for "
 "more info or silence this warning with 
--mute-replay-warnings",
 error_prefix, packet_id_net_print(pin, true, gc));
 }
@@ -697,15 +697,9 @@ openvpn_decrypt(struct buffer *buf, struct buffer work,
 void
 crypto_adjust_frame_parameters(struct frame *frame,
const struct key_type *kt,
-   bool packet_id,
bool packet_id_long_form)
 {
-unsigned int crypto_overhead = 0;
-
-if (packet_id)
-{
-crypto_overhead += packet_id_size(packet_id_long_form);
-}
+unsigned int crypto_overhead = packet_id_size(packet_id_long_form);
 
 if (kt->cipher)
 {
@@ -1013,17 +1007,6 @@ fixup_key(struct key *key, const struct key_type *kt)
 gc_free();
 }
 
-void
-check_replay_consistency(const struct key_type *kt, bool packet_id)
-{
-ASSERT(kt);
-
-if (!packet_id && (cipher_kt_mode_ofb_cfb(kt->cipher)
-   || cipher_kt_mode_aead(kt->cipher)))
-{
-msg(M_FATAL, "--no-replay cannot be used with a CFB, OFB or AEAD mode 
cipher");
-}
-}
 
 /*
  * Generate a random key.  If key_type is provided, make
diff --git a/src/openvpn/crypto.h b/src/openvpn/crypt

Re: [Openvpn-devel] [PATCH 2/2] Permit make dist* targets without py*-docutils

2020-07-17 Thread David Sommerseth
On 17/07/2020 17:36, David Sommerseth wrote:
> On 17/07/2020 17:05, Matthias Andree wrote:
>> Signed-off-by: Matthias Andree 
>> ---
>>  doc/Makefile.am | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/Makefile.am b/doc/Makefile.am
>> index add92198..80cb2cb8 100644
>> --- a/doc/Makefile.am
>> +++ b/doc/Makefile.am
>> @@ -59,8 +59,9 @@ else
>>  endif
>>
>>  if HAVE_PYDOCUTILS
>> -dist_noinst_DATA += openvpn.8
>> -dist_html_DATA = openvpn.8.html
>> +nodist_noinst_DATA = openvpn.8
>> +nodist_html_DATA = openvpn.8.html
>> +EXTRA_DIST = openvpn.8 $(nodist_html_DATA)
>>
>>  # Failsafe - do not delete these files unless we can recreate them
>>  CLEANFILES = \
> 
> 
> Thanks!  This fixes the 'make distdir', which should also fix the 'make check'
> issues Gert found [1].
> 
> Acked-By: David Sommerseth 
> 
> 
> [1] Message-Id: 20200717131607.gs1...@greenie.muc.de
> 
> <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20436.html>
So I'm just retracting the Acked-By ... as this isn't needed.

We were just confused by some failing tests on one of the buildslaves and
realised to late it failed with 'make dist' - not 'make check'.  And then this
change makes things worse by not distributing generated man/html files if
py-docutils is not present.

All the 'make dist*' targets _should_ fail if py-docutils is not present and
the doc/openvpn.8 and doc/openvpn.8.html files are missing.  Running 'make
check' should not fail in any if these cases.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/2] Automake options: add subdir-objects, and clean up

2020-07-17 Thread David Sommerseth
On 17/07/2020 17:05, Matthias Andree wrote:
> diff --git a/Makefile.am b/Makefile.am
> index 439120e4..e4125447 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -25,7 +25,6 @@
> 
>  # This option prevents autoreconf from overriding our COPYING and
>  # INSTALL targets:
> -AUTOMAKE_OPTIONS = foreign 1.9
>  ACLOCAL_AMFLAGS = -I m4
> 
>  MAINTAINERCLEANFILES = \
> diff --git a/configure.ac b/configure.ac
> index 45148892..9d6510ca 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -54,7 +54,7 @@ m4_define([serial_tests], [
>  awk '{split ($NF,a,"."); if (a[1] == 1 && a[2] >= 12) { 
> print "serial-tests" }}'
>  ])
>  ])
> -AM_INIT_AUTOMAKE(foreign serial_tests) dnl NB: Do not [quote] this parameter.
> +AM_INIT_AUTOMAKE(foreign serial_tests subdir-objects 1.9) dnl NB: Do not 
> [quote] this parameter.
>  AC_CANONICAL_HOST
>  AC_USE_SYSTEM_EXTENSIONS

This looks trivial, but I'll have to NAK it in the current shape.  It breaks 
building on at least RHEL-7.

When applying this patch, this happens:

Making all in openvpnmsica
make[3]: Entering directory 
`/home/davids/devel/OpenVPN/openvpn/src/openvpnmsica'
Makefile:548: ../../src/tapctl/.deps/libopenvpnmsica_la-error.Plo: No such file 
or directory
Makefile:549: ../../src/tapctl/.deps/libopenvpnmsica_la-tap.Plo: No such file 
or directory
make[3]: *** No rule to make target 
`../../src/tapctl/.deps/libopenvpnmsica_la-tap.Plo'.  Stop.
make[3]: Leaving directory `/home/davids/devel/OpenVPN/openvpn/src/openvpnmsica'

This needs more work to avoid this issue.  It's also interesting that Windows
code is suddenly being pulled into the dependency tracking on a plain Linux
box.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 2/2] Permit make dist* targets without py*-docutils

2020-07-17 Thread David Sommerseth
On 17/07/2020 17:05, Matthias Andree wrote:
> Signed-off-by: Matthias Andree 
> ---
>  doc/Makefile.am | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index add92198..80cb2cb8 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -59,8 +59,9 @@ else
>  endif
> 
>  if HAVE_PYDOCUTILS
> -dist_noinst_DATA += openvpn.8
> -dist_html_DATA = openvpn.8.html
> +nodist_noinst_DATA = openvpn.8
> +nodist_html_DATA = openvpn.8.html
> +EXTRA_DIST = openvpn.8 $(nodist_html_DATA)
> 
>  # Failsafe - do not delete these files unless we can recreate them
>  CLEANFILES = \


Thanks!  This fixes the 'make distdir', which should also fix the 'make check'
issues Gert found [1].

Acked-By: David Sommerseth 


[1] Message-Id: 20200717131607.gs1...@greenie.muc.de

<https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20436.html>


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Convert cc_check_return to switch/case

2020-07-17 Thread David Sommerseth
On 17/07/2020 13:29, Arne Schwabe wrote:
> The return false/return true is the result of
> running uncrustify.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/multi.c | 24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 97b7df16..1fdf6ce5 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -2229,22 +2229,16 @@ static inline bool
>  cc_check_return(int *cc_succeeded_count,
>  enum client_connect_return ret)
>  {
> -if (ret == CC_RET_SUCCEEDED)
> +switch (ret)
>  {
> -(*cc_succeeded_count)++;
> -return true;
> -}
> -else if (ret == CC_RET_FAILED)
> -{
> -return false;
> -}
> -else if (ret == CC_RET_SKIPPED)
> -{
> -return true;
> -}
> -else
> -{
> -ASSERT(0);
> +case CC_RET_SUCCEEDED: (*cc_succeeded_count)++;
> +return true;
> +
> +case CC_RET_FAILED: return false;
> +
> +case CC_RET_SKIPPED: return true;
> +
> +default: ASSERT(0);

Code style police  Even though it is not clearly defined, but based on the
example here
<https://community.openvpn.net/openvpn/wiki/CodeStyle#Casesinaswitchstatementshouldbreakorexplicitlyfallthrough>
...

... it should be more like:

   switch (ret)
   {
case CC_RET_SUCCEEDED:
(*cc_succeeded_count)++;
return true;

case CC_RET_FAILED:
return false;

case CC_RET_SKIPPED:
    return true;

    default:
ASSERT(0);
   }


I generally find this approach more readable.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] doc/man: Add misssing renegotiation.rst to Makefile.am

2020-07-17 Thread David Sommerseth
This file did not get added to Makefile.am by a mistake during the
man-page overhaul, and the issue this causes is not easily spotted.

If a consumer of a tarball (created with 'make dist' from the git
tree) tries runs 'make clean' and 'make dist' plus have
python-docutils installed from such a tarball, it will explode and
complain about this missing file.

Signed-off-by: David Sommerseth 
---
 doc/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/Makefile.am b/doc/Makefile.am
index a1ac02f6..add92198 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -31,6 +31,7 @@ dist_doc_DATA = \
man-sections/plugin-options.rst \
man-sections/protocol-options.rst \
man-sections/proxy-options.rst \
+   man-sections/renegotiation.rst \
man-sections/signals.rst \
man-sections/script-options.rst \
man-sections/server-options.rst \
-- 
2.26.0



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


[Openvpn-devel] [PATCH] doc/man: Documentation for --bind-dev / VRFs on Linux

2020-07-17 Thread David Sommerseth
Signed-off-by: Maximilian Wilhelm 
Signed-off-by: David Sommerseth 

---

v2 - Added missing entry into Makefile.am
---
 doc/Makefile.am   |  1 +
 doc/man-sections/network-config.rst   |  1 +
 .../virtual-routing-and-forwarding.rst| 78 +++
 doc/man-sections/vpn-network-options.rst  |  4 +
 4 files changed, 84 insertions(+)
 create mode 100644 doc/man-sections/virtual-routing-and-forwarding.rst

diff --git a/doc/Makefile.am b/doc/Makefile.am
index ca3ba9de..a1ac02f6 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -36,6 +36,7 @@ dist_doc_DATA = \
man-sections/server-options.rst \
man-sections/tls-options.rst \
man-sections/unsupported-options.rst \
+   man-sections/virtual-routing-and-forwarding.rst \
man-sections/vpn-network-options.rst \
man-sections/windows-options.rst
 
diff --git a/doc/man-sections/network-config.rst 
b/doc/man-sections/network-config.rst
index 12a6e960..04b30aa3 100644
--- a/doc/man-sections/network-config.rst
+++ b/doc/man-sections/network-config.rst
@@ -7,3 +7,4 @@ network adapter* (tun/tap device).
 
 .. include:: link-options.rst
 .. include:: vpn-network-options.rst
+.. include:: virtual-routing-and-forwarding.rst
diff --git a/doc/man-sections/virtual-routing-and-forwarding.rst 
b/doc/man-sections/virtual-routing-and-forwarding.rst
new file mode 100644
index ..28c13eee
--- /dev/null
+++ b/doc/man-sections/virtual-routing-and-forwarding.rst
@@ -0,0 +1,78 @@
+Virtual Routing and Forwarding
+--
+
+Options in this section relates to configuration of virtual routing and
+forwarding in combination with the underlying operating system.
+
+As of today this is only supported on Linux, a kernel >= 4.9 is
+recommended.
+
+This could come in handy when for example the external network should be
+only used as a means to connect to some VPN endpoints and all regular
+traffic should only be routed through any tunnel(s).  This could be
+achieved by setting up a VRF and configuring the interface connected to
+the external network to be part of the VRF. The examples below will cover
+this setup.
+
+Another option would be to put the tun/tap interface into a VRF. This could
+be done by an up-script which uses the :code:`ip link set` command shown
+below.
+
+
+VRF setup with iproute2
+```
+
+Create VRF :code:`vrf_external` and map it to routing table :code:`1023`
+::
+
+  ip link add vrf_external type vrf table 1023
+
+Move :code:`eth0` into :code:`vrf_external`
+::
+
+  ip link set master vrf_external dev eth0
+
+Any prefixes configured on :code:`eth0` will be moved from the :code`main`
+routing table into routing table `1023`
+
+
+VRF setup with ifupdown
+```
+
+For Debian based Distributions :code:`ifupdown2` provides an almost drop-in
+replacement for :code:`ifupdown` including VRFs and other features.
+A configuration for an interface :code:`eth0` being part of VRF
+code:`vrf_external` could look like this:
+::
+
+  auto eth0
+  iface eth0
+  address 192.0.2.42/24
+  address 2001:db8:08:15::42/64
+  gateway 192.0.2.1
+  gateway 2001:db8:08:15::1
+  vrf vrf_external
+
+  auto vrf_external
+  iface vrf_external
+  vrf-table 1023
+
+
+OpenVPN configuration
+`
+The OpenVPN configuration needs to contain this line:
+::
+
+  bind-dev vrf_external
+
+
+Further reading
+```
+
+Wikipedia has nice page one VRFs: 
https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding
+
+This talk from the Network Track of FrOSCon 2018 provides an overview about
+advanced layer 2 and layer 3 features of Linux
+
+  - Slides: 
https://www.slideshare.net/BarbarossaTM/l2l3-fr-fortgeschrittene-helle-und-dunkle-magie-im-linuxnetzwerkstack
+  - Video (german): 
https://media.ccc.de/v/froscon2018-2247-l2\_l3\_fur\_fortgeschrittene\_-\_helle\_und\_dunkle\_magie\_im\_linux-netzwerkstack
diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index 78c00674..7100c1ae 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -5,6 +5,10 @@ Options in this section relates to configuration of the 
virtual tun/tap
 network interface, including setting the VPN IP address and network
 routing.
 
+--bind-dev device
+  (Linux only) Set ``device`` to bind the server socket to a
+  `Virtual Routing and Forwarding`_ device
+
 --block-ipv6
   On the client, instead of sending IPv6 packets over the VPN tunnel, all
   IPv6 packets are answered with an ICMPv6 no route host message. On the
-- 
2.26.0



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


Re: [Openvpn-devel] [PATCH applied] Re: doc/man: Replace old man page with generated man page

2020-07-17 Thread David Sommerseth
On 17/07/2020 10:02, Gert Doering wrote:
> Acked-by: Gert Doering 
> 
> I have not tested the actual docutils / openvpn.8 generation (Samuli will 
> complain loudly if tarball making doesn't work anymore, so that *will* 
> see testing).  Generally it looks sane.
> 
> This condition looks a bit fishy, though...
> 
>  +AM_CONDITIONAL([HAVE_PYDOCUTILS], [test "${RST2MAN}" -a "${RST2HTML}"])
> 
> not sure what that will do in a POSIX shell.

Hmm ... whoops.  That should probably have been

test -n "${RST2MAN}" -a -n "${RST2HTML}"

Not sure how that passed during my own tests.  I tested it on a various of
boxes, but I only have Linux distros easily available.

> Maybe this shouldn't be conditional either
> 
>  +if HAVE_PYDOCUTILS
>   dist_noinst_DATA += openvpn.8
> 
> because it will lead to "tarballs randomly contain openvpn.8 or not, 
> depending on whether docutils are around" - "make dist" should behave
> consistently, and if there are no docutils, I think it should fail, not
> silently leave out files.

The intention is that the tarball contains prebuilt openvpn.8 and openvpn.html
files, which is generated by "make {dist,distcheck}".  If these files exists,
they will not be rebuilt unless explicitly removed.  So most users building
from the source tarball should not notice any difference from prioer OpenVPN
releases.  This is what the additional dist-hook rule in doc/Makefile.am does;
this is run right before the copied source tree is put into a tarball.

The challenge is that it must be a conditional to actually pass ./configure -
even when built from source tarballs.  Otherwise python-docutils will be a
build dependency.  We discussed this at the Trento Hackathon and you where
skeptic to require a Python stack to be installed to build OpenVPN (as that
stack is not a common system dependency in the non-Linux world).  So we agreed
we will ship pre-built man/html files in the source tarballs.

However, to do the "make {dist,distcheck}" from the *git repo*,
python-docutils need to be a mandatory dependency - because we don't check in
the prebuilt openvpn.8 and openvpn.html files into the git repo.

This logic could probably contains some flaws and can be further improved, but
I figured we need to get this tested on a broader set of use cases and
OS/distros to better see which annoyances which hits us.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v2 5/8] doc/man: Mark compression options as deprecated

2020-07-16 Thread David Sommerseth
Due to the VORACLE attack vector, compression in general is deprecated.
Make this clear in the man page.

Also remove an incorrect statement claiming --compress lzo is compatible
with --comp-lzo.  It is not, as --compress lzo uses a different
compression framing than --comp-lzo.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/protocol-options.rst | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index ae85a25e..a5a1253a 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -60,9 +60,7 @@ configured in a compatible way between both the local and 
remote side.
 
   The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`, or empty.
   LZO and LZ4 are different compression algorithms, with LZ4 generally
-  offering the best performance with least CPU usage. For backwards
-  compatibility with OpenVPN versions before v2.4, use :code:`lzo` (which
-  is identical to the older option ``--comp-lzo yes``).
+  offering the best performance with least CPU usage.
 
   If the ``algorithm`` parameter is empty, compression will be turned off,
   but the packet framing for compression will still be enabled, allowing a
@@ -79,8 +77,9 @@ configured in a compatible way between both the local and 
remote side.
   *not* enable compression.
 
 --comp-lzo mode
-  *DEPRECATED* This option will be removed in a future OpenVPN release.
-  Use the newer ``--compress`` instead.
+  **DEPRECATED** Enable LZO compression algorithm.  Compression is
+  generally not recommended.  VPN tunnels which uses compression are
+  suspectible to the VORALCE attack vector.
 
   Use LZO compression -- may add up to 1 byte per packet for incompressible
   data. ``mode`` may be :code:`yes`, :code:`no`, or :code:`adaptive`
@@ -106,9 +105,9 @@ configured in a compatible way between both the local and 
remote side.
   link, the second sets the client side.
 
 --comp-noadapt
-  When used in conjunction with ``--comp-lzo``, this option will disable
-  OpenVPN's adaptive compression algorithm. Normally, adaptive compression
-  is enabled with ``--comp-lzo``.
+  **DEPRECATED** When used in conjunction with ``--comp-lzo``, this option
+  will disable OpenVPN's adaptive compression algorithm. Normally, adaptive
+  compression is enabled with ``--comp-lzo``.
 
   Adaptive compression tries to optimize the case where you have
   compression enabled, but you are sending predominantly incompressible
-- 
2.26.0



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


[Openvpn-devel] [PATCH v2 7/8] doc/man: Update --txqueuelen default setting (Now OS default)

2020-07-16 Thread David Sommerseth
From: Richard Bonhomme 

Signed-off-by: Richard Bonhomme 
Signed-off-by: David Sommerseth 
---
 doc/man-sections/advanced-options.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/man-sections/advanced-options.rst 
b/doc/man-sections/advanced-options.rst
index dbf7799c..9b96e406 100644
--- a/doc/man-sections/advanced-options.rst
+++ b/doc/man-sections/advanced-options.rst
@@ -103,5 +103,5 @@ used when debugging or testing out special usage scenarios.
 
 --txqueuelen n
   *(Linux only)* Set the TX queue length on the TUN/TAP interface.
-  Currently defaults to 100.
+  Currently defaults to operating system default.
 
-- 
2.26.0



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


[Openvpn-devel] [PATCH v2 6/8] doc/man: Adopt compression documentation

2020-07-16 Thread David Sommerseth
Commit c67e93b25208be2 updated the man page in reagrds to new
compression options and improving existing compression options.  This
adopts those changes into the .rst format.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/protocol-options.rst | 52 ++-
 1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index a5a1253a..d7bcbb98 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -5,6 +5,31 @@ protocol.  Many of these options also define the encryption 
options
 of the data channel in the OpenVPN wire protocol.  These options must be
 configured in a compatible way between both the local and remote side.
 
+--allow-compression mode
+  As described in the ``--compress`` option, compression is a potentially
+  dangerous option.  This option allows controlling the behaviour of
+  OpenVPN when compression is used and allowed.
+
+  Valid syntaxes:
+  ::
+
+  allow-compression
+  allow-compression mode
+
+  The ``mode`` argument can be one of the following values:
+
+  :code:`asym`  (default)
+  OpenVPN will only *decompress downlink packets* but *not compress
+  uplink packets*.  This also allows migrating to disable compression
+  when changing both server and client configurations to remove
+  compression at the same time is not a feasible option.
+
+  :code:`no`
+  OpenVPN will refuse any non-stub compression.
+
+  :code:`yes`
+  OpenVPN will send and receive compressed packets.
+
 --auth alg
   Authenticate data channel packets and (if enabled) ``tls-auth`` control
   channel packets with HMAC using message digest algorithm ``alg``. (The
@@ -58,23 +83,32 @@ configured in a compatible way between both the local and 
remote side.
   not recommended.  VPN tunnels which use compression are susceptible to
   the VORALCE attack vector.
 
-  The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`, or empty.
+  The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`,
+  :code:`lz4-v2`, :code:`stub`, :code:`stub-v2` or empty.
   LZO and LZ4 are different compression algorithms, with LZ4 generally
   offering the best performance with least CPU usage.
 
-  If the ``algorithm`` parameter is empty, compression will be turned off,
-  but the packet framing for compression will still be enabled, allowing a
-  different setting to be pushed later.
+  The :code:`lz4-v2` and :code:`stub-v2` variants implement a better
+  framing that does not add overhead when packets cannot be compressed. All
+  other variants always add one extra framing byte compared to no
+  compression framing.
+
+  If the ``algorithm`` parameter is :code:`stub`, :code:`stub-v2` or empty,
+  compression will be turned off, but the packet framing for compression
+  will still be enabled, allowing a different setting to be pushed later.
+  Additionally, :code:`stub` and :code:`stub-v2` wil disable announcing
+  ``lzo`` and ``lz4`` compression support via *IV_* variables to the
+  server.
 
   ***Security Considerations***
 
   Compression and encryption is a tricky combination. If an attacker knows
-  or is able to control (parts of) the plaintext of packets that contain
+  or is able to control (parts of) the plain-text of packets that contain
   secrets, the attacker might be able to extract the secret if compression
-  is enabled. See e.g. the CRIME and BREACH attacks on TLS which also
-  leverage compression to break encryption. If you are not entirely sure
-  that the above does not apply to your traffic, you are advised to
-  *not* enable compression.
+  is enabled. See e.g. the *CRIME* and *BREACH* attacks on TLS and
+  *VORACLE* on VPNs which also leverage to break encryption. If you are not
+  entirely sure that the above does not apply to your traffic, you are
+  advised to *not* enable compression.
 
 --comp-lzo mode
   **DEPRECATED** Enable LZO compression algorithm.  Compression is
-- 
2.26.0



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


[Openvpn-devel] [PATCH v2 8/8] doc/man: Documentation for --bind-dev / VRFs on Linux

2020-07-16 Thread David Sommerseth
Signed-off-by: Maximilian Wilhelm 
Signed-off-by: David Sommerseth 
---
 doc/man-sections/network-config.rst   |  1 +
 .../virtual-routing-and-forwarding.rst| 78 +++
 doc/man-sections/vpn-network-options.rst  |  4 +
 3 files changed, 83 insertions(+)
 create mode 100644 doc/man-sections/virtual-routing-and-forwarding.rst

diff --git a/doc/man-sections/network-config.rst 
b/doc/man-sections/network-config.rst
index 12a6e960..04b30aa3 100644
--- a/doc/man-sections/network-config.rst
+++ b/doc/man-sections/network-config.rst
@@ -7,3 +7,4 @@ network adapter* (tun/tap device).
 
 .. include:: link-options.rst
 .. include:: vpn-network-options.rst
+.. include:: virtual-routing-and-forwarding.rst
diff --git a/doc/man-sections/virtual-routing-and-forwarding.rst 
b/doc/man-sections/virtual-routing-and-forwarding.rst
new file mode 100644
index ..28c13eee
--- /dev/null
+++ b/doc/man-sections/virtual-routing-and-forwarding.rst
@@ -0,0 +1,78 @@
+Virtual Routing and Forwarding
+--
+
+Options in this section relates to configuration of virtual routing and
+forwarding in combination with the underlying operating system.
+
+As of today this is only supported on Linux, a kernel >= 4.9 is
+recommended.
+
+This could come in handy when for example the external network should be
+only used as a means to connect to some VPN endpoints and all regular
+traffic should only be routed through any tunnel(s).  This could be
+achieved by setting up a VRF and configuring the interface connected to
+the external network to be part of the VRF. The examples below will cover
+this setup.
+
+Another option would be to put the tun/tap interface into a VRF. This could
+be done by an up-script which uses the :code:`ip link set` command shown
+below.
+
+
+VRF setup with iproute2
+```
+
+Create VRF :code:`vrf_external` and map it to routing table :code:`1023`
+::
+
+  ip link add vrf_external type vrf table 1023
+
+Move :code:`eth0` into :code:`vrf_external`
+::
+
+  ip link set master vrf_external dev eth0
+
+Any prefixes configured on :code:`eth0` will be moved from the :code`main`
+routing table into routing table `1023`
+
+
+VRF setup with ifupdown
+```
+
+For Debian based Distributions :code:`ifupdown2` provides an almost drop-in
+replacement for :code:`ifupdown` including VRFs and other features.
+A configuration for an interface :code:`eth0` being part of VRF
+code:`vrf_external` could look like this:
+::
+
+  auto eth0
+  iface eth0
+  address 192.0.2.42/24
+  address 2001:db8:08:15::42/64
+  gateway 192.0.2.1
+  gateway 2001:db8:08:15::1
+  vrf vrf_external
+
+  auto vrf_external
+  iface vrf_external
+  vrf-table 1023
+
+
+OpenVPN configuration
+`
+The OpenVPN configuration needs to contain this line:
+::
+
+  bind-dev vrf_external
+
+
+Further reading
+```
+
+Wikipedia has nice page one VRFs: 
https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding
+
+This talk from the Network Track of FrOSCon 2018 provides an overview about
+advanced layer 2 and layer 3 features of Linux
+
+  - Slides: 
https://www.slideshare.net/BarbarossaTM/l2l3-fr-fortgeschrittene-helle-und-dunkle-magie-im-linuxnetzwerkstack
+  - Video (german): 
https://media.ccc.de/v/froscon2018-2247-l2\_l3\_fur\_fortgeschrittene\_-\_helle\_und\_dunkle\_magie\_im\_linux-netzwerkstack
diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index 894df367..2a587c63 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -5,6 +5,10 @@ Options in this section relates to configuration of the 
virtual tun/tap
 network interface, including setting the VPN IP address and network
 routing.
 
+--bind-dev device
+  (Linux only) Set ``device`` to bind the server socket to a
+  `Virtual Routing and Forwarding`_ device
+
 --block-ipv6
   On the client, instead of sending IPv6 packets over the VPN tunnel, all
   IPv6 packets are answered with an ICMPv6 no route host message. On the
-- 
2.26.0



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


[Openvpn-devel] [PATCH v2 0/8] man-page overhaul project - round 2

2020-07-16 Thread David Sommerseth
Hi,

In the community meeting 2020-07-16, it was agreed to try to squash
several commits and reduce the number of patches.  In addition to
split up the biggest patch into two parts to try to sneak everything
into the mailing list without sending too large patches.

I've kept a few changes separate, as they are not strictly tied to
this overhaul but these changes are important to get included.

Richard Bonhomme has also contributed with a lot of language
improvements which now has been squashed into one of these commits
below.  Unfortunately this squashing removed him as the author of
that commit, but I wanted to be sure he gets the proper credit somehow.


kind regards,

David Sommerseth
OpenVPN Inc




David Sommerseth (7):
  doc/man: Add an .rst formatted version of the man page
  doc/man: Replace old man page with generated man page
  doc/man: Split up and reorganize main man page
  doc/man: Complete openvpn.8.rst splitting
  doc/man: Mark compression options as deprecated
  doc/man: Adopt compression documentation
  doc/man: Documentation for --bind-dev / VRFs on Linux

Richard Bonhomme (1):
  doc/man: Update --txqueuelen default setting (Now OS default)

 .gitignore|1 +
 INSTALL   |3 +-
 configure.ac  |   15 +-
 doc/Makefile.am   |   56 +-
 doc/README.man|   23 +
 doc/man-sections/advanced-options.rst |  107 +
 doc/man-sections/client-options.rst   |  354 +
 doc/man-sections/connection-profiles.rst  |   75 +
 doc/man-sections/encryption-options.rst   |  136 +
 doc/man-sections/examples.rst |  241 +
 doc/man-sections/generic-options.rst  |  436 +
 doc/man-sections/inline-files.rst |   25 +
 doc/man-sections/link-options.rst |  410 +
 doc/man-sections/log-options.rst  |   74 +
 doc/man-sections/management-options.rst   |  136 +
 doc/man-sections/network-config.rst   |   10 +
 doc/man-sections/pkcs11-options.rst   |   81 +
 doc/man-sections/plugin-options.rst   |   60 +
 doc/man-sections/protocol-options.rst |  262 +
 doc/man-sections/proxy-options.rst|   66 +
 doc/man-sections/renegotiation.rst|   53 +
 doc/man-sections/script-options.rst   |  807 ++
 doc/man-sections/server-options.rst   |  769 ++
 doc/man-sections/signals.rst  |   30 +
 doc/man-sections/tls-options.rst  |  643 ++
 doc/man-sections/unsupported-options.rst  |   33 +
 .../virtual-routing-and-forwarding.rst|   78 +
 doc/man-sections/vpn-network-options.rst  |  535 ++
 doc/man-sections/windows-options.rst  |  245 +
 doc/openvpn.8 | 7659 -
 doc/openvpn.8.rst |  169 +
 31 files changed, 5918 insertions(+), 7674 deletions(-)
 create mode 100644 doc/README.man
 create mode 100644 doc/man-sections/advanced-options.rst
 create mode 100644 doc/man-sections/client-options.rst
 create mode 100644 doc/man-sections/connection-profiles.rst
 create mode 100644 doc/man-sections/encryption-options.rst
 create mode 100644 doc/man-sections/examples.rst
 create mode 100644 doc/man-sections/generic-options.rst
 create mode 100644 doc/man-sections/inline-files.rst
 create mode 100644 doc/man-sections/link-options.rst
 create mode 100644 doc/man-sections/log-options.rst
 create mode 100644 doc/man-sections/management-options.rst
 create mode 100644 doc/man-sections/network-config.rst
 create mode 100644 doc/man-sections/pkcs11-options.rst
 create mode 100644 doc/man-sections/plugin-options.rst
 create mode 100644 doc/man-sections/protocol-options.rst
 create mode 100644 doc/man-sections/proxy-options.rst
 create mode 100644 doc/man-sections/renegotiation.rst
 create mode 100644 doc/man-sections/script-options.rst
 create mode 100644 doc/man-sections/server-options.rst
 create mode 100644 doc/man-sections/signals.rst
 create mode 100644 doc/man-sections/tls-options.rst
 create mode 100644 doc/man-sections/unsupported-options.rst
 create mode 100644 doc/man-sections/virtual-routing-and-forwarding.rst
 create mode 100644 doc/man-sections/vpn-network-options.rst
 create mode 100644 doc/man-sections/windows-options.rst
 delete mode 100644 doc/openvpn.8
 create mode 100644 doc/openvpn.8.rst

-- 
2.26.0



___
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

2020-07-16 Thread David Sommerseth
On 16/07/2020 23:07, Gert Doering wrote:
> Hi,
> 
> On Thu, Jul 16, 2020 at 11:04:09PM +0200, David Sommerseth wrote:
>> So I'm looking into migrating this text over to the new .rst format ... and I
>> have a question ...
> 
> This one *should* be identical to 6/6 from the "v7" series, but just for
> completeness - the "v5" series has been reworked completely and the 
> last 6 patches been resent as v7.
> 
> Doc patch is "v7 6/6" now, same subject otherwise.

Ahh, thanks!  Yeah, it looks like it's the same man page.  I suggest we don't
do anything with the man page in this patch-set (except of clarifying the
content) and I'll ensure it gets ported into a reasonable shape into the new
man page structure.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


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

2020-07-16 Thread David Sommerseth

So I'm looking into migrating this text over to the new .rst format ... and I
have a question ...

On 11/07/2020 11:36, Arne Schwabe wrote:
> 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
> +use the client_connect_deferred_file and client_connect_config_file
> +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

This part is oddly rendered, and it seems it lacks something ...

  * OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY and

plugin  hook  to  return  success/failure via
auth_control_file/client_connect_deferred_file
when using deferred auth method


Is this what you intended to say?

  * OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY plugin hook and
--client-connect scripts to return success/failure via
    auth_control_file/client_connect_deferred_file when using
deferred auth method

-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


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

2020-07-15 Thread David Sommerseth
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 attempt to connect against.  But there are some configuration
 options which are related to specific ``--remote`` options.  For these
-use cases, connection profiles is the solution.
+use cases, connection profiles are the solution.
 
 By enacpulating the ``--remote`` option and related options within
  and , these options are handled as a
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

[Openvpn-devel] [PATCH 10/16] doc/man: Moved --reneg-* options to its own section

2020-07-15 Thread David Sommerseth
The options related to renegotiation of the data channel encryption key
is not really a link option.  As the renegotiation is encryption
related but doesn't really fit into the generic, tls or pkcs11 sections,
add it into its own section.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/encryption-options.rst |  1 +
 doc/man-sections/link-options.rst   | 47 --
 doc/man-sections/renegotiation.rst  | 53 +
 3 files changed, 54 insertions(+), 47 deletions(-)
 create mode 100644 doc/man-sections/renegotiation.rst

diff --git a/doc/man-sections/encryption-options.rst 
b/doc/man-sections/encryption-options.rst
index 5e99c52f..42c80eb8 100644
--- a/doc/man-sections/encryption-options.rst
+++ b/doc/man-sections/encryption-options.rst
@@ -130,6 +130,7 @@ Generating key material
access to this file will be to generate auth tokens that the OpenVPN
server will accept as valid.
 
+.. include:: renegotiation.rst
 .. include:: tls-options.rst
 .. include:: pkcs11-options.rst
 
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index 5f75c5f3..43e33176 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -284,53 +284,6 @@ the local and the remote host.
   and has been used since version 2.0-beta17. Previous versions used port
   5000 as the default.
 
---reneg-bytes n
-  Renegotiate data channel key after ``n`` bytes sent or received
-  (disabled by default with an exception, see below). OpenVPN allows the
-  lifetime of a key to be expressed as a number of bytes
-  encrypted/decrypted, a number of packets, or a number of seconds. A key
-  renegotiation will be forced if any of these three criteria are met by
-  either peer.
-
-  If using ciphers with cipher block sizes less than 128-bits,
-  ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly
-  disabled by setting the value to :code:`0`, but this is
-  **HIGHLY DISCOURAGED** as this is designed to add some protection against
-  the SWEET32 attack vector. For more information see the ``--cipher``
-  option.
-
---reneg-pkts n
-  Renegotiate data channel key after **n** packets sent and received
-  (disabled by default).
-
---reneg-sec args
-  Renegotiate data channel key after at most ``max`` seconds
-  (default :code:`3600`) and at least ``min`` seconds (default is 90% of
-  ``max`` for servers, and equal to ``max`` for clients).
-  ::
-
- reneg-sec max [min]
-
-  The effective ``--reneg-sec`` value used is per session
-  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
-  servers, or just 3600 for clients.
-
-  When using dual-factor authentication, note that this default value may
-  cause the end user to be challenged to reauthorize once per hour.
-
-  Also, keep in mind that this option can be used on both the client and
-  server, and whichever uses the lower value will be the one to trigger
-  the renegotiation. A common mistake is to set ``--reneg-sec`` to a
-  higher value on either the client or server, while the other side of the
-  connection is still using the default value of :code:`3600` seconds,
-  meaning that the renegotiation will still occur once per :code:`3600`
-  seconds. The solution is to increase --reneg-sec on both the client and
-  server, or set it to :code:`0` on one side of the connection (to
-  disable), and to your chosen value on the other side.
-
 --rport port
   Set TCP/UDP port number or name used by the ``--remote`` option. The
   port can also be set directly using the ``--remote`` option.
diff --git a/doc/man-sections/renegotiation.rst 
b/doc/man-sections/renegotiation.rst
new file mode 100644
index ..aaede4eb
--- /dev/null
+++ b/doc/man-sections/renegotiation.rst
@@ -0,0 +1,53 @@
+Data Channel Renegotiation
+--
+
+When running OpenVPN in client/server mode, the data channel will use a
+separate ephemeral encryption key which is rotated at regular intervals.
+
+--reneg-bytes n
+  Renegotiate data channel key after ``n`` bytes sent or received
+  (disabled by default with an exception, see below). OpenVPN allows the
+  lifetime of a key to be expressed as a number of bytes
+  encrypted/decrypted, a number of packets, or a number of seconds. A key
+  renegotiation will be forced if any of these three criteria are met by
+  either peer.
+
+  If using ciphers with cipher block sizes less than 128-bits,
+  ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly
+  disabled by setting the value to :code:`0`, but this is
+  **HIGHLY DISCOURAGED** as this is designed to add some protection against
+  the SWEET32 attack vector. For more information see the ``--cipher``
+  option.
+
+--reneg-pkts n
+  Renegotiate data channel key after **n** packets sent and received
+  (disabled

[Openvpn-devel] [PATCH 14/16] doc/man: Update --txqueuelen default setting (Now OS default)

2020-07-15 Thread David Sommerseth
From: Richard Bonhomme 

Signed-off-by: Richard Bonhomme 
Signed-off-by: David Sommerseth 
---
 doc/man-sections/advanced-options.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/man-sections/advanced-options.rst 
b/doc/man-sections/advanced-options.rst
index dbf7799c..9b96e406 100644
--- a/doc/man-sections/advanced-options.rst
+++ b/doc/man-sections/advanced-options.rst
@@ -103,5 +103,5 @@ used when debugging or testing out special usage scenarios.
 
 --txqueuelen n
   *(Linux only)* Set the TX queue length on the TUN/TAP interface.
-  Currently defaults to 100.
+  Currently defaults to operating system default.
 
-- 
2.26.0



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


[Openvpn-devel] [PATCH 09/16] doc/man: Move some options from link to advanced section

2020-07-15 Thread David Sommerseth
Moved --persist-local-ip, --persist-remote-ip, --rcvbuf, --sndbuf
and --shaper from the link options section to the advanced section.

The rationale is that these options are not common to use and is for
more advanced use cases where special tweaking is required.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/advanced-options.rst | 40 +++
 doc/man-sections/link-options.rst | 40 ---
 2 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/doc/man-sections/advanced-options.rst 
b/doc/man-sections/advanced-options.rst
index 9e59677d..262e568c 100644
--- a/doc/man-sections/advanced-options.rst
+++ b/doc/man-sections/advanced-options.rst
@@ -34,6 +34,14 @@ used when debugging or testing out special usage scenarios.
 --bcast-buffers n
   Allocate ``n`` buffers for broadcast datagrams (default :code:`256`).
 
+--persist-local-ip
+  Preserve initially resolved local IP address and port number across
+  ``SIGUSR1`` or ``--ping-restart`` restarts.
+
+--persist-remote-ip
+  Preserve most recently authenticated remote IP address and port number
+  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
+
 --prng args
   *(Advanced)* Change the PRNG (Pseudo-random number generator) parameters
 
@@ -51,6 +59,38 @@ used when debugging or testing out special usage scenarios.
   RAND\_bytes function instead for all of OpenVPN's pseudo-random number
   needs.
 
+--rcvbuf size
+  Set the TCP/UDP socket receive buffer size. Defaults to operation system
+  default.
+
+--shaper n
+  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
+  TCP/UDP port. Note that this will only work if mode is set to
+  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
+  this option on both peers.
+
+  OpenVPN uses the following algorithm to implement traffic shaping: Given
+  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
+  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
+  seconds before queuing the next write.
+
+  It should be noted that OpenVPN supports multiple tunnels between the
+  same two peers, allowing you to construct full-speed and reduced
+  bandwidth tunnels at the same time, routing low-priority data such as
+  off-site backups over the reduced bandwidth tunnel, and other data over
+  the full-speed tunnel.
+
+  Also note that for low bandwidth tunnels (under 1000 bytes per second),
+  you should probably use lower MTU values as well (see above), otherwise
+  the packet latency will grow so large as to trigger timeouts in the TLS
+  layer and TCP connections running over the tunnel.
+
+  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
+  default.
+
 --tcp-queue-limit n
   Maximum number of output packets queued before TCP (default :code:`64`).
 
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index ca719c75..5f75c5f3 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -173,14 +173,6 @@ the local and the remote host.
 --passtos
   Set the TOS field of the tunnel packet to what the payload's TOS is.
 
---persist-local-ip
-  Preserve initially resolved local IP address and port number across
-  ``SIGUSR1`` or ``--ping-restart`` restarts.
-
---persist-remote-ip
-  Preserve most recently authenticated remote IP address and port number
-  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
-
 --ping n
   Ping remote over the TCP/UDP control channel if no packets have been
   sent for at least ``n`` seconds (specify ``--ping`` on both peers to
@@ -292,10 +284,6 @@ the local and the remote host.
   and has been used since version 2.0-beta17. Previous versions used port
   5000 as the default.
 
---rcvbuf size
-  Set the TCP/UDP socket receive buffer size. Defaults to operation system
-  default.
-
 --reneg-bytes n
   Renegotiate data channel key after ``n`` bytes sent or received
   (disabled by default with an exception, see below). OpenVPN allows the
@@ -439,34 +427,6 @@ the local and the remote host.
   default) and you are using either ``--secret`` (shared-secret key mode)
   or TLS mode with ``--tls-auth``.
 
---shaper n
-  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
-  TCP/UDP port. Note that this will only work if mode is set to
-  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
-  this option on both peers.
-
-  OpenVPN uses the following algorithm to implement traffic shaping: Given
-  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
-  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
-  seconds before queuing the next write.
-
-  It should be noted that OpenVPN supports multiple tunnels between the
-  same two peers, allowing you to construct full-speed and reduced
-  bandwidth tunnels

[Openvpn-devel] [PATCH 13/16] doc/man: Adopt compression documentation

2020-07-15 Thread David Sommerseth
Commit c67e93b25208be2 updated the man page in reagrds to new
compression options and improving existing compression options.  This
adopts those changes into the .rst format.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/protocol-options.rst | 52 ++-
 1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index a5a1253a..d7bcbb98 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -5,6 +5,31 @@ protocol.  Many of these options also define the encryption 
options
 of the data channel in the OpenVPN wire protocol.  These options must be
 configured in a compatible way between both the local and remote side.
 
+--allow-compression mode
+  As described in the ``--compress`` option, compression is a potentially
+  dangerous option.  This option allows controlling the behaviour of
+  OpenVPN when compression is used and allowed.
+
+  Valid syntaxes:
+  ::
+
+  allow-compression
+  allow-compression mode
+
+  The ``mode`` argument can be one of the following values:
+
+  :code:`asym`  (default)
+  OpenVPN will only *decompress downlink packets* but *not compress
+  uplink packets*.  This also allows migrating to disable compression
+  when changing both server and client configurations to remove
+  compression at the same time is not a feasible option.
+
+  :code:`no`
+  OpenVPN will refuse any non-stub compression.
+
+  :code:`yes`
+  OpenVPN will send and receive compressed packets.
+
 --auth alg
   Authenticate data channel packets and (if enabled) ``tls-auth`` control
   channel packets with HMAC using message digest algorithm ``alg``. (The
@@ -58,23 +83,32 @@ configured in a compatible way between both the local and 
remote side.
   not recommended.  VPN tunnels which use compression are susceptible to
   the VORALCE attack vector.
 
-  The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`, or empty.
+  The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`,
+  :code:`lz4-v2`, :code:`stub`, :code:`stub-v2` or empty.
   LZO and LZ4 are different compression algorithms, with LZ4 generally
   offering the best performance with least CPU usage.
 
-  If the ``algorithm`` parameter is empty, compression will be turned off,
-  but the packet framing for compression will still be enabled, allowing a
-  different setting to be pushed later.
+  The :code:`lz4-v2` and :code:`stub-v2` variants implement a better
+  framing that does not add overhead when packets cannot be compressed. All
+  other variants always add one extra framing byte compared to no
+  compression framing.
+
+  If the ``algorithm`` parameter is :code:`stub`, :code:`stub-v2` or empty,
+  compression will be turned off, but the packet framing for compression
+  will still be enabled, allowing a different setting to be pushed later.
+  Additionally, :code:`stub` and :code:`stub-v2` wil disable announcing
+  ``lzo`` and ``lz4`` compression support via *IV_* variables to the
+  server.
 
   ***Security Considerations***
 
   Compression and encryption is a tricky combination. If an attacker knows
-  or is able to control (parts of) the plaintext of packets that contain
+  or is able to control (parts of) the plain-text of packets that contain
   secrets, the attacker might be able to extract the secret if compression
-  is enabled. See e.g. the CRIME and BREACH attacks on TLS which also
-  leverage compression to break encryption. If you are not entirely sure
-  that the above does not apply to your traffic, you are advised to
-  *not* enable compression.
+  is enabled. See e.g. the *CRIME* and *BREACH* attacks on TLS and
+  *VORACLE* on VPNs which also leverage to break encryption. If you are not
+  entirely sure that the above does not apply to your traffic, you are
+  advised to *not* enable compression.
 
 --comp-lzo mode
   **DEPRECATED** Enable LZO compression algorithm.  Compression is
-- 
2.26.0



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


[Openvpn-devel] [PATCH 16/16] doc/man: Minor improvements to the plug-in section

2020-07-15 Thread David Sommerseth
Make the valid syntax clearer and apply proper styling of few
reference strings.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/plugin-options.rst | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/doc/man-sections/plugin-options.rst 
b/doc/man-sections/plugin-options.rst
index 20b74edd..1beccd3d 100644
--- a/doc/man-sections/plugin-options.rst
+++ b/doc/man-sections/plugin-options.rst
@@ -5,7 +5,15 @@ OpenVPN can be extended by loading external plug-in modules at 
runtime.  These
 plug-ins must be prebuilt and adhere to the OpenVPN Plug-In API.
 
 --plugin args
-  Loads a given plug-in module.  The ``module-name`` needs to be the first
+  Loads an OpenVPN plug-in module.
+
+  Valid syntax:
+  ::
+
+ plugin module-name
+ plugin module-name "arguments"
+
+  The ``module-name`` needs to be the first
   argument, indicating the plug-in to load.  The second argument is an
   optional init string which will be passed directly to the plug-in.
   If the init consists of multiple arguments it must be enclosed in
@@ -26,8 +34,8 @@ plug-ins must be prebuilt and adhere to the OpenVPN Plug-In 
API.
  /usr/lib/my/plug.so  /usr/lib/my/plug.so
 
 
-  DEFAULT\_DIR is replaced by the default plug-in directory, which is
-  configured at the build time of OpenVPN. CWD is the current directory
+  ``DEFAULT_DIR`` is replaced by the default plug-in directory, which is
+  configured at the build time of OpenVPN. ``CWD`` is the current directory
   where OpenVPN was started or the directory OpenVPN have switched into
   via the ``--cd`` option before the ``--plugin`` option.
 
-- 
2.26.0



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


[Openvpn-devel] [PATCH 04/16] doc/man: Remove unsupported options in OpenVPN 2.5

2020-07-15 Thread David Sommerseth
This removes the options from the man page which is enlisted as
deprecated options in OpenVPN 2.5.  To provide some history, a short
summary of why they were removed has been put into a new file which is
included into its own "UNSUPPORTED OPTIONS" section in the man page.

Signed-off-by: David Sommerseth 
---
 doc/openvpn.8.rst   | 144 +---
 doc/unsupported-options.rst |  33 +
 2 files changed, 35 insertions(+), 142 deletions(-)
 create mode 100644 doc/unsupported-options.rst

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index fc3ecdb8..713cd309 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -454,9 +454,7 @@ Tunnel Options:
 the client's tun interface always points to the local endpoint of the
 server's tun interface. This mode allocates a single IP address per
 connecting client. Only use when none of the connecting clients are
-Windows systems. This mode is functionally equivalent to the
-``--ifconfig-pool-linear`` directive which is available in OpenVPN 2.0,
-is deprecated and will be removed in OpenVPN 2.5
+Windows systems.
 
   :code:`subnet`
 Use a subnet rather than a point-to-point topology by
@@ -2184,17 +2182,6 @@ fast hardware. SSL/TLS authentication must be used in 
this mode.
   receive the given IP address. If you want guaranteed assignment, use
   ``--ifconfig-push``
 
---ifconfig-pool-linear
-  **DEPRECATED** This option will be removed in OpenVPN 2.5
-
-  Modifies the ``--ifconfig-pool`` directive to allocate individual TUN
-  interface addresses for clients rather than /30 subnets.
-
-  *NOTE:*   This option is incompatible with Windows clients.
-
-  This option is deprecated, and should be replaced with ``--topology
-  p2p`` which is functionally equivalent.
-
 --ifconfig-push args
   Push virtual IP endpoints for client tunnel, overriding the
   ``--ifconfig-pool`` dynamic allocation.
@@ -2668,17 +2655,6 @@ fast hardware. SSL/TLS authentication must be used in 
this mode.
   authentication module/script MUST have logic to detect this condition
   and respond accordingly.
 
---client-cert-not-required
-  **DEPRECATED** This option will be removed in OpenVPN 2.5
-
-  Don't require client certificate, client will authenticate using
-  username/password only. Be aware that using this directive is less
-  secure than requiring certificates from all clients.
-
-  **Please note:** This is replaced by ``--verify-client-cert`` which
-  allows for more flexibility. The option ``--verify-client-cert none`` is
-  functionally equivalent to ``--client-cert-not-required``
-
 --verify-client-cert mode
   Specify whether the client is required to supply a valid certificate.
 
@@ -3178,41 +3154,6 @@ These options are meaningful for both Static & 
TLS-negotiated key modes
   ``--show-engines`` standalone option to list the crypto engines which
   are supported by OpenSSL.
 
---no-replay
-  **DEPRECATED** This option will be removed in OpenVPN 2.5.
-
-  (Advanced) Disable OpenVPN's protection against replay attacks. Don't
-  use this option unless you are prepared to make a tradeoff of greater
-  efficiency in exchange for less security.
-
-  OpenVPN provides datagram replay protection by default.
-
-  Replay protection is accomplished by tagging each outgoing datagram with
-  an identifier that is guaranteed to be unique for the key being used.
-  The peer that receives the datagram will check for the uniqueness of the
-  identifier. If the identifier was already received in a previous
-  datagram, OpenVPN will drop the packet. Replay protection is important
-  to defeat attacks such as a SYN flood attack, where the attacker listens
-  in the wire, intercepts a TCP SYN packet (identifying it by the context
-  in which it occurs in relation to other packets), then floods the
-  receiving peer with copies of this packet.
-
-  OpenVPN's replay protection is implemented in slightly different ways,
-  depending on the key management mode you have selected.
-
-  In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses
-  a 64 bit unique identifier that combines a time stamp with an
-  incrementing sequence number.
-
-  When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses
-  only a 32 bit sequence number without a time stamp, since OpenVPN can
-  guarantee the uniqueness of this value for each key. As in IPSec, if the
-  sequence number is close to wrapping back to zero, OpenVPN will trigger
-  a new key exchange.
-
-  To check for replays, OpenVPN uses the *sliding window* algorithm used
-  by IPSec.
-
 --replay-window args
   Modify the replay protection sliding-window size and time window.
 
@@ -3311,27 +3252,6 @@ These options are meaningful for both Static & 
TLS-negotiated key modes
   default) and you are using either ``--secret`` (shared-secret key mode)
   or TLS mode with ``--tls-auth``.
 
---no-iv
-  **DEPRECATED** This option will be remo

[Openvpn-devel] [PATCH 08/16] doc/man: Mark compression options as deprecated

2020-07-15 Thread David Sommerseth
Due to the VORACLE attack vector, compression in general is deprecated.
Make this clear in the man page.

Also remove an incorrect statement claiming --compress lzo is compatible
with --comp-lzo.  It is not, as --compress lzo uses a different
compression framing than --comp-lzo.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/protocol-options.rst | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index 37e55eb7..5bc072af 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -54,13 +54,13 @@ configured in a compatible way between both the local and 
remote side.
   Set ``alg`` to :code:`none` to disable encryption.
 
 --compress algorithm
-  Enable a compression algorithm.
+  **DEPRECATED** Enable a compression algorithm.  Compression is generally
+  not recommended.  VPN tunnels which uses compression are suspectible to
+  the VORALCE attack vector.
 
   The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`, or empty.
   LZO and LZ4 are different compression algorithms, with LZ4 generally
-  offering the best performance with least CPU usage. For backwards
-  compatibility with OpenVPN versions before v2.4, use :code:`lzo` (which
-  is identical to the older option ``--comp-lzo yes``).
+  offering the best performance with least CPU usage.
 
   If the ``algorithm`` parameter is empty, compression will be turned off,
   but the packet framing for compression will still be enabled, allowing a
@@ -77,8 +77,9 @@ configured in a compatible way between both the local and 
remote side.
   *not* enable compression.
 
 --comp-lzo mode
-  *DEPRECATED* This option will be removed in a future OpenVPN release.
-  Use the newer ``--compress`` instead.
+  **DEPRECATED** Enable LZO compression algorithm.  Compression is
+  generally not recommended.  VPN tunnels which uses compression are
+  suspectible to the VORALCE attack vector.
 
   Use LZO compression -- may add up to 1 byte per packet for incompressible
   data. ``mode`` may be :code:`yes`, :code:`no`, or :code:`adaptive`
@@ -104,9 +105,9 @@ configured in a compatible way between both the local and 
remote side.
   link, the second sets the client side.
 
 --comp-noadapt
-  When used in conjunction with ``--comp-lzo``, this option will disable
-  OpenVPN's adaptive compression algorithm. Normally, adaptive compression
-  is enabled with ``--comp-lzo``.
+  **DEPRECATED** When used in conjunction with ``--comp-lzo``, this option
+  will disable OpenVPN's adaptive compression algorithm. Normally, adaptive
+  compression is enabled with ``--comp-lzo``.
 
   Adaptive compression tries to optimize the case where you have
   compression enabled, but you are sending predominantly incompressible
-- 
2.26.0



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


[Openvpn-devel] [PATCH 15/16] doc/man: Fix a few typos and improve style usage

2020-07-15 Thread David Sommerseth
The server returns "AUTH_FAILED".  Such strings and code related
references should use the :code:`SOME_STRING` style.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/client-options.rst | 10 +-
 doc/man-sections/script-options.rst |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index 98b80cb1..249af0a3 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -28,7 +28,7 @@ configuration.
   where the server can push new options to the client. The password the
   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 client will receive an :code:`AUTH_FAILED` 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
@@ -70,14 +70,14 @@ configuration.
 
 --auth-retry type
   Controls how OpenVPN responds to username/password verification errors
-  such as the client-side response to an AUTH\_FAILED message from the
-  server or verification failure of the private key password.
+  such as the client-side response to an :code:`AUTH_FAILED` message from
+  the server or verification failure of the private key password.
 
   Normally used to prevent auth errors from being fatal on the client
   side, and to permit username/password requeries in case of error.
 
-  An AUTH\_FAILED message is generated by the server if the client fails
-  ``--auth-user-pass`` authentication, or if the server-side
+  An :code:`AUTH_FAILED` message is generated by the server if the client
+  fails ``--auth-user-pass`` authentication, or if the server-side
   ``--client-connect`` script returns an error status when the client
   tries to connect.
 
diff --git a/doc/man-sections/script-options.rst 
b/doc/man-sections/script-options.rst
index 8ea5b4a7..ee209a6d 100644
--- a/doc/man-sections/script-options.rst
+++ b/doc/man-sections/script-options.rst
@@ -467,7 +467,7 @@ permitted character class for each string:
 *--auth-user-pass username*
Same as Common Name, with one exception:
starting with OpenVPN 2.0.1, the username is passed to the
-   OPENVPN\_PLUGIN\_AUTH\_USER\_PASS\_VERIFY plugin in its raw form,
+   :code:`OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY` plugin in its raw form,
without string remapping.
 
 *--auth-user-pass password*
-- 
2.26.0



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


[Openvpn-devel] [PATCH 11/16] doc/man: Cleaned up the examples

2020-07-15 Thread David Sommerseth
Removed a lot of outdated information.  The loading of the tun module is
not needed on current Linux distributions; it is automatically loaded
when needed.

Also removed all the iptables references and rather refer the reader to
figure out how firewalling is configured on their system.  The reason is
that iptables is moving towards being deprecated in faviour of
nftables/nft.  In addition many Linux distributions provide their own
wrappers around it (ufw, firewalld, to mention a couple).  In addition
it makes the man page less Linux-centric.

The only Linux specific reference left is configuration of IP
forwarding.  But extended the text to ask the reader to find the
preferred way of configuring IP forwarding in a persistent way.  Many
Linux distributions uses their own set of network configuration tools as
well (NetworkManager, systemd-networkd, netplan, to mention a few).

The rest of the instructions should be fairly OS neutral and is a quick
introduction how to get tunnels configured and gradually expand the
configuration and improve the security along the way.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/examples.rst | 105 --
 1 file changed, 11 insertions(+), 94 deletions(-)

diff --git a/doc/man-sections/examples.rst b/doc/man-sections/examples.rst
index 0bea7f5a..ecc2a29f 100644
--- a/doc/man-sections/examples.rst
+++ b/doc/man-sections/examples.rst
@@ -7,32 +7,12 @@ installed OpenVPN, consult the INSTALL file included in the 
OpenVPN
 distribution.
 
 
-TUN/TAP Setup:
---
-
-If you are using Linux 2.4 or higher, make the tun device node and load
-the tun module:
-
-::
-
-mknod /dev/net/tun c 10 200
-modprobe tun
-
-If you installed from RPM, the ``mknod`` step may be omitted, because
-the RPM install does that for you.
-
-Only Linux 2.4 and newer are supported.
-
-For other platforms, consult the INSTALL file at
-https://openvpn.net/community-resources/the-standard-install-file-included-in-the-source-distribution/
-for more information.
-
-
 Firewall Setup:
 ---
 
 If firewalls exist between the two machines, they should be set to
-forward UDP port 1194 in both directions. If you do not have control
+forward the port OpenVPN is configured to use, in both directions.
+The default for OpenVPN is 1194/udp.  If you do not have control
 over the firewalls between the two machines, you may still be able to
 use OpenVPN by adding ``--ping 15`` to each of the ``openvpn`` commands
 used below in the examples (this will cause each peer to send out a UDP
@@ -40,13 +20,8 @@ ping to its remote peer once every 15 seconds which will 
cause many
 stateful firewalls to forward packets in both directions without an
 explicit firewall rule).
 
-If you are using a Linux iptables-based firewall, you may need to enter
-the following command to allow incoming packets on the TUN device:
-
-:code:`iptables -A INPUT -i tun+ -j ACCEPT`
-
-See the firewalls section below for more information on configuring
-firewalls for use with OpenVPN.
+Please see your operating system guides for how to configure the firewall
+on your systems.
 
 
 VPN Address Setup:
@@ -239,10 +214,14 @@ enable routing:
 
 echo 1 > /proc/sys/net/ipv4/ip_forward
 
-and enable TUN packet forwarding through the firewall:
-::
+This setting is not persistent.  Please see your operating systems
+documentation how to properly configure IP forwarding, which is also
+persistent through system boots.
 
-   iptables -A FORWARD -i tun+ -j ACCEPT
+If you system is configured with a firewall.  Please see your operating
+systems guide on how to configure the firewall.  You typically want to
+allow traffic coming from and going to the tun/tap adapter OpenVPN is
+configured to use.
 
 On bob:
 ::
@@ -260,65 +239,3 @@ Now any machine on the *10.0.0.0/24* subnet can access any 
machine on the
 In a production environment, you could put the route command(s) in a
 script and execute with the ``--up`` option.
 
-
-FIREWALLS
-=
-
-OpenVPN's usage of a single UDP port makes it fairly firewall-friendly.
-You should add an entry to your firewall rules to allow incoming OpenVPN
-packets. On Linux 2.4+:
-::
-
-   iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT
-
-This will allow incoming packets on UDP port :code:`1194` (OpenVPN's
-default UDP port) from an OpenVPN peer at :code:`1.2.3.4`.
-
-If you are using HMAC-based packet authentication (the default in any of
-OpenVPN's secure modes), having the firewall filter on source address
-can be considered optional, since HMAC packet authentication is a much
-more secure method of verifying the authenticity of a packet source. In
-that case:
-::
-
-   iptables -A INPUT -p udp --dport 1194 -j ACCEPT
-
-would be adequate and would not render the host inflexible with respect
-to its peer having a dynamic IP address.
-
-OpenVPN also works well on stateful firewalls. In some cases, you may
-not need to add any static rules to the firewall l

[Openvpn-devel] [PATCH 07/16] doc/man: Move --dhcp-option from client to vpn-network section

2020-07-15 Thread David Sommerseth
Even though the --dhcp-option is only useful in a client context, it is
more related to configuration of the VPN network interface and the
related settings.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/client-options.rst  | 69 
 doc/man-sections/vpn-network-options.rst | 69 
 2 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index d6f9e6aa..966ede1e 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -146,75 +146,6 @@ configuration.
 --connect-timeout n
   See ``--server-poll-timeout``.
 
---dhcp-option args
-  Set additional network settings via DHCP.  On Windows, this is parsed by
-  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
-  options can be picked up by a ``--up`` script or plug-in if it has been
-  pushed by the OpenVPN server.  The option will then be saved in the
-  client's environment before the ``--up`` script is called, under the name
-  :code:`foreign_option_{n}`.
-
-  Valid syntax:
-  ::
-
- dhcp-options type [parm]
-
-  :code:`DOMAIN` ``name``
-Set Connection-specific DNS Suffix to :code:`name`.
-
-  :code:`DNS` ``address``
-Set primary domain name server IPv4 or IPv6 address.
-Repeat this option to set secondary DNS server addresses.
-
-Note: DNS IPv6 servers are currently set using netsh (the existing
-DHCP code can only do IPv4 DHCP, and that protocol only permits
-IPv4 addresses anywhere). The option will be put into the
-environment, so an ``--up`` script could act upon it if needed.
-
-  :code:`WINS` ``address``
-Set primary WINS server address (NetBIOS over TCP/IP Name Server).
-Repeat this option to set secondary WINS server addresses.
-
-  :code:`NBDD` ``address``
-Set primary NBDD server address (NetBIOS over TCP/IP Datagram
-Distribution Server). Repeat this option to set secondary NBDD
-server addresses.
-
-  :code:`NTP` ``address``
-Set primary NTP server address (Network Time Protocol).
-Repeat this option to set secondary NTP server addresses.
-
-  :code:`NBT` ``type``
-Set NetBIOS over TCP/IP Node type. Possible options:
-
-:code:`1`
-  b-node (broadcasts)
-
-:code:`2`
-  p-node (point-to-point name queries to a WINS server)
-
-:code:`4`
-  m-node (broadcast then query name server)
-
-:code:`8`
-  h-node (query name server, then broadcast).
-
-  :code:`NBS` ``scope-id``
-Set NetBIOS over TCP/IP Scope. A NetBIOS Scope ID provides an
-extended naming service for the NetBIOS over TCP/IP (Known as NBT)
-module. The primary purpose of a NetBIOS scope ID is to isolate
-NetBIOS traffic on a single network to only those nodes with the
-same NetBIOS scope ID. The NetBIOS scope ID is a character string
-that is appended to the NetBIOS name. The NetBIOS scope ID on two
-hosts must match, or the two hosts will not be able to communicate.
-The NetBIOS Scope ID also allows computers to use the same computer
-name, as they have different scope IDs. The Scope ID becomes a part
-of the NetBIOS name, making the name unique. (This description of
-NetBIOS scopes courtesy of neonsu...@abyss.com)
-
-  :code:`DISABLE-NBT`
-Disable Netbios-over-TCP/IP.
-
 --explicit-exit-notify n
   In UDP client mode or point-to-point mode, send server/peer an exit
   notification if tunnel is restarted or OpenVPN process is exited. In
diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index fc18676e..d75cf540 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -88,6 +88,75 @@ routing.
   the TUN/TAP device used with ``--dev`` does not begin with :code:`tun`
   or :code:`tap`.
 
+--dhcp-option args
+  Set additional network settings via DHCP.  On Windows, this is parsed by
+  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
+  options can be picked up by a ``--up`` script or plug-in if it has been
+  pushed by the OpenVPN server.  The option will then be saved in the
+  client's environment before the ``--up`` script is called, under the name
+  :code:`foreign_option_{n}`.
+
+  Valid syntax:
+  ::
+
+ dhcp-options type [parm]
+
+  :code:`DOMAIN` ``name``
+Set Connection-specific DNS Suffix to :code:`name`.
+
+  :code:`DNS` ``address``
+Set primary domain name server IPv4 or IPv6 address.
+Repeat this option to set secondary DNS server addresses.
+
+Note: DNS IPv6 servers are currently set using netsh (the existing
+DHCP code can only do IPv4 DHCP, and that protocol only permits
+IPv4 addresses anywhere). The option will be put

[Openvpn-devel] [PATCH 06/16] doc/man: Move --bind from generic to link section

2020-07-15 Thread David Sommerseth
This is more related to the configuration of the link, plus --nobind is
already placed in the link section.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/generic-options.rst | 7 ---
 doc/man-sections/link-options.rst| 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/man-sections/generic-options.rst 
b/doc/man-sections/generic-options.rst
index cd048fa5..35985afc 100644
--- a/doc/man-sections/generic-options.rst
+++ b/doc/man-sections/generic-options.rst
@@ -22,13 +22,6 @@ which mode OpenVPN is configured as.
   This directive does not affect the ``--http-proxy`` username/password.
   It is always cached.
 
---bind keywords
-  Bind to local address and port. This is the default unless any of
-  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
-
-  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
-  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
-
 --cd dir
   Change directory to ``dir`` prior to reading any files such as
   configuration files, key files, scripts, etc. ``dir`` should be an
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index 595f7f69..ca719c75 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -3,6 +3,13 @@ Link Options
 This link options section covers options related to the connection between
 the local and the remote host.
 
+--bind keywords
+  Bind to local address and port. This is the default unless any of
+  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
+
+  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
+  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
+
 --float
   Allow remote peer to change its IP address and/or port number, such as
   due to DHCP (this is the default if ``--remote`` is not used).
-- 
2.26.0



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


[Openvpn-devel] [PATCH 03/16] doc/man: Move profiles section

2020-07-15 Thread David Sommerseth
The  profile documentation has been enlisted in between all
the other OpenVPN options.  As  is not strictly an option by
itself but a grouping mechanism, move it into its own section in the man
page.  This also makes the HTML rendering look much nicer and better
structured.

Signed-off-by: David Sommerseth 
---
 doc/openvpn.8.rst | 149 --
 1 file changed, 78 insertions(+), 71 deletions(-)

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index 4627a7d3..fc3ecdb8 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -204,77 +204,6 @@ Tunnel Options:
   prevent DNS caching. For example, "foo.bar.gov" would be modified to
   ".foo.bar.gov".
 
-
-  Define a client connection profile. Client connection profiles are
-  groups of OpenVPN options that describe how to connect to a given
-  OpenVPN server. Client connection profiles are specified within an
-  OpenVPN configuration file, and each profile is bracketed by
-   and .
-
-  An OpenVPN client will try each connection profile sequentially until it
-  achieves a successful connection.
-
-  ``--remote-random`` can be used to initially "scramble" the connection
-  list.
-
-  Here is an example of connection profile usage:
-  ::
-
- client
- dev tun
-
- 
- remote 198.19.34.56 1194 udp
- 
-
- 
- remote 198.19.34.56 443 tcp
- 
-
- 
- remote 198.19.34.56 443 tcp
- http-proxy 192.168.0.8 8080
- 
-
- 
- remote 198.19.36.99 443 tcp
- http-proxy 192.168.0.8 8080
- 
-
- persist-key
- persist-tun
- pkcs12 client.p12
- remote-cert-tls server
- verb 3
-
-  First we try to connect to a server at 198.19.34.56:1194 using UDP. If
-  that fails, we then try to connect to 198.19.34.56:443 using TCP. If
-  that also fails, then try connecting through an HTTP proxy at
-  192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect
-  through the same proxy to a server at 198.19.36.99:443 using TCP.
-
-  The following OpenVPN options may be used inside of a 
-  block:
-
-  ``bind``, ``connect-retry``, ``connect-retry-max``, ``connect-timeout``,
-  ``explicit-exit-notify``, ``float``, ``fragment``, ``http-proxy``,
-  ``http-proxy-option``, ``key-direction``, ``link-mtu``, ``local``,
-  ``lport``, ``mssfix``, ``mtu-disc``, ``nobind``, ``port``, ``proto``,
-  ``remote``, ``rport``, ``socks-proxy``, ``tls-auth``, ``tls-crypt``,
-  ``tun-mtu and``, ``tun-mtu-extra``.
-
-  A defaulting mechanism exists for specifying options to apply to all
-   profiles. If any of the above options (with the
-  exception of ``remote`` ) appear outside of a  block,
-  but in a configuration file which has one or more 
-  blocks, the option setting will be used as a default for
-   blocks which follow it in the configuration file.
-
-  For example, suppose the ``nobind`` option were placed in the sample
-  configuration file above, near the top of the file, before the first
-   block. The effect would be as if ``nobind`` were
-  declared in all  blocks below it.
-
 --proto-force p
   When iterating through connection profiles, only consider profiles using
   protocol ``p`` (:code:`tcp` \| :code:`udp`).
@@ -5400,6 +5329,84 @@ instances.
 
 
 
+CONNECTION PROFILES
+===
+
+Client configuration files may contain multiple remote servers which
+it will attempt to connect against.  But there are some configuration
+options which are related to specific ``--remote`` options.  For these
+use cases, connection profiles is the solution.
+
+By enacpulating the ``--remote`` option and related options within
+ and , these options are handled as a
+group.
+
+An OpenVPN client will try each connection profile sequentially until it
+achieves a successful connection.
+
+``--remote-random`` can be used to initially "scramble" the connection
+list.
+
+Here is an example of connection profile usage:
+::
+
+   client
+   dev tun
+
+   
+   remote 198.19.34.56 1194 udp
+   
+
+   
+   remote 198.19.34.56 443 tcp
+   
+
+   
+   remote 198.19.34.56 443 tcp
+   http-proxy 192.168.0.8 8080
+   
+
+   
+   remote 198.19.36.99 443 tcp
+   http-proxy 192.168.0.8 8080
+   
+
+   persist-key
+   persist-tun
+   pkcs12 client.p12
+   remote-cert-tls server
+   verb 3
+
+First we try to connect to a server at 198.19.34.56:1194 using UDP. If
+that fails, we then try to connect to 198.19.34.56:443 using TCP. If
+that also fails, then try connecting through an HTTP proxy at
+192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect
+through the same proxy to a server at 198.19.36.99:443 using TCP.
+
+The following OpenVPN options may be used inside of a 
+block:
+
+``bind``, ``connect-retry``, ``connect-retry-max``, ``connect-timeout``,
+``explicit-exit-notify``, ``float``, ``fragment``, ``http-proxy``,
+``http-proxy-option``, ``key-direction``, ``link-mtu``, ``local``,
+``lpo

[Openvpn-devel] [PATCH 00/16] man-page overhaul project

2020-07-15 Thread David Sommerseth
Hi,

The time has come to send this pile of patches to the mailing list,
which incorporates many improvements by Richard Bonhomme (Thanks a lot!).

I do however fear that patch 5/16 and possibly patch 1/16 and 2/16 will
be rejected by the sourceforge mailman instance as they might exceed some
mailing list limts.  The other patches are below 30KiB and should arrive
fine on the mailing list.

  Patch 1/16: 
<https://gitlab.com/dazo/openvpn/-/commit/32e72c9fc9ce329293a6007347e2b7a3e3e297ac.patch>
  Patch 2/16: 
<https://gitlab.com/dazo/openvpn/-/commit/69085b6fd378ffcf5f26836c0e8b53e6fc3ae900.patch>
  Patch 5/16: 
<https://gitlab.com/dazo/openvpn/-/commit/c4d2d70c204f4cbda398387df5672d02f874ae8a.patch>

All patches are available from here:
  <https://gitlab.com/dazo/openvpn/-/commits/dev/man-reformatting>

If it makes sense to squash some or all of these changes into a single
commit, I have no issues with that.


kind regards,

David Sommerseth
OpenVPN Inc


David Sommerseth (14):
  doc/man: Add an .rst formatted version of the man page
  doc/man: Replace old man page with generated man page
  doc/man: Move  profiles section
  doc/man: Remove unsupported options in OpenVPN 2.5
  doc/man: Split up and reorganize main man page
  doc/man: Move --bind from generic to link section
  doc/man: Move --dhcp-option from client to vpn-network section
  doc/man: Mark compression options as deprecated
  doc/man: Move some options from link to advanced section
  doc/man: Moved --reneg-* options to its own section
  doc/man: Cleaned up the examples
  doc/man: Adopt compression documentation
  doc/man: Fix a few typos and improve style usage
  doc/man: Minor improvements to the plug-in section

Richard Bonhomme (2):
  doc/man: Misc grammar and typo fixes
  doc/man: Update --txqueuelen default setting (Now OS default)

 .gitignore   |1 +
 INSTALL  |3 +-
 configure.ac |   15 +-
 doc/Makefile.am  |   56 +-
 doc/README.man   |   23 +
 doc/man-sections/advanced-options.rst|  107 +
 doc/man-sections/client-options.rst  |  354 +
 doc/man-sections/connection-profiles.rst |   75 +
 doc/man-sections/encryption-options.rst  |  136 +
 doc/man-sections/examples.rst|  241 +
 doc/man-sections/generic-options.rst |  436 ++
 doc/man-sections/inline-files.rst|   25 +
 doc/man-sections/link-options.rst|  410 ++
 doc/man-sections/log-options.rst |   74 +
 doc/man-sections/management-options.rst  |  136 +
 doc/man-sections/network-config.rst  |9 +
 doc/man-sections/pkcs11-options.rst  |   81 +
 doc/man-sections/plugin-options.rst  |   60 +
 doc/man-sections/protocol-options.rst|  262 +
 doc/man-sections/proxy-options.rst   |   66 +
 doc/man-sections/renegotiation.rst   |   53 +
 doc/man-sections/script-options.rst  |  807 +++
 doc/man-sections/server-options.rst  |  769 +++
 doc/man-sections/signals.rst |   30 +
 doc/man-sections/tls-options.rst |  643 ++
 doc/man-sections/unsupported-options.rst |   33 +
 doc/man-sections/vpn-network-options.rst |  531 ++
 doc/man-sections/windows-options.rst |  245 +
 doc/openvpn.8| 7659 --
 doc/openvpn.8.rst|  169 +
 30 files changed, 5835 insertions(+), 7674 deletions(-)
 create mode 100644 doc/README.man
 create mode 100644 doc/man-sections/advanced-options.rst
 create mode 100644 doc/man-sections/client-options.rst
 create mode 100644 doc/man-sections/connection-profiles.rst
 create mode 100644 doc/man-sections/encryption-options.rst
 create mode 100644 doc/man-sections/examples.rst
 create mode 100644 doc/man-sections/generic-options.rst
 create mode 100644 doc/man-sections/inline-files.rst
 create mode 100644 doc/man-sections/link-options.rst
 create mode 100644 doc/man-sections/log-options.rst
 create mode 100644 doc/man-sections/management-options.rst
 create mode 100644 doc/man-sections/network-config.rst
 create mode 100644 doc/man-sections/pkcs11-options.rst
 create mode 100644 doc/man-sections/plugin-options.rst
 create mode 100644 doc/man-sections/protocol-options.rst
 create mode 100644 doc/man-sections/proxy-options.rst
 create mode 100644 doc/man-sections/renegotiation.rst
 create mode 100644 doc/man-sections/script-options.rst
 create mode 100644 doc/man-sections/server-options.rst
 create mode 100644 doc/man-sections/signals.rst
 create mode 100644 doc/man-sections/tls-options.rst
 create mode 100644 doc/man-sections/unsupported-options.rst
 create mode 100644 doc/man-sections/vpn-network-options.rst
 create mode 100644 doc/man-sections/windows-options.rst
 delete mode 100644 doc/openvpn.8
 create mode 100644 doc/openvpn.8.rst

-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lis

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

2020-07-02 Thread David Sommerseth
On 30/06/2020 16:15, Jan Just Keijser wrote:
> hi,
> 
> On 30/06/20 16:11, Gert Doering wrote:
>> Hi,
>>
>> On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
>>> @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, const 
>>> struct tuntap_options *o)
>>>  write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, );
>>>  write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, 
>>> );
>>>  
>>> +for (int i=0; i < o->domain_search_list_len; i++)
>>> +{
>>> +write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
>>> +}
>> I assume that this won't work.  In the DHCP answer, it must be a single 
>> option with the concatenated list, not multiple answers with a single 
>> domain name each.
>>
>> gert
>>
> see https://tools.ietf.org/html/rfc3397
> 
> "
> 
>In the above diagram, Searchstring is a string specifying the
>searchlist.  If the length of the searchlist exceeds the maximum
>permissible within a single option (255 octets), then multiple
>options MAY be used, as described in "Encoding Long Options in the
>Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396 
> <https://tools.ietf.org/html/rfc3396>].
> 
> "
> 
> 
> so you MAY use this option multiple times - and wireshark groks it fine. I 
> don't have a Windows 10 
> client to test it against, however, so I am hoping that someone (Selva?) can 
> do that for me.
> 

Hi,

Can we please see this discussion also in context of this mail thread, which
tries to look a broader at this challenge?

Message-Id: 
URL:
<https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20101.html>

One change in that RFC since last time is that we will move IV_PROTO to be
only about the OpenVPN wire protocol (features/settings only affecting
protocol for the communication between the OpenVPN end-points themselves).
The DNS settings and more related to host configuration and similar will be
moved into an IV_FEAT field.  Except of that, nothing else has changed from
the initial mail.

The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
consistently across all OpenVPN implementations we care about, and that we
document this properly.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] New man page corrections - advanced-options.rst

2020-06-26 Thread David Sommerseth
On 26/06/2020 15:32, Richard Bonhomme wrote:
> Signed-off-by: Richard Bonhomme 
> ---
>  doc/man-sections/advanced-options.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 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
> @@ -61,5 +61,5 @@ used when debugging or testing out special usage scenarios.
>  
>  --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.
>  
> @@ -89,5 +89,5 @@ used when debugging or testing out special usage scenarios.
>  
>  --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.

Thanks again!

I've squashed this change into your previous grammar/typo fix commit.

-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] New man page corrections - encryption-options.rst

2020-06-26 Thread David Sommerseth
On 26/06/2020 16:34, tincanteksup wrote:
> 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 ..

It wouldn't make sense to keep a (shared) private key used for encryption
"secret from the server"; that would make it a bit difficult to use :)

I think what was meant was:

   "This file should be kept secret *on* the server ..."


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] New man page - Simple corrections

2020-06-26 Thread David Sommerseth
On 25/06/2020 23:01, Richard Bonhomme wrote:
> Signed-off-by: Richard Bonhomme 
> ---
>  doc/man-sections/connection-profiles.rst | 2 +-
>  doc/man-sections/examples.rst| 2 +-
>  doc/man-sections/pkcs11-options.rst  | 2 +-
>  doc/man-sections/plugin-options.rst  | 4 ++--
>  doc/man-sections/signals.rst | 2 +-
>  doc/man-sections/unsupported-options.rst | 4 ++--
>  6 files changed, 8 insertions(+), 8 deletions(-)
> 

Thanks a lot!  I've applied the patch and pushed it out.  Just did a minor
adjustment to the commit subject, to align it with the other commits in this
branch.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 00/11] man-page overhaul project

2020-06-24 Thread David Sommerseth
On 24/06/2020 20:07, David Sommerseth wrote:
> Hi,
> 
> This is the first real review round of the man-page overhaul project.
> Since the n/groff based openvpn.8 format is fairly cumbersome to edit,
> we agreed at the 2019 Hackathon in Trento to move the man page into
> something more editing and management friendly.
> 
> This set of patches converts the openvpn.8 file into the
> ReStructuredText format (.rst) which can easily be converted into both
> man and html files using python-docutils.  The advantage of this format
> is that it is easy to edit in any plain text editors and displays
> reasonably well in any terminals.  And it will be easier to review
> patches man page updates sent to the mailing list.
> 
> To avoid everyone building the OpenVPN source tarball to have the full
> python stack available, the doc/Makefile.am file has been adopted to
> generate the man and html files when we create the source tarball
> we distribute in releases.  Only users only pulling down the source
> directly from git will need to have python-docutils available.
> 
> As I worked my way through the man page, there were several things
> which was less good.  Lots of options where misplaced in not related
> sections, a few options where documented several places.  And lots
> of the sections overlapped quite a bit.  From patch 5/11 splits
> the whole man page into several smaller files; one file per section.
> This is all tied into a single man-page/html file when running the
> rst2man/rst2html tools.  The following patches just cleans up and
> moves some options into more suitable sections.
> 
> 
> I will continue to update my own git branch containing this work as
> review comments come in until this is merged into master.  You can
> find it here:
> 
>   https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting/doc
> 

So sf.net mailing list is grumpy at me for sending a large mail, patch 5/11 is
currently waiting to be unlocked by the list admin.  In the mean time, here's
the patch:

<https://gitlab.com/dazo/openvpn/-/commit/6eef9d3b1989166542805644cbc74baa96c72a80.patch>


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH 07/11] doc/man: Move --dhcp-option from client to vpn-network section

2020-06-24 Thread David Sommerseth
Even though the --dhcp-option is only useful in a client context, it is
more related to configuration of the VPN network interface and the
related settings.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/client-options.rst  | 69 
 doc/man-sections/vpn-network-options.rst | 69 
 2 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index d6f9e6aa..966ede1e 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -146,75 +146,6 @@ configuration.
 --connect-timeout n
   See ``--server-poll-timeout``.
 
---dhcp-option args
-  Set additional network settings via DHCP.  On Windows, this is parsed by
-  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
-  options can be picked up by a ``--up`` script or plug-in if it has been
-  pushed by the OpenVPN server.  The option will then be saved in the
-  client's environment before the ``--up`` script is called, under the name
-  :code:`foreign_option_{n}`.
-
-  Valid syntax:
-  ::
-
- dhcp-options type [parm]
-
-  :code:`DOMAIN` ``name``
-Set Connection-specific DNS Suffix to :code:`name`.
-
-  :code:`DNS` ``address``
-Set primary domain name server IPv4 or IPv6 address.
-Repeat this option to set secondary DNS server addresses.
-
-Note: DNS IPv6 servers are currently set using netsh (the existing
-DHCP code can only do IPv4 DHCP, and that protocol only permits
-IPv4 addresses anywhere). The option will be put into the
-environment, so an ``--up`` script could act upon it if needed.
-
-  :code:`WINS` ``address``
-Set primary WINS server address (NetBIOS over TCP/IP Name Server).
-Repeat this option to set secondary WINS server addresses.
-
-  :code:`NBDD` ``address``
-Set primary NBDD server address (NetBIOS over TCP/IP Datagram
-Distribution Server). Repeat this option to set secondary NBDD
-server addresses.
-
-  :code:`NTP` ``address``
-Set primary NTP server address (Network Time Protocol).
-Repeat this option to set secondary NTP server addresses.
-
-  :code:`NBT` ``type``
-Set NetBIOS over TCP/IP Node type. Possible options:
-
-:code:`1`
-  b-node (broadcasts)
-
-:code:`2`
-  p-node (point-to-point name queries to a WINS server)
-
-:code:`4`
-  m-node (broadcast then query name server)
-
-:code:`8`
-  h-node (query name server, then broadcast).
-
-  :code:`NBS` ``scope-id``
-Set NetBIOS over TCP/IP Scope. A NetBIOS Scope ID provides an
-extended naming service for the NetBIOS over TCP/IP (Known as NBT)
-module. The primary purpose of a NetBIOS scope ID is to isolate
-NetBIOS traffic on a single network to only those nodes with the
-same NetBIOS scope ID. The NetBIOS scope ID is a character string
-that is appended to the NetBIOS name. The NetBIOS scope ID on two
-hosts must match, or the two hosts will not be able to communicate.
-The NetBIOS Scope ID also allows computers to use the same computer
-name, as they have different scope IDs. The Scope ID becomes a part
-of the NetBIOS name, making the name unique. (This description of
-NetBIOS scopes courtesy of neonsu...@abyss.com)
-
-  :code:`DISABLE-NBT`
-Disable Netbios-over-TCP/IP.
-
 --explicit-exit-notify n
   In UDP client mode or point-to-point mode, send server/peer an exit
   notification if tunnel is restarted or OpenVPN process is exited. In
diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index fc18676e..d75cf540 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -88,6 +88,75 @@ routing.
   the TUN/TAP device used with ``--dev`` does not begin with :code:`tun`
   or :code:`tap`.
 
+--dhcp-option args
+  Set additional network settings via DHCP.  On Windows, this is parsed by
+  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
+  options can be picked up by a ``--up`` script or plug-in if it has been
+  pushed by the OpenVPN server.  The option will then be saved in the
+  client's environment before the ``--up`` script is called, under the name
+  :code:`foreign_option_{n}`.
+
+  Valid syntax:
+  ::
+
+ dhcp-options type [parm]
+
+  :code:`DOMAIN` ``name``
+Set Connection-specific DNS Suffix to :code:`name`.
+
+  :code:`DNS` ``address``
+Set primary domain name server IPv4 or IPv6 address.
+Repeat this option to set secondary DNS server addresses.
+
+Note: DNS IPv6 servers are currently set using netsh (the existing
+DHCP code can only do IPv4 DHCP, and that protocol only permits
+IPv4 addresses anywhere). The option will be put

[Openvpn-devel] [PATCH 11/11] doc/man: Cleaned up the examples

2020-06-24 Thread David Sommerseth
Removed a lot of outdated information.  The loading of the tun module is
not needed on current Linux distributions; it is automatically loaded
when needed.

Also removed all the iptables references and rather refer the reader to
figure out how firewalling is configured on their system.  The reason is
that iptables is moving towards being deprecated in faviour of
nftables/nft.  In addition many Linux distributions provide their own
wrappers around it (ufw, firewalld, to mention a couple).  In addition
it makes the man page less Linux-centric.

The only Linux specific reference left is configuration of IP
forwarding.  But extended the text to ask the reader to find the
preferred way of configuring IP forwarding in a persistent way.  Many
Linux distributions uses their own set of network configuration tools as
well (NetworkManager, systemd-networkd, netplan, to mention a few).

The rest of the instructions should be fairly OS neutral and is a quick
introduction how to get tunnels configured and gradually expand the
configuration and improve the security along the way.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/examples.rst | 105 --
 1 file changed, 11 insertions(+), 94 deletions(-)

diff --git a/doc/man-sections/examples.rst b/doc/man-sections/examples.rst
index 0bea7f5a..ecc2a29f 100644
--- a/doc/man-sections/examples.rst
+++ b/doc/man-sections/examples.rst
@@ -7,32 +7,12 @@ installed OpenVPN, consult the INSTALL file included in the 
OpenVPN
 distribution.
 
 
-TUN/TAP Setup:
---
-
-If you are using Linux 2.4 or higher, make the tun device node and load
-the tun module:
-
-::
-
-mknod /dev/net/tun c 10 200
-modprobe tun
-
-If you installed from RPM, the ``mknod`` step may be omitted, because
-the RPM install does that for you.
-
-Only Linux 2.4 and newer are supported.
-
-For other platforms, consult the INSTALL file at
-https://openvpn.net/community-resources/the-standard-install-file-included-in-the-source-distribution/
-for more information.
-
-
 Firewall Setup:
 ---
 
 If firewalls exist between the two machines, they should be set to
-forward UDP port 1194 in both directions. If you do not have control
+forward the port OpenVPN is configured to use, in both directions.
+The default for OpenVPN is 1194/udp.  If you do not have control
 over the firewalls between the two machines, you may still be able to
 use OpenVPN by adding ``--ping 15`` to each of the ``openvpn`` commands
 used below in the examples (this will cause each peer to send out a UDP
@@ -40,13 +20,8 @@ ping to its remote peer once every 15 seconds which will 
cause many
 stateful firewalls to forward packets in both directions without an
 explicit firewall rule).
 
-If you are using a Linux iptables-based firewall, you may need to enter
-the following command to allow incoming packets on the TUN device:
-
-:code:`iptables -A INPUT -i tun+ -j ACCEPT`
-
-See the firewalls section below for more information on configuring
-firewalls for use with OpenVPN.
+Please see your operating system guides for how to configure the firewall
+on your systems.
 
 
 VPN Address Setup:
@@ -239,10 +214,14 @@ enable routing:
 
 echo 1 > /proc/sys/net/ipv4/ip_forward
 
-and enable TUN packet forwarding through the firewall:
-::
+This setting is not persistent.  Please see your operating systems
+documentation how to properly configure IP forwarding, which is also
+persistent through system boots.
 
-   iptables -A FORWARD -i tun+ -j ACCEPT
+If you system is configured with a firewall.  Please see your operating
+systems guide on how to configure the firewall.  You typically want to
+allow traffic coming from and going to the tun/tap adapter OpenVPN is
+configured to use.
 
 On bob:
 ::
@@ -260,65 +239,3 @@ Now any machine on the *10.0.0.0/24* subnet can access any 
machine on the
 In a production environment, you could put the route command(s) in a
 script and execute with the ``--up`` option.
 
-
-FIREWALLS
-=
-
-OpenVPN's usage of a single UDP port makes it fairly firewall-friendly.
-You should add an entry to your firewall rules to allow incoming OpenVPN
-packets. On Linux 2.4+:
-::
-
-   iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT
-
-This will allow incoming packets on UDP port :code:`1194` (OpenVPN's
-default UDP port) from an OpenVPN peer at :code:`1.2.3.4`.
-
-If you are using HMAC-based packet authentication (the default in any of
-OpenVPN's secure modes), having the firewall filter on source address
-can be considered optional, since HMAC packet authentication is a much
-more secure method of verifying the authenticity of a packet source. In
-that case:
-::
-
-   iptables -A INPUT -p udp --dport 1194 -j ACCEPT
-
-would be adequate and would not render the host inflexible with respect
-to its peer having a dynamic IP address.
-
-OpenVPN also works well on stateful firewalls. In some cases, you may
-not need to add any static rules to the firewall l

[Openvpn-devel] [PATCH 10/11] doc/man: Moved --reneg-* options to its own section

2020-06-24 Thread David Sommerseth
The options related to renegotiation of the data channel encryption key
is not really a link option.  As the renegotiation is encryption
related but doesn't really fit into the generic, tls or pkcs11 sections,
add it into its own section.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/encryption-options.rst |  1 +
 doc/man-sections/link-options.rst   | 47 --
 doc/man-sections/renegotiation.rst  | 53 +
 3 files changed, 54 insertions(+), 47 deletions(-)
 create mode 100644 doc/man-sections/renegotiation.rst

diff --git a/doc/man-sections/encryption-options.rst 
b/doc/man-sections/encryption-options.rst
index 5e99c52f..42c80eb8 100644
--- a/doc/man-sections/encryption-options.rst
+++ b/doc/man-sections/encryption-options.rst
@@ -130,6 +130,7 @@ Generating key material
access to this file will be to generate auth tokens that the OpenVPN
server will accept as valid.
 
+.. include:: renegotiation.rst
 .. include:: tls-options.rst
 .. include:: pkcs11-options.rst
 
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index 5f75c5f3..43e33176 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -284,53 +284,6 @@ the local and the remote host.
   and has been used since version 2.0-beta17. Previous versions used port
   5000 as the default.
 
---reneg-bytes n
-  Renegotiate data channel key after ``n`` bytes sent or received
-  (disabled by default with an exception, see below). OpenVPN allows the
-  lifetime of a key to be expressed as a number of bytes
-  encrypted/decrypted, a number of packets, or a number of seconds. A key
-  renegotiation will be forced if any of these three criteria are met by
-  either peer.
-
-  If using ciphers with cipher block sizes less than 128-bits,
-  ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly
-  disabled by setting the value to :code:`0`, but this is
-  **HIGHLY DISCOURAGED** as this is designed to add some protection against
-  the SWEET32 attack vector. For more information see the ``--cipher``
-  option.
-
---reneg-pkts n
-  Renegotiate data channel key after **n** packets sent and received
-  (disabled by default).
-
---reneg-sec args
-  Renegotiate data channel key after at most ``max`` seconds
-  (default :code:`3600`) and at least ``min`` seconds (default is 90% of
-  ``max`` for servers, and equal to ``max`` for clients).
-  ::
-
- reneg-sec max [min]
-
-  The effective ``--reneg-sec`` value used is per session
-  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
-  servers, or just 3600 for clients.
-
-  When using dual-factor authentication, note that this default value may
-  cause the end user to be challenged to reauthorize once per hour.
-
-  Also, keep in mind that this option can be used on both the client and
-  server, and whichever uses the lower value will be the one to trigger
-  the renegotiation. A common mistake is to set ``--reneg-sec`` to a
-  higher value on either the client or server, while the other side of the
-  connection is still using the default value of :code:`3600` seconds,
-  meaning that the renegotiation will still occur once per :code:`3600`
-  seconds. The solution is to increase --reneg-sec on both the client and
-  server, or set it to :code:`0` on one side of the connection (to
-  disable), and to your chosen value on the other side.
-
 --rport port
   Set TCP/UDP port number or name used by the ``--remote`` option. The
   port can also be set directly using the ``--remote`` option.
diff --git a/doc/man-sections/renegotiation.rst 
b/doc/man-sections/renegotiation.rst
new file mode 100644
index ..aaede4eb
--- /dev/null
+++ b/doc/man-sections/renegotiation.rst
@@ -0,0 +1,53 @@
+Data Channel Renegotiation
+--
+
+When running OpenVPN in client/server mode, the data channel will use a
+separate ephemeral encryption key which is rotated at regular intervals.
+
+--reneg-bytes n
+  Renegotiate data channel key after ``n`` bytes sent or received
+  (disabled by default with an exception, see below). OpenVPN allows the
+  lifetime of a key to be expressed as a number of bytes
+  encrypted/decrypted, a number of packets, or a number of seconds. A key
+  renegotiation will be forced if any of these three criteria are met by
+  either peer.
+
+  If using ciphers with cipher block sizes less than 128-bits,
+  ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly
+  disabled by setting the value to :code:`0`, but this is
+  **HIGHLY DISCOURAGED** as this is designed to add some protection against
+  the SWEET32 attack vector. For more information see the ``--cipher``
+  option.
+
+--reneg-pkts n
+  Renegotiate data channel key after **n** packets sent and received
+  (disabled

[Openvpn-devel] [PATCH 04/11] doc/man: Remove unsupported options in OpenVPN 2.5

2020-06-24 Thread David Sommerseth
This removes the options from the man page which is enlisted as
deprecated options in OpenVPN 2.5.  To provide some history, a short
summary of why they were removed has been put into a new file which is
included into its own "UNSUPPORTED OPTIONS" section in the man page.

Signed-off-by: David Sommerseth 
---
 doc/openvpn.8.rst   | 144 +---
 doc/unsupported-options.rst |  33 +
 2 files changed, 35 insertions(+), 142 deletions(-)
 create mode 100644 doc/unsupported-options.rst

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index fc3ecdb8..713cd309 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -454,9 +454,7 @@ Tunnel Options:
 the client's tun interface always points to the local endpoint of the
 server's tun interface. This mode allocates a single IP address per
 connecting client. Only use when none of the connecting clients are
-Windows systems. This mode is functionally equivalent to the
-``--ifconfig-pool-linear`` directive which is available in OpenVPN 2.0,
-is deprecated and will be removed in OpenVPN 2.5
+Windows systems.
 
   :code:`subnet`
 Use a subnet rather than a point-to-point topology by
@@ -2184,17 +2182,6 @@ fast hardware. SSL/TLS authentication must be used in 
this mode.
   receive the given IP address. If you want guaranteed assignment, use
   ``--ifconfig-push``
 
---ifconfig-pool-linear
-  **DEPRECATED** This option will be removed in OpenVPN 2.5
-
-  Modifies the ``--ifconfig-pool`` directive to allocate individual TUN
-  interface addresses for clients rather than /30 subnets.
-
-  *NOTE:*   This option is incompatible with Windows clients.
-
-  This option is deprecated, and should be replaced with ``--topology
-  p2p`` which is functionally equivalent.
-
 --ifconfig-push args
   Push virtual IP endpoints for client tunnel, overriding the
   ``--ifconfig-pool`` dynamic allocation.
@@ -2668,17 +2655,6 @@ fast hardware. SSL/TLS authentication must be used in 
this mode.
   authentication module/script MUST have logic to detect this condition
   and respond accordingly.
 
---client-cert-not-required
-  **DEPRECATED** This option will be removed in OpenVPN 2.5
-
-  Don't require client certificate, client will authenticate using
-  username/password only. Be aware that using this directive is less
-  secure than requiring certificates from all clients.
-
-  **Please note:** This is replaced by ``--verify-client-cert`` which
-  allows for more flexibility. The option ``--verify-client-cert none`` is
-  functionally equivalent to ``--client-cert-not-required``
-
 --verify-client-cert mode
   Specify whether the client is required to supply a valid certificate.
 
@@ -3178,41 +3154,6 @@ These options are meaningful for both Static & 
TLS-negotiated key modes
   ``--show-engines`` standalone option to list the crypto engines which
   are supported by OpenSSL.
 
---no-replay
-  **DEPRECATED** This option will be removed in OpenVPN 2.5.
-
-  (Advanced) Disable OpenVPN's protection against replay attacks. Don't
-  use this option unless you are prepared to make a tradeoff of greater
-  efficiency in exchange for less security.
-
-  OpenVPN provides datagram replay protection by default.
-
-  Replay protection is accomplished by tagging each outgoing datagram with
-  an identifier that is guaranteed to be unique for the key being used.
-  The peer that receives the datagram will check for the uniqueness of the
-  identifier. If the identifier was already received in a previous
-  datagram, OpenVPN will drop the packet. Replay protection is important
-  to defeat attacks such as a SYN flood attack, where the attacker listens
-  in the wire, intercepts a TCP SYN packet (identifying it by the context
-  in which it occurs in relation to other packets), then floods the
-  receiving peer with copies of this packet.
-
-  OpenVPN's replay protection is implemented in slightly different ways,
-  depending on the key management mode you have selected.
-
-  In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses
-  a 64 bit unique identifier that combines a time stamp with an
-  incrementing sequence number.
-
-  When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses
-  only a 32 bit sequence number without a time stamp, since OpenVPN can
-  guarantee the uniqueness of this value for each key. As in IPSec, if the
-  sequence number is close to wrapping back to zero, OpenVPN will trigger
-  a new key exchange.
-
-  To check for replays, OpenVPN uses the *sliding window* algorithm used
-  by IPSec.
-
 --replay-window args
   Modify the replay protection sliding-window size and time window.
 
@@ -3311,27 +3252,6 @@ These options are meaningful for both Static & 
TLS-negotiated key modes
   default) and you are using either ``--secret`` (shared-secret key mode)
   or TLS mode with ``--tls-auth``.
 
---no-iv
-  **DEPRECATED** This option will be remo

[Openvpn-devel] [PATCH 03/11] doc/man: Move profiles section

2020-06-24 Thread David Sommerseth
The  profile documentation has been enlisted in between all
the other OpenVPN options.  As  is not strictly an option by
itself but a grouping mechanism, move it into its own section in the man
page.  This also makes the HTML rendering look much nicer and better
structured.

Signed-off-by: David Sommerseth 
---
 doc/openvpn.8.rst | 149 --
 1 file changed, 78 insertions(+), 71 deletions(-)

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index 4627a7d3..fc3ecdb8 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -204,77 +204,6 @@ Tunnel Options:
   prevent DNS caching. For example, "foo.bar.gov" would be modified to
   ".foo.bar.gov".
 
-
-  Define a client connection profile. Client connection profiles are
-  groups of OpenVPN options that describe how to connect to a given
-  OpenVPN server. Client connection profiles are specified within an
-  OpenVPN configuration file, and each profile is bracketed by
-   and .
-
-  An OpenVPN client will try each connection profile sequentially until it
-  achieves a successful connection.
-
-  ``--remote-random`` can be used to initially "scramble" the connection
-  list.
-
-  Here is an example of connection profile usage:
-  ::
-
- client
- dev tun
-
- 
- remote 198.19.34.56 1194 udp
- 
-
- 
- remote 198.19.34.56 443 tcp
- 
-
- 
- remote 198.19.34.56 443 tcp
- http-proxy 192.168.0.8 8080
- 
-
- 
- remote 198.19.36.99 443 tcp
- http-proxy 192.168.0.8 8080
- 
-
- persist-key
- persist-tun
- pkcs12 client.p12
- remote-cert-tls server
- verb 3
-
-  First we try to connect to a server at 198.19.34.56:1194 using UDP. If
-  that fails, we then try to connect to 198.19.34.56:443 using TCP. If
-  that also fails, then try connecting through an HTTP proxy at
-  192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect
-  through the same proxy to a server at 198.19.36.99:443 using TCP.
-
-  The following OpenVPN options may be used inside of a 
-  block:
-
-  ``bind``, ``connect-retry``, ``connect-retry-max``, ``connect-timeout``,
-  ``explicit-exit-notify``, ``float``, ``fragment``, ``http-proxy``,
-  ``http-proxy-option``, ``key-direction``, ``link-mtu``, ``local``,
-  ``lport``, ``mssfix``, ``mtu-disc``, ``nobind``, ``port``, ``proto``,
-  ``remote``, ``rport``, ``socks-proxy``, ``tls-auth``, ``tls-crypt``,
-  ``tun-mtu and``, ``tun-mtu-extra``.
-
-  A defaulting mechanism exists for specifying options to apply to all
-   profiles. If any of the above options (with the
-  exception of ``remote`` ) appear outside of a  block,
-  but in a configuration file which has one or more 
-  blocks, the option setting will be used as a default for
-   blocks which follow it in the configuration file.
-
-  For example, suppose the ``nobind`` option were placed in the sample
-  configuration file above, near the top of the file, before the first
-   block. The effect would be as if ``nobind`` were
-  declared in all  blocks below it.
-
 --proto-force p
   When iterating through connection profiles, only consider profiles using
   protocol ``p`` (:code:`tcp` \| :code:`udp`).
@@ -5400,6 +5329,84 @@ instances.
 
 
 
+CONNECTION PROFILES
+===
+
+Client configuration files may contain multiple remote servers which
+it will attempt to connect against.  But there are some configuration
+options which are related to specific ``--remote`` options.  For these
+use cases, connection profiles is the solution.
+
+By enacpulating the ``--remote`` option and related options within
+ and , these options are handled as a
+group.
+
+An OpenVPN client will try each connection profile sequentially until it
+achieves a successful connection.
+
+``--remote-random`` can be used to initially "scramble" the connection
+list.
+
+Here is an example of connection profile usage:
+::
+
+   client
+   dev tun
+
+   
+   remote 198.19.34.56 1194 udp
+   
+
+   
+   remote 198.19.34.56 443 tcp
+   
+
+   
+   remote 198.19.34.56 443 tcp
+   http-proxy 192.168.0.8 8080
+   
+
+   
+   remote 198.19.36.99 443 tcp
+   http-proxy 192.168.0.8 8080
+   
+
+   persist-key
+   persist-tun
+   pkcs12 client.p12
+   remote-cert-tls server
+   verb 3
+
+First we try to connect to a server at 198.19.34.56:1194 using UDP. If
+that fails, we then try to connect to 198.19.34.56:443 using TCP. If
+that also fails, then try connecting through an HTTP proxy at
+192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect
+through the same proxy to a server at 198.19.36.99:443 using TCP.
+
+The following OpenVPN options may be used inside of a 
+block:
+
+``bind``, ``connect-retry``, ``connect-retry-max``, ``connect-timeout``,
+``explicit-exit-notify``, ``float``, ``fragment``, ``http-proxy``,
+``http-proxy-option``, ``key-direction``, ``link-mtu``, ``local``,
+``lpo

[Openvpn-devel] [PATCH 09/11] doc/man: Move some options from link to advanced section

2020-06-24 Thread David Sommerseth
Moved --persist-local-ip, --persist-remote-ip, --rcvbuf, --sndbuf
and --shaper from the link options section to the advanced section.

The rationale is that these options are not common to use and is for
more advanced use cases where special tweaking is required.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/advanced-options.rst | 40 +++
 doc/man-sections/link-options.rst | 40 ---
 2 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/doc/man-sections/advanced-options.rst 
b/doc/man-sections/advanced-options.rst
index 9e59677d..262e568c 100644
--- a/doc/man-sections/advanced-options.rst
+++ b/doc/man-sections/advanced-options.rst
@@ -34,6 +34,14 @@ used when debugging or testing out special usage scenarios.
 --bcast-buffers n
   Allocate ``n`` buffers for broadcast datagrams (default :code:`256`).
 
+--persist-local-ip
+  Preserve initially resolved local IP address and port number across
+  ``SIGUSR1`` or ``--ping-restart`` restarts.
+
+--persist-remote-ip
+  Preserve most recently authenticated remote IP address and port number
+  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
+
 --prng args
   *(Advanced)* Change the PRNG (Pseudo-random number generator) parameters
 
@@ -51,6 +59,38 @@ used when debugging or testing out special usage scenarios.
   RAND\_bytes function instead for all of OpenVPN's pseudo-random number
   needs.
 
+--rcvbuf size
+  Set the TCP/UDP socket receive buffer size. Defaults to operation system
+  default.
+
+--shaper n
+  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
+  TCP/UDP port. Note that this will only work if mode is set to
+  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
+  this option on both peers.
+
+  OpenVPN uses the following algorithm to implement traffic shaping: Given
+  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
+  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
+  seconds before queuing the next write.
+
+  It should be noted that OpenVPN supports multiple tunnels between the
+  same two peers, allowing you to construct full-speed and reduced
+  bandwidth tunnels at the same time, routing low-priority data such as
+  off-site backups over the reduced bandwidth tunnel, and other data over
+  the full-speed tunnel.
+
+  Also note that for low bandwidth tunnels (under 1000 bytes per second),
+  you should probably use lower MTU values as well (see above), otherwise
+  the packet latency will grow so large as to trigger timeouts in the TLS
+  layer and TCP connections running over the tunnel.
+
+  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
+  default.
+
 --tcp-queue-limit n
   Maximum number of output packets queued before TCP (default :code:`64`).
 
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index ca719c75..5f75c5f3 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -173,14 +173,6 @@ the local and the remote host.
 --passtos
   Set the TOS field of the tunnel packet to what the payload's TOS is.
 
---persist-local-ip
-  Preserve initially resolved local IP address and port number across
-  ``SIGUSR1`` or ``--ping-restart`` restarts.
-
---persist-remote-ip
-  Preserve most recently authenticated remote IP address and port number
-  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
-
 --ping n
   Ping remote over the TCP/UDP control channel if no packets have been
   sent for at least ``n`` seconds (specify ``--ping`` on both peers to
@@ -292,10 +284,6 @@ the local and the remote host.
   and has been used since version 2.0-beta17. Previous versions used port
   5000 as the default.
 
---rcvbuf size
-  Set the TCP/UDP socket receive buffer size. Defaults to operation system
-  default.
-
 --reneg-bytes n
   Renegotiate data channel key after ``n`` bytes sent or received
   (disabled by default with an exception, see below). OpenVPN allows the
@@ -439,34 +427,6 @@ the local and the remote host.
   default) and you are using either ``--secret`` (shared-secret key mode)
   or TLS mode with ``--tls-auth``.
 
---shaper n
-  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
-  TCP/UDP port. Note that this will only work if mode is set to
-  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
-  this option on both peers.
-
-  OpenVPN uses the following algorithm to implement traffic shaping: Given
-  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
-  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
-  seconds before queuing the next write.
-
-  It should be noted that OpenVPN supports multiple tunnels between the
-  same two peers, allowing you to construct full-speed and reduced
-  bandwidth tunnels

[Openvpn-devel] [PATCH 08/11] doc/man: Mark compression options as deprecated

2020-06-24 Thread David Sommerseth
Due to the VORACLE attack vector, compression in general is deprecated.
Make this clear in the man page.

Also remove an incorrect statement claiming --compress lzo is compatible
with --comp-lzo.  It is not, as --compress lzo uses a different
compression framing than --comp-lzo.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/protocol-options.rst | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index 37e55eb7..5bc072af 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -54,13 +54,13 @@ configured in a compatible way between both the local and 
remote side.
   Set ``alg`` to :code:`none` to disable encryption.
 
 --compress algorithm
-  Enable a compression algorithm.
+  **DEPRECATED** Enable a compression algorithm.  Compression is generally
+  not recommended.  VPN tunnels which uses compression are suspectible to
+  the VORALCE attack vector.
 
   The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`, or empty.
   LZO and LZ4 are different compression algorithms, with LZ4 generally
-  offering the best performance with least CPU usage. For backwards
-  compatibility with OpenVPN versions before v2.4, use :code:`lzo` (which
-  is identical to the older option ``--comp-lzo yes``).
+  offering the best performance with least CPU usage.
 
   If the ``algorithm`` parameter is empty, compression will be turned off,
   but the packet framing for compression will still be enabled, allowing a
@@ -77,8 +77,9 @@ configured in a compatible way between both the local and 
remote side.
   *not* enable compression.
 
 --comp-lzo mode
-  *DEPRECATED* This option will be removed in a future OpenVPN release.
-  Use the newer ``--compress`` instead.
+  **DEPRECATED** Enable LZO compression algorithm.  Compression is
+  generally not recommended.  VPN tunnels which uses compression are
+  suspectible to the VORALCE attack vector.
 
   Use LZO compression -- may add up to 1 byte per packet for incompressible
   data. ``mode`` may be :code:`yes`, :code:`no`, or :code:`adaptive`
@@ -104,9 +105,9 @@ configured in a compatible way between both the local and 
remote side.
   link, the second sets the client side.
 
 --comp-noadapt
-  When used in conjunction with ``--comp-lzo``, this option will disable
-  OpenVPN's adaptive compression algorithm. Normally, adaptive compression
-  is enabled with ``--comp-lzo``.
+  **DEPRECATED** When used in conjunction with ``--comp-lzo``, this option
+  will disable OpenVPN's adaptive compression algorithm. Normally, adaptive
+  compression is enabled with ``--comp-lzo``.
 
   Adaptive compression tries to optimize the case where you have
   compression enabled, but you are sending predominantly incompressible
-- 
2.26.0



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


[Openvpn-devel] [PATCH 06/11] doc/man: Move --bind from generic to link section

2020-06-24 Thread David Sommerseth
This is more related to the configuration of the link, plus --nobind is
already placed in the link section.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/generic-options.rst | 7 ---
 doc/man-sections/link-options.rst| 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/man-sections/generic-options.rst 
b/doc/man-sections/generic-options.rst
index cd048fa5..35985afc 100644
--- a/doc/man-sections/generic-options.rst
+++ b/doc/man-sections/generic-options.rst
@@ -22,13 +22,6 @@ which mode OpenVPN is configured as.
   This directive does not affect the ``--http-proxy`` username/password.
   It is always cached.
 
---bind keywords
-  Bind to local address and port. This is the default unless any of
-  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
-
-  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
-  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
-
 --cd dir
   Change directory to ``dir`` prior to reading any files such as
   configuration files, key files, scripts, etc. ``dir`` should be an
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index 595f7f69..ca719c75 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -3,6 +3,13 @@ Link Options
 This link options section covers options related to the connection between
 the local and the remote host.
 
+--bind keywords
+  Bind to local address and port. This is the default unless any of
+  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
+
+  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
+  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
+
 --float
   Allow remote peer to change its IP address and/or port number, such as
   due to DHCP (this is the default if ``--remote`` is not used).
-- 
2.26.0



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


[Openvpn-devel] [PATCH 00/11] man-page overhaul project

2020-06-24 Thread David Sommerseth
Hi,

This is the first real review round of the man-page overhaul project.
Since the n/groff based openvpn.8 format is fairly cumbersome to edit,
we agreed at the 2019 Hackathon in Trento to move the man page into
something more editing and management friendly.

This set of patches converts the openvpn.8 file into the
ReStructuredText format (.rst) which can easily be converted into both
man and html files using python-docutils.  The advantage of this format
is that it is easy to edit in any plain text editors and displays
reasonably well in any terminals.  And it will be easier to review
patches man page updates sent to the mailing list.

To avoid everyone building the OpenVPN source tarball to have the full
python stack available, the doc/Makefile.am file has been adopted to
generate the man and html files when we create the source tarball
we distribute in releases.  Only users only pulling down the source
directly from git will need to have python-docutils available.

As I worked my way through the man page, there were several things
which was less good.  Lots of options where misplaced in not related
sections, a few options where documented several places.  And lots
of the sections overlapped quite a bit.  From patch 5/11 splits
the whole man page into several smaller files; one file per section.
This is all tied into a single man-page/html file when running the
rst2man/rst2html tools.  The following patches just cleans up and
moves some options into more suitable sections.


I will continue to update my own git branch containing this work as
review comments come in until this is merged into master.  You can
find it here:

  https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting/doc



kind regards,

David Sommerseth
OpenVPN Inc.



David Sommerseth (11):
  doc/man: Add an .rst formatted version of the man page
  doc/man: Replace old man page with generated man page
  doc/man: Move  profiles section
  doc/man: Remove unsupported options in OpenVPN 2.5
  doc/man: Split up and reorganize main man page
  doc/man: Move --bind from generic to link section
  doc/man: Move --dhcp-option from client to vpn-network section
  doc/man: Mark compression options as deprecated
  doc/man: Move some options from link to advanced section
  doc/man: Moved --reneg-* options to its own section
  doc/man: Cleaned up the examples

 .gitignore   |1 +
 INSTALL  |3 +-
 configure.ac |   15 +-
 doc/Makefile.am  |   56 +-
 doc/README.man   |   23 +
 doc/man-sections/advanced-options.rst|  107 +
 doc/man-sections/client-options.rst  |  355 +
 doc/man-sections/connection-profiles.rst |   75 +
 doc/man-sections/encryption-options.rst  |  136 +
 doc/man-sections/examples.rst|  241 +
 doc/man-sections/generic-options.rst |  436 ++
 doc/man-sections/inline-files.rst|   25 +
 doc/man-sections/link-options.rst|  410 ++
 doc/man-sections/log-options.rst |   74 +
 doc/man-sections/management-options.rst  |  136 +
 doc/man-sections/network-config.rst  |9 +
 doc/man-sections/pkcs11-options.rst  |   81 +
 doc/man-sections/plugin-options.rst  |   52 +
 doc/man-sections/protocol-options.rst|  228 +
 doc/man-sections/proxy-options.rst   |   66 +
 doc/man-sections/renegotiation.rst   |   53 +
 doc/man-sections/script-options.rst  |  807 +++
 doc/man-sections/server-options.rst  |  769 +++
 doc/man-sections/signals.rst |   30 +
 doc/man-sections/tls-options.rst |  643 ++
 doc/man-sections/unsupported-options.rst |   33 +
 doc/man-sections/vpn-network-options.rst |  531 ++
 doc/man-sections/windows-options.rst |  245 +
 doc/openvpn.8| 7631 --
 doc/openvpn.8.rst|  169 +
 30 files changed, 5794 insertions(+), 7646 deletions(-)
 create mode 100644 doc/README.man
 create mode 100644 doc/man-sections/advanced-options.rst
 create mode 100644 doc/man-sections/client-options.rst
 create mode 100644 doc/man-sections/connection-profiles.rst
 create mode 100644 doc/man-sections/encryption-options.rst
 create mode 100644 doc/man-sections/examples.rst
 create mode 100644 doc/man-sections/generic-options.rst
 create mode 100644 doc/man-sections/inline-files.rst
 create mode 100644 doc/man-sections/link-options.rst
 create mode 100644 doc/man-sections/log-options.rst
 create mode 100644 doc/man-sections/management-options.rst
 create mode 100644 doc/man-sections/network-config.rst
 create mode 100644 doc/man-sections/pkcs11-options.rst
 create mode 100644 doc/man-sections/plugin-options.rst
 create mode 100644 doc/man-sections/protocol-options.rst
 create mode 100644 doc/man-sections/proxy-options.rst
 create mode 100644 doc/man-sections/renegotiation.rst
 create mode 100644 doc/man-sections/script-options.rst
 create mode 100644 doc/man

Re: [Openvpn-devel] Summary of the community meeting (24th June 2020)

2020-06-24 Thread David Sommerseth
On 24/06/2020 13:10, Samuli Seppänen wrote:
[...snip...]
> Talked about the status of OpenVPN 2.5:
> 
> <https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25>
> 
> Ordex promised to have a look at the async-cc patches this week.
> Plaisthos, dazo and cron2 will follow-up on the review comments to get
> them resolved quickly.
> 
> OpenVPN 2.5 MSI looks surprisingly good. Mattock was able to produce
> tap-windows6 MSM ("merge module") which he then used to produce OpenVPN
> 2.5-based MSI installer. The only significant challenge is adding
> code-signing support to openvpn-build/generic.
> 
> Automating MSI builds also seems easier than expected, given that the
> existing openvpn-build buildslave can perform the actual build and push
> the artifacts to the Windows packager, which can then build and push the
> results to build.openvpn.net.
> 
> Code-vise 2.5-alpha1 is in a good shape, mainly missing

Just a nit-pick; we have not considered an alpha cycle for 2.5.  The first
beta will be released early July according to:
<https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25>

> - compression
> - async cc
> - VRF (which is quite trivial)
> 
> The auth-token fixes are corner-cases and it was agreed that that can be
> resolved between 2.5-alpha1 and 2.5-beta1.

That's also incorrect.  We will resolve these issues between the beta1 and rc1
releases.


-- 
kind regards,

David Sommerseth
OpenVPN Inc



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


[Openvpn-devel] [RFC] Challenges with OpenVPN and configuring DNS

2020-06-23 Thread David Sommerseth
ropose the following bit-mask:

- bit 0 (1)
 Reserved (this is essentially today's IV_PROTO=1)

- bit 1 (2)
 Supports P_DATA_V2 (IV_PROTO=2 in current implementations)

- bit 2 (4) - Extended DNS support
 Supports the additional DNS options: DOMAIN-SEARCH, DOMAIN-ROUTE,
 DNSSEC.  DOMAIN will only allowed once.

- bit 3 (8) - Split DNS
 Client can configure split DNS on the host

 - bit 4 (16) - Blocking/Exclusive DNS
 Client can configure exclusive DNS with blocking (exclusive)

 - bit 5 (32) - DNSSEC
  Client can modify DNSSEC configuration for VPN DNS resolver
  based on the DNSSEC option.

We have looked through the other IV_* options as well, and we can also
consider to allocate a bit for IV_TCPNL and start a process to deprecate
the dedicated IV_TCPNL variable.  This is to save space in the IV_* already
limited IV buffer.

We considered the compression options as well (IV_LZO, IV_LZ4, IV_LZ4v2
and IV_COMP_STUB*) but believe these should move away from compression
in the future.



Some of these IV_PROTO settings can on some platforms be added into OpenVPN
itself.  But we believe it is good to also allow the --plugin and script
hooks to also facilitate these settings.  This allows a simpler OpenVPN
binary to signal to the server that it intends to support various features.
In this discussion, we also realized this can also be used for the
auth-pending feature as well, which currently is only supported via the
management interface.

We therefore suggests adding yet another OpenVPN option:

--feature-support GROUP TEXT-FLAGS

  * GROUP: dns with these flags:

  - `extended`
sets IV_PROTO bit 2 if not already set.

  - `split-dns`
 sets IV_PROTO bit 3

  - `dns-block`
 sets IV_PROTO bit 4

  - `dnssec`
 sets IV_PROTO bit 5

  * GROUP: auth-pending
This signals to the server which kind of pending authentication
features the client can support

  - `openurl`
Adds `openurl` to IV_SSO

  - `proxyurl`
Adds proxyurl to IV_SSO

  - `crtext`
Adds crtext to IV_SSO


For platform implementations we have considered the following:

* macOS
  Tunnelblick uses external scripts which are well tested and seems to
  work fine.  Will it make sense to implement native DNS configuration
  support into OpenVPN on macOS?  This might mean we need to link OpenVPN
  against some Objective-C code to communicate directly with the network
  configuration APIs.  It could also be possible to implement this as an
  external plug-in, which extends OpenVPN's current behavior.

* Windows
  On Windows we already have a native implementation.  We did not consider
  any alternative approaches here.

* Android
  Has its own implementation in OpenVPN for Android, with ideas
  from the the Windows implementation.  This also facilitates the
  possibilities provided via the VPN API in Android.

* Linux
  Currently uses --up scripts (pull-resolv-conf, update-systemd-resolved)
  and --plugin (NetworkManager).  It is possible to implement a plug-in
  which talks directly to systemd-resolved as well.  Native support
  included would require linking against a D-Bus library, which can become
  pretty invasive.

  There are some advantages to move over to a --plugin
  for systemd-resolved support, as it can interact quicker with the
  service instead of running a script which parses options and does the
  same D-Bus calls to systemd-resolved.  But this will not get a too high
  priority as the script based update-systemd-resolved approach will work
  well too.

  OpenVPN 3 Linux will be extended with native systemd-resolved support
  in a coming release.

* *BSD
  We do not know enough of the capabilities here.  But a both script
  and --plugin solutions can work, especially if facilitating the new
  --feature-support option - where it will be more up to the script/plug-in
  to define what it will be capable of.


--
kind regards,

Arne Schwabe
David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


  1   2   3   4   5   6   7   8   9   10   >