Re: [Openvpn-devel] [PATCH v2 2/5] Implement support for signalling IV_SSO to server
Sorry, I'm loosing grip of my mailing-list-fu ... Managed to reply only to Arne.
On 27/03/2020 21:59, David Sommerseth wrote:
> On 09/11/2019 16:13, Arne Schwabe wrote:
>> Signed-off-by: Arne Schwabe
>> ---
>> src/openvpn/ssl.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
>> index 4455ebb8..cbb87e43 100644
>> --- a/src/openvpn/ssl.c
>> +++ b/src/openvpn/ssl.c
>> @@ -2355,7 +2355,9 @@ push_peer_info(struct buffer *buf, struct tls_session
>> *session)
>> if strncmp(e->string, "UV_", 3)==0
>> || strncmp(e->string, "IV_PLAT_VER=",
>> sizeof("IV_PLAT_VER=")-1)==0)
>>&& session->opt->push_peer_info_detail >= 2)
>> - ||
>> (strncmp(e->string,"IV_GUI_VER=",sizeof("IV_GUI_VER=")-1)==0))
>> + ||
>> (strncmp(e->string,"IV_GUI_VER=",sizeof("IV_GUI_VER=")-1)==0)
>> + ||
>> (strncmp(e->string,"IV_SSO=",sizeof("IV_SSO=")-1)==0)
>> + )
>> && buf_safe(&out, strlen(e->string)+1))
>> {
>> buf_printf(&out, "%s\n", e->string);
>>
>
> Code looks good, smoke tested on RHEL-7 against a test server without any
> issues.
>
> Test 1: openvpn --config test.conf --push-peer-info
> No IV_SSO entry found in server log.
>
> Test 2: openvpn --config test.conf --push-peer-info --setenv IV_SSO 1
> IV_SSO=1 was found in server log
>
> Test 3: openvpn --config test.conf --push-peer-info setenv IV_SSX 1
> No IV_SSO nor IV_SSX found in server log
>
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] Reformat all source files
On 28/03/2020 12:33, Gert Doering wrote: > Hi, > > On Fri, Mar 27, 2020 at 04:24:00PM +0100, David Sommerseth wrote: >> On 16/11/2019 11:28, Arne Schwabe wrote: >>> Over time some patches slipped in that were not 100% complient to uncrustify >>> This rerun fixes those issues > [..] >> Only done quick code review and RHEL-7 build. Changes looks reasonable and >> is >> by far closer to what I would expect our coding style to look like. >> >> Acked-By: David Sommerseth > > ... but it does not apply to current git master...? > > Applying: Reformat all source files > error: patch failed: src/openvpn/tun.c:3418 > error: src/openvpn/tun.c: patch does not apply > Patch failed at 0001 Reformat all source files Ahh, sorry ... I did the reviews based on Arne's github tree [1], so I could compile test them. And I trust him enough to not do any stupid stunts in his tree. His icsopenvpn branch has all of the stuff I've reviewed; that branch rebased against our latest master without any hickups. Unfortunately git apply is (rightfully) super picky about conflicts. Not sure now what would be the best approach forward. Picking the commit contents from a rebased icsopenvpn branch would be one way (I can provide commitish references I reviewed, if needed). Another approach is for Arne to resend rebased patches to ML. As we have several patch series lingering in our mail queue, we should look at alternatives pulling in patches which would go smoother and allow a better flexibility for all of us (submitter, reviewer and committer) while keeping the review and commit process decentralized. But that's a longer discussion we need to take in a different place than this thread. [1] <https://github.com/schwabe/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] [Openvpn-users] Removing --disable-server option from OpenVPN
On 28/02/2020 20:18, Radu Hociung wrote:
> I would recommend that rather than removing the useful bit of
> documentation that is P2MP_SERVER, the developers consider:
>
> 1. Restructure the source tree to split the src/openvpn code into
>src/{common,client,server}
>
> 2. Remove the configure --disable-server option, but add Makefile rules
>to build separate client, server and combined binaries, while
>also enabling distro maintainers to package openvpn-server and
>openvpn-client separately, from the same tarball. The combined
>binary can be used to build drop-in replacement packages.
>
> 3. Improve the test suite to verify the inter-operability of the
>3 binaries.
>
> 4. Separate the manpage into a server and a client edition.
I've not had the capacity to go through your detailed mail too closely. But I
consider these 4 points to be a reasonable TL;DR version.
Yes, this all sounds lovely. But I wonder who will have time to work on such
work? This work will require quite some efforts to avoid duplicating too much
of what already exists in options.c and openvpn.c; which would be the starting
point for such a task.
In addition, such a change has a big possibility to break a lot of existing
configurations via package upgrades - as in this case the unified openvpn will
no longer exists but be split into two different binaries.
To be honest, I think it makes more sense to put efforts into the OpenVPN 3
code base, which already is ready for such a split. On top of getting such a
split in place, you would get a higher performance as the OpenVPN 3 code is
more efficient than OpenVPN 2.x. But OpenVPN 3 does not support all the use
cases OpenVPN 2.x does.
I hate to be so pessimistic, but I doubt any of the current core OpeVPN
community developers will have capacity to get such a job done in the near
future. We already struggle to get the current open patches for review
processed, in addition to get OpenVPN 2.5 ready. More people helping out
reviewing patches thoroughly would certainly help us move forward.
Btw, in regards to the man page. On my plate, in time for the 2.5 release, I
will redo the formatting of the man page from ?roff format to some .rst files
(and parse that to ?roff format during packaging). This is just the first
step to get the man page in an easier editable format than what it is today.
--
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
On 14/04/2020 20:52, Juliusz Sosinowicz wrote: > diff --git a/src/openvpn/cryptoapi.c b/src/openvpn/cryptoapi.c > index 30eba7b2..a82c52ad 100644 > --- a/src/openvpn/cryptoapi.c > +++ b/src/openvpn/cryptoapi.c > @@ -39,6 +39,10 @@ > > #ifdef ENABLE_CRYPTOAPI > > +#ifdef ENABLE_CRYPTO_WOLFSSL > +#error wolfSSL does not support CryptoAPI > +#endif > + Except of the documentation effect, wouldn't it be better to handle that in syshead.h instead? In syshead.h, I see this: -- #if defined(_WIN32) && defined(ENABLE_CRYPTO_OPENSSL) #define ENABLE_CRYPTOAPI #endif -- This is the only place I could find defining this macro. So extending it with && !defined(ENABLE_CRYPTO_WOLFSSL) would eliminate the need to worry about the ENABLE_CRYPTOAPI elsewhere. Has this patch been tested against Windows builds with WolfSSL enabled, like via mingw? -- 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 - v9 beta released
Hi, The OpenVPN 3 Linux v9 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 30, 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) Ubuntu 19.04 is no longer supported upstream, so we do no longer provide builds for this disitribution version. Normally we also have Fedora Rawhide builds available, but there are some issues with the Fedora Rawhide images so it is currently not possible to provide these builds there yet. This may change in coming days. 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: AWS VPC add-on service (openvpn3-addon-aws package) which can be configured on EC2 Linux hosts deployed inside an AWS Virtual Private Cloud (VPC). This allows the host running an OpenVPN 3 Linux client with this service configured to act as a proper VPN gateway for hosts inside the VPC. The AWS service will update the VPC configuration dynamically, adding and removing routes pushed to the VPN client. The openvpn3-service-aws(8) man page contains the configuration details. * Bugfix: openvpn3 session-manage --restart and --resume modes would not respond to re-authentication requests required by the VPN server * Bugfix: openvpn3 session-start and openvpn3 session-manage commands would not handle CTRL-C (SIGINT) situations properly during the connect phase to the remote server or when asking for user input. Prior releases would just leave the VPN session running in the background. To get rid of these background sessions the user had to also use openvpn3 session-manage --disconnect to really stop these lingering sessions. With this update, interrupting the openvpn3 session-start and openvpn3 session-manage operations during the connect phase or when acquiring user input, will result in the running VPN session will be properly shutdown. * SELinux: The policy file needed on hosts with SELinux enabled has been relocated to a more proper location for such extensions, moving it out of /etc/openvpn3/selinux. A slightly modified version of this SELinux policy has also been accepted for inclusion in the upstream SELinux reference policy project. Packagers needs to ensure this policy is not shipped on distributions with a recent enough reference policy. See the GitHub pull-request #209 [1] in the SELinux reference policy project for details. -- kind regards, David Sommerseth OpenVPN Inc [0] <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> [1] <https://github.com/SELinuxProject/refpolicy/pull/209> Source tarballs * OpenVPN 3 Linux v9 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-9_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-9_beta.tar.xz.asc> SHA256 Checksums --- c6d530b660239c80b96e3207fae69839b186704d3416f25f4cd1d8daef12ff36 openvpn3-linux-9_beta.tar.xz ec535ce49e4b957ae54bb717d7a72fb5c89bb4b67c1f0202a4c178e8c8e5674d openvpn3-linux-9_beta.tar.xz.asc git references - git tag: v9_beta git commit: 4e251217750ebf1b268e345815f3df3b154f576f Changes from v8 to v9 ------ David Sommerseth (13): selinux: Clean up SELinux policy selinux: Compress the policy and move install dir build: Rework SELinux logic with --disable-selinux-build addons/aws: Implement proper option parser log/core: Extend CoreDBusLogBase to also set LogGroup docs: Update D-Bus service doc for net.openvpn.v3.netcfg selinux: Further minor improvement to policy module python: Add --dev-node to the list of ignored options docs/man: More rendering improvements to openvpn2(1) vendor: Update to asio-1.14.0 ovpn3cli/session: Handle re-authentication for --resume/--restart ovpn3cli/sessions: Improve SIGINT handling when starting/resuming sessions ovpn3cli/session: Improve user input of credentials Lev Stipakov (5): netcfg/cli.cpp: add missing #ifdef guard Add missing override declaration Update to latest openvpn3-core library addons: Add Amazon Web Service VPC support man: Add conditional man page for openvpn3-service-aws - signature.asc Description: OpenPGP digital signature ___ Open
[Openvpn-devel] [PATCH 1/2] options: Fix failing inline tls-auth/crypt with persist-key
A configuration file using --persist-key and with inlined --tls-auth or --tls-crypt files was failing in check_file_access(). The file argument to check_file_access() contained the key file and not the file name. This was because check_file_access_inline() which calls check_file_access() if the file is not inlined was told the file was not an inline file. The reason the check_file_access_inline() was misled was due to a prior option_postprocess_mutate() call puts these key files into a connection block entry in option_postprocess_mutate_ce(). OpenVPN was modified a long while ago to always use connection blocks in the option structure for simplicity. So the "root" key files would be transferred into a connection entry in this method. When --persist-key is used, option_postprocess_mutate_ce() will load the key file and "convert" the option into an inline option. But in commit cb2e9218f2bc73fa2 this logic had lost the "inline indicator". The result was that the connection entry had the key file content stored in the object but was "tagged" as a normal file (name) not an inline file. Signed-off-by: David Sommerseth --- src/openvpn/options.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 611652fd..a37106ce 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -2936,6 +2936,7 @@ options_postprocess_mutate_ce(struct options *o, struct connection_entry *ce) } ce->tls_auth_file = (char *)in.data; +ce->tls_auth_file_inline = true; } if (ce->tls_crypt_file && !ce->tls_crypt_file_inline) @@ -2948,6 +2949,7 @@ options_postprocess_mutate_ce(struct options *o, struct connection_entry *ce) } ce->tls_crypt_file = (char *)in.data; +ce->tls_crypt_file_inline = true; } } } -- 2.26.0 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 2/2] options: Restore --tls-crypt-v2 inline file capability
Commit cb2e9218f2bc73f re-factored the internal file handling, but
somehow overlooked the --tls-crypt-v2 option processing. It was no
longer possible to load a configuration file with this key file inlined.
There where two issues here. First was that the OPT_P_INLINE flag was
not set, so the option parser rejected --tls-crypt-v2 as inline capable.
Second issue was that the 'streq(p[1], INLINE_FILE_TAG)' check makes no
longer sense, as at this point p[1] contains the file contents. Instead
use the is_inline flag.
Signed-off-by: David Sommerseth
---
src/openvpn/options.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index a37106ce..56c9e411 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -8324,22 +8324,16 @@ add_option(struct options *options,
}
else if (streq(p[0], "tls-crypt-v2") && p[1] && !p[3])
{
-VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_CONNECTION);
+VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_CONNECTION|OPT_P_INLINE);
if (permission_mask & OPT_P_GENERAL)
{
-if (streq(p[1], INLINE_FILE_TAG) && p[2])
-{
-options->tls_crypt_v2_file_inline = p[2];
-}
options->tls_crypt_v2_file = p[1];
+options->tls_crypt_v2_file_inline = is_inline;
}
else if (permission_mask & OPT_P_CONNECTION)
{
-if (streq(p[1], INLINE_FILE_TAG) && p[2])
-{
-options->ce.tls_crypt_v2_file_inline = p[2];
-}
options->ce.tls_crypt_v2_file = p[1];
+options->ce.tls_crypt_v2_file_inline = is_inline;
}
}
else if (streq(p[0], "tls-crypt-v2-verify") && p[1] && !p[2])
--
2.26.0
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] options: fix inlining auth-gen-token-secret file
On 08/05/2020 23:14, Antonio Quartulli wrote:
> With commit ("convert *_inline attributes to bool") the logic for
> signaling when a certain option is inline has been changed.
> Due to an overlook, the auth-gen-token-secret was not converted, thus
> making it impossible to be inlined.
>
> Fix parsing logic and allow auth-gen-token-secret to be inlined as well.
>
> Signed-off-by: Antonio Quartulli
> ---
> src/openvpn/options.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 56c9e411..2d2089e3 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -6981,16 +6981,12 @@ add_option(struct options *options,
> }
>
> }
> -else if (streq(p[0], "auth-gen-token-secret") && p[1] && (!p[2]
> - || (p[2] &&
> streq(p[1], INLINE_FILE_TAG
> +else if (streq(p[0], "auth-gen-token-secret") && p[1] && !p[2])
> {
> -VERIFY_PERMISSION(OPT_P_GENERAL);
> +VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_INLINE);
> options->auth_token_secret_file = p[1];
> +options->auth_token_secret_file_inline = is_inline;
>
> -if (streq(p[1], INLINE_FILE_TAG) && p[2])
> -{
> -options->auth_token_secret_file_inline = p[2];
> -}
> }
> else if (streq(p[0], "client-connect") && p[1])
> {
>
Good to see that braintwister of boolean logic go away. I've only done a
quick compile test and glared at the code change, which all makes sense.
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] get rid of TAG_FILE_INLINE constant
On 08/05/2020 23:23, Antonio Quartulli wrote:
> Now that the whole inline logic has been converted to using bool flags,
> the TAG_FILE_INLINE constant is not useful anymore.
>
> Get rid of the constant as it's now unused and to prevent any future
> developer from mistakenly use it again.
>
> Signed-off-by: Antonio Quartulli
> ---
>
> to be applied after all other fixes, as they remove the few last usages
> of this constant.
>
>
> src/openvpn/common.h | 6 --
> src/openvpn/crypto.c | 2 +-
> 2 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/src/openvpn/common.h b/src/openvpn/common.h
> index 4e6f4809..623b3e0d 100644
> --- a/src/openvpn/common.h
> +++ b/src/openvpn/common.h
> @@ -88,12 +88,6 @@ typedef unsigned long ptr_type;
> */
> #define PUSH_REQUEST_INTERVAL 5
>
> -/*
> - * A sort of pseudo-filename for data provided inline within
> - * the configuration file.
> - */
> -#define INLINE_FILE_TAG "[[INLINE]]"
> -
> /*
> * Script security warning
> */
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 672aa14a..f1a52d8c 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -1189,7 +1189,7 @@ print_key_filename(const char *str, bool is_inline)
> {
> if (is_inline)
> {
> -return INLINE_FILE_TAG;
> +return "[[INLINE]]";
> }
>
> return np(str);
>
This looks promising, but is not complete - and breaking compilation:
$ git grep INLINE_FILE_TAG
src/openvpn/tls_crypt.c:client_filename = INLINE_FILE_TAG;
$ make -j5
[...]
make[3]: Entering directory `/home/davids/devel/OpenVPN/openvpn/src/openvpn'
CC tls_crypt.o
tls_crypt.c: In function ‘tls_crypt_v2_write_client_key_file’:
tls_crypt.c:706:27: error: ‘INLINE_FILE_TAG’ undeclared (first use in this
function)
client_filename = INLINE_FILE_TAG;
^
I haven't dug into if client_filename really needs to be set to INLINE_FILE_TAG.
--
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] tls-crypt-v2: fix testing of inline key
On 10/05/2020 16:00, Antonio Quartulli wrote:
> The inline logic was recently changed by commit
> ("convert *_inline attributes to bool"), however the code testing a
> newly created tls-crypt-v2 client key was not adapted.
>
> Adapt tls-crypt-v2 test routine by properly signaling when the passed
> key is inlined or not.
>
> Signed-off-by: Antonio Quartulli
> ---
> src/openvpn/tls_crypt.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index 484d4d46..a3894d66 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -697,14 +697,14 @@ tls_crypt_v2_write_client_key_file(const char *filename,
> goto cleanup;
> }
>
> -const char *client_filename = filename;
> -const char *client_inline = NULL;
> +const char *client_file = filename;
> +bool client_inline = false;
>
> if (!filename || streq(filename, ""))
> {
> printf("%s\n", BPTR(&client_key_pem));
> -client_filename = INLINE_FILE_TAG;
> -client_inline = (const char *)BPTR(&client_key_pem);
> +client_file = (const char *)BPTR(&client_key_pem);
> +client_inline = true;
> }
> else if (!buffer_write_file(filename, &client_key_pem))
> {
> @@ -717,7 +717,7 @@ tls_crypt_v2_write_client_key_file(const char *filename,
> struct buffer test_wrapped_client_key;
> msg(D_GENKEY, "Testing client-side key loading...");
> tls_crypt_v2_init_client_key(&test_client_key, &test_wrapped_client_key,
> - client_filename, client_inline);
> + client_file, client_inline);
> free_key_ctx_bi(&test_client_key);
>
> /* Sanity check: unwrap and load client key (as "server") */
>
This looks good.
Without this patch, generating tls-crypt-v2-client keys fails.
--
$ ./src/openvpn/openvpn --tls-crypt-v2 tv2-srv --genkey tls-crypt-v2-client
-BEGIN OpenVPN tls-crypt-v2 client key-
OCvS/y1ZC/jDJ6wSkVMITJ7t5kI4XRLRikUP8TTukOtXlLHVwVbkL5Sw7cO+ChAf
RcngI8Zzglk2u3fYmlsfU9W6aBouUeBxjixPamA0Yr4xg15eb30HZU2i6YPkJVIL
iiSU+IlfR694fSEWM/j/+Yy3dOid6/kqUpw6Py5wpGuwMJ2ZKBYq+OQhwQ+HBZvF
ftYMJ1W21wx4hWiNT4EyqlC/WYJJFsOpW67eLHQ6L61tMxrQBdSEMTfrP0vlC8lj
anQMIfaDg7RHVq4oiXiTvrA7EgVJi0dra3DND/OXrtk5SyiDfJ1V2VuQ8fs6IoYf
PHXXGuWYCAfBT+0A/ZQ9Agc1jtvRbyYJxkebCid5xCOV8sDSEBCP/PivP+Mysysk
3kptpJQhJx4FHf65xxvVdxio9VW2fyw5NawYdX1XFtVzro486f++8q32Ma8HtD4V
ZCy39QdjK5SzNXKO3Q1Vun3IVtrCA6TMfoyHMkTYcnWkr0a4t47u9tefIJmcwmF5
iBMvKGoEQqjM+Xll9Vqi1FmW35JaQXz9gE8YXi+CC2vB3jrW07W9Xg+m9E6qhxv7
x3wTWRvHDeGaCJlQOO3QVClQMcsryLmBe7Dev8ido54JEAGVHkf0kfC/7E+yFgDq
PMFg99QKQph2HlLS8NOUg5RTgRGkg0VWj+paaOQ7Vej77io9M/1yR4TtyDxovfgN
AZFUlRNuCd7sGHDmwHKA0giaAgvfDpCodQEr
-END OpenVPN tls-crypt-v2 client key-
Mon May 11 14:16:24 2020 crypto_pem_decode: PEM decode failed
Mon May 11 14:16:24 2020 ERROR: OpenVPN tls-crypt-v2 client key pem decode
failed
Mon May 11 14:16:24 2020 ERROR: invalid tls-crypt-v2 client key format
Mon May 11 14:16:24 2020 Exiting due to fatal error
--------------
With this patch, the error messages below the generated key is gone. And
since the code changes are not surprising, this is good to go.
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] get rid of TAG_FILE_INLINE constant
On 08/05/2020 23:23, Antonio Quartulli wrote:
> Now that the whole inline logic has been converted to using bool flags,
> the TAG_FILE_INLINE constant is not useful anymore.
>
> Get rid of the constant as it's now unused and to prevent any future
> developer from mistakenly use it again.
>
> Signed-off-by: Antonio Quartulli
> ---
>
> to be applied after all other fixes, as they remove the few last usages
> of this constant.
>
>
> src/openvpn/common.h | 6 --
> src/openvpn/crypto.c | 2 +-
> 2 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/src/openvpn/common.h b/src/openvpn/common.h
> index 4e6f4809..623b3e0d 100644
> --- a/src/openvpn/common.h
> +++ b/src/openvpn/common.h
> @@ -88,12 +88,6 @@ typedef unsigned long ptr_type;
> */
> #define PUSH_REQUEST_INTERVAL 5
>
> -/*
> - * A sort of pseudo-filename for data provided inline within
> - * the configuration file.
> - */
> -#define INLINE_FILE_TAG "[[INLINE]]"
> -
> /*
> * Script security warning
> */
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 672aa14a..f1a52d8c 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -1189,7 +1189,7 @@ print_key_filename(const char *str, bool is_inline)
> {
> if (is_inline)
> {
> -return INLINE_FILE_TAG;
> +return "[[INLINE]]";
> }
>
> return np(str);
>
So with Antonio's explaination in message-id
<6a62b6d2-7870-124f-5b5f-be657ffeb...@unstable.cc> and applying message-id
<20200510140017.16837-...@unstable.cc> ([PATCH] tls-crypt-v2: fix testing of
inline key, which I just gave an ACK) before this patch, it is all 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
Re: [Openvpn-devel] [PATCH v2 3/5] Implement sending response to challenge via CR_RESPONSE
Hi, So I'm giving this one another look again. I started now by trying to use this feature manually, to see that each step works as expected. But this time I also discovered a few other details. On 09/11/2019 16:13, Arne Schwabe wrote: > When a client announces its support to support text based > challenge/response via IV_SOO=cr_text,the client needs to also Just reminding of the IV_SOO -> IV_SSO typo-fix ... and it should also be 'crtext', not 'cr_text'. The former is what is used in the management notes. The more I dive into this, I'm also not sure IV_SSO is the proper term. As it is actually defines additional authentication mechanisms, where SSO (Single Sign-on) is just one potential user of this feature. What about just using IV_AUTH? (knowing this will change the prior patches) [...snip...] > diff --git a/doc/management-notes.txt b/doc/management-notes.txt > index 17645c1d..e380ca2b 100644 > --- a/doc/management-notes.txt > +++ b/doc/management-notes.txt > @@ -806,6 +806,14 @@ To accept connecting to the host and port directly, use > this command: > >proxy NONE > > +COMMAND -- cr-response (OpenVPN 2.5 or higher) > +- > +Provides support for sending responses a challenge/response > +query via INFOMSG,CR_TEXT. The response should be base64 encoded: > + > + cr-response SGFsbG8gV2VsdCE= > + > + Could we please have more documentation how to use to enable and use this feature properly? Similar to the examples later down for both the static and dynamic challenge protocols. This does not need to happen in this patch though, as this is also tightly connected to the next patches. > +static bool > +management_callback_send_cc_mesage(void *arg, I didn't spot this earlier, but there's a typo in the function name; it is 'message' with two 's'. > static bool > management_callback_remote_cmd(void *arg, const char **p) > @@ -3990,6 +4028,7 @@ init_management_callback_p2p(struct context *c) > cb.show_net = management_show_net_callback; > cb.proxy_cmd = management_callback_proxy_cmd; > cb.remote_cmd = management_callback_remote_cmd; > +cb.send_cc_message = management_callback_send_cc_mesage; Same typo here in the callback function name; which is why it compiles ;-) -- 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 4/5] Implement sending SSO challenge to clients
ist.callback.client_sso)
> +{
> +bool ret = (*man->persist.callback.client_sso)
> + (man->persist.callback.arg, cid, extra);
> +
> +if (ret)
> +{
> +msg(M_CLIENT, "SUCCESS: client-sso-auth command succeeded");
> +}
> +else
> +{
> +msg(M_CLIENT, "SUCCESS: client-sso-auth command failed."
> + " Extra paramter might be too long");
> +}
> +}
> +else
> +{
> +msg(M_CLIENT, "ERROR: The client-sso-auth command is not
> supported by the current daemon mode");
> +}
> +}
> +}
> +
> static void
> man_client_auth(struct management *man, const char *cid_str, const char
> *kid_str, const bool extra)
> {
> @@ -1541,6 +1580,13 @@ man_dispatch_command(struct management *man, struct
> status_output *so, const cha
> man_client_auth(man, p[1], p[2], true);
> }
> }
> +else if (streq(p[0], "client-sso-auth"))
> +{
> +if (man_need(man, p, 2, 0))
> +{
> +man_client_sso_auth(man, p[1], p[2]);
> +}
> +}
> #ifdef MANAGEMENT_PF
> else if (streq(p[0], "client-pf"))
> {
> diff --git a/src/openvpn/manage.h b/src/openvpn/manage.h
> index 8acc18bf..f570afc6 100644
> --- a/src/openvpn/manage.h
> +++ b/src/openvpn/manage.h
> @@ -174,6 +174,9 @@ struct management_callback
> const char *reason,
> const char *client_reason,
> struct buffer_list *cc_config); /* ownership
> transferred */
> +bool (*client_sso) (void *arg,
> +const unsigned long cid,
> +const char *url);
> char *(*get_peer_info) (void *arg, const unsigned long cid);
> #endif
> #ifdef MANAGEMENT_PF
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index d594dd25..692fb62a 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -3288,6 +3288,24 @@ management_kill_by_cid(void *arg, const unsigned long
> cid, const char *kill_msg)
> }
> }
>
> +static bool
> +management_client_sso(void *arg,> +const unsigned long cid,
> +const char *extra)
> +{
> +struct multi_context *m = (struct multi_context *) arg;
> +struct multi_instance *mi = lookup_by_cid(m, cid);
> +if (mi)
> +{
> +/* sends INFO_PRE and AUTH_PENDING messages to client */
> +bool ret = send_sso_messages(&mi->context, extra);
> +multi_schedule_context_wakeup(m, mi);
> +return ret;
> +}
> +return false;
> +}
> +
> +
> static bool
> management_client_auth(void *arg,
> const unsigned long cid,
> @@ -3395,6 +3413,7 @@ init_management_callback_multi(struct multi_context *m)
> #ifdef MANAGEMENT_DEF_AUTH
> cb.kill_by_cid = management_kill_by_cid;
> cb.client_auth = management_client_auth;
> +cb.client_sso = management_client_sso;
> cb.get_peer_info = management_get_peer_info;
> #endif
> #ifdef MANAGEMENT_PF
> diff --git a/src/openvpn/push.c b/src/openvpn/push.c
> index ee1cb980..4b375ae3 100644
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -268,6 +268,30 @@ send_auth_failed(struct context *c, const char
> *client_reason)
> gc_free(&gc);
> }
>
> +bool
> +send_sso_messages(struct context *c, const char* extra)
> +{
> +send_control_channel_string(c, "AUTH_PENDING", D_PUSH);
> +
> +static const char info_pre[] = "INFO_PRE,";
> +
> +
> +size_t len = strlen(extra)+1 + sizeof(info_pre);
> +if (len > PUSH_BUNDLE_SIZE)
> +{
> +return false;
> +}
> +struct gc_arena gc = gc_new();
> +
> +struct buffer buf = alloc_buf_gc(len, &gc);
> +buf_printf(&buf, info_pre);
> +buf_printf(&buf, "%s", extra);
> +send_control_channel_string(c, BSTR(&buf), D_PUSH);
> +
> +gc_free(&gc);
> +return true;
> +}
> +
> /*
> * Send restart message from server to client.
> */
> diff --git a/src/openvpn/push.h b/src/openvpn/push.h
> index 9cf8fb34..f814f572 100644
> --- a/src/openvpn/push.h
> +++ b/src/openvpn/push.h
> @@ -70,6 +70,8 @@ void remove_iroutes_from_push_route_list(struct options *o);
>
> void send_auth_failed(struct context *c, const char *client_reason);
>
> +bool send_sso_messages(struct context *c, const char *url);
> +
> void send_restart(struct context *c, const char *kill_msg);
Several of the function names also uses 'sso', which should be aligned to a
non-sso specific function name.
--
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 4/5] Implement sending SSO challenge to clients
On 15/05/2020 17:36, David Sommerseth wrote:
> On 09/11/2019 16:13, Arne Schwabe wrote:
>> This implements sending AUTH_PENDING and INFO_PRE messages to clients
>> that indicate that the clients should be continue authentication with
>> a second factor. This can currently be out of band (openurl) or a normal
>> challenge/response 2FA like TOTP (CR_TEXT).
>
> Can we settle on a single CR_TEXT vs CRTEXT terminology? The 3/5 patch used
> crtext in the documentation but cr_text in the commit message.
>
>> Signed-off-by: Arne Schwabe
>> ---
>> doc/management-notes.txt | 26 +++
>> src/openvpn/manage.c | 46
>> src/openvpn/manage.h | 3 +++
>> src/openvpn/multi.c | 19 +
>> src/openvpn/push.c | 24 +
>> src/openvpn/push.h | 2 ++
>> 6 files changed, 120 insertions(+)
>>
>> diff --git a/doc/management-notes.txt b/doc/management-notes.txt
>> index e380ca2b..4b405a9b 100644
>> --- a/doc/management-notes.txt
>> +++ b/doc/management-notes.txt
>> @@ -592,6 +592,32 @@ interface to approve client connections.
>> CID,KID -- client ID and Key ID. See documentation for ">CLIENT:"
>> notification for more info.
>>
>> +COMMAND -- client-sso-auth (OpenVPN 2.5 or higher)
>> +
>> +
>> +Instruct OpenVPN server to send AUTH_PENDING and INFO_PRE signal
>> +a single sign on url to the client.
>> +
>> +client-sso-auth {CID} {EXTRA}
>
> I think we should use a different naming for this than 'sso'. This is not
> tied to only SSO (Single Sign-On). What about:
>
> - client-extended-auth
> - client-external-auth
> - client-ext-auth
> - client-additional-auth
> - client-xauth
Another alternative popped up in my head, as CR/Challenge-Response is used a
lot in this context client-cr-auth but all of them are just
suggestions to avoid the 'sso' reference.
>
> As long as the name is quite generic, I'm fine with most alternatives. But it
> should be very generic. We have so many alternative auth methods these days:
> Yubico OTP [1], TOTP/HOTP, FIDO/U2F, SAML, OAuth, Kerberos/GSSAPI, etc ...
>
> [1] <https://developers.yubico.com/OTP/OTPs_Explained.html>
--
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/5] Implement forwarding client CR_RESPONSE messages to management
v(management, mdac);
> +}
> +man_output_env(es, true, management->connection.env_filter_level,
> "CLIENT");
> +management_notify_generic(management, BSTR(&out));
> +
> +gc_free(&gc);
> +}
> +}
> +
> void
> management_connection_established(struct management *management,
>struct man_def_auth_context *mdac,
> diff --git a/src/openvpn/manage.h b/src/openvpn/manage.h
> index f570afc6..ff6b6737 100644
> --- a/src/openvpn/manage.h
> +++ b/src/openvpn/manage.h
> @@ -432,6 +432,10 @@ void management_learn_addr(struct management *management,
> const struct mroute_addr *addr,
> const bool primary);
>
> +void management_notify_client_cr_response(unsigned mda_key_id,
> + const struct man_def_auth_context
> *mdac,
> + const struct env_set *es,
> + const char* response);
> #endif
>
> char *management_query_pk_sig(struct management *man, const char *b64_data);
> diff --git a/src/openvpn/push.c b/src/openvpn/push.c
> index 4b375ae3..c94076cb 100644
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -210,6 +210,27 @@ server_pushed_info(struct context *c, const struct
> buffer *buffer,
> msg(D_PUSH, "Info command was pushed by server ('%s')", m);
> }
>
> +void
> +receive_cr_response(struct context *c, const struct buffer *buffer)
> +{
> +struct buffer buf = *buffer;
> +const char *m = "";
> +
> +if (buf_advance(&buf, 11) && buf_read_u8(&buf) == ',' && BLEN(&buf))
> +{
> +m = BSTR(&buf);
> +}
This will accept an empty CR_RESPONSE from the client. Could that be an
acceptable reply from the client? My initial thought is: When the server
sends a challenge to the client, it should have a "meaningful" response. I
struggle to see where an empty response would be meaningful.
And by "meaningful" I mean in the broadest interpretation. Invalid
authentication response, invalid data (not base64 encoded, etc) is meaningful.
I'm also wondering if it would make sense to validate the base64 response as
well.
To summarize all patches:
- They all look reasonable and fine, but there are a few things to improve.
- We should avoid the SSO terminology in the implementation; it can be used
for a much broader authentication scope than just SSO. Patch 2/5 also needs
to be revisited, despite the ACK I've already given.
- Documentation could be a bit better.
- It would be nice to have a really simple test "module" for the server side,
which would just give challenges like "How much is X + Y?" where X and Y are
random numbers (1-10) and doesn't really need to account for multiple
clients at the same time. But I do realize the management interface can be
annoying to work with from simple scripting tools.
--
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] Refuse server mode on Android
On 18/05/2020 17:54, Arne Schwabe wrote:
> After the commit 042429d3 "build: Remove --disable-server from ./configure"
> Android needs another way to ensure that OpenVPN is not run in server mode.
>
> Signed-off-by: Arne Schwabe
> ---
> src/openvpn/options.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 2da8cf6d..bfba62ad 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -2254,6 +2254,9 @@ options_postprocess_verify_ce(const struct options
> *options, const struct connec
> */
> if (options->mode == MODE_SERVER)
> {
> +#ifdef TARGET_ANDROID
> +msg(M_FATAL, "--mode server not supported on Android");
> +#endif
> if (!(dev == DEV_TYPE_TUN || dev == DEV_TYPE_TAP))
> {
> msg(M_USAGE, "--mode server only works with --dev tun or --dev
> tap");
>
Not tested this, but this change is pretty clear and explicit. I also can't
imagine now a better way to tackle this, even though I'm not too happy about
adding more #ifdef.
If someone really needs TARGET_ANDROID with server support, lets wait for them
to appear so we can clearly define the use-case and design a better solution
for a known scenario.
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 v3 1/5] Implement parsing and sending INFO and INFO_PRE control messages
On 20/05/2020 00:00, Arne Schwabe wrote: > OpenVPN 3 implements these messages to send information during the > authentication to the UI, implement these message also in OpenVPN 2.x > > Signed-off-by: Arne Schwabe > --- > src/openvpn/forward.c | 8 > src/openvpn/push.c| 32 > src/openvpn/push.h| 3 +++ > 3 files changed, 43 insertions(+) > [...] 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 v3 2/5] Implement support for signalling IV_SSO to server
On 20/05/2020 00:00, Arne Schwabe wrote:
> Signed-off-by: Arne Schwabe
> ---
> src/openvpn/ssl.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index c2e9a4f3..f85ef3eb 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -2333,7 +2333,9 @@ push_peer_info(struct buffer *buf, struct tls_session
> *session)
> if strncmp(e->string, "UV_", 3)==0
> || strncmp(e->string, "IV_PLAT_VER=",
> sizeof("IV_PLAT_VER=")-1)==0)
>&& session->opt->push_peer_info_detail >= 2)
> - ||
> (strncmp(e->string,"IV_GUI_VER=",sizeof("IV_GUI_VER=")-1)==0))
> + ||
> (strncmp(e->string,"IV_GUI_VER=",sizeof("IV_GUI_VER=")-1)==0)
> + || (strncmp(e->string,"IV_SSO=",sizeof("IV_SSO=")-1)==0)
> + )
> && buf_safe(&out, strlen(e->string)+1))
> {
> buf_printf(&out, "%s\n", e->string);
>
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 v3 3/5] Implement sending response to challenge via CR_RESPONSE
On 20/05/2020 00:00, Arne Schwabe wrote: > When a client announces its support to support text based > challenge/response via IV_SSO=crtext,the client needs to also > be able to reply to that response. > > This adds the "cr-response" management function to be able to > do this. The answer should be base64 encoded. > > Signed-off-by: Arne Schwabe > --- > doc/management-notes.txt | 14 ++ > src/openvpn/init.c | 39 +++ > src/openvpn/manage.c | 39 ++- > src/openvpn/manage.h | 1 + > 4 files changed, 92 insertions(+), 1 deletion(-) > > diff --git a/doc/management-notes.txt b/doc/management-notes.txt > index e54e1082..a7ae84e3 100644 > --- a/doc/management-notes.txt > +++ b/doc/management-notes.txt > @@ -806,6 +806,20 @@ To accept connecting to the host and port directly, use > this command: > >proxy NONE > > +COMMAND -- cr-response (OpenVPN 2.5 or higher) > +- > +Provides support for sending responses a challenge/response > +query via INFOMSG,CR_TEXT. The response should be base64 encoded: > + > + cr-response SGFsbG8gV2VsdCE= > + > +The document is intended to be used after the client received a > +CR_TEXT challenge (see send-pending-auth section). The answer is > +the answer to the challenge and depends on the challenge itself > +for a TOTP challenge this would the number encoded as base64 or > +just a string for a challenge like what "day is it today?". The quoting should probably start before "what" instead of after. This can be fixed during commit time if we care enough about that typo. I've only glared at this patch, as I tested the previous version quite a bit. Changes requested are added to this. Arne and I have discussed the IV_SSO naming a bit, I realize we need to keep at least the IV_SSO as changing that would be an incompatible protocol change with OpenVPN Access Server (already in production) and OpenVPN Cloud (recently released). This is something we can consider change later on, then in cooperation with OpenVPN Access Server and OpenVPN Cloud. 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 v3 4/5] Implement sending AUTH_PENDING challenges to clients
On 20/05/2020 00:00, Arne Schwabe wrote: > This implements sending AUTH_PENDING and INFO_PRE messages to clients > that indicate that the clients should be continue authentication with > a second factor. This can currently be out of band (openurl) or a normal > challenge/response two like TOTP (CR_TEXT). > > Unfortunately this patch spend so much time in review in openvpn2 that > the corosponding IV_SSO commit in openvpn3 (34a3f264) already made its > way to released products so changing this right now is difficult. > > https://github.com/OpenVPN/openvpn3/commit/34a3f264f56bd050d9b26d2e7163f88af9a559e2 > > Signed-off-by: Arne Schwabe > --- > doc/management-notes.txt | 86 > src/openvpn/manage.c | 46 + > src/openvpn/manage.h | 3 ++ > src/openvpn/multi.c | 19 + > src/openvpn/push.c | 24 +++ > src/openvpn/push.h | 7 > 6 files changed, 185 insertions(+) > [...] Only compile tested, as I've done quite some testing earlier. Requested changes are in, with the exception of IV_SSO which we can't change now. 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 v3 5/5] Implement forwarding client CR_RESPONSE messages to management
On 20/05/2020 00:00, Arne Schwabe wrote: > When signalling the client that it should do Challenge response > without reconnecting (IV_SSO=crtext/INFOPRE=CR_TEXT), the server > needs forward the response via the management console. > > Signed-off-by: Arne Schwabe > --- > doc/management-notes.txt | 30 +- > src/openvpn/forward.c| 4 > src/openvpn/manage.c | 28 +++- > src/openvpn/manage.h | 5 + > src/openvpn/push.c | 22 ++ > src/openvpn/push.h | 2 ++ > 6 files changed, 89 insertions(+), 2 deletions(-) > [...] Basing this also on prior testing, looking good. Only done compile testing in this round. 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] man page overhaul project
Hi, For the OpenVPN 2.5 we decided to do an overhaul to the man page. The first step in this project has been completed, converting the man page into an .rst based text file instead - which hopefully will be much easier to edit for more people. This .rst file will then be converted to proper man and html files when we produce the source tarballs during releases. You can all follow the work in my own git repository where I'm pulling together various changes before they are sent to the mailing list for proper vetting and ACKs. The repository can be found here: https://gitlab.com/dazo/openvpn/ And the git branch is dev/man-reformatting Feel free to submit patches or gitlab pull-requests or gitlab issues as you see it fits with suggestions for improving the man page. If you are new to the .rst formatting, I would recommend you to pay close attention to how things are done in the current openvpn.8.rst [0] file, as well as the .rst markup docs [1, 2] [0] <https://gitlab.com/dazo/openvpn/-/blob/dev/man-reformatting/doc/openvpn.8.rst> [1] Quickstart: <https://docutils.sourceforge.io/docs/user/rst/quickstart.html > [2] .rst spec: <https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html> Also, even though both gitlab and github does automatic "html rendering", there might be some artifacts in the rendered result. We will try to make it look as nice as possible everywhere, but the rst2man output will be the main target which will trump most rendering conflicts. If it doesn't render well as a text based man page, it is not good enough. For the OpenVPN 2.5 release we will also keep everything in a single man page. For future releases we might reconsider the organization of the man page. So any discussions which might appear regarding to split this file up will be postponed until after the v2.5 release. Other than that, I think we can be our best efforts to make this file even easier to read and not the least, more up-to-date. This man page is getting closer to 20 years old or so, so a clean-up of older and less useful information for this day and age is welcome. Looking forward to hear back from you, whenever you have some input how to make the man page better. -- 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] Add .git-blame-ignore-revs with reformat commits
On 29/05/2020 01:54, Arne Schwabe wrote: > This allows git blame to ignore reformatting changes and instead > shows the previous commit that changed the line. > > To avoid manually building the list of commits this commit > adds a file with a list of reformatting commits. I might have > missed a few but this should be a good start. To use the file > use: > >git blame --ignore-revs-file=.git-blame-ignore-revs file > > or to automatically always use the file > >git config blame.ignoreRevsFile .git-blame-ignore-revs > > Naming the file .git-blame-ignore-revs is a convention. > > Some more details in this random blog post: > > https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame > Feature-ACK ... the commit message could also mention that git 2.23 is needed as well. > Signed-off-by: Arne Schwabe > --- > .git-blame-ignore-revs| 29 +++ > .../managent-demo/management-demo-server.py | 0 > contrib/ovpnkeys.py | 0 > 3 files changed, 29 insertions(+) > create mode 100644 .git-blame-ignore-revs > create mode 100644 contrib/managent-demo/management-demo-server.py > create mode 100644 contrib/ovpnkeys.py > > diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs > new file mode 100644 > index ..3cc811cf > --- /dev/null > +++ b/.git-blame-ignore-revs > @@ -0,0 +1,29 @@ > +# Uncrustify the tests/unit_tests/ part of our tree. > +da1574ef7826d73f01e120cbd1ba40ce39a305b7 > + > +# Another round of uncrustify code cleanup. > +9cf7b4925a54d93fbea1cadcf3dc0e11f3ce358f > + > +# networking_sitnl.c: uncrustify file > +2c45d268ca65c522fbabb7c4dab5e721296b4623 > + > +# Uncrustify tapctl and openvpnmsica > +6280d3d5536174934ee22d3840457d61896e0e3a Missing a blank line here, for consistency > +# tun.c: uncrustify > +baef44fc8769bbd99f4d699ce9f63180c29a5455 > + > +# networking_sitnl.c: uncrustify file > +2c45d268ca65c522fbabb7c4dab5e721296b4623 > + > +# uncrustify openvpn sources > +f57431cdc88f22fa4d7962946f0d3187fe058539 > + > +# More broadly enforce Allman style and braces-around-conditionals > +4cd4899e8e80efae03c584a760fd107251735723 > + > +# Merge 'reformatting' branch into master > +1f004b2f06e987d73e48f7fd7b96b0b248274f58 Are you sure this "merge" commit shouldn't be commit 81d882d5 instead? > + > +# The Great Reformatting - first phase > +81d882d5302b8b647202a6893b57dfdc61fd6df2 > + > diff --git a/contrib/managent-demo/management-demo-server.py > b/contrib/managent-demo/management-demo-server.py > new file mode 100644 This file shouldn't be included in this change. > index ..e69de29b > diff --git a/contrib/ovpnkeys.py b/contrib/ovpnkeys.py > new file mode 100644 > index ..e69de29b > So a few minor things to look into, otherwise this is really valuable. I would probably also consider to also add a note about this git feature in README. It's not the most ideal file, but I struggle to find a better place currently (I might have overlooked something). We would probably benefit having a separate developers README with all the hints, tips and tricks developers would need to care about. That is, however, out of scope for this change. -- 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 .git-blame-ignore-revs with reformat commits
On 05/06/2020 01:53, Arne Schwabe wrote: > This allows git blame to ignore reformatting changes and instead > to show the previous commit that changed the line. > > To avoid manually building the list of commits this commit > adds a file with a list of reformatting commits. I might have > missed a few but this should be a good start. To use the file > use: > >git blame --ignore-revs-file=.git-blame-ignore-revs file > > or to automatically always use the file > >git config blame.ignoreRevsFile .git-blame-ignore-revs > > Naming the file .git-blame-ignore-revs is a convention. > > Some more details in this random blog post: > > https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame > > Patch V2: Remove merge commit of the great formatting, add small > reminder how to use the feature at the top of the file > > Signed-off-by: Arne Schwabe > --- > .git-blame-ignore-revs| 39 +++ > .../managent-demo/management-demo-server.py | 0 > contrib/ovpnkeys.py | 0 > 3 files changed, 39 insertions(+) > create mode 100644 .git-blame-ignore-revs > create mode 100644 contrib/managent-demo/management-demo-server.py > create mode 100644 contrib/ovpnkeys.py > > diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs > new file mode 100644 > index ..6d9b374f > --- /dev/null > +++ b/.git-blame-ignore-revs > @@ -0,0 +1,39 @@ > +# This FILE allows git blame to ignore reformatting changes and instead > +# shows the previous commit that changed the line. > +# > +# To avoid manually building the list of commits this commit > +# adds a file with a list of reformatting commits. TO use: > +# > +# git blame --ignore-revs-file=.git-blame-ignore-revs file > +# > +# or to automatically always use the file > +# > +# git config blame.ignoreRevsFile .git-blame-ignore-revs > + > + > +# Uncrustify the tests/unit_tests/ part of our tree. > +da1574ef7826d73f01e120cbd1ba40ce39a305b7 > + > +# Another round of uncrustify code cleanup. > +9cf7b4925a54d93fbea1cadcf3dc0e11f3ce358f > + > +# networking_sitnl.c: uncrustify file > +2c45d268ca65c522fbabb7c4dab5e721296b4623 > + > +# Uncrustify tapctl and openvpnmsica > +6280d3d5536174934ee22d3840457d61896e0e3a > + > +# tun.c: uncrustify > +baef44fc8769bbd99f4d699ce9f63180c29a5455 > + > +# networking_sitnl.c: uncrustify file > +2c45d268ca65c522fbabb7c4dab5e721296b4623 > + > +# uncrustify openvpn sources > +f57431cdc88f22fa4d7962946f0d3187fe058539 > + > +# More broadly enforce Allman style and braces-around-conditionals > +4cd4899e8e80efae03c584a760fd107251735723 > + > +# The Great Reformatting - first phase > +81d882d5302b8b647202a6893b57dfdc61fd6df2 > diff --git a/contrib/managent-demo/management-demo-server.py > b/contrib/managent-demo/management-demo-server.py This looks good. > new file mode 100644 > index ..e69de29b > diff --git a/contrib/ovpnkeys.py b/contrib/ovpnkeys.py > new file mode 100644 > index ..e69de29b > Why do you keep on adding this file ;-) I'd say this file could be removed at apply time. Acked-By: David Somerseth -- 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 webinar - 24th June
Hi, OpenVPN Inc will host a webinar covering OpenVPN configuration and how the community version differs from the OpenVPN Access Server. The webinar is held by Johan Draaisma. 24th June at 18:00 CET / 19:00 CEST /10:00 PDT Webinar details: <https://go.openvpn.net/aswebinar.html> Time details: <https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenVPN+Access+Server+webinar&iso=20200624T10&p1=224> -- 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-users] Multiple DNS search suffixes on Windows
On 21/06/2020 13:14, Gert Doering wrote: > Hi, > > going through OpenVPN threads that went stale - I think this is > actually a nice addition (read: other people have already asked > me if this can be done). > > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote: >> So, for what it's worth, I've dusted off the patch again and rebased it >> to the current openvpn master tree. See attached. Note that I did only >> rudimentary testing, as I don't use Windows 10 a lot and I was testing >> using a mingw cross-compile only. In wireshark I *do* see that the >> correct DHCP offer is sent to the tap-win adapter. >> >> Also note that I implemented multiple search domains by separating them >> using semi-colons, e.g. >> >> --dhcp-option SEARCH example.com;example.org;example.nl;example.de >> >> etc as that was easier to implement > > The patch looks okay-ish on quick reading. Feature-ACK from my side as well. But there are a few things we need to look more into. [...snip...] > More interesting is the question "which option to use" - it should > be synchronized between openvpn platform handlers. So if systemd-networkd > uses "SEARCH-DOMAIN" it would make sense to use that for windows > as well. Nit-pick, systemd-resolved is the target service in this case though. But it is related to systemd-networkd. But I agree, we should synchronize this a bit. IIRC, there might already be somewhat partial support for this in OpenVPN Connect clients as well, which might also be used in Access Server. I would also expect the OpenVPN Cloud service to facilitate such a feature. I have recently been working on systemd-resolved support in OpenVPN 3 Linux as well, and reached out earlier this week to Jonathan (update-systemd-resolved maintainer) to see if we can join forces better and standardize on a common understanding of the DHCP options. I would also like to at least consider pulling update-systemd-resolved (or a similar approach) into our OpenVPN distribution, as an alternative to the rather hacky pull-resolv-conf scripts we're shipping. I quickly spoke with Arne late on Friday about it as well, and we might also want to consider some IV flags from client to server as well, to flag support for features like split-dns (which at least systemd-resolved can provide). > Does anyone know about commercial VPN providers basing their clients > on OpenVPN? I will clarify with our folks internally how this will influence OpenVPN Cloud. I can't imagine many other commercial VPNs depending on such a feature, this is more typically a business feature than a consumer VPN feature. There might be a few ones implementing or needing such a feature, but if they don't appear here and raise there concerns here, I don't think we should spend time on them. -- 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] systemd: Change the default cipher to AES-256-GCM for server configs
This change makes the server use AES-256-GCM instead of BF-CBC as the default cipher for the VPN tunnel when starting OpenVPN via systemd and the openvpn-server@.service unit file. To avoid breaking existing running configurations defaulting to BF-CBC, the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in addition to AES-CBC. This makes it possible to migrate existing older client configurations one-by-one to use at least AES-CBC unless the client is updated to v2.4 or newer (which defaults to upgrade to AES-GCM automatically) This has been tested in Fedora 27 (released November 2017) with no reported issues. By making this default for all Linux distributions with systemd shipping with the unit files we provide, we gradually expand setups using this possibility. As we gather experience from this change, we can further move these changes into the defaults of the OpenVPN binary itself with time. Signed-off-by: David Sommerseth --- Changes.rst | 15 +++ distro/systemd/openvpn-ser...@.service.in | 2 +- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/Changes.rst b/Changes.rst index 00dd6ed8..e76d3c73 100644 --- a/Changes.rst +++ b/Changes.rst @@ -14,6 +14,21 @@ ChaCha20-Poly1305 cipher support channel. +User-visible Changes + +New default cipher for systemd based Linux distributions +For Linux distributions with systemd which packages the systemd unit files +from the OpenVPN project, the default cipher is now changed to AES-256-GCM, +with BF-CBC as a fallback through the NCP feature. This change has been +tested successfully since the Fedora 27 release (released November 2017). + +*WARNING* This MAY break configurations where the client uses +``--disable-occ`` feature where the ``--cipher`` has +not been explicitly configured on both client and +server side. It is recommended to remove the ``--disable-occ`` +option *or* explicitly add ``--cipher AES-256-GCM`` on the +client side if ``--disable-occ`` is strictly needed. + Overview of changes in 2.4 == diff --git a/distro/systemd/openvpn-ser...@.service.in b/distro/systemd/openvpn-ser...@.service.in index d1cc72cb..f3545ff5 100644 --- a/distro/systemd/openvpn-ser...@.service.in +++ b/distro/systemd/openvpn-ser...@.service.in @@ -10,7 +10,7 @@ Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO Type=notify PrivateTmp=true WorkingDirectory=/etc/openvpn/server -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC --config %i.conf CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE LimitNPROC=10 DeviceAllow=/dev/null rw -- 2.26.0 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs
On 22/06/2020 14:21, Arne Schwabe wrote: > >> PrivateTmp=true >> WorkingDirectory=/etc/openvpn/server >> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >> --status-version 2 --suppress-timestamps --config %i.conf >> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >> --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers >> AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC --config %i.conf >> CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE >> CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE >> CAP_AUDIT_WRITE >> LimitNPROC=10 >> DeviceAllow=/dev/null rw >> > > NACK. > > Setting ncp-cipher to include BF-CBC by default allows BF-CBC in configs > that did not allow it before. Basically any config that had something > other than cipher BF-CBC and no ncp-ciphers in it will now allow clients > with BF-CBC to connect. I don't want force users to set ncp-cipher to a > sane value since the systemd unit file doesn't. That will break existing configs on the next upgrade. Do we want do do that? I'm fine with removing BF-CBC, but it is scheduled for removal in OpenVPN 2.6. <https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2> -- 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] systemd: Change the default cipher to AES-256-GCM for server configs
On 22/06/2020 19:20, André via Openvpn-devel wrote: > Hi, > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Monday 22 June 2020 18:58, Selva Nair wrote: > >> On Mon, Jun 22, 2020 at 7:31 AM David Sommerseth dav...@openvpn.net wrote: >> >>> This change makes the server use AES-256-GCM instead of BF-CBC as the >>> default cipher for the VPN tunnel when starting OpenVPN via systemd >>> and the openvpn-server@.service unit file. >>> To avoid breaking existing running configurations defaulting to BF-CBC, >>> the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in >>> addition to AES-CBC. This makes it possible to migrate existing older >>> client configurations one-by-one to use at least AES-CBC unless the >>> client is updated to v2.4 or newer (which defaults to upgrade to >>> AES-GCM automatically) >>> This has been tested in Fedora 27 (released November 2017) with no >>> reported issues. By making this default for all Linux distributions >>> with systemd shipping with the unit files we provide, we gradually >>> expand setups using this possibility. As we gather experience from >>> this change, we can further move these changes into the defaults of >>> the OpenVPN binary itself with time. >>> >>> Signed-off-by: David Sommerseth dav...@openvpn.net >>> >>> --- >>> >>> Changes.rst | 15 +++ >>> distro/systemd/openvpn-ser...@.service.in | 2 +- >>> 2 files changed, 16 insertions(+), 1 deletion(-) >>> diff --git a/Changes.rst b/Changes.rst >>> index 00dd6ed8..e76d3c73 100644 >>> --- a/Changes.rst >>> +++ b/Changes.rst >>> @@ -14,6 +14,21 @@ ChaCha20-Poly1305 cipher support >>> channel. >>> +User-visible Changes >>> + >>> +New default cipher for systemd based Linux distributions >>> >>> - For Linux distributions with systemd which packages the systemd unit >>> files >>> - from the OpenVPN project, the default cipher is now changed to >>> AES-256-GCM, >>> - with BF-CBC as a fallback through the NCP feature. This change has been >>> - tested successfully since the Fedora 27 release (released November >>> 2017). >>> - >>> - WARNING This MAY break configurations where the client uses >>> - ``--disable-occ`` feature where the ``--cipher`` has >>> >>> >>> - not been explicitly configured on both client and >>> >>> >>> - server side. It is recommended to remove the >>> ``--disable-occ`` >>> >>> >>> - option *or* explicitly add ``--cipher AES-256-GCM`` on >>> the >>> >>> >>> - client side if ``--disable-occ`` is strictly needed. >>> >>> >>> - >>> >>> Overview of changes in 2.4 >>> >>> === >>> >>> diff --git a/distro/systemd/openvpn-ser...@.service.in >>> b/distro/systemd/openvpn-ser...@.service.in >>> index d1cc72cb..f3545ff5 100644 >>> --- a/distro/systemd/openvpn-ser...@.service.in >>> +++ b/distro/systemd/openvpn-ser...@.service.in >>> @@ -10,7 +10,7 @@ >>> Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO >>> Type=notify >>> PrivateTmp=true >>> WorkingDirectory=/etc/openvpn/server >>> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >>> --status-version 2 --suppress-timestamps --config %i.conf >>> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >>> --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers >>> AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC --config %i.conf >> >> This is why I keep my openvpn servers out of systemd's view -- it >> keeps deciding what's good for us. I want to run my configs as is. >> >> Selva >> >> Openvpn-devel mailing list >> Openvpn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > Sorry for the noise in advance but I agree. > No idea how to keep it out of systemd's view :) but I change the line to > -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log > --status-version 2 --suppress-timestamps --config %i.conf > +ExecStart=@sbindir@/openvpn --config %i.conf &g
Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs
On 22/06/2020 14:43, Steffan Karger wrote: > Hi, > > On 22-06-2020 14:29, David Sommerseth wrote: >> On 22/06/2020 14:21, Arne Schwabe wrote: >>> >>>> PrivateTmp=true >>>> WorkingDirectory=/etc/openvpn/server >>>> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >>>> --status-version 2 --suppress-timestamps --config %i.conf >>>> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >>>> --status-version 2 --suppress-timestamps --cipher AES-256-GCM >>>> --ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC >>>> --config %i.conf >>>> CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE >>>> CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE >>>> CAP_AUDIT_WRITE >>>> LimitNPROC=10 >>>> DeviceAllow=/dev/null rw >>>> >>> >>> NACK. >>> >>> Setting ncp-cipher to include BF-CBC by default allows BF-CBC in configs >>> that did not allow it before. Basically any config that had something >>> other than cipher BF-CBC and no ncp-ciphers in it will now allow clients >>> with BF-CBC to connect. I don't want force users to set ncp-cipher to a >>> sane value since the systemd unit file doesn't. >> >> That will break existing configs on the next upgrade. Do we want do do that? >> >> I'm fine with removing BF-CBC, but it is scheduled for removal in OpenVPN >> 2.6. > > I think Arne has a very good point that it's kinda weird to "degrade" > the NCP defaults. > > Making AES-256-GCM the default cipher for TLS-based connections (GCM > won't work with static key configs) does not imply *removing* BF-CBC > support. Maybe these should be the steps: > > 2.4: Use to AES-256-GCM when available (basically what NCP did) > 2.5: Switch to AES-256-GCM as the default cipher (but allow overriding) > 2.6: Remove support for small block ciphers all together > > Yes, this will probably break some (less secure) setups and make some > people angry. But at some point people need to move on. We've been > throwing warnings at them for a while now. Yes, I agree that Arne got a point. But I'm not completely convinced breaking configs in OpenVPN 2.5 without a prior note that it will stop working. Our warning only screams "you shouldn't use ciphers with block sizes < 128 bits", it doesn't say "this will stop working in a future release". OpenVPN 2.4.9 gives this warning: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). The community has been informed it will stop working in 2.6, not before this release. This must be documented properly and log warnings updated to indicate short-term workarounds. I could be willing to consider breaking configs for ciphers in a later 2.5.x release as long as users are properly warned *when* it will stop working - and that users gets a real chance to fix configs before we do break their configs - where a workaround approach could be considered and available from v2.5.0 (on the other hand, if they change their configs, they should swap ciphers instead of applying a workaround for a dying cipher - but for some it might be a bit more complicated to do such a swap). We need to find a good middle-way for OpenVPN 2.5, where we clearly signal "weak ciphers will be removed" and when we will do that. While also moving forward and break as few configs as possible and not make configs weaker than before. -- 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] systemd: Change the default cipher to AES-256-GCM for server configs
[resent for the ML inclusion] On 22/06/2020 18:58, Selva Nair wrote: > On Mon, Jun 22, 2020 at 7:31 AM David Sommerseth wrote: [...snip...] >> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log >> --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers >> AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC --config %i.conf > > This is why I keep my openvpn servers out of systemd's view -- it > keeps deciding what's good for us. I want to run my configs as is. The order of options are crucial here. This only changes the _default_ if these options are not set. If they are set in the config file, the config file will override. -- 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] [RFC] Challenges with OpenVPN and configuring DNS
es of 1 and 2. We propose 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
Re: [Openvpn-devel] Summary of the community meeting (24th June 2020)
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] [PATCH 00/11] man-page overhaul project
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
[Openvpn-devel] [PATCH 06/11] doc/man: Move --bind from generic to link section
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 08/11] doc/man: Mark compression options as deprecated
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 03/11] doc/man: Move profiles section
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
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 tunn
[Openvpn-devel] [PATCH 04/11] doc/man: Remove unsupported options in OpenVPN 2.5
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 - **DEPRECA
[Openvpn-devel] [PATCH 10/11] doc/man: Moved --reneg-* options to its own section
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 + (disabl
[Openvpn-devel] [PATCH 11/11] doc/man: Cleaned up the examples
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
[Openvpn-devel] [PATCH 07/11] doc/man: Move --dhcp-option from client to vpn-network section
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 pu
Re: [Openvpn-devel] [PATCH 00/11] man-page overhaul project
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
Re: [Openvpn-devel] [PATCH] New man page - Simple corrections
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] New man page corrections - encryption-options.rst
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 corrections - advanced-options.rst
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] [Openvpn-users] Multiple DNS search suffixes on Windows
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, &error);
>>> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len,
>>> &error);
>>>
>>> +for (int i=0; i < o->domain_search_list_len; i++)
>>> +{
>>> +write_dhcp_search_str(buf, 119, o->domain_search_list[i], &error);
>>> +}
>> 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
[Openvpn-devel] [PATCH 00/16] man-page overhaul project
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
[Openvpn-devel] [PATCH 03/16] doc/man: Move profiles section
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 06/16] doc/man: Move --bind from generic to link section
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 11/16] doc/man: Cleaned up the examples
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
[Openvpn-devel] [PATCH 16/16] doc/man: Minor improvements to the plug-in section
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
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 - **DEPRECA
[Openvpn-devel] [PATCH 08/16] doc/man: Mark compression options as deprecated
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
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 07/16] doc/man: Move --dhcp-option from client to vpn-network section
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 pu
[Openvpn-devel] [PATCH 10/16] doc/man: Moved --reneg-* options to its own section
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 + (disabl
[Openvpn-devel] [PATCH 14/16] doc/man: Update --txqueuelen default setting (Now OS default)
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
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 tunn
[Openvpn-devel] [PATCH 13/16] doc/man: Adopt compression documentation
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 12/16] doc/man: Misc grammar and typo fixes
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
Re: [Openvpn-devel] [PATCH v5 14/14] client-connect: Add documentation for the deferred client connect feature
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
Re: [Openvpn-devel] [PATCH v5 14/14] client-connect: Add documentation for the deferred client connect feature
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
[Openvpn-devel] [PATCH v2 0/8] man-page overhaul project - round 2
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
[Openvpn-devel] [PATCH v2 6/8] doc/man: Adopt compression documentation
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 7/8] doc/man: Update --txqueuelen default setting (Now OS default)
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 8/8] doc/man: Documentation for --bind-dev / VRFs on Linux
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 5/8] doc/man: Mark compression options as deprecated
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
Re: [Openvpn-devel] [PATCH applied] Re: doc/man: Replace old man page with generated man page
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] doc/man: Documentation for --bind-dev / VRFs on Linux
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
[Openvpn-devel] [PATCH] doc/man: Add misssing renegotiation.rst to Makefile.am
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
Re: [Openvpn-devel] [PATCH] Convert cc_check_return to switch/case
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
Re: [Openvpn-devel] [PATCH 2/2] Permit make dist* targets without py*-docutils
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 1/2] Automake options: add subdir-objects, and clean up
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
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
[Openvpn-devel] [PATCH] Remove --no-replay
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(&gc);
}
-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/c
[Openvpn-devel] [PATCH] Remove --no-iv
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
Re: [Openvpn-devel] [PATCH] Merge Makefile.am's AUTOMAKE_OPTIONS into configure.ac's AM_INIT_AUTOMAKE.
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] doc/man: Do not install man *.rst files
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
[Openvpn-devel] [PATCH] travis: Fix make distcheck failure
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] Remove --client-cert-not-required
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 v2] Remove --client-cert-not-required
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 --ifconfig-pool-linear
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
Re: [Openvpn-devel] [PATCH v2 5/9] Remove key-method 1
reuse of struct tls_session *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, &session->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
Re: [Openvpn-devel] [PATCH v2 5/9] Remove key-method 1
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 = &multi->session[TM_ACTIVE];
>>> struct key_state *ks = &session->key[KS_PRIMARY];
>>>
>>>
Re: [Openvpn-devel] [PATCH v3 5/9] Remove key-method 1
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
[Openvpn-devel] [PATCH] options: Remove --udp-mtu
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] options: Remove --udp-mtu
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
Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers
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 8/9] Rename ncp-ciphers to data-ciphers
into how to ensure proper 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] Regarding deprecation of --route-nopull
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
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(&new_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] [PATCH 8/9] Rename ncp-ciphers to data-ciphers
rop support for something > something that should 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
[Openvpn-devel] OpenVPN 3 Linux client - v10 beta released
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] New man-section pages format
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
Re: [Openvpn-devel] [PATCH v3] Fix best gateway selection over netlink
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] [PATCH] Document that --push-remove is generally more suitable than --push-reset
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] 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. > > 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] Fix --remote protocol can't be set without port argument
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
[Openvpn-devel] [PATCH] man: Improve --remote entry
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
