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] 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
[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
[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
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 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
[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 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 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 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
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
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
[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
[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 + (disabled
[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 tunnels
[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 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 - **DEPRECATED** This option will be remo
[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 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 the firewall l
[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 put
[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 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 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
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, );
>>> write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len,
>>> );
>>>
>>> +for (int i=0; i < o->domain_search_list_len; i++)
>>> +{
>>> +write_dhcp_search_str(buf, 119, o->domain_search_list[i], );
>>> +}
>> I assume that this won't work. In the DHCP answer, it must be a single
>> option with the concatenated list, not multiple answers with a single
>> domain name each.
>>
>> gert
>>
> see https://tools.ietf.org/html/rfc3397
>
> "
>
>In the above diagram, Searchstring is a string specifying the
>searchlist. If the length of the searchlist exceeds the maximum
>permissible within a single option (255 octets), then multiple
>options MAY be used, as described in "Encoding Long Options in the
>Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396
> <https://tools.ietf.org/html/rfc3396>].
>
> "
>
>
> so you MAY use this option multiple times - and wireshark groks it fine. I
> don't have a Windows 10
> client to test it against, however, so I am hoping that someone (Selva?) can
> do that for me.
>
Hi,
Can we please see this discussion also in context of this mail thread, which
tries to look a broader at this challenge?
Message-Id:
URL:
<https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20101.html>
One change in that RFC since last time is that we will move IV_PROTO to be
only about the OpenVPN wire protocol (features/settings only affecting
protocol for the communication between the OpenVPN end-points themselves).
The DNS settings and more related to host configuration and similar will be
moved into an IV_FEAT field. Except of that, nothing else has changed from
the initial mail.
The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
consistently across all OpenVPN implementations we care about, and that we
document this properly.
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] New man page corrections - advanced-options.rst
On 26/06/2020 15:32, Richard Bonhomme wrote: > Signed-off-by: Richard Bonhomme > --- > doc/man-sections/advanced-options.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/doc/man-sections/advanced-options.rst > b/doc/man-sections/advanced-options.rst > index 262e568c..dbf7799c 100644 > --- a/doc/man-sections/advanced-options.rst > +++ b/doc/man-sections/advanced-options.rst > @@ -61,5 +61,5 @@ used when debugging or testing out special usage scenarios. > > --rcvbuf size > - Set the TCP/UDP socket receive buffer size. Defaults to operation system > + Set the TCP/UDP socket receive buffer size. Defaults to operating system >default. > > @@ -89,5 +89,5 @@ used when debugging or testing out special usage scenarios. > > --sndbuf size > - Set the TCP/UDP socket send buffer size. Defaults to operation system > + Set the TCP/UDP socket send buffer size. Defaults to operating system >default. Thanks again! I've squashed this change into your previous grammar/typo fix commit. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] New man page corrections - encryption-options.rst
On 26/06/2020 16:34, tincanteksup wrote: > Comment inline: > > On 26/06/2020 15:29, Richard Bonhomme wrote: >> Signed-off-by: Richard Bonhomme >> --- >> doc/man-sections/encryption-options.rst | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/doc/man-sections/encryption-options.rst >> b/doc/man-sections/encryption-options.rst >> index 42c80eb8..076b5fd3 100644 >> --- a/doc/man-sections/encryption-options.rst >> +++ b/doc/man-sections/encryption-options.rst >> @@ -86,5 +86,5 @@ Generating key material >> * Generating *TLS Crypt v2 Server key* >> - Generate a ``--tls-crypt-v2`` key tp be used by an OpenVPN server. >> + Generate a ``--tls-crypt-v2`` key to be used by an OpenVPN server. >> The key is stored in ``keyfile``. >> @@ -127,7 +127,7 @@ Generating key material >> *Note:* >> - This file should be kept secret to the server as anyone that >> - access to this file will be to generate auth tokens that the OpenVPN >> - server will accept as valid. >> + This file should be kept secret to the server as anyone that has > > I don't know if this is correct or if it should read: > This file should be kept secret from the server .. It wouldn't make sense to keep a (shared) private key used for encryption "secret from the server"; that would make it a bit difficult to use :) I think what was meant was: "This file should be kept secret *on* the server ..." -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] New man page - Simple corrections
On 25/06/2020 23:01, Richard Bonhomme wrote: > Signed-off-by: Richard Bonhomme > --- > doc/man-sections/connection-profiles.rst | 2 +- > doc/man-sections/examples.rst| 2 +- > doc/man-sections/pkcs11-options.rst | 2 +- > doc/man-sections/plugin-options.rst | 4 ++-- > doc/man-sections/signals.rst | 2 +- > doc/man-sections/unsupported-options.rst | 4 ++-- > 6 files changed, 8 insertions(+), 8 deletions(-) > Thanks a lot! I've applied the patch and pushed it out. Just did a minor adjustment to the commit subject, to align it with the other commits in this branch. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 00/11] man-page overhaul project
On 24/06/2020 20:07, David Sommerseth wrote: > Hi, > > This is the first real review round of the man-page overhaul project. > Since the n/groff based openvpn.8 format is fairly cumbersome to edit, > we agreed at the 2019 Hackathon in Trento to move the man page into > something more editing and management friendly. > > This set of patches converts the openvpn.8 file into the > ReStructuredText format (.rst) which can easily be converted into both > man and html files using python-docutils. The advantage of this format > is that it is easy to edit in any plain text editors and displays > reasonably well in any terminals. And it will be easier to review > patches man page updates sent to the mailing list. > > To avoid everyone building the OpenVPN source tarball to have the full > python stack available, the doc/Makefile.am file has been adopted to > generate the man and html files when we create the source tarball > we distribute in releases. Only users only pulling down the source > directly from git will need to have python-docutils available. > > As I worked my way through the man page, there were several things > which was less good. Lots of options where misplaced in not related > sections, a few options where documented several places. And lots > of the sections overlapped quite a bit. From patch 5/11 splits > the whole man page into several smaller files; one file per section. > This is all tied into a single man-page/html file when running the > rst2man/rst2html tools. The following patches just cleans up and > moves some options into more suitable sections. > > > I will continue to update my own git branch containing this work as > review comments come in until this is merged into master. You can > find it here: > > https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting/doc > So sf.net mailing list is grumpy at me for sending a large mail, patch 5/11 is currently waiting to be unlocked by the list admin. In the mean time, here's the patch: <https://gitlab.com/dazo/openvpn/-/commit/6eef9d3b1989166542805644cbc74baa96c72a80.patch> -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 07/11] doc/man: Move --dhcp-option from client to vpn-network section
Even though the --dhcp-option is only useful in a client context, it is
more related to configuration of the VPN network interface and the
related settings.
Signed-off-by: David Sommerseth
---
doc/man-sections/client-options.rst | 69
doc/man-sections/vpn-network-options.rst | 69
2 files changed, 69 insertions(+), 69 deletions(-)
diff --git a/doc/man-sections/client-options.rst
b/doc/man-sections/client-options.rst
index d6f9e6aa..966ede1e 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -146,75 +146,6 @@ configuration.
--connect-timeout n
See ``--server-poll-timeout``.
---dhcp-option args
- Set additional network settings via DHCP. On Windows, this is parsed by
- the ``tap-windows6`` or ``wintun`` driver. On other platforms these
- options can be picked up by a ``--up`` script or plug-in if it has been
- pushed by the OpenVPN server. The option will then be saved in the
- client's environment before the ``--up`` script is called, under the name
- :code:`foreign_option_{n}`.
-
- Valid syntax:
- ::
-
- dhcp-options type [parm]
-
- :code:`DOMAIN` ``name``
-Set Connection-specific DNS Suffix to :code:`name`.
-
- :code:`DNS` ``address``
-Set primary domain name server IPv4 or IPv6 address.
-Repeat this option to set secondary DNS server addresses.
-
-Note: DNS IPv6 servers are currently set using netsh (the existing
-DHCP code can only do IPv4 DHCP, and that protocol only permits
-IPv4 addresses anywhere). The option will be put into the
-environment, so an ``--up`` script could act upon it if needed.
-
- :code:`WINS` ``address``
-Set primary WINS server address (NetBIOS over TCP/IP Name Server).
-Repeat this option to set secondary WINS server addresses.
-
- :code:`NBDD` ``address``
-Set primary NBDD server address (NetBIOS over TCP/IP Datagram
-Distribution Server). Repeat this option to set secondary NBDD
-server addresses.
-
- :code:`NTP` ``address``
-Set primary NTP server address (Network Time Protocol).
-Repeat this option to set secondary NTP server addresses.
-
- :code:`NBT` ``type``
-Set NetBIOS over TCP/IP Node type. Possible options:
-
-:code:`1`
- b-node (broadcasts)
-
-:code:`2`
- p-node (point-to-point name queries to a WINS server)
-
-:code:`4`
- m-node (broadcast then query name server)
-
-:code:`8`
- h-node (query name server, then broadcast).
-
- :code:`NBS` ``scope-id``
-Set NetBIOS over TCP/IP Scope. A NetBIOS Scope ID provides an
-extended naming service for the NetBIOS over TCP/IP (Known as NBT)
-module. The primary purpose of a NetBIOS scope ID is to isolate
-NetBIOS traffic on a single network to only those nodes with the
-same NetBIOS scope ID. The NetBIOS scope ID is a character string
-that is appended to the NetBIOS name. The NetBIOS scope ID on two
-hosts must match, or the two hosts will not be able to communicate.
-The NetBIOS Scope ID also allows computers to use the same computer
-name, as they have different scope IDs. The Scope ID becomes a part
-of the NetBIOS name, making the name unique. (This description of
-NetBIOS scopes courtesy of neonsu...@abyss.com)
-
- :code:`DISABLE-NBT`
-Disable Netbios-over-TCP/IP.
-
--explicit-exit-notify n
In UDP client mode or point-to-point mode, send server/peer an exit
notification if tunnel is restarted or OpenVPN process is exited. In
diff --git a/doc/man-sections/vpn-network-options.rst
b/doc/man-sections/vpn-network-options.rst
index fc18676e..d75cf540 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -88,6 +88,75 @@ routing.
the TUN/TAP device used with ``--dev`` does not begin with :code:`tun`
or :code:`tap`.
+--dhcp-option args
+ Set additional network settings via DHCP. On Windows, this is parsed by
+ the ``tap-windows6`` or ``wintun`` driver. On other platforms these
+ options can be picked up by a ``--up`` script or plug-in if it has been
+ pushed by the OpenVPN server. The option will then be saved in the
+ client's environment before the ``--up`` script is called, under the name
+ :code:`foreign_option_{n}`.
+
+ Valid syntax:
+ ::
+
+ dhcp-options type [parm]
+
+ :code:`DOMAIN` ``name``
+Set Connection-specific DNS Suffix to :code:`name`.
+
+ :code:`DNS` ``address``
+Set primary domain name server IPv4 or IPv6 address.
+Repeat this option to set secondary DNS server addresses.
+
+Note: DNS IPv6 servers are currently set using netsh (the existing
+DHCP code can only do IPv4 DHCP, and that protocol only permits
+IPv4 addresses anywhere). The option will be put
[Openvpn-devel] [PATCH 11/11] doc/man: Cleaned up the examples
Removed a lot of outdated information. The loading of the tun module is not needed on current Linux distributions; it is automatically loaded when needed. Also removed all the iptables references and rather refer the reader to figure out how firewalling is configured on their system. The reason is that iptables is moving towards being deprecated in faviour of nftables/nft. In addition many Linux distributions provide their own wrappers around it (ufw, firewalld, to mention a couple). In addition it makes the man page less Linux-centric. The only Linux specific reference left is configuration of IP forwarding. But extended the text to ask the reader to find the preferred way of configuring IP forwarding in a persistent way. Many Linux distributions uses their own set of network configuration tools as well (NetworkManager, systemd-networkd, netplan, to mention a few). The rest of the instructions should be fairly OS neutral and is a quick introduction how to get tunnels configured and gradually expand the configuration and improve the security along the way. Signed-off-by: David Sommerseth --- doc/man-sections/examples.rst | 105 -- 1 file changed, 11 insertions(+), 94 deletions(-) diff --git a/doc/man-sections/examples.rst b/doc/man-sections/examples.rst index 0bea7f5a..ecc2a29f 100644 --- a/doc/man-sections/examples.rst +++ b/doc/man-sections/examples.rst @@ -7,32 +7,12 @@ installed OpenVPN, consult the INSTALL file included in the OpenVPN distribution. -TUN/TAP Setup: --- - -If you are using Linux 2.4 or higher, make the tun device node and load -the tun module: - -:: - -mknod /dev/net/tun c 10 200 -modprobe tun - -If you installed from RPM, the ``mknod`` step may be omitted, because -the RPM install does that for you. - -Only Linux 2.4 and newer are supported. - -For other platforms, consult the INSTALL file at -https://openvpn.net/community-resources/the-standard-install-file-included-in-the-source-distribution/ -for more information. - - Firewall Setup: --- If firewalls exist between the two machines, they should be set to -forward UDP port 1194 in both directions. If you do not have control +forward the port OpenVPN is configured to use, in both directions. +The default for OpenVPN is 1194/udp. If you do not have control over the firewalls between the two machines, you may still be able to use OpenVPN by adding ``--ping 15`` to each of the ``openvpn`` commands used below in the examples (this will cause each peer to send out a UDP @@ -40,13 +20,8 @@ ping to its remote peer once every 15 seconds which will cause many stateful firewalls to forward packets in both directions without an explicit firewall rule). -If you are using a Linux iptables-based firewall, you may need to enter -the following command to allow incoming packets on the TUN device: - -:code:`iptables -A INPUT -i tun+ -j ACCEPT` - -See the firewalls section below for more information on configuring -firewalls for use with OpenVPN. +Please see your operating system guides for how to configure the firewall +on your systems. VPN Address Setup: @@ -239,10 +214,14 @@ enable routing: echo 1 > /proc/sys/net/ipv4/ip_forward -and enable TUN packet forwarding through the firewall: -:: +This setting is not persistent. Please see your operating systems +documentation how to properly configure IP forwarding, which is also +persistent through system boots. - iptables -A FORWARD -i tun+ -j ACCEPT +If you system is configured with a firewall. Please see your operating +systems guide on how to configure the firewall. You typically want to +allow traffic coming from and going to the tun/tap adapter OpenVPN is +configured to use. On bob: :: @@ -260,65 +239,3 @@ Now any machine on the *10.0.0.0/24* subnet can access any machine on the In a production environment, you could put the route command(s) in a script and execute with the ``--up`` option. - -FIREWALLS -= - -OpenVPN's usage of a single UDP port makes it fairly firewall-friendly. -You should add an entry to your firewall rules to allow incoming OpenVPN -packets. On Linux 2.4+: -:: - - iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT - -This will allow incoming packets on UDP port :code:`1194` (OpenVPN's -default UDP port) from an OpenVPN peer at :code:`1.2.3.4`. - -If you are using HMAC-based packet authentication (the default in any of -OpenVPN's secure modes), having the firewall filter on source address -can be considered optional, since HMAC packet authentication is a much -more secure method of verifying the authenticity of a packet source. In -that case: -:: - - iptables -A INPUT -p udp --dport 1194 -j ACCEPT - -would be adequate and would not render the host inflexible with respect -to its peer having a dynamic IP address. - -OpenVPN also works well on stateful firewalls. In some cases, you may -not need to add any static rules to the firewall l
[Openvpn-devel] [PATCH 10/11] doc/man: Moved --reneg-* options to its own section
The options related to renegotiation of the data channel encryption key is not really a link option. As the renegotiation is encryption related but doesn't really fit into the generic, tls or pkcs11 sections, add it into its own section. Signed-off-by: David Sommerseth --- doc/man-sections/encryption-options.rst | 1 + doc/man-sections/link-options.rst | 47 -- doc/man-sections/renegotiation.rst | 53 + 3 files changed, 54 insertions(+), 47 deletions(-) create mode 100644 doc/man-sections/renegotiation.rst diff --git a/doc/man-sections/encryption-options.rst b/doc/man-sections/encryption-options.rst index 5e99c52f..42c80eb8 100644 --- a/doc/man-sections/encryption-options.rst +++ b/doc/man-sections/encryption-options.rst @@ -130,6 +130,7 @@ Generating key material access to this file will be to generate auth tokens that the OpenVPN server will accept as valid. +.. include:: renegotiation.rst .. include:: tls-options.rst .. include:: pkcs11-options.rst diff --git a/doc/man-sections/link-options.rst b/doc/man-sections/link-options.rst index 5f75c5f3..43e33176 100644 --- a/doc/man-sections/link-options.rst +++ b/doc/man-sections/link-options.rst @@ -284,53 +284,6 @@ the local and the remote host. and has been used since version 2.0-beta17. Previous versions used port 5000 as the default. ---reneg-bytes n - Renegotiate data channel key after ``n`` bytes sent or received - (disabled by default with an exception, see below). OpenVPN allows the - lifetime of a key to be expressed as a number of bytes - encrypted/decrypted, a number of packets, or a number of seconds. A key - renegotiation will be forced if any of these three criteria are met by - either peer. - - If using ciphers with cipher block sizes less than 128-bits, - ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly - disabled by setting the value to :code:`0`, but this is - **HIGHLY DISCOURAGED** as this is designed to add some protection against - the SWEET32 attack vector. For more information see the ``--cipher`` - option. - ---reneg-pkts n - Renegotiate data channel key after **n** packets sent and received - (disabled by default). - ---reneg-sec args - Renegotiate data channel key after at most ``max`` seconds - (default :code:`3600`) and at least ``min`` seconds (default is 90% of - ``max`` for servers, and equal to ``max`` for clients). - :: - - reneg-sec max [min] - - The effective ``--reneg-sec`` value used is per session - pseudo-uniform-randomized between ``min`` and ``max``. - - With the default value of :code:`3600` this results in an effective per - session value in the range of :code:`3240`..:code:`3600` seconds for - servers, or just 3600 for clients. - - When using dual-factor authentication, note that this default value may - cause the end user to be challenged to reauthorize once per hour. - - Also, keep in mind that this option can be used on both the client and - server, and whichever uses the lower value will be the one to trigger - the renegotiation. A common mistake is to set ``--reneg-sec`` to a - higher value on either the client or server, while the other side of the - connection is still using the default value of :code:`3600` seconds, - meaning that the renegotiation will still occur once per :code:`3600` - seconds. The solution is to increase --reneg-sec on both the client and - server, or set it to :code:`0` on one side of the connection (to - disable), and to your chosen value on the other side. - --rport port Set TCP/UDP port number or name used by the ``--remote`` option. The port can also be set directly using the ``--remote`` option. diff --git a/doc/man-sections/renegotiation.rst b/doc/man-sections/renegotiation.rst new file mode 100644 index ..aaede4eb --- /dev/null +++ b/doc/man-sections/renegotiation.rst @@ -0,0 +1,53 @@ +Data Channel Renegotiation +-- + +When running OpenVPN in client/server mode, the data channel will use a +separate ephemeral encryption key which is rotated at regular intervals. + +--reneg-bytes n + Renegotiate data channel key after ``n`` bytes sent or received + (disabled by default with an exception, see below). OpenVPN allows the + lifetime of a key to be expressed as a number of bytes + encrypted/decrypted, a number of packets, or a number of seconds. A key + renegotiation will be forced if any of these three criteria are met by + either peer. + + If using ciphers with cipher block sizes less than 128-bits, + ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly + disabled by setting the value to :code:`0`, but this is + **HIGHLY DISCOURAGED** as this is designed to add some protection against + the SWEET32 attack vector. For more information see the ``--cipher`` + option. + +--reneg-pkts n + Renegotiate data channel key after **n** packets sent and received + (disabled
[Openvpn-devel] [PATCH 04/11] doc/man: Remove unsupported options in OpenVPN 2.5
This removes the options from the man page which is enlisted as deprecated options in OpenVPN 2.5. To provide some history, a short summary of why they were removed has been put into a new file which is included into its own "UNSUPPORTED OPTIONS" section in the man page. Signed-off-by: David Sommerseth --- doc/openvpn.8.rst | 144 +--- doc/unsupported-options.rst | 33 + 2 files changed, 35 insertions(+), 142 deletions(-) create mode 100644 doc/unsupported-options.rst diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst index fc3ecdb8..713cd309 100644 --- a/doc/openvpn.8.rst +++ b/doc/openvpn.8.rst @@ -454,9 +454,7 @@ Tunnel Options: the client's tun interface always points to the local endpoint of the server's tun interface. This mode allocates a single IP address per connecting client. Only use when none of the connecting clients are -Windows systems. This mode is functionally equivalent to the -``--ifconfig-pool-linear`` directive which is available in OpenVPN 2.0, -is deprecated and will be removed in OpenVPN 2.5 +Windows systems. :code:`subnet` Use a subnet rather than a point-to-point topology by @@ -2184,17 +2182,6 @@ fast hardware. SSL/TLS authentication must be used in this mode. receive the given IP address. If you want guaranteed assignment, use ``--ifconfig-push`` ---ifconfig-pool-linear - **DEPRECATED** This option will be removed in OpenVPN 2.5 - - Modifies the ``--ifconfig-pool`` directive to allocate individual TUN - interface addresses for clients rather than /30 subnets. - - *NOTE:* This option is incompatible with Windows clients. - - This option is deprecated, and should be replaced with ``--topology - p2p`` which is functionally equivalent. - --ifconfig-push args Push virtual IP endpoints for client tunnel, overriding the ``--ifconfig-pool`` dynamic allocation. @@ -2668,17 +2655,6 @@ fast hardware. SSL/TLS authentication must be used in this mode. authentication module/script MUST have logic to detect this condition and respond accordingly. ---client-cert-not-required - **DEPRECATED** This option will be removed in OpenVPN 2.5 - - Don't require client certificate, client will authenticate using - username/password only. Be aware that using this directive is less - secure than requiring certificates from all clients. - - **Please note:** This is replaced by ``--verify-client-cert`` which - allows for more flexibility. The option ``--verify-client-cert none`` is - functionally equivalent to ``--client-cert-not-required`` - --verify-client-cert mode Specify whether the client is required to supply a valid certificate. @@ -3178,41 +3154,6 @@ These options are meaningful for both Static & TLS-negotiated key modes ``--show-engines`` standalone option to list the crypto engines which are supported by OpenSSL. ---no-replay - **DEPRECATED** This option will be removed in OpenVPN 2.5. - - (Advanced) Disable OpenVPN's protection against replay attacks. Don't - use this option unless you are prepared to make a tradeoff of greater - efficiency in exchange for less security. - - OpenVPN provides datagram replay protection by default. - - Replay protection is accomplished by tagging each outgoing datagram with - an identifier that is guaranteed to be unique for the key being used. - The peer that receives the datagram will check for the uniqueness of the - identifier. If the identifier was already received in a previous - datagram, OpenVPN will drop the packet. Replay protection is important - to defeat attacks such as a SYN flood attack, where the attacker listens - in the wire, intercepts a TCP SYN packet (identifying it by the context - in which it occurs in relation to other packets), then floods the - receiving peer with copies of this packet. - - OpenVPN's replay protection is implemented in slightly different ways, - depending on the key management mode you have selected. - - In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses - a 64 bit unique identifier that combines a time stamp with an - incrementing sequence number. - - When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses - only a 32 bit sequence number without a time stamp, since OpenVPN can - guarantee the uniqueness of this value for each key. As in IPSec, if the - sequence number is close to wrapping back to zero, OpenVPN will trigger - a new key exchange. - - To check for replays, OpenVPN uses the *sliding window* algorithm used - by IPSec. - --replay-window args Modify the replay protection sliding-window size and time window. @@ -3311,27 +3252,6 @@ These options are meaningful for both Static & TLS-negotiated key modes default) and you are using either ``--secret`` (shared-secret key mode) or TLS mode with ``--tls-auth``. ---no-iv - **DEPRECATED** This option will be remo
[Openvpn-devel] [PATCH 03/11] doc/man: Move profiles section
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 tunnels
[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 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 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
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] [RFC] Challenges with OpenVPN and configuring DNS
ropose the following bit-mask: - bit 0 (1) Reserved (this is essentially today's IV_PROTO=1) - bit 1 (2) Supports P_DATA_V2 (IV_PROTO=2 in current implementations) - bit 2 (4) - Extended DNS support Supports the additional DNS options: DOMAIN-SEARCH, DOMAIN-ROUTE, DNSSEC. DOMAIN will only allowed once. - bit 3 (8) - Split DNS Client can configure split DNS on the host - bit 4 (16) - Blocking/Exclusive DNS Client can configure exclusive DNS with blocking (exclusive) - bit 5 (32) - DNSSEC Client can modify DNSSEC configuration for VPN DNS resolver based on the DNSSEC option. We have looked through the other IV_* options as well, and we can also consider to allocate a bit for IV_TCPNL and start a process to deprecate the dedicated IV_TCPNL variable. This is to save space in the IV_* already limited IV buffer. We considered the compression options as well (IV_LZO, IV_LZ4, IV_LZ4v2 and IV_COMP_STUB*) but believe these should move away from compression in the future. Some of these IV_PROTO settings can on some platforms be added into OpenVPN itself. But we believe it is good to also allow the --plugin and script hooks to also facilitate these settings. This allows a simpler OpenVPN binary to signal to the server that it intends to support various features. In this discussion, we also realized this can also be used for the auth-pending feature as well, which currently is only supported via the management interface. We therefore suggests adding yet another OpenVPN option: --feature-support GROUP TEXT-FLAGS * GROUP: dns with these flags: - `extended` sets IV_PROTO bit 2 if not already set. - `split-dns` sets IV_PROTO bit 3 - `dns-block` sets IV_PROTO bit 4 - `dnssec` sets IV_PROTO bit 5 * GROUP: auth-pending This signals to the server which kind of pending authentication features the client can support - `openurl` Adds `openurl` to IV_SSO - `proxyurl` Adds proxyurl to IV_SSO - `crtext` Adds crtext to IV_SSO For platform implementations we have considered the following: * macOS Tunnelblick uses external scripts which are well tested and seems to work fine. Will it make sense to implement native DNS configuration support into OpenVPN on macOS? This might mean we need to link OpenVPN against some Objective-C code to communicate directly with the network configuration APIs. It could also be possible to implement this as an external plug-in, which extends OpenVPN's current behavior. * Windows On Windows we already have a native implementation. We did not consider any alternative approaches here. * Android Has its own implementation in OpenVPN for Android, with ideas from the the Windows implementation. This also facilitates the possibilities provided via the VPN API in Android. * Linux Currently uses --up scripts (pull-resolv-conf, update-systemd-resolved) and --plugin (NetworkManager). It is possible to implement a plug-in which talks directly to systemd-resolved as well. Native support included would require linking against a D-Bus library, which can become pretty invasive. There are some advantages to move over to a --plugin for systemd-resolved support, as it can interact quicker with the service instead of running a script which parses options and does the same D-Bus calls to systemd-resolved. But this will not get a too high priority as the script based update-systemd-resolved approach will work well too. OpenVPN 3 Linux will be extended with native systemd-resolved support in a coming release. * *BSD We do not know enough of the capabilities here. But a both script and --plugin solutions can work, especially if facilitating the new --feature-support option - where it will be more up to the script/plug-in to define what it will be capable of. -- kind regards, Arne Schwabe David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
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
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
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 > and do every
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
[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] [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] 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=20200624T10=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] [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
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
[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 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
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 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 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(, strlen(e->string)+1))
> {
> buf_printf(, "%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 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] 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 v2 5/5] Implement forwarding client CR_RESPONSE messages to management
man_output_env(es, true, management->connection.env_filter_level,
> "CLIENT");
> +management_notify_generic(management, BSTR());
> +
> +gc_free();
> +}
> +}
> +
> 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(, 11) && buf_read_u8() == ',' && BLEN())
> +{
> +m = BSTR();
> +}
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 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 4/5] Implement sending SSO challenge to clients
_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(>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();
> }
>
> +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, );
> +buf_printf(, info_pre);
> +buf_printf(, "%s", extra);
> +send_control_channel_string(c, BSTR(), D_PUSH);
> +
> +gc_free();
> +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 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] 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] 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(_key_pem));
> -client_filename = INLINE_FILE_TAG;
> -client_inline = (const char *)BPTR(_key_pem);
> +client_file = (const char *)BPTR(_key_pem);
> +client_inline = true;
> }
> else if (!buffer_write_file(filename, _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(_client_key, _wrapped_client_key,
> - client_filename, client_inline);
> + client_file, client_inline);
> free_key_ctx_bi(_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);
>
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] 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
[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
[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] 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
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
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] 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] [PATCH v2 4/5] Implement sending SSO challenge to clients
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). > > 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(+) Code and management notes looks reasonable. But again, it would be good to have a way to test this properly to avoid regressions later on. Since this is also a more advanced authentication method, having good test methods is even more critical. -- 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] Reformat all source files
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 > > This run used Uncrustify-0.69.0_f > --- > src/openvpn/buffer.c | 2 +- > src/openvpn/crypto.h | 2 +- > src/openvpn/networking.h | 4 +-- > src/openvpn/networking_iproute2.c | 14 > src/openvpn/networking_sitnl.h| 2 +- > src/openvpn/openvpn.h | 2 +- > src/openvpn/options.c | 8 +++-- > src/openvpn/options.h | 4 +-- > src/openvpn/proto.h | 2 +- > src/openvpn/push.c| 20 ++-- > src/openvpn/route.c | 2 +- > src/openvpn/socket.h | 54 +++ > src/openvpn/ssl.c | 6 ++-- > src/openvpn/ssl.h | 1 + > src/openvpn/ssl_openssl.c | 10 +++--- > src/openvpn/ssl_verify.c | 18 +-- > src/openvpn/ssl_verify.h | 3 +- > src/openvpn/tun.c | 20 ++-- > src/openvpn/vlan.c| 4 +-- > 19 files changed, 99 insertions(+), 79 deletions(-) > 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 -- 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 1/5] Implement parsing and sending INFO and INFO_PRE control messages
On 09/11/2019 16:13, 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| 33 +
> src/openvpn/push.h| 3 +++
> 3 files changed, 44 insertions(+)
>
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
> index 8451706b..0f735384 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -395,6 +395,14 @@ check_incoming_control_channel_dowork(struct context *c)
> {
> server_pushed_signal(c, , false, 4);
> }
> +else if (buf_string_match_head_str(, "INFO_PRE"))
> +{
> +server_pushed_info(c, , 8);
> +}
> +else if (buf_string_match_head_str(, "INFO"))
> +{
> +server_pushed_info(c, , 4);
> +}
> else
> {
> msg(D_PUSH_ERRORS, "WARNING: Received unknown control
> message: %s", BSTR());
> diff --git a/src/openvpn/push.c b/src/openvpn/push.c
> index 368b6920..ee1cb980 100644
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -178,6 +178,39 @@ server_pushed_signal(struct context *c, const struct
> buffer *buffer, const bool
> }
> }
>
> +void
> +server_pushed_info(struct context *c, const struct buffer *buffer,
> + const int adv)
> +{
> +const char *m = "";
> +struct buffer buf = *buffer;
> +
> +if (buf_advance(, adv) && buf_read_u8() == ',' && BLEN())
> +{
> +m = BSTR();
> +}
> +
> +#ifdef ENABLE_MANAGEMENT
> +struct gc_arena gc;
> +if (management)
> +{
> +gc = gc_new();
> +
> +/*
> + * We use >INFOMSG here instead of plain >INFO since INFO is used to
> + * for management greeting and we don't want to confuse the client
> + */
> +struct buffer out = alloc_buf_gc(256, );
> +buf_printf(, ">%s:%s", "INFOMSG", m);
> + management_notify_generic(management, BSTR());
> +
> +gc_free();
> +}
> +#endif
The indent of this #endif is wrong. Wouldn't harm with an "/*
ENABLE_MANAGEMENT */" comment as well. This could be fixed at merge time.
Otherwise, this looks 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 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(, strlen(e->string)+1))
>> {
>> buf_printf(, "%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 v2 3/5] Implement sending response to challenge via CR_RESPONSE
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 Typo. IV_SOO -> IV_SSO > 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. Could we have some kind of test/sample script demonstrating this feature? It would also help test that this feature works and also useful for regression testing later on. -- 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 v6 5/5] Normalise ncp-ciphers option and restrict it to 127 bytes
On 12/03/2020 12:36, Arne Schwabe wrote: > In scenarios of mbed TLS vs OpenSSL we already normalise the ciphers > that are send via the wire protocol via OCC to not have a mismatch > warning between server and client. This is done by > translate_cipher_name_from_openvpn. The same applies also to the > ncp-ciphers list. Specifying non normalised names in ncp-ciphers will > cause negotation not to succeed if ciphers are not in the same form. > Therefore we will normalise the ciphers in options_postmutate. > > The alternative and a lot less user friendly alternative would be to > bail if on of the ciphers in ncp-ciphers is not in its normalised form. > > Also restrict the ncp-ciphers list to 127. This is somewhat arbitrary > but should prevent too large IV_CIPHER messages and problems sending > those. The server will accept also large IV_CIPHER values from clients. > > Patch V2: Correct comment about normalising ciphers > Patch V3: Correct #ifdef statement > Patch V5: Fix tests with OpenSSL 1.0.2 and libraries missing Chacha > Patch V6: Fix unit tests for mbed tls, which recognises ChaCha20-Poly1305 > only when used with all uppercase, fix missing space in message > > Signed-off-by: Arne Schwabe > --- > doc/openvpn.8 | 3 ++ > src/openvpn/options.c | 14 --- > src/openvpn/ssl_ncp.c | 57 + > src/openvpn/ssl_ncp.h | 19 +- > tests/unit_tests/openvpn/test_ncp.c | 54 +++ > 5 files changed, 125 insertions(+), 22 deletions(-) > I've only done quick code review and built it on RHEL7 not finding any issues. Code looks reasonable, so I don't see any reason to hold this back any more. 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] OpenVPN git master builds for Fedora/RHEL/CentOS
Hi, I've put together a Fedora Copr repository which contains builds of the OpenVPN 2.x git master; which will contains what will arrive in the next major release. <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-git/> Instructions are pretty simple when using yum copr. If you are on RHEL/CentOS/Scientific Linux, ensure you have the 'yum-plugin-copr' package installed first. Then you can just do: # yum copr enable dsommers/openvpn-git # yum clean all If the copr plugin is not available, see the URL above for direct access to the repository files. If you already have openvpn installed: # yum update openvpn Or replace 'update' with 'install' if this is a fresh openvpn install. I will on some semi-regular intervals update these builds when I see git master has been updated. If you have any issues, you can easily downgrade to the previous version by doing 'yum downgrade openvpn'. If you have automated updates enabled on your system, you might want to consider to blacklist the openvpn package - as the openvpn git master might not be as stable yet as the released versions. -- 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 some limitations of --auth-user-pass
On 16/03/2020 14:48, Selva Nair wrote: [...snip...] >> I would just rephrase it to say: >> >> OpenVPN GUI v11 and newer uses its own internal username/password storage >> independent of the --auth-user-pass file provided. The file argument is >> ignored on such installations. > > I wish it behaved like that. Unfortunately the file argument is not > ignored in such cases. If the file has only username, openvpn.exe > reads it from the file and then fails to prompt for password as there > is no console available. Ouch ... that is a pointless misbehavior. Lets try to fix that. > I propose to change this behaviour to: if --management-query-passwords > is set (which the GUI does), ignore the file given in auth-user-pass > and prompt both username and password from management. I think its > only logical for a later option (in this case the one set by the GUI) > to override a previous one. Anyway we do already ignore it if the file > is "stdin". Agreed! -- 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 some limitations of --auth-user-pass
On 13/03/2020 14:01, sam...@openvpn.net wrote: > From: Samuli Seppänen > > URL: https://community.openvpn.net/openvpn/ticket/757 > Signed-off-by: Samuli Seppänen > --- > doc/openvpn.8 | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/openvpn.8 b/doc/openvpn.8 > index 864f94e8..9e54890e 100644 > --- a/doc/openvpn.8 > +++ b/doc/openvpn.8 > @@ -4127,6 +4127,12 @@ The server configuration must specify an > .B \-\-auth\-user\-pass\-verify > script to verify the username/password provided by > the client. > + > +Note that OpenVPN GUI on Windows does not prompt for the > +password if the file contains only the username. However, > +OpenVPN versions from 2.4 up bundle OpenVPN GUI version 11 > +which is able to cache usernames and passwords internally. > + Could we rephrase this, to not live in the past. This will go into master and probably also release/2.4. I also doubt anyone using man pages on 2.3 would even read this. If there are Windows users on 2.3, there are no excuse not to upgrade - unless it's an enterprise deployment, where end users most likely would not even care (they should anyway complain to their IT department regardless, for using outdated security software). I would just rephrase it to say: OpenVPN GUI v11 and newer uses its own internal username/password storage independent of the --auth-user-pass file provided. The file argument is ignored on such installations. (or something like that) -- 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] build: Remove --disable-server from ./configure
After some discussion among the core community developers [1,2], it was
decided to remove the possibility to build openvpn as a pure client.
This was alterted on the mailing list [3] that it was scheduled for
removal unless anyone had strong arguments why it was needed.
The general consensus was that we had not received any strong arguments
to keep this possibility after approximately 5 months, so it was fine to
remove this ./configure option.
By removing this, we remove quite some entangled sections of #ifdef
scattered all over the code base, making it more readable.
One note:
Inside the options_postprocess_mutate_invariant() function,
the #ifdef P2MP_SERVER and #ifdef _WIN32 blocks where slightly
reworked to make the _WIN32 block more continous and avoiding having an
empty if(options->mode == MODE_SERVER) block.
Signed-off-by: David Sommerseth
[1]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18830.html
[2]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19505.html
[3]
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18829.html
---
configure.ac| 8
doc/doxygen/openvpn.doxyfile.in | 2 +-
src/openvpn/forward.c | 5 +
src/openvpn/helper.c| 8
src/openvpn/init.c | 14 --
src/openvpn/list.c | 8
src/openvpn/list.h | 3 ---
src/openvpn/misc.c | 4
src/openvpn/misc.h | 3 ---
src/openvpn/mroute.c| 8
src/openvpn/mroute.h| 3 ---
src/openvpn/mtcp.c | 4
src/openvpn/mtcp.h | 3 ---
src/openvpn/mudp.c | 3 ---
src/openvpn/mudp.h | 5 +
src/openvpn/multi.c | 9 -
src/openvpn/multi.h | 3 ---
src/openvpn/openvpn.c | 2 --
src/openvpn/openvpn.h | 5 -
src/openvpn/options.c | 32 ++--
src/openvpn/options.h | 4
src/openvpn/push.c | 14 --
src/openvpn/push.h | 2 --
src/openvpn/pushlist.h | 5 ++---
src/openvpn/schedule.c | 3 ---
src/openvpn/schedule.h | 3 ---
src/openvpn/ssl.c | 4
src/openvpn/ssl_common.h| 4
src/openvpn/ssl_mbedtls.c | 2 --
src/openvpn/ssl_openssl.c | 2 --
src/openvpn/ssl_verify.c| 2 --
src/openvpn/ssl_verify.h| 2 --
src/openvpn/syshead.h | 16 +---
src/openvpn/vlan.c | 4
src/openvpn/vlan.h | 4
35 files changed, 12 insertions(+), 191 deletions(-)
diff --git a/configure.ac b/configure.ac
index a47ef3e7..59b1ed15 100644
--- a/configure.ac
+++ b/configure.ac
@@ -91,13 +91,6 @@ AC_ARG_ENABLE(
[enable_x509_alt_username="no"]
)
-AC_ARG_ENABLE(
- [server],
- [AS_HELP_STRING([--disable-server], [disable server support only (but
retain client support) @<:@default=yes@:>@])],
- ,
- [enable_server="yes"]
-)
-
AC_ARG_ENABLE(
[plugins],
[AS_HELP_STRING([--disable-plugins], [disable plug-in support
@<:@default=yes@:>@])],
@@ -1218,7 +1211,6 @@ if test "${enable_x509_alt_username}" = "yes"; then
fi
test "${ac_cv_header_sys_uio_h}" = "yes" && AC_DEFINE([HAVE_IOVEC], [1],
[struct iovec needed for IPv6 support])
-test "${enable_server}" = "no" && AC_DEFINE([ENABLE_CLIENT_ONLY], [1], [Enable
client capability only])
test "${enable_management}" = "yes" && AC_DEFINE([ENABLE_MANAGEMENT], [1],
[Enable management server capability])
test "${enable_multihome}" = "yes" && AC_DEFINE([ENABLE_MULTIHOME], [1],
[Enable multi-homed UDP server capability])
test "${enable_debug}" = "yes" && AC_DEFINE([ENABLE_DEBUG], [1], [Enable
debugging support])
diff --git a/doc/doxygen/openvpn.doxyfile.in b/doc/doxygen/openvpn.doxyfile.in
index d9e9ed08..beb02d96 100644
--- a/doc/doxygen/openvpn.doxyfile.in
+++ b/doc/doxygen/openvpn.doxyfile.in
@@ -235,7 +235,7 @@ EXPAND_ONLY_PREDEF = NO
SEARCH_INCLUDES= YES
INCLUDE_PATH =
INCLUDE_FILE_PATTERNS =
-PREDEFINED = _WIN32 NTLM USE_LZO ENABLE_FRAGMENT P2MP P2MP_SERVER
ENABLE_CRYPTO_OPENSSL ENABLE_PLUGIN ENABLE_MANAGEMENT ENABLE_OCC
HAVE_GETTIMEOFDAY
+PREDEFINED = _WIN32 NTLM USE_LZO ENABLE_FRAGMENT P2MP
ENABLE_CRYPTO_OPENSSL ENABLE_PLUGIN ENABLE_MANAGEMENT ENABLE_OCC
HAVE_GETTIMEOFDAY
EXPAND_AS_DEFINED =
SKIP_FUNCTION_MACROS = YES
#---
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index ea10f0bf..dd6bbc69 100644
--- a/src/openvpn/forward.c
+++ b
Re: [Openvpn-devel] [PATCH v4 4/5] Move NCP related function into a seperate file and add unit tests
On 17/02/2020 15:43, Arne Schwabe wrote: > This allows unit test the NCP functions. The ssl.c file has too > many dependencies to make unit testing of it viable. > > Patch V2: Removing the include "ssl_ncp.h" from options.c for V2 of > implement dynamic NCP forces a new version of this patch to > add the #include in this patch. Merge VS studio file changes > for ssl_ncp.[ch] into this patch > > Patch V3: Regenerate for changes in earlier patches, apply Lev's changes > to Visual Studio project file > > Patch V4: Regenerate to also have the changes of earlier patches. > > Signed-off-by: Arne Schwabe > --- > src/openvpn/Makefile.am | 1 + > src/openvpn/init.c | 1 + > src/openvpn/multi.c | 1 + > src/openvpn/openvpn.vcxproj | 2 + > src/openvpn/openvpn.vcxproj.filters | 8 +- > src/openvpn/options.c| 1 + > src/openvpn/push.c | 1 + > src/openvpn/ssl.c| 176 +--- > src/openvpn/ssl.h| 65 > src/openvpn/ssl_ncp.c| 231 +++ > src/openvpn/ssl_ncp.h| 101 > tests/unit_tests/openvpn/Makefile.am | 18 ++- > tests/unit_tests/openvpn/test_ncp.c | 179 + > 13 files changed, 544 insertions(+), 241 deletions(-) > create mode 100644 src/openvpn/ssl_ncp.c > create mode 100644 src/openvpn/ssl_ncp.h > create mode 100644 tests/unit_tests/openvpn/test_ncp.c > Sorry, but this gets a NAK from me. $ ./tests/unit_tests/openvpn/ncp_testdriver [==] Running 4 test(s). [ RUN ] test_check_ncp_ciphers_list Unsupported cipher in --ncp-ciphers: AES-256-GCM Unsupported cipher in --ncp-ciphers: AES-128-GCM [ ERROR ] --- tls_check_ncp_cipher_list(aes_ciphers) [ LINE ] --- test_ncp.c:50: error: Failure! [ FAILED ] test_check_ncp_ciphers_list [ RUN ] test_extract_client_ciphers [ OK ] test_extract_client_ciphers [ RUN ] test_poor_man [ OK ] test_poor_man [ RUN ] test_ncp_best [ OK ] test_ncp_best [==] 4 test(s) run. [ PASSED ] 3 test(s). [ FAILED ] 1 test(s), listed below: [ FAILED ] test_check_ncp_ciphers_list 1 FAILED TEST(S) We can't have any failing tests ;-) This is tested on RHEL-7.7 (openssl-1.0.2k-19) which I also do know have AES-GCM support. -- 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 applied] Fix possibly uninitialized return value in GetOpenvpnSettings()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit e1f7d7885752ac3a0279ecc7e31ccee2af40fbe4 Author: Selva Nair Date: Wed Feb 19 19:49:37 2020 -0500 Fix possibly uninitialized return value in GetOpenvpnSettings() Signed-off-by: Selva Nair Acked-by: Lev Stipakov Message-Id: <1582159777-2437-1-git-send-email-selva.n...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19479.html Signed-off-by: David Sommerseth - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTsaVAAoJEIbPlEyWcf3yC3UP/1i/BYgIF0RXaUY4ghyOZcWk zuDvSrwBu2xCBNjV31h060vIDpLkV7hFNpN1/sxnDblQE2k+R5kInLfJHQs1vDs6 DzyexfFgmZDxexjXkNpUCRfHwL1u1Jv7OFjXGk93OnmUhxIRFtj+ik9RgLG0Hwae vf+uj5Df1LXRRaCb8Psxg2gubcQU800XNZDVhrtCEaaiDjdz691C6ptTBzCNzAIQ 6ptwz2axAzmlIi5QunPKwSmBu5WHrf0azQs2P6adxxRhZyw1a3A3ZadxcgTur+Xj SvD2MNixlmUAm8AbYroQ88sttdExYPR4lasw1l3fDICICcvMj3Eo3bArcD0mfips 3qWIib4cCMQ8EwwSaE9l//fYHcJTvSnKkAhzzQvCcKpbIP0Sl4AYjrZomWwD07bk R6uX2VMc8yBKy8ZYt14mhhxYFpKa2R7UUHagUQXFuiIRppEglnblHJXz89jaUzTj gSJpPDLhrpsg1RLKHhVf3O6T7FKe7ZVu4bek9iICC3lNBJx7k9Kr1ufCPaeO5bD5 +KnPwEX5tK83Xs5fLnAY14iT9PypmCMEn+4AvyoA60dNL56xCUUntRNaD4un57Bg KHoKg69qRCW4Fmr00e3mf40bZaa6PNRZ8A966GgVUFacg0f6inufrVoP+tRFzZqZ dfiltjeR5NdkBSsuMIVL =55lQ -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] Warn about insecure ciphers also in init_key_type
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit 3ca9d94f8688b7851312f7edabae0ff8690bee63 Author: Arne Schwabe Date: Wed Feb 19 12:21:53 2020 +0100 Warn about insecure ciphers also in init_key_type Signed-off-by: Arne Schwabe Acked-by: Steffan Karger Message-Id: <20200219112153.13013-1-a...@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19476.html Signed-off-by: David Sommerseth - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTs1+AAoJEIbPlEyWcf3ybAkP+weT5r8liaQauL7MOXTepXSz 0GfDyrCYwnQ9ITZ609j2ad24lqd1rZfiHZXuKwg8eQXFXg+64v3/1V6PUBktCW2f ZkkSfRnyC8N2c3vk09qpt2Y14k8ZZzpBxd0bIM1DT/5RFcjDtM8waZObttcB9qqc 8rxB6JJh49VgE/5YTzcx/LiEmCeGMCRwQa1ag88XDgPDTsNJ+pReK7WpRUeD0i8G k72sTBi96cV1kNicuy1q/dIhlr9J9BfvVoD6nrt8jN9earbw+yFnxlwpW8+Km20s g0A/BgEE1IqBwwdUxOzaA6clfQSmcFmAsXac79KlZdsgDvSJnvaOAuFBlPqas5os 2cMSBG+VEsEGfJ21qpAdmuzB2vxfS4TXxIClwMIPM9FVqrAwOWbqgaLTr5hiV6kd /pp/2GMyHCi5/8YfXPxrpEwSsNkPbrHF6j+uRgO3O8LnvQEJaHGlgG/9kHaX52S+ RKUVA1jmCrGwcn9jWlv4KbNPaOQSttDLDtVCpjUj4DA8jKU5dpxIV5AuqIy7o+cm QRM+AZ3MlW0y0LW1/+9lj7YfhEXwmcmQudHj2j7Tg4pHvTpFVoP5Z9Ky0Gw+H7h7 8mrK4fXL1bC7ERYReqYj05fL+Gd6de7bJbP3vnOswd7xEnAhsiRoB3A3VPB5E55x zvpl6mZgRCcYZD63qeIe =xJub -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] Fix possible access of uninitialized pipe handles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit 32723d29b2775d63d3fe329d017e7a08e0cdcb72 Author: Selva Nair Date: Wed Feb 19 20:56:43 2020 -0500 Fix possible access of uninitialized pipe handles Signed-off-by: Selva Nair Acked-by: Lev Stipakov Message-Id: <1582163803-3342-1-git-send-email-selva.n...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19480.html Signed-off-by: David Sommerseth - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTsejAAoJEIbPlEyWcf3ysT0QALdZe2FV06fMaBp4oljUr2AZ H/bViP11W21UpcyiHDAGR2YsjOf+Uzrg7z5S/eEmAdIk6TdymsOlEwLkxOwog9qd ve5EQp2Zpwnnugz5YPdAsnXt5BY6FwfEA3roeU20s4O+dnovuHxmquDmZr8MosXD b2Zj+OTaQbKlggqtpc7J0uaVWirV3EPK9sE86VGHBp43di2DzA+OlJBawrzqOJj8 9XTC5VPgncFsfQ5IxwnlaW0JkFJxQAceTEstGbkzPaf17o4uot7eW7xmeiA7z8A5 MAxJj8gM0sTgQx20hn0il9tqn9k6UazRLyQ+KIZpK4yeRyZRNRXiR9VhjozmVu5T y36IwDhghoLnJGHwcpLoys0ZLEP43RLhZRZ2ez6/8A/06+NsFMWkUmJnlaPmGuOP iJqFoQBixnyWxWbnN5vuYGeem5x9CBF0WS7gk6wyP36yzmFAgbie0NgbC25sXE7L 0iJ5ZMzuKFcrik3NosNeqr6wl4yVeTXmRDxGoCaImBo1UD3GIo7z/j3+mnSl6HpC qaEpYrxrXxH6oV518QZLC5NWR4JtlEalXml46KnH8vaKETR2+1Qh/thCEfprkxC+ D3SsPsGfuMHjRr7wyuBczpdrOlUMRlkO4D2RfBdPPhtr4W5jlWS/1KughzXiFsSm ITg12xX4ms+SQ1Sf5XXf =IIso -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] re-implement argv_printf_*()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit 4ed7bf7f94a8cecbc2430d8025a2b8a46f94e429 Author: Heiko Hund Date: Thu Feb 6 14:21:00 2020 +0100 re-implement argv_printf_*() Signed-off-by: Heiko Hund Signed-off-by: David Sommerseth Acked-by: Arne Schwabe Message-Id: <20200206132103.15977-2-dav...@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19380.html - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTqgvAAoJEIbPlEyWcf3yydQQAKcm4yux1TlCBPXt7PUmM26a RYbEy2FxeGTwHGVidHgP79H1XH1W06Pu0i24KeE6FzRYpilBSW3DJ4zm5MJMByKM iiXYHItsyUCQdJaQJrYleBwSp9LQ6bYWRLQ6Lu5IMrcVwnnxReGFVI7fkDfNE+d2 u1jAyDGw5XWnsaT+Aycc5GmaDujB2nlcX4dlyJW9UUK6tFkelhVS2pXF47ABSzRl 7o4IPa7tFuVQIV0yTrqQW6LcQa3vSgLusWr5MQPJWbdccfpX0l4iySjTH1c1o7ii qNqDzGsnnf0rq9xO4McN4j/PTFZfKFBVr3nwtwCd1c5EJ1RtkwWEuI3llaipG7ZJ 7jc1o4PiQdawxCLWKlbWgQcscAcQbDJQYSfKOFZVYnDn2P8SvWfcZ8EkIS3nKjMs CV2zx5emb+5+u+TnSkeAPPgY4xMsKXGbfJHssbf1xu163Bw3Yf2fteUxmeWjwLMv N8iqQlVHHQolqvKg7ChFOK1ZqhTvFkmcSX1ZLPGs4ADGbrDZOvQXPrjqUGf0loBR m8xW/4QrG99LVxBxQ/20vfGWtVaQ7ohxVS9qm4/YKcmV+cBxGcCX+V1SGsJTvWCO KeG9ngTmUdPjuQ3v6QxreG2Ha3DuvpSkw5nHOoPFK+/Mlmi+g2u1GDvu1nTBRaEV k1FYYjJ/0kyfnKV3EUV5 =1hgh -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] Documented all the argv related code with minor refactoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit 3226c2edaf0ddd1b4541ce81ebce97a9ae9ecd2a Author: David Sommerseth Date: Thu Feb 6 14:21:03 2020 +0100 Documented all the argv related code with minor refactoring Signed-off-by: David Sommerseth Acked-by: Arne Schwabe Message-Id: <20200206132103.15977-5-dav...@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19377.html - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTqjQAAoJEIbPlEyWcf3y/uQP/0Qi832YfcHF7oYwGy2QNjII 0Sg42prQVlDPtaflH0VsR6Zcvy/1aOK2Bjl6JsepvAepNNGzreebEo3qgoOnfzVK hgV1ZxffUfoaS2g43xgjb5E3nGPtlQhDDV20djQG9CYZ9eyHIVW3fPDzHlssfV+A jLYM71hptQ8I3YFvk7A2rKSNKgJzT46ilDVo7c7AUbNOjLb7BLP0VWLpeTTgbz4m 1Ydh2Aur26TgmYF4Lf2KRAxQYCBcLwN9XsQU7BjALxnFZi9NOdTV2mOIXBewXc7E iorOEZcXsCSL+xc6Ek8jIs3bTJym0K3Rsxg9ymu3ybfUcaIGNAcu0FbMrvrYNB2F K281FfRdv4AKm8J4qnujeO4+kOGfxG2WJ4uovPASP2R3kLVgv/YA5XAAVMGbYW9x tmPVOtiHCYkwqXMmgrxEXbmvk6WksDnxGIAyqzFvIcSROmMtcL8qnsdsSvLJX8xG 4JJMmz25v/YYYR6HG3hp1rhtv7+P+dwSd47maqOyQe4DdBOEczqlg3/TBAmDI7vc N1z4/fNGPCskEOdhkUyGQAJ2G9/mxSnh1pm2lmDgKRAKox/lQ22IUprC19bBQtVA PHjhF8dJZrAVyM9fzBdgTrMp/FFp7EWDJMPj81E3Y8EODcobeW2kRshEKjyvQUbS zmvCpm4eaDfme/UGgwum =VckR -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] Add gc_arena to struct argv to save allocations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit e7500875efe03937fc222d737050789f97c30c03 Author: Heiko Hund Date: Thu Feb 6 14:21:02 2020 +0100 Add gc_arena to struct argv to save allocations Signed-off-by: Heiko Hund Signed-off-by: David Sommerseth Acked-by: Arne Schwabe Message-Id: <20200206132103.15977-4-dav...@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19376.html - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTqiqAAoJEIbPlEyWcf3y/W4P/RmiDlqxefz7bcvn6FFXuqhX V4z4S54+J/GyvTtrOZhVUsaQ0/J2i6R6qvKdTd87jUOYhrkwd5rfN3D10WCizYhH reGU5nTiMjhIKeCDfaI2gRN0XNXngL7bxFrv+1ND6wsJe1b4dBoqqU+YvSfEusI+ IPD/YWe1QlAW2oYzFAnZL8rx3FZwKGm2BMA0gC3bgEeTwSdh6R9K4PPxkfUiFe/e NgC5N5mAspH6JMARIfWxaqqRM3QysOXruKshvWs+L4N+Y4Rp96ZOm7U6QWK2FXPZ PI66l/GEzhY2PyQj3TpZrTM5+ibD8nOnAyMqceqA6j+mkhggpR0V3gJLRrO/KJM7 J/XTpFrUbnkGxoHWCUNsc495cQedm76cg+sLK73eF0FKIhpAsSvWh1W1pwVAmAtO jRL7g1Xtc+AdM5j/m02dK+jCxgGfIaqobptRGdMGsi2KwJjUxrQeag11+5zLg/x/ GME52Xzf7gHcLw0dZPYxflA+ZCtA/zh6Xfi0ab9J5oM3N+LmOzhUeJGX4WaCRgod cNWD+kYLXWNlyOWPTNm/HhSSgFS6w3KlZ+pezAdp8A40kOtTGLXUN7XRQVpsVUH4 ZZyYb05XiZnDjFmcj547WNQPCzSSyok+mt8nw/yZdFs6HAyqY7XrI8iWmb6zET1Y Ans8eFG2HBWsXcOhbzHX =iJcm -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH applied] argv: do fewer memory re-allocations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Your patch has been applied to the master branch commit 870e2405e27fb0c119ade6fc0032c81af4d89819 Author: Heiko Hund Date: Thu Feb 6 14:21:01 2020 +0100 argv: do fewer memory re-allocations Signed-off-by: Heiko Hund Signed-off-by: David Sommerseth Acked-by: Arne Schwabe Message-Id: <20200206132103.15977-3-dav...@openvpn.net> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19378.html - -- kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJeTqh3AAoJEIbPlEyWcf3y7JoP/j7hrKtTzmEpYVIbPqC5NDjr qwk9knNt5tQ1dcoae18qtYkyPXoanxgWnqgMwwyyFZfvU9LenQkFx/edioxRX0VV PtoniuM512sGKUoPXiKjs8Kpdhpg1swnOqPbgUMx1mhdD3KFpzhKq2U39pAn5d2G 7hzGJd4jP7dU8ilfqpYfNneIXRr65VRimOGTAgquQgkndcy3WUlrLAxpmUS+HYMk pvWTP6wRi6607ECTTcuRJTrc2317o3RiFcmVxodxSuGWSbASaqtt0hsbChwWG2pu QFc7Cjxc9Gd7EG2eKG2SItocOpcFJ8tg6tgGj8clnBjWhvLXHGO2TWiBMg3RLEEm Vq7+3MrCUYwtIUgfSEqnmUCfEEqz+7cwVXONdWnCxW+adN0Iafk1FevCyTIhGF+J 0ZdAVecy8g6eZJTgUC8OX6iIZxKu4JEI6VfgXZ1E0CK196YgIpeDC31xyxB3h/nR 4tmFitE/bh3W/D2QNPe+XJlZKOqbMaq7iluclJuqkE73TWWA9nlK5HRnuaUzYIZv nYjYyzWrNsDQ5JrLuW7TNFFuONJeUEmuJUaq0HVTOwYCAv+ELScbNCT2Sri3iXg4 a5BibPdVmQOJepLri+7IVdRObtkDbhrJzHj42p/N7Er57BBZLAM1De7jXtLI8ayd 6aO6VHgW5wsUN5ZUbcHn =KeLS -END PGP SIGNATURE- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] OpenVPN 3 Linux client - v8 beta released
On 10/02/2020 23:32, David Sommerseth wrote: > > Hi, > > The OpenVPN 3 Linux v8 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 Rawhide(via Fedora Copr: x86_64, ppc64le, aarch64) > * RHEL/CentOS 7 and 8 (via Fedora Copr: x86_64, ppc64le, aarch64) > * Debian 9 and 10 (amd64) > * Ubuntu 16.04, 18.04, 19.04 and 19.10 (amd64) > > But there is an annoying detail with this release. Cloudflare is doing > its best to ensure that the .deb package repositories are corrupt, invalid, > missing or not seeing the new files. I've tried to do the magic steps > required to clean up this, with no results. This issue should now be resolved. If you have issues with the openvpn3 Debian or Ubuntu packages, please get in touch so we can figure it out. -- 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] openssl: alternative names support for --verify-x509-name CN checks
On 12/02/2020 15:39, Arne Schwabe wrote:
>> +bool
>> +x509v3_is_host_in_alternative_names(mbedtls_x509_crt *cert, const char
>> *host, bool *has_alt_names)
>> +{
>> + msg(M_WARN, "Missing support for subject alternative names in
>> mbedtls.");
I'm not happy about this at all. This should be possible to achieve with
mbed TLS as well:
<https://tls.mbed.org/api/structmbedtls__x509__crt.html#a1f148e8fb52e03e2604e716386a07df4>
One starting point for this can probably found here:
<https://tls.mbed.org/api/group__x509__module.html#ga033567483649030f7f859db4f4cb7e14>
--
kind regards,
David Sommerseth
OpenVPN Inc
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] OpenVPN 3 Linux client - v8 beta released
Hi, The OpenVPN 3 Linux v8 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 Rawhide(via Fedora Copr: x86_64, ppc64le, aarch64) * RHEL/CentOS 7 and 8 (via Fedora Copr: x86_64, ppc64le, aarch64) * Debian 9 and 10 (amd64) * Ubuntu 16.04, 18.04, 19.04 and 19.10 (amd64) But there is an annoying detail with this release. Cloudflare is doing its best to ensure that the .deb package repositories are corrupt, invalid, missing or not seeing the new files. I've tried to do the magic steps required to clean up this, with no results. So for now, if you want to test it on those distros you need to build it yourself from source or use Fedora, RHEL or CentOS - where the repos works perfectly fine. In the mean time I will try to figure out how to fix this Cloudflux mess. 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: * Improvement: Brand new DNS resolver settings handling. This is expected to avoid several bugs found in the prior releases; from not cleaning up correctly to adding duplicated entries for pushed DNS settings. * Improvement: Refactored the code tied to setting up the direct route for the VPN server. * Improvement: openvpn3-admin log-service --list-subscriptions now adds the PID of the process the log subscription is tied to. * Bugfix: The openvpn3 Python module broke in v7_beta for Ubuntu 16.04 and other distributions shipping with Python 3.5 or older. This has now been fixed but it will be required to install the aenum Python module via pip3. This is not needed on distributions with Python 3.6 or newer. * Bugfix: The openvpn2 interface would not work if the --verb option was missing. * Bugfix: The D-Bus policy was incorrect for the net.openvpn.v3.netcfg service, related to the org.freedesktop.DBus.Ping method. * Bugfix: Corrected a typo in Python constants related to DNS_SERVER_ADDED * Bugfix: openvpn2 will now warn about ignoring --up and --down options, and will silently ignore --down-pre and --script-security. These are not relevant or supported in OpenVPN 3 Linux. Prior versions did not work. * Build: It now builds with GCC 10 * Build: It should be possible to build openvpn3-linux with no warnings on most platforms (gcc-4.8.5 requires -std=c++1y) * OpenVPN 3 Core: Upgraded to the latest development version, with lots of bugfixes and improvements. [0] <https://gitlab.com/openvpn/openvpn3-linux> <https://github.com/OpenVPN/openvpn3-linux> -- kind regards, David Sommerseth OpenVPN Inc Source tarballs * OpenVPN 3 Linux v8 beta <https://swupdate.openvpn.net/community/releases/openvpn3-linux-8_beta.tar.xz> <https://swupdate.openvpn.net/community/releases/openvpn3-linux-8_beta.tar.xz.asc> SHA256 Checksums --- 74d806d43ed803aece46748292783b17e33c85d6f116a9d0d6b26ebcdae2a557 openvpn3-linux-8_beta.tar.xz 2a39c897b3f0669ba47af63409b36545fbde32fc9cb5c9cd0146c65fd6d4a651 openvpn3-linux-8_beta.tar.xz.asc git references - git tag: v8_beta git commit: ee9ae86605b4985fac94e7c534a0012dc8958f67 Changes from v7 to v8 -- Arne Schwabe (14): contrib: Add cli-netcfg as a CMake build target netcfg: Move D-Bus logic returning fd in method call netcfg: Use C++ default copy constructor in NetCfgOptions Code style fixes ovpn3cli: Compile config command with USE_TUN_BUILDER netcfg: Declare ~NetCfgProxyException() as an override properly netcfg: Move device object creation into a separate method netcfg: Factor out notification signals in core-tunbuilder netcfg: Implement honouring remove_cmds in core tunbuilder contrib: Update CMake file to add missing files netcfg/client: Replace add_bypass_route with socket_protect netcfg/client: Cleanup tun devices and protected sockets on exit build: Update cmake files to include DNS related changes netcfg/client: Fix NetCfg::Cleanup() not called from openvpn-service-client David Sommerseth (48): netcfg: NetCfgChangeEvent could incorrectly parse GVariant data client: Allow non-session manager access to log_level and device_path client: Provide more information on non-sessionmgr rejections client: Fix incorrect return in the Ready D-Bus method docs: Improve documentation dbus: Add missing glib2 include file in dbus/exceptions.hpp sessionmgr: Don't panic when device_path or device_name is unavailable common: Fix lookup functions ret
[Openvpn-devel] [PATCH 3/4] Add gc_arena to struct argv to save allocations
From: Heiko Hund
With the private gc_arena we do not have to allocate the strings
found during parsing again, since we know the arena they are
allocated in is valid as long as the argv vector is.
Signed-off-by: Heiko Hund
Signed-off-by: David Sommerseth
---
src/openvpn/argv.c | 50
src/openvpn/argv.h | 1 +
tests/unit_tests/openvpn/test_argv.c | 23 +
3 files changed, 45 insertions(+), 29 deletions(-)
diff --git a/src/openvpn/argv.c b/src/openvpn/argv.c
index 4f7aa4e5..7d949d24 100644
--- a/src/openvpn/argv.c
+++ b/src/openvpn/argv.c
@@ -47,12 +47,11 @@ argv_extend(struct argv *a, const size_t newcap)
{
char **newargv;
size_t i;
-ALLOC_ARRAY_CLEAR(newargv, char *, newcap);
+ALLOC_ARRAY_CLEAR_GC(newargv, char *, newcap, >gc);
for (i = 0; i < a->argc; ++i)
{
newargv[i] = a->argv[i];
}
-free(a->argv);
a->argv = newargv;
a->capacity = newcap;
}
@@ -64,6 +63,7 @@ argv_init(struct argv *a)
a->capacity = 0;
a->argc = 0;
a->argv = NULL;
+a->gc = gc_new();
argv_extend(a, 8);
}
@@ -78,24 +78,21 @@ argv_new(void)
void
argv_free(struct argv *a)
{
-size_t i;
-for (i = 0; i < a->argc; ++i)
-{
-free(a->argv[i]);
-}
-free(a->argv);
+gc_free(>gc);
}
static void
argv_reset(struct argv *a)
{
-size_t i;
-for (i = 0; i < a->argc; ++i)
+if (a->argc)
{
-free(a->argv[i]);
-a->argv[i] = NULL;
+size_t i;
+for (i = 0; i < a->argc; ++i)
+{
+a->argv[i] = NULL;
+}
+a->argc = 0;
}
-a->argc = 0;
}
static void
@@ -107,7 +104,7 @@ argv_grow(struct argv *a, const size_t add)
}
static void
-argv_append(struct argv *a, char *str) /* str must have been malloced or be
NULL */
+argv_append(struct argv *a, char *str) /* str must have been gc_malloced or
be NULL */
{
argv_grow(a, 1);
a->argv[a->argc++] = str;
@@ -127,7 +124,7 @@ argv_clone(const struct argv *a, const size_t headroom)
{
for (size_t i = 0; i < a->argc; ++i)
{
-argv_append(, string_alloc(a->argv[i], NULL));
+argv_append(, string_alloc(a->argv[i], ));
}
}
return r;
@@ -138,7 +135,7 @@ argv_insert_head(const struct argv *a, const char *head)
{
struct argv r;
r = argv_clone(a, 1);
-r.argv[0] = string_alloc(head, NULL);
+r.argv[0] = string_alloc(head, );
return r;
}
@@ -222,7 +219,6 @@ argv_prep_format(const char *format, const char delim,
size_t *count, struct gc_
static bool
argv_printf_arglist(struct argv *a, const char *format, va_list arglist)
{
-struct gc_arena gc = gc_new();
const char delim = 0x1D; /* ASCII Group Separator (GS) */
bool res = false;
@@ -236,7 +232,7 @@ argv_printf_arglist(struct argv *a, const char *format,
va_list arglist)
*
*/
size_t argc = a->argc;
-char *f = argv_prep_format(format, delim, , );
+char *f = argv_prep_format(format, delim, , >gc);
if (f == NULL)
{
goto out;
@@ -256,8 +252,8 @@ argv_printf_arglist(struct argv *a, const char *format,
va_list arglist)
* Do the actual vsnprintf() operation, which expands the format
* string with the provided arguments.
*/
-size_t size = len + 1;
-char *buf = gc_malloc(size, false, );
+size_t size = adjust_power_of_2(len + 1);
+char *buf = gc_malloc(size, false, >gc);
len = vsnprintf(buf, size, f, arglist);
if (len < 0 || len >= size)
{
@@ -272,11 +268,11 @@ argv_printf_arglist(struct argv *a, const char *format,
va_list arglist)
while (end)
{
*end = '\0';
-argv_append(a, string_alloc(buf, NULL));
+argv_append(a, buf);
buf = end + 1;
end = strchr(buf, delim);
}
-argv_append(a, string_alloc(buf, NULL));
+argv_append(a, buf);
if (a->argc != argc)
{
@@ -287,7 +283,6 @@ argv_printf_arglist(struct argv *a, const char *format,
va_list arglist)
res = true;
out:
-gc_free();
return res;
}
@@ -321,21 +316,18 @@ argv_parse_cmd(struct argv *a, const char *s)
{
argv_reset(a);
-struct gc_arena gc = gc_new();
char *parms[MAX_PARMS + 1] = { 0 };
-int nparms = parse_line(s, parms, MAX_PARMS, "SCRIPT-ARGV", 0,
D_ARGV_PARSE_CMD, );
+int nparms = parse_line(s, parms, MAX_PARMS, "SCRIPT-ARGV", 0,
D_ARGV_PARSE_CMD, >gc);
if (nparms)
{
int i;
for (i = 0; i < nparms; ++i)
{
-argv_append(a, string_alloc(parms[i], NULL));
+argv_append(a, parms[i]);
}
}
else
{
-argv_append(a, string_alloc(s, NULL));
+
[Openvpn-devel] [PATCH 4/4] Documented all the argv related code with minor refactoring
Added doxygen comments for all the functions in argv.c.
There are some slight refactoring, renaming a few variables to make
their use case more obvious and ensure lines do not break our 80-chars
per line coding style limit.
Signed-off-by: David Sommerseth
---
src/openvpn/argv.c | 251 +
1 file changed, 211 insertions(+), 40 deletions(-)
diff --git a/src/openvpn/argv.c b/src/openvpn/argv.c
index 7d949d24..b799c974 100644
--- a/src/openvpn/argv.c
+++ b/src/openvpn/argv.c
@@ -40,6 +40,13 @@
#include "env_set.h"
#include "options.h"
+/**
+ * Resizes the list of arguments struct argv can carry. This resize
+ * operation will only increase the size, never decrease the size.
+ *
+ * @param *a Valid pointer to a struct argv to resize
+ * @param newcap size_t with the new size of the argument list.
+ */
static void
argv_extend(struct argv *a, const size_t newcap)
{
@@ -57,6 +64,12 @@ argv_extend(struct argv *a, const size_t newcap)
}
}
+/**
+ * Initialise an already allocated struct argv.
+ * It is expected that the input argument is a valid pointer.
+ *
+ * @param *a Pointer to a struct argv to initialise
+ */
static void
argv_init(struct argv *a)
{
@@ -67,6 +80,12 @@ argv_init(struct argv *a)
argv_extend(a, 8);
}
+/**
+ * Allocates a new struct argv and ensures it is initialised.
+ * Note that it does not return a pointer, but a struct argv directly.
+ *
+ * @returns Returns an initialised and empty struct argv.
+ */
struct argv
argv_new(void)
{
@@ -75,12 +94,24 @@ argv_new(void)
return ret;
}
+/**
+ * Frees all memory allocations allocated by the struct argv
+ * related functions.
+ *
+ * @param *a Valid pointer to a struct argv to release memory from
+ */
void
argv_free(struct argv *a)
{
gc_free(>gc);
}
+/**
+ * Resets the struct argv to an initial state. No memory buffers
+ * will be released by this call.
+ *
+ * @param *a Valid pointer to a struct argv to resize
+ */
static void
argv_reset(struct argv *a)
{
@@ -95,6 +126,19 @@ argv_reset(struct argv *a)
}
}
+/**
+ * Extends an existing struct argv to carry minimum 'add' number
+ * of new arguments. This builds on argv_extend(), which ensures the
+ * new size will only be higher than the current capacity.
+ *
+ * The new size is also calculated based on the result of adjust_power_of_2().
+ * This approach ensures that the list does grow bulks and only when the
+ * current limit is reached.
+ *
+ * @param *a Valid pointer to the struct argv to extend
+ * @param add size_t with the number of elements to add.
+ *
+ */
static void
argv_grow(struct argv *a, const size_t add)
{
@@ -103,15 +147,39 @@ argv_grow(struct argv *a, const size_t add)
argv_extend(a, adjust_power_of_2(newargc));
}
+/**
+ * Appends a string to to the list of arguments stored in a struct argv
+ * This will ensure the list size in struct argv has the needed capacity to
+ * store the value.
+ *
+ * @param *astruct argv where to append the new string value
+ * @param *str Pointer to string to append. The provided string *MUST* have
+ * been malloc()ed or NULL.
+ */
static void
-argv_append(struct argv *a, char *str) /* str must have been gc_malloced or
be NULL */
+argv_append(struct argv *a, char *str)
{
argv_grow(a, 1);
a->argv[a->argc++] = str;
}
+/**
+ * Clones a struct argv with all the contents to a new allocated struct argv.
+ * If 'headroom' is larger than 0, it will create a head-room in front of the
+ * values being copied from the source input.
+ *
+ *
+ * @param *source Valid pointer to the source struct argv to clone. It may
+ * be NULL.
+ * @param headroom Number of slots to leave empty in front of the slots
+ * copied from the source.
+ *
+ * @returns Returns a new struct argv containing a copy of the source
+ * struct argv, with the given headroom in front of the copy.
+ *
+ */
static struct argv
-argv_clone(const struct argv *a, const size_t headroom)
+argv_clone(const struct argv *source, const size_t headroom)
{
struct argv r;
argv_init();
@@ -120,16 +188,24 @@ argv_clone(const struct argv *a, const size_t headroom)
{
argv_append(, NULL);
}
-if (a)
+if (source)
{
-for (size_t i = 0; i < a->argc; ++i)
+for (size_t i = 0; i < source->argc; ++i)
{
-argv_append(, string_alloc(a->argv[i], ));
+argv_append(, string_alloc(source->argv[i], ));
}
}
return r;
}
+/**
+ * Inserts an argument string in front of all other argument slots.
+ *
+ * @param *a Valid pointer to the struct argv to insert the argument into
+ * @param *head Pointer to the char * string with the argument to insert
+ *
+ * @returns Returns a new struct argv with the inserted argument in front
+
[Openvpn-devel] [PATCH 2/4] argv: do fewer memory re-allocations
From: Heiko Hund
Prevent the re-allocations of memory when the internal argv grows
beyond 2 and 4 arguments by initially allocating argv to hold up to
7 (+ trailing NULL) pointers.
While at it rename argv_reset to argv_free to actually express
what's going on. Redo the argv_reset functionality so that it can
be used to actually reset the argv without re-allocation.
Signed-off-by: Heiko Hund
Signed-off-by: David Sommerseth
---
src/openvpn/argv.c | 81 ++--
src/openvpn/argv.h | 2 +-
src/openvpn/console_systemd.c| 2 +-
src/openvpn/init.c | 15 ++
src/openvpn/lladdr.c | 2 +-
src/openvpn/multi.c | 10 ++--
src/openvpn/networking_iproute2.c| 23
src/openvpn/options.c| 2 +-
src/openvpn/plugin.c | 2 +-
src/openvpn/route.c | 8 +--
src/openvpn/socket.c | 4 +-
src/openvpn/ssl_verify.c | 6 +--
src/openvpn/tls_crypt.c | 2 +-
src/openvpn/tun.c| 38 ++---
tests/unit_tests/openvpn/test_argv.c | 43 ++-
15 files changed, 124 insertions(+), 116 deletions(-)
diff --git a/src/openvpn/argv.c b/src/openvpn/argv.c
index fcf61ec5..4f7aa4e5 100644
--- a/src/openvpn/argv.c
+++ b/src/openvpn/argv.c
@@ -40,34 +40,6 @@
#include "env_set.h"
#include "options.h"
-static void
-argv_init(struct argv *a)
-{
-a->capacity = 0;
-a->argc = 0;
-a->argv = NULL;
-}
-
-struct argv
-argv_new(void)
-{
-struct argv ret;
-argv_init();
-return ret;
-}
-
-void
-argv_reset(struct argv *a)
-{
-size_t i;
-for (i = 0; i < a->argc; ++i)
-{
-free(a->argv[i]);
-}
-free(a->argv);
-argv_init(a);
-}
-
static void
argv_extend(struct argv *a, const size_t newcap)
{
@@ -86,6 +58,46 @@ argv_extend(struct argv *a, const size_t newcap)
}
}
+static void
+argv_init(struct argv *a)
+{
+a->capacity = 0;
+a->argc = 0;
+a->argv = NULL;
+argv_extend(a, 8);
+}
+
+struct argv
+argv_new(void)
+{
+struct argv ret;
+argv_init();
+return ret;
+}
+
+void
+argv_free(struct argv *a)
+{
+size_t i;
+for (i = 0; i < a->argc; ++i)
+{
+free(a->argv[i]);
+}
+free(a->argv);
+}
+
+static void
+argv_reset(struct argv *a)
+{
+size_t i;
+for (i = 0; i < a->argc; ++i)
+{
+free(a->argv[i]);
+a->argv[i] = NULL;
+}
+a->argc = 0;
+}
+
static void
argv_grow(struct argv *a, const size_t add)
{
@@ -133,14 +145,7 @@ argv_insert_head(const struct argv *a, const char *head)
const char *
argv_str(const struct argv *a, struct gc_arena *gc, const unsigned int flags)
{
-if (a->argv)
-{
-return print_argv((const char **)a->argv, gc, flags);
-}
-else
-{
-return "";
-}
+return print_argv((const char **)a->argv, gc, flags);
}
void
@@ -221,8 +226,6 @@ argv_printf_arglist(struct argv *a, const char *format,
va_list arglist)
const char delim = 0x1D; /* ASCII Group Separator (GS) */
bool res = false;
-argv_extend(a, 1); /* ensure trailing NULL */
-
/*
* Prepare a format string which will be used by vsnprintf() later on.
*
@@ -279,7 +282,6 @@ argv_printf_arglist(struct argv *a, const char *format,
va_list arglist)
{
/* Someone snuck in a GS (0x1D), fail gracefully */
argv_reset(a);
-argv_extend(a, 1); /* ensure trailing NULL */
goto out;
}
res = true;
@@ -318,7 +320,6 @@ void
argv_parse_cmd(struct argv *a, const char *s)
{
argv_reset(a);
-argv_extend(a, 1); /* ensure trailing NULL */
struct gc_arena gc = gc_new();
char *parms[MAX_PARMS + 1] = { 0 };
diff --git a/src/openvpn/argv.h b/src/openvpn/argv.h
index b9105a43..989cd297 100644
--- a/src/openvpn/argv.h
+++ b/src/openvpn/argv.h
@@ -40,7 +40,7 @@ struct argv {
struct argv argv_new(void);
-void argv_reset(struct argv *a);
+void argv_free(struct argv *a);
const char *argv_str(const struct argv *a, struct gc_arena *gc, const unsigned
int flags);
diff --git a/src/openvpn/console_systemd.c b/src/openvpn/console_systemd.c
index 8d9e825b..c7cf1ada 100644
--- a/src/openvpn/console_systemd.c
+++ b/src/openvpn/console_systemd.c
@@ -85,7 +85,7 @@ get_console_input_systemd(const char *prompt, const bool
echo, char *input, cons
}
close(std_out);
-argv_reset();
+argv_free();
return ret;
}
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 04207b61..db7d1216 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -164,7 +164,7 @@ run_up_down(const char *command,
msg(M_FATAL, "ERROR: up/down plugin call failed");
}
-argv_reset();
+argv_free();
}
if (command)
@@
[Openvpn-devel] [PATCH 0/4] struct argv overhaul - Feb 2020 edition
Hi, I've yet again rebased the last attempt of the struct argv overhaul patches [1] to the latest public git master [2]. This rebase just needed a few minor changes to account for changes with tls-crypt-v2 and sitnl patches now being included. I've also applied Arne's review comments [3]. To simplify the review, I've also pushed these changes to my gitlab account: https://gitlab.com/dazo/openvpn.git Look at the dev/struct-argv-overhaul-2020.02 [4] branch for the proper commits. This patch-set supersedes the "struct argv overhaul - Oct 2019 edition" patches [5] [1] <https://patchwork.openvpn.net/project/openvpn2/list/?series=386=%2A=both> [2] git master commit 5822e52c6b0f86f9e4de946f9fb1374c6fad95f1 [3] Message-ID: <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17957.html> [4] <https://gitlab.com/dazo/openvpn/-/tree/dev/struct-argv-overhaul-2020.02> [5] <https://patchwork.openvpn.net/project/openvpn2/list/?series=553=%2A=both> -- kind regards, David Sommerseth OpenVPN Inc ------- David Sommerseth (1): Documented all the argv related code with minor refactoring Heiko Hund (3): re-implement argv_printf_*() argv: do fewer memory re-allocations Add gc_arena to struct argv to save allocations src/openvpn/argv.c | 541 +-- src/openvpn/argv.h | 7 +- src/openvpn/console_systemd.c| 2 +- src/openvpn/init.c | 15 +- src/openvpn/lladdr.c | 2 +- src/openvpn/multi.c | 10 +- src/openvpn/networking_iproute2.c| 23 +- src/openvpn/options.c| 2 +- src/openvpn/plugin.c | 2 +- src/openvpn/route.c | 16 +- src/openvpn/socket.c | 4 +- src/openvpn/ssl_verify.c | 6 +- src/openvpn/tls_crypt.c | 2 +- src/openvpn/tun.c| 62 +-- tests/unit_tests/openvpn/test_argv.c | 118 +- 15 files changed, 518 insertions(+), 294 deletions(-) -- 2.17.1 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH 1/4] re-implement argv_printf_*()
From: Heiko Hund
The previous implementation had the problem that it was not fully
compatible with printf() and could only detect % format directives
following a space character (0x20).
It modifies the format string and inserts marks to separate groups
before passing it to the regular printf in libc. The marks are
later used to separate the output string into individual command
line arguments.
The choice of 0x1D as the argument delimiter is based on the
assumption that no "regular" string passed to argv_printf_*() will
ever have to contain that byte (and the fact that it actually is
the ASCII "group separator" control character, which fits its
purpose).
This commit has been updated by David Sommerseth based on Arne
Schwabe and his own feedback on the mailing list.
Signed-off-by: Heiko Hund
Signed-off-by: David Sommerseth
---
v2 - Improved comments, to make it even clearer what is going on
- Switched to C99 variable declaration, closer to where used
- Swapped out adjust_power_of_2() length calculation in
argv_printf_arglist() to len+1, which should be good enough.
---
src/openvpn/argv.c | 289 +--
src/openvpn/argv.h | 4 +-
src/openvpn/route.c | 8 +-
src/openvpn/tun.c| 24 +--
tests/unit_tests/openvpn/test_argv.c | 58 +-
5 files changed, 206 insertions(+), 177 deletions(-)
diff --git a/src/openvpn/argv.c b/src/openvpn/argv.c
index 9100a196..fcf61ec5 100644
--- a/src/openvpn/argv.c
+++ b/src/openvpn/argv.c
@@ -105,16 +105,15 @@ static struct argv
argv_clone(const struct argv *a, const size_t headroom)
{
struct argv r;
-size_t i;
-
argv_init();
-for (i = 0; i < headroom; ++i)
+
+for (size_t i = 0; i < headroom; ++i)
{
argv_append(, NULL);
}
if (a)
{
-for (i = 0; i < a->argc; ++i)
+for (size_t i = 0; i < a->argc; ++i)
{
argv_append(, string_alloc(a->argv[i], NULL));
}
@@ -131,64 +130,6 @@ argv_insert_head(const struct argv *a, const char *head)
return r;
}
-static char *
-argv_term(const char **f)
-{
-const char *p = *f;
-const char *term = NULL;
-size_t termlen = 0;
-
-if (*p == '\0')
-{
-return NULL;
-}
-
-while (true)
-{
-const int c = *p;
-if (c == '\0')
-{
-break;
-}
-if (term)
-{
-if (!isspace(c))
-{
-++termlen;
-}
-else
-{
-break;
-}
-}
-else
-{
-if (!isspace(c))
-{
-term = p;
-termlen = 1;
-}
-}
-++p;
-}
-*f = p;
-
-if (term)
-{
-char *ret;
-ASSERT(termlen > 0);
-ret = malloc(termlen + 1);
-check_malloc_return(ret);
-memcpy(ret, term, termlen);
-ret[termlen] = '\0';
-return ret;
-}
-else
-{
-return NULL;
-}
-}
-
const char *
argv_str(const struct argv *a, struct gc_arena *gc, const unsigned int flags)
{
@@ -218,132 +159,170 @@ argv_msg_prefix(const int msglev, const struct argv *a,
const char *prefix)
gc_free();
}
-static void
+
+/*
+ * argv_prep_format - prepare argv format string for further processing
+ *
+ * Individual argument must be separated by space. Ignores leading and
trailing spaces.
+ * Consecutive spaces count as one. Returns prepared format string, with space
replaced
+ * by delim and adds the number of arguments to the count parameter.
+ */
+static char *
+argv_prep_format(const char *format, const char delim, size_t *count, struct
gc_arena *gc)
+{
+if (format == NULL)
+{
+return NULL;
+}
+
+bool in_token = false;
+char *f = gc_malloc(strlen(format) + 1, true, gc);
+for (int i = 0, j = 0; i < strlen(format); i++)
+{
+if (format[i] == ' ')
+{
+in_token = false;
+continue;
+}
+
+if (!in_token)
+{
+(*count)++;
+
+/*
+ * We don't add any delimiter to the output string if
+ * the string is empty; the resulting format string
+ * will never start with a delimiter.
+ */
+if (j > 0) /* Has anything been written to the output string? */
+{
+f[j++] = delim;
+}
+}
+
+f[j++] = format[i];
+in_token = true;
+}
+
+return f;
+}
+
+/*
+ * argv_printf_arglist - create a struct argv from a format string
+ *
+ * Instead of parsing the format string ourselves place delimiters via
argv_prep_format()
+ * before we let libc's printf() do the parsing. Then split the resulting
string at the
+ * injected delimiters.
+ */
+static bool
argv_printf_arglist(s
[Openvpn-devel] OpenVPN 3 Linux client - v7 beta released
c71767c7f
openvpn3-linux-7_beta.tar.xz
765e1f8072fd32226d3f249669c02bf7a9ef2623129bd51f0a64cd63bfaac508
openvpn3-linux-7_beta.tar.xz.asc
git references -
git tag: v7_beta
git commit: 9478329ed017ba252b61b702d16a076b3adab678
Changes from v6 to v7 ----------
David Sommerseth (72):
docs: Updated README file
python: Give better information when starting background VPN sessions
build: Ensure we really use the system liblz4 library
docs: Update the pre-built section in README
ovpn3cli: Fix misbehaving log --session-path
core: Update to latest OpenVPN 3 Core Library
tests: Adding unit-test framework
tests: Port a few simple unit tests
tests: Ported NetCfgChangeEvent unit test
tests: Ported StatusEvent selftest to unit test
tests: Ported LogEvent selftest to unit test
common/cmdargparser: Slight minor improvements
common: Make cmdargparser.hpp a separate compilation unit
client: Tackle better if NetCfgProxy object is lost
netcfg: Add version property to main service object
netcfg: Make proxy-netcfg a separate compilation unit
dbus/proxy: Ensure access denials exceptions are handled explicitly
log: Don't throw access denied exception during init
ovpn3cli/admin: Add --service argument to openvpn3-admin version
tests: Make Jenkins run unit tests and collect results
client: Expose session name via D-Bus
sessionmgr: Expose session name
ovpn3cli/session: Display session name
python: Add OpenVPN 3 version to Python constants
python: Add openvpn3-as - Access Server support utility
python/openvpn3-as: Fix trailing slashes in URLs
python/openvpn3-as: Extend with challenge/response auth support
tests: Fix failing unittest with --enable-debug-core-events
proxy: Add input validation on D-Bus paths
client: Proxy warning from Core when compression has been enabled
proxy: Provide method extracting proxy object path
client: Provide methods retrieving netcfg device path and name
client: Expose netcfg device path and name via D-Bus
sessionmgr: Expose NetCfg device path and name for VPN sessions
cli/session: Expose device name used by session in sessions-list
session/proxy: Fix memory leaks in GetConnectionStats()
sessionmgr: Add two new main manager methods
sessionmgr/proxy: Add proxy methods for interface lookups
ovpn3cli: Add argument helper for retrieving interface names
ovpn3cli/session: Add --interface option to some session commands
tests: Fix lookup unit-test with SUSE docker containers
log/proxy: Fix -Wcatch-value compiler warnings
core-ext: Replace hacky option string export
client: Fix incorrect processing of port override
netcfg: Fix inconsistent glib2 behaviour on Ubuntu
sessionmgr: Handle missing backend gracefully for device_name
tests: Add test program quering version property in services
Fix incorrect spelling of 'retrieving'
dbus/proxy: Strip "remote" part of GDBus errors
core: Update to latest OpenVPN 3 Core library
python: Add support for --verify-x509-name
proxy: Don't throw access denials in GetServiceVersion()
man: Update openvpn2
proxy: Fix incorrect error in DBusProxy::GetServiceVersion()
netcfg: Reorganize netcfg-changeevent.{cpp,hpp}
policy: Split up the D-Bus policy per service
proxy: Move the GDBus error message strip after AccessDenied check
dbus: Ensure the D-Bus connection still valid
sessionmgr/proxy: Verify session objects availability before calling it
dbus/idlecheck: Consider last_operation when executing idle exit
tests: Add simple connect/disconnect stress test
dbus/signals: Add getter methods for interface and object path
dbus/proxy: Ensure we have a valid D-Bus connection before proxy calls
log: Add new admin method retrieving attached subscriptions
log/proxy: Add C++ method for accessing GetSubscriberLog
ovpn3cli/log-service: Add --list-subscriptions mode
ovpn3cli/session: Minor overhaul of sessions-list
sessionmgr: Grant access to the device_path in a session
python/SessionManager: Add Introspection() and GetObjectPath() methods
python: Add NetCfgChangeType constants
python/NetCfgManager: New openvpn3 module for the netcfg service
build: Clean up *~ files in a few forgotten places
-----
--
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 clang warning about missing braces
On 29/11/2019 12:37, Gert Doering wrote: > Hi, > > On Fri, Nov 29, 2019 at 12:25:13PM +0100, David Sommerseth wrote: >> On 29/11/2019 11:52, Gert Doering wrote: >>> On Fri, Nov 29, 2019 at 11:47:02AM +0100, David Sommerseth wrote: >>>> With GCC-4.3.8, I see this warning: >>> >>> This is about as old as you :-) - do we care about suppressing warnings >>> in old gcc versions that might suppress a *relevant* warning when >>> compiling with a current gcc version? >> >> This is the default compiler on stock RHEL-7 ... which goes EOL August 2024. > > We're not going to break it. > > I'm just not going to care very much about the warnings it might throw > (and I might object to any patches that are "just for the benefit of > suppressing warnings from gcc-4"). Fair enough. But that will actually restrain us from adding -Werror by default for some time forward, unless we want to make package maintenance a bit more tricky - needing to revert a -Werror chage or add -Wno-missing-braces. If we have status quo for the moment, I can live with that until RHEL-7 is EOL. -- 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
