Re: [Openvpn-devel] OpenVPN 2.4.8 released
Il 07/11/19 05:46, d tbsky ha scritto: > >> It would be interesting too what error message there is in setupapi.dev.log: >> > > I found a win7 vm with openvpn 2.4.6. try to upgrade to 2.4.8 and get > the same result. > setupapi.dev.log attached. there are some international characters but > I think they are not important. > I snapshot the vm before upgrade. so I can repeat the procedure if necessary. > > Regards, > tbskyd > Hi, The error is pretty clear: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. Is your computer perhaps behind in Windows updates? My hunch is that Digicert's latest root certificate is not availabe in the Windows certificate store and this causes the failure. Samuli 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 2/2] Add support for OpenSSL TLS 1.3 when using management-external-key
Hi, This started exactly a year ago, so let's get over with it :) By any chance is this an older version rebased to master? Saying this because most of the comments below are also in my previous remarks and were agreed to in your response... See https://patchwork.openvpn.net/patch/587/#1157 and response On Sat, Nov 9, 2019 at 7:31 AM Arne Schwabe wrote: > For TLS 1.0 to 1.2 and OpenSSL 1.1.0 calls us and requires a PKCS1 > padded response. As TLS 1.3 mandates RSA-PSS padding support and also > requires an TLS 1.3 implementation to support RSA-PSS for older TLS > version, OpenSSL will query us to sign an already RSA-PSS padded > string. > > This patch adds an 'unpadded' and 'pkcs1' parameter to the > management-external-key option to signal that the client is > able to support pkcs1 as well as unpadded signature requests. > > Since clients that implement the management-external-key interface > are usually rather tightly integrated solutions (OpenVPN Connect in the > past, OpenVPN for Android), it is reasonable to expect that > upgrading the OpenSSL library can be done together with > management interface changes. Therefore we provide no backwards > compatbility for mangement-interface clients not supporting > OpenSSL 1.1.1. > > Using the management api client version instead might seem like the > more logical way but since we only now that version very late, > it would extra logic and complexity to deal with this asynchronous > behaviour. Instead just give an error early if OpenSSL 1.1.1 and > management-external-key without nopadding is detected. > > The interface is prepared for signalling PCKS1 and RSA-PSS support > instead of signalling unpadded support. > > Patch v3: fix overlong lines and few other style patches. Note > two overlong lines concerning mbedtls are not fixed as they > are removed/shortend by the mbed tls patch to avoid conflicts > > Patch v4: Setting minimum TLS version proved to be not enough and > instead of implementing a whole compability layer we require > mangement-clients to implement the new feature when they want > to use OpenSSL 1.1.1 > > Add a padding=ALGORITHM argument to pk-sig to indicate the The code below adds ",ALG" to PK_SIGN, not padding=ALG to pk-sig. algorithm. Drop adding PKCS1 ourselves. > > Patch v5: Send the right version of the patch > > Patch v6: Send version rebased on master > > Signed-off-by: Arne Schwabe > --- > doc/management-notes.txt | 13 +- > doc/openvpn.8 | 7 -- > src/openvpn/manage.c | 20 --- > src/openvpn/manage.h | 23 +++-- > src/openvpn/options.c | 36 +- > src/openvpn/ssl_mbedtls.c | 7 -- > src/openvpn/ssl_openssl.c | 53 +++ > 7 files changed, 130 insertions(+), 29 deletions(-) > > diff --git a/doc/management-notes.txt b/doc/management-notes.txt > index 17645c1d..f685af28 100644 > --- a/doc/management-notes.txt > +++ b/doc/management-notes.txt > @@ -816,6 +816,7 @@ actual private key. When the SSL protocol needs to > perform a sign > operation, the data to be signed will be sent to the management interface > via a notification as follows: > > +>PK_SIGN:[BASE64_DATA],[ALG] (if client announces support for management > version > 2) > >PK_SIGN:[BASE64_DATA] (if client announces support for management > version > 1) > >RSA_SIGN:[BASE64_DATA] (only older clients will be prompted like this) > > @@ -823,7 +824,7 @@ The management interface client should then create an > appropriate signature of > the (decoded) BASE64_DATA using the private key and return the SSL > signature as > follows: > > -pk-sig (or rsa-sig) > +pk-sig (or rsa-sig) > [BASE64_SIG_LINE] > . > . > @@ -833,6 +834,12 @@ END > Base 64 encoded output of RSA_private_encrypt for RSA or ECDSA_sign() > for EC using OpenSSL or mbedtls_pk_sign() using mbed TLS will provide a > correct signature. > +The rsa-sig interfaces expects PKCS1 padded signatures for RSA keys > +(RSA_PKCS1_PADDING). EC signatures are always unpadded. > + > +The padding field is only present when pk-sig is used and > +currently the following values can be requested PCKS1 and NOPADDING for > RSA > +certificates and NOPADDING for EC certificates. > > This capability is intended to allow the use of arbitrary cryptographic service providers with OpenVPN via the management interface. > @@ -840,6 +847,10 @@ service providers with OpenVPN via the management > interface. > New and updated clients are expected to use the version command to > announce > a version > 1 and handle '>PK_SIGN' prompt and respond with 'pk-sig'. > > +The older rsa-sig and pk-sig interfaces hav no capability to indidicate > the > hav -> have indidicate -> indicate > +requested padding algorithm. When the 'nopadding' using version >= 2 is > required. > That would be version > 2 isn't it ? Anyway, the meaning of this sentence is totally unclear.. > +To
[Openvpn-devel] [PATCH] Update sample configs to use modern cipher, remove static key examples
Since these are examples, people might use them as a basis for their own configs. In the non-push/pull configs, we should specify a decent cipher. Further, I don't think we should recommend anyone to still use a static key configuration, so remove the static key config examples. Signed-off-by: Steffan Karger --- sample/sample-config-files/loopback-client| 1 + sample/sample-config-files/loopback-server| 1 + sample/sample-config-files/static-home.conf | 75 --- sample/sample-config-files/static-office.conf | 72 -- sample/sample-config-files/tls-home.conf | 12 +-- sample/sample-config-files/tls-office.conf| 3 + 6 files changed, 11 insertions(+), 153 deletions(-) delete mode 100644 sample/sample-config-files/static-home.conf delete mode 100644 sample/sample-config-files/static-office.conf diff --git a/sample/sample-config-files/loopback-client b/sample/sample-config-files/loopback-client index 7117307d..1734aa8b 100644 --- a/sample/sample-config-files/loopback-client +++ b/sample/sample-config-files/loopback-client @@ -22,5 +22,6 @@ ca sample-keys/ca.crt key sample-keys/client.key cert sample-keys/client.crt tls-auth sample-keys/ta.key 1 +cipher AES-256-GCM ping 1 inactive 120 1000 diff --git a/sample/sample-config-files/loopback-server b/sample/sample-config-files/loopback-server index 8e1f39cd..58daeb56 100644 --- a/sample/sample-config-files/loopback-server +++ b/sample/sample-config-files/loopback-server @@ -22,5 +22,6 @@ ca sample-keys/ca.crt key sample-keys/server.key cert sample-keys/server.crt tls-auth sample-keys/ta.key 0 +cipher AES-256-GCM ping 1 inactive 120 1000 diff --git a/sample/sample-config-files/static-home.conf b/sample/sample-config-files/static-home.conf deleted file mode 100644 index ed0c6726.. --- a/sample/sample-config-files/static-home.conf +++ /dev/null @@ -1,75 +0,0 @@ -# -# Sample OpenVPN configuration file for -# home using a pre-shared static key. -# -# '#' or ';' may be used to delimit comments. - -# Use a dynamic tun device. -# For Linux 2.2 or non-Linux OSes, -# you may want to use an explicit -# unit number such as "tun1". -# OpenVPN also supports virtual -# ethernet "tap" devices. -dev tun - -# Our OpenVPN peer is the office gateway. -remote 1.2.3.4 - -# 10.1.0.2 is our local VPN endpoint (home). -# 10.1.0.1 is our remote VPN endpoint (office). -ifconfig 10.1.0.2 10.1.0.1 - -# Our up script will establish routes -# once the VPN is alive. -up ./home.up - -# Our pre-shared static key -secret static.key - -# Cipher to use -cipher AES-256-CBC - -# OpenVPN 2.0 uses UDP port 1194 by default -# (official port assignment by iana.org 11/04). -# OpenVPN 1.x uses UDP port 5000 by default. -# Each OpenVPN tunnel must use -# a different port number. -# lport or rport can be used -# to denote different ports -# for local and remote. -; port 1194 - -# Downgrade UID and GID to -# "nobody" after initialization -# for extra security. -; user nobody -; group nobody - -# If you built OpenVPN with -# LZO compression, uncomment -# out the following line. -; comp-lzo - -# Send a UDP ping to remote once -# every 15 seconds to keep -# stateful firewall connection -# alive. Uncomment this -# out if you are using a stateful -# firewall. -; ping 15 - -# Uncomment this section for a more reliable detection when a system -# loses its connection. For example, dial-ups or laptops that -# travel to other locations. -; ping 15 -; ping-restart 45 -; ping-timer-rem -; persist-tun -; persist-key - -# Verbosity level. -# 0 -- quiet except for fatal errors. -# 1 -- mostly quiet, but display non-fatal network errors. -# 3 -- medium output, good for normal operation. -# 9 -- verbose, good for troubleshooting -verb 3 diff --git a/sample/sample-config-files/static-office.conf b/sample/sample-config-files/static-office.conf deleted file mode 100644 index 609ddd02.. --- a/sample/sample-config-files/static-office.conf +++ /dev/null @@ -1,72 +0,0 @@ -# -# Sample OpenVPN configuration file for -# office using a pre-shared static key. -# -# '#' or ';' may be used to delimit comments. - -# Use a dynamic tun device. -# For Linux 2.2 or non-Linux OSes, -# you may want to use an explicit -# unit number such as "tun1". -# OpenVPN also supports virtual -# ethernet "tap" devices. -dev tun - -# 10.1.0.1 is our local VPN endpoint (office). -# 10.1.0.2 is our remote VPN endpoint (home). -ifconfig 10.1.0.1 10.1.0.2 - -# Our up script will establish routes -# once the VPN is alive. -up ./office.up - -# Our pre-shared static key -secret static.key - -# Cipher to use -cipher AES-256-CBC - -# OpenVPN 2.0 uses UDP port 1194 by default -# (official port assignment by iana.org 11/04). -# OpenVPN 1.x uses UDP port 5000 by default. -# Each OpenVPN tunnel must use -# a different port number. -# lport or rport can be used -# to denote different ports -# for local and remote. -; port 1194 - -# Downgrade UID and GID to -# "nobody" after
[Openvpn-devel] [PATCH applied] Re: travis: bump MSVC to 2019
Your patch has been applied to the master branch. commit b8b3f1177e48678e3bbe955634fe412d5515fab0 Author: Lev Stipakov Date: Sat Nov 9 18:40:11 2019 +0200 travis: bump MSVC to 2019 Signed-off-by: Lev Stipakov Acked-by: Simon Rozman Message-Id: <1573317611-6462-1-git-send-email-lstipa...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19074.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Only announce IV_NCP=2 when we are willing to support these ciphers
Am 23.09.19 um 16:34 schrieb Gert Doering:
> Hi,
>
> On Mon, Sep 23, 2019 at 03:32:24PM +0200, Arne Schwabe wrote:
>> +if (!(tls_item_in_cipher_list("AES-128-GCM", options->ncp_ciphers)
>> + && tls_item_in_cipher_list("AES-256-GCM",
>> options->ncp_ciphers)))
>
> What about AES-192-GCM? What *exactly* does IV_NCP=2 guarantee?
>
Our manpage says only 128 and 256 are in the default ncp-cihper list, so
lets not guarantee 192.
Arne
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 applied] Re: socks: use the right function when printing struct openvpn_sockaddr
Acked-by: Gert Doering Thanks for fixing my oversight (amazing we both did not see the warning in the first patch...). socks.c compiles without warning now, and still prints the right address. Your patch has been applied to the master and release/2.4 branch (bugfix). commit 6c39b4dc4766594c6517043af59aeea53ea009d0 (master) commit 0ba4f91667b8931684e704d1836d71c893e3b9f6 (resolve/2.4) Author: Antonio Quartulli Date: Sat Nov 9 17:37:14 2019 +0100 socks: use the right function when printing struct openvpn_sockaddr Signed-off-by: Antonio Quartulli Acked-by: Gert Doering Message-Id: <20191109163714.25506-...@unstable.cc> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19073.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] travis: bump MSVC to 2019
Acked-by: Simon Rozman Best regards, Simon smime.p7s Description: S/MIME cryptographic signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] Make compression asymmetric by default and add warnings
Hi,
Feature-ack, and overall looks good. But some nits to tackle.
On 24-10-2018 12:06, Arne Schwabe wrote:
> This commit introduces the allow-compression option that allow
> changing the new default to the previous default or to a stricter
> version.
>
> Warning are not generated in the post option check
> (options_postprocess_mutate) since these warnings should also be shown
> on pushed options.
>
> Patch V2: fix spelling and grammer (thanks tincantech), also fix
>uncompressiable to incompressible in three other instances in the
>source code
>
> Patch V3: fix overlong lines. Do not allow compression to be pushed
> ---
> doc/openvpn.8 | 44 ++
> src/openvpn/comp-lz4.c | 3 +-
> src/openvpn/comp.c | 2 +-
> src/openvpn/comp.h | 16 +--
> src/openvpn/lzo.c | 2 +-
> src/openvpn/mtu.h | 2 +-
> src/openvpn/options.c | 101 -
> 7 files changed, 143 insertions(+), 27 deletions(-)
>
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index d40dcf43..ac923f51 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -2545,26 +2545,54 @@ Enable a compression algorithm.
>
> The
> .B algorithm
> -parameter may be "lzo", "lz4", or empty. LZO and LZ4
> -are different compression algorithms, with LZ4 generally
> +parameter may be "lzo", "lz4", "lz4\-v2", "stub", "stub\-v2" 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 "lzo"
> (which is identical to the older option "\-\-comp\-lzo yes").
>
> +The "lz4\-v2" and "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
> .B 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.
> +parameter is "stub", "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, "stub" and "stub\-v2" will disable
> +announcing lzo and lz4 compression support via "IV_" variables to the server.
> +
>
> .B 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 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.
> +e.g. the CRIME and BREACH attacks on TLS and VORACLE on VPNs 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.
> +
> +.\"*
> +.TP
> +.B \-\-allow\-compression [mode]
> +As described in
> +\.B \-\-compress
> +option, compression is potentially dangerous option. This option allows
> +controlling the behaviour of OpenVPN when compression is used and allowed.
> +.B mode
> +may be "yes", "no", or "asym" (default).
> +
> +With allow\-compression set to "no", OpenVPN will refuse any non stub
> +compression. With "yes" OpenVPN will send and receive compressed packets.
> +With "asym", the 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.
> +
> +The default of asym has been chosen to maximise compatibility with existing
> +configuration while at the same time phasing out compression in existing
> +deployment by disabling compression on the uplink, effectively completely
> disabling
> +compression if both client and server are upgraded.
>
> .\"*
> .TP
> diff --git a/src/openvpn/comp-lz4.c b/src/openvpn/comp-lz4.c
> index f52fdbfb..fa23e5a5 100644
> --- a/src/openvpn/comp-lz4.c
> +++ b/src/openvpn/comp-lz4.c
> @@ -70,8 +70,9 @@ do_lz4_compress(struct buffer *buf,
> {
> /*
> * In order to attempt compression, length must be at least
> COMPRESS_THRESHOLD.
> + * and asymmetric compression must be disabled
> */
> -if (buf->len >= COMPRESS_THRESHOLD)
> +if (buf->len >= COMPRESS_THRESHOLD && (compctx->flags & COMP_F_NO_ASYM))
> {
> const size_t ps = PAYLOAD_SIZE(frame);
> int zlen_max = ps +
Re: [Openvpn-devel] [PATCH] socks: use the right function when printing struct openvpn_sockaddr
Am 09.11.19 um 17:37 schrieb Antonio Quartulli: > 57623b4e introduced a print_sockaddr() call in socks.c to print an > openvpn_sockaddr object. > > However, this is not correct because print_sockaddr() expects a sockaddr > object as argument instead of openvpn_sockaddr. > > This error did not lead to any issue because the two objects are very > similar in regards to the data accessed by print_sockaddr(). > > Fix this by replacing print_sockaddr() with print_openvpn_sockaddr(). > Not compile tested but looks like the right fix to me. Acked-By: Arne Schwabe Arne 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] travis: bump MSVC to 2019
From: Lev Stipakov
Since we changed MSVC version in project files to 2019,
we have to do the same in travis script.
Signed-off-by: Lev Stipakov
---
.travis/build-check.sh | 2 +-
.travis/build-deps.sh | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/.travis/build-check.sh b/.travis/build-check.sh
index d2d2e8a..039a7dc 100755
--- a/.travis/build-check.sh
+++ b/.travis/build-check.sh
@@ -2,7 +2,7 @@
set -eux
if [ "${TRAVIS_OS_NAME}" = "windows" ]; then
- PATH="/c/Program Files (x86)/Microsoft Visual
Studio/2017/BuildTools/MSBuild/15.0/Bin/":$PATH
+ PATH="/c/Program Files (x86)/Microsoft Visual
Studio/2019/BuildTools/MSBuild/Current/Bin/":$PATH
MSBuild.exe openvpn.sln //p:Platform=x64 && exit 0
fi
diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
index 724ff30..4c5cb05 100755
--- a/.travis/build-deps.sh
+++ b/.travis/build-deps.sh
@@ -3,6 +3,8 @@ set -eux
if [ "${TRAVIS_OS_NAME}" = "windows" ]; then
choco install strawberryperl nasm
+choco install visualstudio2019buildtools --package-parameters
"--includeRecommended --includeOptional"
+choco install visualstudio2019-workload-vctools
cd ..
git clone https://github.com/openvpn/openvpn-build.git
cd openvpn-build
--
2.7.4
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] socks: use the right function when printing struct openvpn_sockaddr
57623b4e introduced a print_sockaddr() call in socks.c to print an openvpn_sockaddr object. However, this is not correct because print_sockaddr() expects a sockaddr object as argument instead of openvpn_sockaddr. This error did not lead to any issue because the two objects are very similar in regards to the data accessed by print_sockaddr(). Fix this by replacing print_sockaddr() with print_openvpn_sockaddr(). Signed-off-by: Antonio Quartulli --- src/openvpn/socks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/openvpn/socks.c b/src/openvpn/socks.c index ad3a70b2..57f0cee2 100644 --- a/src/openvpn/socks.c +++ b/src/openvpn/socks.c @@ -416,7 +416,7 @@ recv_socks_reply(socket_descriptor_t sd, memcpy(>addr.in4.sin_port, buf + 8, sizeof(addr->addr.in4.sin_port)); struct gc_arena gc = gc_new(); msg(M_INFO, "SOCKS proxy wants us to send UDP to %s", -print_sockaddr(addr, )); +print_openvpn_sockaddr(addr, )); gc_free(); } -- 2.24.0 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v6 1/2] Make tls_version_max return the actual maximum version
Hi,
On 09-11-2019 13:03, Arne Schwabe wrote:
> Before OpenSSL 1.1.1 there could be no mismatch between
> compiled and actual OpenSSL version. With OpenSSL 1.1.1 we need
> runtime detection to detect the actual best TLS version supported.
>
> Allowing this runtime detection also allows removing some of the
> TLS 1.3/OpenSSL 1.1.1 #ifdefs
>
> Without this patch tls-min-version 1.3 or-highest will actually
> downgrade to TLS 1.3 in the "compiled with 1.1.0 and linked against
> 1.1.1" scenario.
>
> Signed-off-by: Arne Schwabe
> ---
> src/openvpn/ssl.c | 11 +--
> src/openvpn/ssl_openssl.c | 31 ---
> 2 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 4455ebb8..e708fc93 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -4194,12 +4194,11 @@ show_available_tls_ciphers(const char *cipher_list,
> {
> printf("Available TLS Ciphers, listed in order of preference:\n");
>
> -#if (ENABLE_CRYPTO_OPENSSL && OPENSSL_VERSION_NUMBER >= 0x1010100fL)
> -printf("\nFor TLS 1.3 and newer (--tls-ciphersuites):\n\n");
> -show_available_tls_ciphers_list(cipher_list_tls13, tls_cert_profile,
> true);
> -#else
> -(void) cipher_list_tls13; /* Avoid unused warning */
> -#endif
> +if (tls_version_max() >= TLS_VER_1_3)
> +{
> +printf("\nFor TLS 1.3 and newer (--tls-ciphersuites):\n\n");
> +show_available_tls_ciphers_list(cipher_list_tls13, tls_cert_profile,
> true);
> +}
>
> printf("\nFor TLS 1.2 and older (--tls-cipher):\n\n");
> show_available_tls_ciphers_list(cipher_list, tls_cert_profile, false);
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 07916c3c..e07d6e74 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -215,7 +215,23 @@ int
> tls_version_max(void)
> {
> #if defined(TLS1_3_VERSION)
> +/* If this is defined we can safely assume TLS 1.3 support */
> return TLS_VER_1_3;
This clause is no longer needed, right?
> +#elif OPENSSL_VERSION_NUMBER >= 0x1010L
> +/*
> + * The library we are *linked* against is OpenSSL 1.1.1
s/is/might be/ ?
> + * and therefore supports TLS 1.3. This needs to be checked at runtime
> + * since we can be compiled against 1.1.0 and then the library can be
> + * upgraded to 1.1.1
> + */
> +if (OpenSSL_version_num() >= 0x1010100fL)
> +{
> +return TLS_VER_1_3;
> +}
> +else
> +{
> +return TLS_VER_1_2;
> +}
> #elif defined(TLS1_2_VERSION) || defined(SSL_OP_NO_TLSv1_2)
> return TLS_VER_1_2;
> #elif defined(TLS1_1_VERSION) || defined(SSL_OP_NO_TLSv1_1)
> @@ -241,12 +257,20 @@ openssl_tls_version(int ver)
> {
> return TLS1_2_VERSION;
> }
> -#if defined(TLS1_3_VERSION)
> else if (ver == TLS_VER_1_3)
> {
> +/*
> + * Supporting the library upgraded to TLS1.3 without recompile
> + * is enough to support here with a simple constant that the same
> + * as in the TLS 1.3, so spec it is very unlikely that OpenSSL
> + * will change this constant
> + */
> +#ifndef TLS1_3_VERSION
> +return 0x0304;
> +#else
Why not do this outside the function as
#ifndef TLS1_3_VERSION
#define TLS1_3_VERSION 0x0304
#endif
> return TLS1_3_VERSION;
> -}
> #endif
> +}
> return 0;
> }
>
> @@ -2015,7 +2039,8 @@ show_available_tls_ciphers_list(const char *cipher_list,
> #if defined(TLS1_3_VERSION)
> if (tls13)
> {
> -SSL_CTX_set_min_proto_version(tls_ctx.ctx, TLS1_3_VERSION);
> +SSL_CTX_set_min_proto_version(tls_ctx.ctx,
> + openssl_tls_version(TLS_VER_1_3));
> tls_ctx_restrict_ciphers_tls13(_ctx, cipher_list);
> }
> else
>
Otherwise looks good.
-Steffan
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: wintun: implement opening wintun device
Your patch has been applied to the master branch. Since this introduces a new library requirement, I gave it a test run on my Ubuntu 16 / MinGW linux build system. "Builds fine". Have not run the result. I have not done anything resembling proper code review. Just basic "this is only changing _WIN32 code, and doesn't seem to do bad stuff with pointers". What I do not really like is the inflation of the code with if (!tt->wintun) statements now. I think this should be refactored out into an "open_tun_wintun()" and an "open_tun_tap_windows()" function, where all the bits that are now inside an "if (!tt->wintun)" get their own function with less if() and less nesting. commit e64b4a9e68bde3cb7d878d277878fb2805040e3e Author: Lev Stipakov Date: Thu Nov 7 19:45:25 2019 +0200 wintun: implement opening wintun device Signed-off-by: Lev Stipakov Acked-by: Simon Rozman Message-Id: <1573148729-27339-4-git-send-email-lstipa...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19029.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v2 4/7] wintun: ring buffers based I/O
Hi,
Some first-round review comments. I still need to fully grasp the event
mechanism intricacies for a real in-depth review.
As a general remark: could you try to stick to the 80 char line length
limit?
On 07-11-2019 18:45, Lev Stipakov wrote:
> From: Lev Stipakov
>
> Implemented according to Wintun documentation
> and reference client code.
>
> Wintun uses ring buffers to communicate between
> kernel driver and user process. Client allocates
> send and receive ring buffers, creates events
> and passes it to kernel driver under LocalSystem
> privileges.
>
> When data is available for read, wintun modifies
> "tail" pointer of send ring and signals via event.
> User process reads data from "head" to "tail" and
> updates "head" pointer.
>
> When user process is ready to write, it writes
> to receive ring, updates "tail" pointer and signals
> to kernel via event.
>
> In openvpn code we add send ring's event to event loop.
> Before performing io wait, we compare "head" and "tail"
> pointers of send ring and if they're different, we skip
> io wait and perform read.
>
> This also adds ring buffers support to tcp and udp
> server code.
>
> Signed-off-by: Lev Stipakov
> ---
> src/openvpn/forward.c | 42 +++---
> src/openvpn/forward.h | 47 +++-
> src/openvpn/mtcp.c| 28 +++-
> src/openvpn/mudp.c| 14 ++
> src/openvpn/options.c | 4 +-
> src/openvpn/syshead.h | 1 +
> src/openvpn/tun.c | 45 +++
> src/openvpn/tun.h | 121
> +-
> src/openvpn/win32.c | 120 +
> src/openvpn/win32.h | 47
> 10 files changed, 458 insertions(+), 11 deletions(-)
>
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
> index 8451706..0be8b6d 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -1256,12 +1256,30 @@ read_incoming_tun(struct context *c)
> perf_push(PERF_READ_IN_TUN);
>
> c->c2.buf = c->c2.buffers->read_tun_buf;
> +
> #ifdef _WIN32
> -read_tun_buffered(c->c1.tuntap, >c2.buf);
> +if (c->c1.tuntap->wintun)
> +{
> +read_wintun(c->c1.tuntap, >c2.buf);
> +if (c->c2.buf.len == -1)
> +{
> +register_signal(c, SIGHUP, "tun-abort");
> +c->persist.restart_sleep_seconds = 1;
> +msg(M_INFO, "Wintun read error, restarting");
> +perf_pop();
> +return;
> +}
> +}
> +else
> +{
> +read_tun_buffered(c->c1.tuntap, >c2.buf);
> #else
> -ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
> -ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
> -c->c2.buf.len = read_tun(c->c1.tuntap, BPTR(>c2.buf),
> MAX_RW_SIZE_TUN(>c2.frame));
> +ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
> +ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
> +c->c2.buf.len = read_tun(c->c1.tuntap, BPTR(>c2.buf),
> MAX_RW_SIZE_TUN(>c2.frame));
> +#endif
> +#ifdef _WIN32
> +}
> #endif
As Simon mentioned too, this code is getting more and more hard to read.
Can we maybe do this in some cleaner way? Maybe add some helper function(s)?
>
> #ifdef PACKET_TRUNCATION_CHECK
> @@ -2103,7 +2121,21 @@ io_wait_dowork(struct context *c, const unsigned int
> flags)
> * Configure event wait based on socket, tuntap flags.
> */
> socket_set(c->c2.link_socket, c->c2.event_set, socket, (void
> *)_shift, NULL);
> -tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift, NULL);
> +
> +#ifdef _WIN32
> +if (c->c1.tuntap && c->c1.tuntap->wintun)
> +{
> +/* add ring buffer event */
> +struct rw_handle rw = {.read = c->c1.tuntap->send_tail_moved };
> +event_ctl(c->c2.event_set, , EVENT_READ, (void *)_shift);
> +}
> +else
> +{
> +#endif
> +tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift,
> NULL);
> +#ifdef _WIN32
> +}
> +#endif
As above :)
>
> #ifdef ENABLE_MANAGEMENT
> if (management)
> diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
> index 48202c0..6096fa8 100644
> --- a/src/openvpn/forward.h
> +++ b/src/openvpn/forward.h
> @@ -375,6 +375,19 @@ p2p_iow_flags(const struct context *c)
> {
> flags |= IOW_TO_TUN;
> }
> +#ifdef _WIN32
> +{
> +struct tuntap *tt = c->c1.tuntap;
> +if (tt && tt->wintun)
> +{
> +if (tt->send_ring->head == tt->send_ring->tail)
> +{
> +/* nothing to read from tun -> remove tun read flag set by
> IOW_READ */
> +flags &= ~IOW_READ_TUN;
> +}
> +}
> +}
> +#endif
Looks like this should be a helper function (with a good name that helps
understand what this does).
> return flags;
> }
>
> @@ -403,8 +416,38 @@ io_wait(struct context *c, const unsigned int flags)
> }
> else
> {
>
Re: [Openvpn-devel] [PATCH v2 7/7] wintun: clear adapter settings on tun close
Hi,
> -Original Message-
> From: Lev Stipakov [mailto:lstipa...@gmail.com]
> Sent: Thursday, November 7, 2019 6:45 PM
> To: openvpn-devel@lists.sourceforge.net
> Cc: Lev Stipakov
> Subject: [Openvpn-devel] [PATCH v2 7/7] wintun: clear adapter settings on
tun
> close
>
> }
> +else
> +if (tt->wintun)
> +{
> +netsh_delete_address_dns(tt, false, );
> +}
> #endif
if (tt->wintun && tt->options.msg_channel)
{
...
}
else
if (tt->ipapi_context_defined)
{
...
}
else
if (tt->wintun)
{
...
}
This construct got a bit convoluted.
Otherwise, LGTM.
Best regards,
Simon
smime.p7s
Description: S/MIME cryptographic signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v2 3/5] Implement sending response to challenge via CR_RESPONSE
When a client announces its support to support text based
challenge/response via IV_SOO=cr_text,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 | 8
src/openvpn/init.c | 39 +++
src/openvpn/manage.c | 39 ++-
src/openvpn/manage.h | 1 +
4 files changed, 86 insertions(+), 1 deletion(-)
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=
+
+
COMMAND -- pk-sig (OpenVPN 2.5 or higher, management version > 1)
COMMAND -- rsa-sig (OpenVPN 2.3 or higher, management version <= 1)
-
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 0bdb0a9c..77c1c23b 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -288,6 +288,44 @@ ce_management_query_proxy(struct context *c)
return ret;
}
+/**
+ * This method sends a custom control channel message
+ *
+ * This will write the control message
+ *
+ * command parm1,parm2,..
+ * .
+ * to the control channel.
+ *
+ * @param arg The context struct
+ * @param command The command being sent
+ * @param parametersthe parameters to the command
+ * @return if sending was successful
+ */
+static bool
+management_callback_send_cc_mesage(void *arg,
+ const char *command,
+ const char *parameters)
+{
+struct context *c = (struct context *) arg;
+size_t len = strlen(command) + 1 + sizeof(parameters) + 1;
+if (len > PUSH_BUNDLE_SIZE)
+{
+return false;
+}
+
+struct gc_arena gc = gc_new();
+struct buffer buf = alloc_buf_gc(len, );
+ASSERT(buf_printf(, "%s", command));
+if (parameters)
+{
+ASSERT(buf_printf(, ",%s", parameters));
+}
+bool status = send_control_channel_string(c, BSTR(), D_PUSH);
+
+gc_free();
+return status;
+}
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;
#ifdef TARGET_ANDROID
cb.network_change = management_callback_network_change;
#endif
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 1d97c2b6..8dada6f2 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -75,6 +75,7 @@ man_help(void)
msg(M_CLIENT, "auth-retry t : Auth failure retry mode
(none,interact,nointeract).");
msg(M_CLIENT, "bytecount n: Show bytes in/out, update every n
secs (0=off).");
msg(M_CLIENT, "echo [on|off] [N|all] : Like log, but only show messages
in echo buffer.");
+msg(M_CLIENT, "cr-response response : Send a challenge response answer
via CR_RESPONSE to server");
msg(M_CLIENT, "exit|quit : Close management session.");
msg(M_CLIENT, "forget-passwords : Forget passwords entered so far.");
msg(M_CLIENT, "help : Print this message.");
@@ -779,6 +780,27 @@ man_net(struct management *man)
}
}
+static void
+man_send_cc_message(struct management *man, const char *message, const char
*parameters)
+{
+if (man->persist.callback.send_cc_message)
+{
+const bool status = (*man->persist.callback.send_cc_message)
+(man->persist.callback.arg, message, parameters);
+if (status)
+{
+msg(M_CLIENT, "SUCCESS: command succeeded");
+}
+else
+{
+msg(M_CLIENT, "ERROR: command failed");
+}
+}
+else
+{
+msg(M_CLIENT, "ERROR: This command is not supported by the current
daemon mode");
+}
+}
#ifdef ENABLE_PKCS11
static void
@@ -1144,7 +1166,15 @@ man_load_stats(struct management *man)
}
#define MN_AT_LEAST (1<<0)
-
+/**
+ * Checks if the correct number of arguments to a management command are
present
+ * and otherwise prints an error and returns false.
+ *
+ * @param p pointer to the parameter array
+ * @param n number of arguments required
+ * @param flags if
[Openvpn-devel] [PATCH v2 5/5] Implement forwarding client CR_RESPONSE messages to management
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 | 26 +-
src/openvpn/forward.c| 4
src/openvpn/manage.c | 28 +++-
src/openvpn/manage.h | 4
src/openvpn/push.c | 21 +
src/openvpn/push.h | 2 ++
6 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index 4b405a9b..6d29b0d6 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -971,7 +971,7 @@ The ">CLIENT:" notification is enabled by the
--management-client-auth
OpenVPN configuration directive that gives the management interface client
the responsibility to authenticate OpenVPN clients after their client
certificate has been verified. CLIENT notifications may be multi-line, and
-the sequentiality of a given CLIENT notification, its associated environmental
+the sequentially of a given CLIENT notification, its associated environmental
variables, and the terminating ">CLIENT:ENV,END" line are guaranteed to be
atomic.
@@ -1013,6 +1013,30 @@ CLIENT notification types:
>CLIENT:ADDRESS,{CID},{ADDR},{PRI}
+(5) Single Sign On Based Challenge/Response
+
+ >CLIENT:CR_RESPONSE,{CID},{KID},{response_base64}
+ >CLIENT:ENV,name1=val1
+ >CLIENT:ENV,name2=val2
+ >CLIENT:ENV,...
+ >CLIENT:ENV,END
+
+ CR_RESPONSE notification. The >CR_RESPONSE fulfils the same purpose as the
+ CRV1 response in the traditional challenge/response. See that section below
for more
+ details. Since this still uses the same cid as the original response, we do
+ not use the username and opaque session data in this response.
+
+ It is important to note that OpenVPN2 merely passes the authentication
information and
+ does not do any further checks. (E.g. if a CR was issued before or if
multiple CR responses
+ were sent from the client).
+
+ This interface should be be sufficient for almost all challenge/response
system that
+ can be implemented with a single round and base64 encoding the response.
Mechanisms that
+ need multiple rounds or more complex answers should implement a different
response type
+ than CR_RESPONSE.
+
+
+
Variables:
CID -- Client ID, numerical ID for each connecting client, sequence =
0,1,2,...
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 0f735384..48c316c9 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -403,6 +403,10 @@ check_incoming_control_channel_dowork(struct context *c)
{
server_pushed_info(c, , 4);
}
+else if (buf_string_match_head_str(, "CR_RESPONSE"))
+{
+receive_cr_response(c, );
+}
else
{
msg(D_PUSH_ERRORS, "WARNING: Received unknown control message:
%s", BSTR());
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index c055f2ce..b3a4d5c8 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -2908,7 +2908,7 @@ management_notify_generic(struct management *man, const
char *str)
#ifdef MANAGEMENT_DEF_AUTH
static void
-man_output_peer_info_env(struct management *man, struct man_def_auth_context
*mdac)
+man_output_peer_info_env(struct management *man, const struct
man_def_auth_context *mdac)
{
char line[256];
if (man->persist.callback.get_peer_info)
@@ -2958,6 +2958,32 @@ management_notify_client_needing_auth(struct management
*management,
}
}
+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)
+{
+struct gc_arena gc;
+if (management)
+{
+gc = gc_new();
+
+struct buffer out = alloc_buf_gc(256, );
+msg(M_CLIENT, ">CLIENT:CR_RESPONSE,%lu,%u,%s",
+mdac->cid, mda_key_id, response);
+man_output_extra_env(management, "CLIENT");
+if (management->connection.env_filter_level>0)
+{
+man_output_peer_info_env(management, mdac);
+}
+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
[Openvpn-devel] [PATCH v2 1/5] Implement parsing and sending INFO and INFO_PRE control messages
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
+msg(D_PUSH, "Info command was pushed by server ('%s')", m);
+}
+
+
#if P2MP_SERVER
/**
* Add an option to the given push list by providing a format string.
diff --git a/src/openvpn/push.h b/src/openvpn/push.h
index 070782dd..9cf8fb34 100644
--- a/src/openvpn/push.h
+++ b/src/openvpn/push.h
@@ -50,6 +50,9 @@ void receive_auth_failed(struct context *c, const struct
buffer *buffer);
void server_pushed_signal(struct context *c, const struct buffer *buffer,
const bool restart, const int adv);
+void server_pushed_info(struct context *c, const struct buffer *buffer,
+const int adv);
+
void incoming_push_message(struct context *c, const struct buffer *buffer);
#if P2MP_SERVER
--
2.22.0
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v2 2/5] Implement support for signalling IV_SSO to server
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);
--
2.22.0
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v2 4/5] Implement sending SSO challenge to clients
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(+)
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}
+
+The server will send AUTH_PENDING and INFO_PRE,{EXTRA} to the client.
+The client is expected to inform the user that authentication is pending and
+display the extra information. For the SSO/SAML EXTRA would be OPEN_URL:url
+and client should ask to the user to open the URL to continue.
+
+For the OpenVPN server this is stateless operation and needs to be
+followed by a client-deny/client-auth[-nt] command (that is the result of the
+out of band authentication).
+
+Before issuing a client-sso-auth to a client instead of a
+client-auth/client-deny, the server should check the IV_SSO
+environment variable if the method is support. The currently
+defined method are crtext for challenge/response using text
+(e.g. TOTP) and openurl for opening an URL in the client to
+continue authentication. A client support both methods would set
+
+ setenv IV_SSO openurl,crtext
+
COMMAND -- client-deny (OpenVPN 2.1 or higher)
---
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 8dada6f2..c055f2ce 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -105,6 +105,8 @@ man_help(void)
msg(M_CLIENT, "client-auth-nt CID KID : Authenticate client-id/key-id
CID/KID");
msg(M_CLIENT, "client-deny CID KID R [CR] : Deny auth client-id/key-id
CID/KID with log reason");
msg(M_CLIENT, " text R and optional client
reason text CR");
+msg(M_CLIENT, "client-sso-auth CID MSG : Instruct OpenVPN to send
AUTH_PENDING and INFO_PRE msg"
+ " to the client and wait for a
final client-auth/client-deny");
msg(M_CLIENT, "client-kill CID [M]: Kill client instance CID with
message M (def=RESTART)");
msg(M_CLIENT, "env-filter [level] : Set env-var filter level");
#ifdef MANAGEMENT_PF
@@ -1001,6 +1003,43 @@ parse_kid(const char *str, unsigned int *kid)
}
}
+/**
+ * Will send a notification to the client that succesful authentication
+ * will require an additional step (web based SSO/2-factor auth/etc)
+ *
+ * @param man The management interface struct
+ * @param cid_str The CID in string form
+ * @param extra The string to be send to the client containing
+ * the information of the additional steps
+ */
+static void
+man_client_sso_auth(struct management *man, const char *cid_str, const char
*extra)
+{
+unsigned long cid = 0;
+if (parse_cid(cid_str, ))
+{
+if (man->persist.callback.client_sso)
+{
+bool ret = (*man->persist.callback.client_sso)
+ (man->persist.callback.arg, cid, extra);
+
+if (ret)
+{
+msg(M_CLIENT, "SUCCESS: client-sso-auth command succeeded");
+}
+else
+{
+msg(M_CLIENT, "SUCCESS: client-sso-auth command failed."
+ " Extra paramter might be too long");
+}
+}
+else
+{
+msg(M_CLIENT, "ERROR: The client-sso-auth command is not supported
by the current daemon mode");
+}
+}
+}
+
static void
man_client_auth(struct management *man, const char *cid_str, const char
*kid_str, const bool extra)
{
@@ -1541,6 +1580,13 @@ man_dispatch_command(struct management *man, struct
status_output *so, const cha
man_client_auth(man, p[1], p[2], true);
}
}
+else if (streq(p[0], "client-sso-auth"))
+{
+if (man_need(man, p, 2, 0))
+{
+man_client_sso_auth(man, p[1], p[2]);
+}
+}
#ifdef MANAGEMENT_PF
else if (streq(p[0], "client-pf"))
{
diff --git a/src/openvpn/manage.h b/src/openvpn/manage.h
index 8acc18bf..f570afc6 100644
Re: [Openvpn-devel] [PATCH applied] Re: wintun: add --windows-driver config option
Hi, On Sat, Nov 09, 2019 at 03:49:51PM +0100, Gert Doering wrote: > wintun: add --windows-driver config option > > Signed-off-by: Lev Stipakov > Acked-by: Simon Rozman Ooops. Misattributed the ACK, so this was really Steffan's ACK. I am not amending & re-pusing the commit. This will call more confusion. Sorry. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 0/5] Implement additional two step authentication methods
> > +1. What functionality does this new mechanism add? > > Tunnelblick implements 2FA through the management interface using the > existing static and dynamic challenge-response mechanism. For a > dynamic challenge, for example. Tunnelblick gets a response from the user in > a popup window or from a user-specified script. (A script is usually > used to get the response from hardware devices.) > It adds 2FA without reconnect dance and also the ability to do something like web based SSO authentication. But a server should not use these unless your client will announce support for them via IV_SSO variable. The v2 version of the patch will describe the IV_SSO variable too. Arne 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 applied] Re: wintun: add --windows-driver config option
Your patch has been applied to the master branch. (It needed a bit of manual massaging as the context in options.c:851 changed due to the merge of the VLAN patches) I'm not totally happy with introducing a new function (parse_windows_driver()) to effectively map two constant strings to a boolan variable... but since this got ACKed already, in it goes... commit c0658271be5b45a201eb6aba1e4bdc5a729285be Author: Lev Stipakov Date: Fri Nov 8 19:37:35 2019 +0200 wintun: add --windows-driver config option Signed-off-by: Lev Stipakov Acked-by: Simon Rozman Message-Id: <1573234655-905-1-git-send-email-lstipa...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19046.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: Visual Studio: upgrade project files to VS2019
Your patch has been applied to the master branch. commit 472f9809430ec7311a98df134b4a91928ade5a6f Author: Lev Stipakov Date: Thu Nov 7 19:45:23 2019 +0200 Visual Studio: upgrade project files to VS2019 Signed-off-by: Lev Stipakov Acked-by: Simon Rozman Message-Id: <1573148729-27339-2-git-send-email-lstipa...@gmail.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19027.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v6 1/2] Make tls_version_max return the actual maximum version
Before OpenSSL 1.1.1 there could be no mismatch between
compiled and actual OpenSSL version. With OpenSSL 1.1.1 we need
runtime detection to detect the actual best TLS version supported.
Allowing this runtime detection also allows removing some of the
TLS 1.3/OpenSSL 1.1.1 #ifdefs
Without this patch tls-min-version 1.3 or-highest will actually
downgrade to TLS 1.3 in the "compiled with 1.1.0 and linked against
1.1.1" scenario.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl.c | 11 +--
src/openvpn/ssl_openssl.c | 31 ---
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 4455ebb8..e708fc93 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -4194,12 +4194,11 @@ show_available_tls_ciphers(const char *cipher_list,
{
printf("Available TLS Ciphers, listed in order of preference:\n");
-#if (ENABLE_CRYPTO_OPENSSL && OPENSSL_VERSION_NUMBER >= 0x1010100fL)
-printf("\nFor TLS 1.3 and newer (--tls-ciphersuites):\n\n");
-show_available_tls_ciphers_list(cipher_list_tls13, tls_cert_profile, true);
-#else
-(void) cipher_list_tls13; /* Avoid unused warning */
-#endif
+if (tls_version_max() >= TLS_VER_1_3)
+{
+printf("\nFor TLS 1.3 and newer (--tls-ciphersuites):\n\n");
+show_available_tls_ciphers_list(cipher_list_tls13, tls_cert_profile,
true);
+}
printf("\nFor TLS 1.2 and older (--tls-cipher):\n\n");
show_available_tls_ciphers_list(cipher_list, tls_cert_profile, false);
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 07916c3c..e07d6e74 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -215,7 +215,23 @@ int
tls_version_max(void)
{
#if defined(TLS1_3_VERSION)
+/* If this is defined we can safely assume TLS 1.3 support */
return TLS_VER_1_3;
+#elif OPENSSL_VERSION_NUMBER >= 0x1010L
+/*
+ * The library we are *linked* against is OpenSSL 1.1.1
+ * and therefore supports TLS 1.3. This needs to be checked at runtime
+ * since we can be compiled against 1.1.0 and then the library can be
+ * upgraded to 1.1.1
+ */
+if (OpenSSL_version_num() >= 0x1010100fL)
+{
+return TLS_VER_1_3;
+}
+else
+{
+return TLS_VER_1_2;
+}
#elif defined(TLS1_2_VERSION) || defined(SSL_OP_NO_TLSv1_2)
return TLS_VER_1_2;
#elif defined(TLS1_1_VERSION) || defined(SSL_OP_NO_TLSv1_1)
@@ -241,12 +257,20 @@ openssl_tls_version(int ver)
{
return TLS1_2_VERSION;
}
-#if defined(TLS1_3_VERSION)
else if (ver == TLS_VER_1_3)
{
+/*
+ * Supporting the library upgraded to TLS1.3 without recompile
+ * is enough to support here with a simple constant that the same
+ * as in the TLS 1.3, so spec it is very unlikely that OpenSSL
+ * will change this constant
+ */
+#ifndef TLS1_3_VERSION
+return 0x0304;
+#else
return TLS1_3_VERSION;
-}
#endif
+}
return 0;
}
@@ -2015,7 +2039,8 @@ show_available_tls_ciphers_list(const char *cipher_list,
#if defined(TLS1_3_VERSION)
if (tls13)
{
-SSL_CTX_set_min_proto_version(tls_ctx.ctx, TLS1_3_VERSION);
+SSL_CTX_set_min_proto_version(tls_ctx.ctx,
+ openssl_tls_version(TLS_VER_1_3));
tls_ctx_restrict_ciphers_tls13(_ctx, cipher_list);
}
else
--
2.22.0
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v6 2/2] Add support for OpenSSL TLS 1.3 when using management-external-key
For TLS 1.0 to 1.2 and OpenSSL 1.1.0 calls us and requires a PKCS1 padded response. As TLS 1.3 mandates RSA-PSS padding support and also requires an TLS 1.3 implementation to support RSA-PSS for older TLS version, OpenSSL will query us to sign an already RSA-PSS padded string. This patch adds an 'unpadded' and 'pkcs1' parameter to the management-external-key option to signal that the client is able to support pkcs1 as well as unpadded signature requests. Since clients that implement the management-external-key interface are usually rather tightly integrated solutions (OpenVPN Connect in the past, OpenVPN for Android), it is reasonable to expect that upgrading the OpenSSL library can be done together with management interface changes. Therefore we provide no backwards compatbility for mangement-interface clients not supporting OpenSSL 1.1.1. Using the management api client version instead might seem like the more logical way but since we only now that version very late, it would extra logic and complexity to deal with this asynchronous behaviour. Instead just give an error early if OpenSSL 1.1.1 and management-external-key without nopadding is detected. The interface is prepared for signalling PCKS1 and RSA-PSS support instead of signalling unpadded support. Patch v3: fix overlong lines and few other style patches. Note two overlong lines concerning mbedtls are not fixed as they are removed/shortend by the mbed tls patch to avoid conflicts Patch v4: Setting minimum TLS version proved to be not enough and instead of implementing a whole compability layer we require mangement-clients to implement the new feature when they want to use OpenSSL 1.1.1 Add a padding=ALGORITHM argument to pk-sig to indicate the algorithm. Drop adding PKCS1 ourselves. Patch v5: Send the right version of the patch Patch v6: Send version rebased on master Signed-off-by: Arne Schwabe --- doc/management-notes.txt | 13 +- doc/openvpn.8 | 7 -- src/openvpn/manage.c | 20 --- src/openvpn/manage.h | 23 +++-- src/openvpn/options.c | 36 +- src/openvpn/ssl_mbedtls.c | 7 -- src/openvpn/ssl_openssl.c | 53 +++ 7 files changed, 130 insertions(+), 29 deletions(-) diff --git a/doc/management-notes.txt b/doc/management-notes.txt index 17645c1d..f685af28 100644 --- a/doc/management-notes.txt +++ b/doc/management-notes.txt @@ -816,6 +816,7 @@ actual private key. When the SSL protocol needs to perform a sign operation, the data to be signed will be sent to the management interface via a notification as follows: +>PK_SIGN:[BASE64_DATA],[ALG] (if client announces support for management version > 2) >PK_SIGN:[BASE64_DATA] (if client announces support for management version > 1) >RSA_SIGN:[BASE64_DATA] (only older clients will be prompted like this) @@ -823,7 +824,7 @@ The management interface client should then create an appropriate signature of the (decoded) BASE64_DATA using the private key and return the SSL signature as follows: -pk-sig (or rsa-sig) +pk-sig (or rsa-sig) [BASE64_SIG_LINE] . . @@ -833,6 +834,12 @@ END Base 64 encoded output of RSA_private_encrypt for RSA or ECDSA_sign() for EC using OpenSSL or mbedtls_pk_sign() using mbed TLS will provide a correct signature. +The rsa-sig interfaces expects PKCS1 padded signatures for RSA keys +(RSA_PKCS1_PADDING). EC signatures are always unpadded. + +The padding field is only present when pk-sig is used and +currently the following values can be requested PCKS1 and NOPADDING for RSA +certificates and NOPADDING for EC certificates. This capability is intended to allow the use of arbitrary cryptographic service providers with OpenVPN via the management interface. @@ -840,6 +847,10 @@ service providers with OpenVPN via the management interface. New and updated clients are expected to use the version command to announce a version > 1 and handle '>PK_SIGN' prompt and respond with 'pk-sig'. +The older rsa-sig and pk-sig interfaces hav no capability to indidicate the +requested padding algorithm. When the 'nopadding' using version >= 2 is required. +To support TLS 1.3 with OpenSSL 1.1.1 supporting unpadded signatures is required. + COMMAND -- certificate (OpenVPN 2.4 or higher) -- Provides support for external storage of the certificate. Requires the diff --git a/doc/openvpn.8 b/doc/openvpn.8 index f58a3ccc..99e01252 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -2708,10 +2708,13 @@ Allow management interface to override directives (client\-only). .\"* .TP -.B \-\-management\-external\-key +.B \-\-management\-external\-key [nopadding] [pkcs1] Allows usage for external private key file instead of .B \-\-key -option (client\-only). +option (client\-only). The optional parameters
Re: [Openvpn-devel] [PATCH v2 6/7] wintun: set adapter properties via interactive service
Hi,
> -Original Message-
> From: Lev Stipakov [mailto:lstipa...@gmail.com]
> Sent: Thursday, November 7, 2019 6:45 PM
> To: openvpn-devel@lists.sourceforge.net
> Cc: Lev Stipakov
> Subject: [Openvpn-devel] [PATCH v2 6/7] wintun: set adapter properties via
> interactive service
>
> static bool
> -do_dns6_service(bool add, const struct tuntap *tt)
> +do_dns_service(bool add, const short family, const struct tuntap *tt)
> {
> bool ret = false;
> ack_message_t ack;
> struct gc_arena gc = gc_new();
> HANDLE pipe = tt->options.msg_channel;
> -int addr_len = add ? tt->options.dns6_len : 0;
> +int len = family == AF_INET6 ? tt->options.dns6_len :
tt->options.dns_len;
> +int addr_len = add ? len : 0;
> +char ip_proto_name[5];
> +
> +strcpy(ip_proto_name, family == AF_INET6 ? "IPv6" : "IPv4");
const char *ip_proto_name = family == AF_INET6 ? "IPv6" : "IPv4";
... to avoid the strcpy().
The rest LGTM, so...
Acked-by: Simon Rozman
Best regards,
Simon
smime.p7s
Description: S/MIME cryptographic signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v3 4/7] wintun: ring buffers based I/O
From: Lev Stipakov
Implemented according to Wintun documentation
and reference client code.
Wintun uses ring buffers to communicate between
kernel driver and user process. Client allocates
send and receive ring buffers, creates events
and passes it to kernel driver under LocalSystem
privileges.
When data is available for read, wintun modifies
"tail" pointer of send ring and signals via event.
User process reads data from "head" to "tail" and
updates "head" pointer.
When user process is ready to write, it writes
to receive ring, updates "tail" pointer and signals
to kernel via event.
In openvpn code we add send ring's event to event loop.
Before performing io wait, we compare "head" and "tail"
pointers of send ring and if they're different, we skip
io wait and perform read.
This also adds ring buffers support to tcp and udp
server code.
Signed-off-by: Lev Stipakov
---
v3:
- simplified convoluted #ifdefs
- replaced "greater than" with "greater or equal than"
v2:
- rebased on top of master
src/openvpn/forward.c | 32 -
src/openvpn/forward.h | 45 ++-
src/openvpn/mtcp.c| 26 ++-
src/openvpn/mudp.c| 14 ++
src/openvpn/options.c | 4 +-
src/openvpn/syshead.h | 1 +
src/openvpn/tun.c | 45 +++
src/openvpn/tun.h | 121 +-
src/openvpn/win32.c | 120 +
src/openvpn/win32.h | 47
10 files changed, 447 insertions(+), 8 deletions(-)
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 8451706..484975b 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1256,8 +1256,24 @@ read_incoming_tun(struct context *c)
perf_push(PERF_READ_IN_TUN);
c->c2.buf = c->c2.buffers->read_tun_buf;
+
#ifdef _WIN32
-read_tun_buffered(c->c1.tuntap, >c2.buf);
+if (c->c1.tuntap->wintun)
+{
+read_wintun(c->c1.tuntap, >c2.buf);
+if (c->c2.buf.len == -1)
+{
+register_signal(c, SIGHUP, "tun-abort");
+c->persist.restart_sleep_seconds = 1;
+msg(M_INFO, "Wintun read error, restarting");
+perf_pop();
+return;
+}
+}
+else
+{
+read_tun_buffered(c->c1.tuntap, >c2.buf);
+}
#else
ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
@@ -2103,7 +2119,19 @@ io_wait_dowork(struct context *c, const unsigned int
flags)
* Configure event wait based on socket, tuntap flags.
*/
socket_set(c->c2.link_socket, c->c2.event_set, socket, (void
*)_shift, NULL);
-tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift, NULL);
+
+#ifdef _WIN32
+if (c->c1.tuntap && c->c1.tuntap->wintun)
+{
+/* add ring buffer event */
+struct rw_handle rw = {.read = c->c1.tuntap->send_tail_moved };
+event_ctl(c->c2.event_set, , EVENT_READ, (void *)_shift);
+}
+else
+#endif
+{
+tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift,
NULL);
+}
#ifdef ENABLE_MANAGEMENT
if (management)
diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
index 48202c0..b2c6152 100644
--- a/src/openvpn/forward.h
+++ b/src/openvpn/forward.h
@@ -375,6 +375,19 @@ p2p_iow_flags(const struct context *c)
{
flags |= IOW_TO_TUN;
}
+#ifdef _WIN32
+{
+struct tuntap *tt = c->c1.tuntap;
+if (tt && tt->wintun)
+{
+if (tt->send_ring->head == tt->send_ring->tail)
+{
+/* nothing to read from tun -> remove tun read flag set by
IOW_READ */
+flags &= ~IOW_READ_TUN;
+}
+}
+}
+#endif
return flags;
}
@@ -403,8 +416,36 @@ io_wait(struct context *c, const unsigned int flags)
}
else
{
-/* slow path */
-io_wait_dowork(c, flags);
+#ifdef _WIN32
+bool skip_iowait = flags & IOW_TO_TUN;
+if (flags & IOW_READ_TUN)
+{
+/*
+ * don't read from tun if we have pending write to link,
+ * since every tun read overwrites to_link buffer filled
+ * by previous tun read
+ */
+skip_iowait = !(flags & IOW_TO_LINK);
+}
+if (c->c1.tuntap && c->c1.tuntap->wintun && skip_iowait)
+{
+unsigned int ret = 0;
+if (flags & IOW_TO_TUN)
+{
+ret |= TUN_WRITE;
+}
+if (flags & IOW_READ_TUN)
+{
+ret |= TUN_READ;
+}
+c->c2.event_set_status = ret;
+}
+else
+#endif
+{
+/* slow path */
+io_wait_dowork(c, flags);
+}
}
}
diff --git a/src/openvpn/mtcp.c b/src/openvpn/mtcp.c
index abe2059..02e9016 100644
--- a/src/openvpn/mtcp.c
+++ b/src/openvpn/mtcp.c
@@
Re: [Openvpn-devel] [PATCH v2 5/7] wintun: interactive service support
Hi, Acked-by: Simon Rozman Best regards, Simon smime.p7s Description: S/MIME cryptographic signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 9/9] VLAN: allow user to avoid compiling VLAN handling code
Hi all,
today, during the hackathon, we discussed whether it makes sense to
allow a user to compile out the VLAN tagging code.
The only reason we could came up with is "binary size". A non-negligible
difference between the openvpn binary with and without VLAN code might
be a meaningful reason for introducing a compile time option.
The following are the output of the 'size' tool on the openvpn binary
without and with VLAN code:
$ size src/openvpn/openvpn
textdata bss dec hex filename
78742872242136 796788 c2874 src/openvpn/openvpn
$ size src/openvpn/openvpn
textdata bss dec hex filename
79159872242136 800958 c38be src/openvpn/openvpn
The difference is around 4KB and none of us believes that this is enough
to justify having yet another compile time option.
For the reason explained above, we decided to NACK this patch.
Cheers,
On 09/10/2019 16:34, Antonio Quartulli wrote:
> To handle VLANs a whole lot of code has been introduced.
> However, there are a number of users who may not need this feature and
> would rather preserve disk space.
>
> Implement a configure knob (--disable-vlan-tagging) to conditionally
> take the entire VLAN code out.
>
> This patch introduces the conditional by keeping all the logic/ifdefs in
> vlan.h and avoid polluting the rest of code (exception made for
> options.h/c which is really troublesome to deal with).
>
> Signed-off-by: Antonio Quartulli
> ---
> configure.ac| 12 ++
> src/openvpn/Makefile.am | 5 ++-
> src/openvpn/mroute.c| 6 +--
> src/openvpn/mroute.h| 2 +
> src/openvpn/multi.c | 10 ++---
> src/openvpn/options.c | 15
> src/openvpn/options.h | 2 +
> src/openvpn/vlan.h | 83 +
> 8 files changed, 126 insertions(+), 9 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index c7fd7a84..66d58b91 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -256,6 +256,13 @@ AC_ARG_ENABLE(
> [enable_async_push="no"]
> )
>
> +AC_ARG_ENABLE(
> + [vlan-tagging],
> + [AS_HELP_STRING([--disable-vlan-tagging], [Disble support for
> 802.1Q-based VLAN tagging])],
> + ,
> + [enable_vlan="yes"]
> +)
> +
> AC_ARG_WITH(
> [special-build],
> [AS_HELP_STRING([--with-special-build=STRING], [specify special build
> string])],
> @@ -1321,6 +1328,10 @@ if test "${enable_async_push}" = "yes"; then
> )
> fi
>
> +if test "${enable_vlan}" = "yes"; then
> + AC_DEFINE(ENABLE_VLAN_TAGGING, 1, [Enable 802.1Q-based VLAN
> tagging/untagging])
> +fi
> +
> CONFIGURE_DEFINES="`set | grep '^enable_.*=' ; set | grep '^with_.*='`"
> AC_DEFINE_UNQUOTED([CONFIGURE_DEFINES], ["`echo ${CONFIGURE_DEFINES}`"],
> [Configuration settings])
>
> @@ -1349,6 +1360,7 @@ AC_SUBST([OPTIONAL_PKCS11_HELPER_LIBS])
> AC_SUBST([PLUGIN_AUTH_PAM_CFLAGS])
> AC_SUBST([PLUGIN_AUTH_PAM_LIBS])
>
> +AM_CONDITIONAL([VLAN_TAGGING], [test "${enable_vlan}" = "yes"])
> AM_CONDITIONAL([WIN32], [test "${WIN32}" = "yes"])
> AM_CONDITIONAL([GIT_CHECKOUT], [test "${GIT_CHECKOUT}" = "yes"])
> AM_CONDITIONAL([ENABLE_PLUGIN_AUTH_PAM], [test "${enable_plugin_auth_pam}" =
> "yes"])
> diff --git a/src/openvpn/Makefile.am b/src/openvpn/Makefile.am
> index bc976019..64df1df4 100644
> --- a/src/openvpn/Makefile.am
> +++ b/src/openvpn/Makefile.am
> @@ -123,7 +123,7 @@ openvpn_SOURCES = \
> syshead.h \
> tls_crypt.c tls_crypt.h \
> tun.c tun.h \
> - vlan.c vlan.h \
> + vlan.h \
> win32.h win32.c \
> cryptoapi.h cryptoapi.c
> openvpn_LDADD = \
> @@ -136,6 +136,9 @@ openvpn_LDADD = \
> $(OPTIONAL_SELINUX_LIBS) \
> $(OPTIONAL_SYSTEMD_LIBS) \
> $(OPTIONAL_DL_LIBS)
> +if VLAN_TAGGING
> +openvpn_SOURCES += vlan.c
> +endif
> if WIN32
> openvpn_SOURCES += openvpn_win32_resources.rc block_dns.c block_dns.h
> openvpn_LDADD += -lgdi32 -lws2_32 -lwininet -lcrypt32 -liphlpapi -lwinmm
> -lfwpuclnt -lrpcrt4 -lncrypt
> diff --git a/src/openvpn/mroute.c b/src/openvpn/mroute.c
> index bdb1b0c0..d6dc8d22 100644
> --- a/src/openvpn/mroute.c
> +++ b/src/openvpn/mroute.c
> @@ -35,6 +35,7 @@
> #include "proto.h"
> #include "error.h"
> #include "socket.h"
> +#include "vlan.h"
>
> #include "memdbg.h"
>
> @@ -256,8 +257,7 @@ mroute_copy_ether_to_addr(struct mroute_addr *maddr,
> maddr->netbits = 0;
> maddr->len = OPENVPN_ETH_ALEN;
> memcpy(maddr->ether.addr, ether_addr, OPENVPN_ETH_ALEN);
> -maddr->len += sizeof(vid);
> -maddr->ether.vid = vid;
> +vlan_maddr_copy_vid(maddr, vid);
> }
>
> unsigned int
> @@ -467,7 +467,7 @@ mroute_addr_print_ex(const struct mroute_addr *ma,
> case MR_ADDR_ETHER:
> buf_printf(, "%s", format_hex_ex(ma->ether.addr,
> sizeof(ma->ether.addr),
> 0, 1, ":", gc));
> -buf_printf(, "@%hu", ma->ether.vid);
> +
[Openvpn-devel] [PATCH applied] Re: VLAN: add documentation to manpage
Acked-by: Gert Doering Documentation is good :-) and it matches observed behaviour, so that's even better. Can the wording be improved? Surely, always, but this is a continuous process by letting "untainted" people read the docs and come up with questions that we find obvious... Your patch has been applied to the master branch. commit 0328003b0e987de0b7b91c3e53c84604188d9421 Author: Antonio Quartulli Date: Sat Nov 9 10:58:36 2019 +0100 VLAN: add documentation to manpage Signed-off-by: Fabian Knittel Signed-off-by: Antonio Quartulli Acked-by: Gert Doering Message-Id: <20191109095836.11190-...@unstable.cc> URL: https://www.mail-archive.com/search?l=mid=20191109095836.11190-...@unstable.cc Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: VLAN: allow forwarding tagged and untagged packets on the server TAP device
Acked-by: Gert Doering Stared at code, ran full t_client/t_server tests. In my test I had a "vlan 200" which was the native/untagged VLAN on the tap interface now (so ipv4/v6 config goes to "tap9") and a "vlan 207" which was tagged (-> tap9.207), and clients in "pvid 200" could nicely talk to clients in "pvid 207" by means of linux routing between tap9 and tap9.207. Shutting down tap9.207 stopped communication (= proof that it really went out of openvpn and in again). Your patch has been applied to the master branch. commit d626fa179b215a12398051ffca25b43ecfc0ad60 Author: Antonio Quartulli Date: Wed Oct 9 16:34:20 2019 +0200 VLAN: allow forwarding tagged and untagged packets on the server TAP device Signed-off-by: Fabian Knittel Signed-off-by: Antonio Quartulli Acked-by: Gert Doering Message-Id: <20191009143422.9419-...@unstable.cc> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18919.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v2 4/7] wintun: ring buffers based I/O
Hi,
> -Original Message-
> From: Lev Stipakov [mailto:lstipa...@gmail.com]
> Sent: Thursday, November 7, 2019 6:45 PM
> To: openvpn-devel@lists.sourceforge.net
> Cc: Lev Stipakov
> Subject: [Openvpn-devel] [PATCH v2 4/7] wintun: ring buffers based I/O
>
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c index
> 8451706..0be8b6d 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -1256,12 +1256,30 @@ read_incoming_tun(struct context *c)
> perf_push(PERF_READ_IN_TUN);
>
> c->c2.buf = c->c2.buffers->read_tun_buf;
> +
> #ifdef _WIN32
> -read_tun_buffered(c->c1.tuntap, >c2.buf);
> +if (c->c1.tuntap->wintun)
> +{
> +read_wintun(c->c1.tuntap, >c2.buf);
> +if (c->c2.buf.len == -1)
> +{
> +register_signal(c, SIGHUP, "tun-abort");
> +c->persist.restart_sleep_seconds = 1;
> +msg(M_INFO, "Wintun read error, restarting");
> +perf_pop();
> +return;
> +}
> +}
> +else
> +{
> +read_tun_buffered(c->c1.tuntap, >c2.buf);
> #else
> -ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
> -ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
> -c->c2.buf.len = read_tun(c->c1.tuntap, BPTR(>c2.buf),
> MAX_RW_SIZE_TUN(>c2.frame));
> +ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
> +ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
> +c->c2.buf.len = read_tun(c->c1.tuntap, BPTR(>c2.buf),
> +MAX_RW_SIZE_TUN(>c2.frame)); #endif #ifdef _WIN32
> +}
> #endif
This #ifdef dance is a bit convoluted. I suggest simplification.
> #ifdef PACKET_TRUNCATION_CHECK
> @@ -2103,7 +2121,21 @@ io_wait_dowork(struct context *c, const unsigned
> int flags)
> * Configure event wait based on socket, tuntap flags.
> */
> socket_set(c->c2.link_socket, c->c2.event_set, socket, (void
*)_shift,
> NULL);
> -tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift,
NULL);
> +
> +#ifdef _WIN32
> +if (c->c1.tuntap && c->c1.tuntap->wintun)
> +{
> +/* add ring buffer event */
> +struct rw_handle rw = {.read = c->c1.tuntap->send_tail_moved };
> +event_ctl(c->c2.event_set, , EVENT_READ, (void *)_shift);
> +}
> +else
> +{
> +#endif
> +tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void
> +*)_shift, NULL); #ifdef _WIN32
> +}
> +#endif
This #ifdef dance is a bit convoluted. I suggest simplification.
> +static inline int
> +write_wintun(struct tuntap *tt, struct buffer *buf) {
> +struct tun_ring *ring = tt->receive_ring;
> +ULONG head = ring->head;
> +ULONG tail = ring->tail;
> +ULONG aligned_packet_size;
> +ULONG buf_space;
> +struct TUN_PACKET *packet;
> +
> +if ((head > WINTUN_RING_CAPACITY) || (tail >=
> WINTUN_RING_CAPACITY))
Should be `...head >= WINTUN_RING_CAPACITY...`
Regards,
Simon
smime.p7s
Description: S/MIME cryptographic signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH v3 8/9] VLAN: add documentation to manpage
This patch adds documentation for all the VLAN related knobs. Signed-off-by: Fabian Knittel Signed-off-by: Antonio Quartulli --- Changes from v1: - slight rewording of some sentences, as suggested by Arne Changes from v2: - slight rewording of some sentences, as suggested by Gert doc/openvpn.8 | 100 +- 1 file changed, 99 insertions(+), 1 deletion(-) diff --git a/doc/openvpn.8 b/doc/openvpn.8 index 11daa92a..f58a3ccc 100644 --- a/doc/openvpn.8 +++ b/doc/openvpn.8 @@ -3440,7 +3440,8 @@ without needing to restart the server. The following options are legal in a client\-specific context: -.B \-\-push, \-\-push\-reset, \-\-push\-remove, \-\-iroute, \-\-ifconfig\-push, +.B \-\-push, \-\-push\-reset, \-\-push\-remove, \-\-iroute, +.B \-\-ifconfig\-push, \-\-vlan\-pvid and .B \-\-config. .\"* @@ -3908,6 +3909,103 @@ connection is torn down. Not implemented on Windows. .\"* +.TP +.B \-\-vlan\-tagging +Server-only option. Turns the OpenVPN server instance into a switch that +understands VLAN\-tagging, based on IEEE 802.1Q. + +The server TAP device and each of the connecting clients is seen as a port of the +switch. All client ports are in untagged mode and the server TAP device is +VLAN-tagged, untagged or accepts both, depending on the +.B \-\-vlan\-accept setting. + +Ethernet frames with a prepended 802.1Q tag are called "tagged". If the VLAN +Identifier (VID) field in such a tag is non-zero, the frame is called +"VLAN\-tagged". If the VID is zero, but the Priority Control Point (PCP) field +is non\-zero, the frame is called "prio\-tagged". If there is no 802.1Q tag, the +frame is "untagged". + +Using the +.B \-\-vlan\-pvid v +option once per client (see \-\-client\-config\-dir), each port can be associated +with a certain VID. Packets +can only be forwarded between ports having the same VID. Therefore, clients +with differing VIDs are completely separated from one\-another, even if +.B \-\-client\-to\-client +is activated. + +The packet filtering takes place in the OpenVPN server. Clients should not +have any VLAN tagging configuration applied. + +The +.B \-\-vlan\-tagging +option is off by default. While turned off, OpenVPN +accepts any Ethernet frame and does not perform any special processing +for VLAN\-tagged packets. + +The option can only be activated in +.B \-\-dev tap mode. + +.\"* +.TP +.B \-\-vlan\-accept all | tagged | untagged +Configure the VLAN tagging policy for the server TAP device. The following modes +are available: + +.B tagged +\-\- Admit only VLAN\-tagged frames. +Only VLAN\-tagged packets are accepted, while untagged or priority\-tagged +packets are dropped when entering the server TAP device. + +.br +.B untagged +\-\- Admit only untagged and prio\-tagged frames. +.br +VLAN\-tagged packets are not accepted, while untagged or priority\-tagged +packets entering the server TAP device are tagged with the value configured +for the global +.B \-\-vlan\-pvid +setting. +.br +.B all +(default) \-\- Admit all frames. +.br +All packets are admitted and then treated like untagged or tagged mode +respectively. + +(Note: Some vendors refer to switch ports running in +.B tagged +mode as "trunk ports" and switch ports running in +.B untagged +mode as "access ports".) + +Packets forwarded from clients to the server are VLAN\-tagged +with the originating client's PVID, unless the VID matches the +global \-\-vlan\-pvid, in which case the tag is removed. + +If no PVID is configured for a given client (see \-\-vlan\-pvid) packets +are tagged with 1 by default. +.\"* +.TP +.B \-\-vlan\-pvid v +Specifies which VLAN identifier a "port" is associated with. Only valid when +\fB\-\-vlan\-tagging\fR is speficied. + +In the client context, the setting specifies which VLAN ID a client is +associated with. In the global context, the VLAN ID of the server TAP device is set. +The latter only makes sense for +.B \-\-vlan\-accept untagged +and +.B \-\-vlan\-accept all +modes. + +Valid values for +.B v +go from 1 through to 4094. The global value defaults to 1. If no \-\-vlan\-pvid +is specified in the client context, the global value is inherited. + +In some switch implementations, the PVID is also referred to as "Native VLAN". +.\"* .SS Client Mode Use client mode when connecting to an OpenVPN server which has -- 2.24.0 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH applied] Re: VLAN: implement support for forwarding only pre-tagged VLAN packets
Acked-by: Gert Doering
Stared at the code. Ran a full set of t_client/t_server tests with
disabled VLAN tagging (no change, no brokenness).
With enabled VLAN tagging and using "untagged mode" it now correctly
sorts out packets tap <-> client and client1 <-> client2 according
to PVID - if PVIDs match, devices can talk and broadcasts are seen,
and if they do not match, no communication happens. Great.
One bug for the upcoming documentation: if there is *no* "vlan-pvid"
setting in a ccd/ file, it will not use "1" but the "global vlan-pvid"
setting. Which, as we just agreed on, makes sense, just needs to be
documented.
If enabling "tagging only" ("vlan-accept tagged") half the openvpn server
config stops having a meaning - like "ifconfig" or "ifconfig-pool" - so
you really want tap devices that are setup outside of OpenVPN or
by means of a --up script (setting up dot1q subinterfaces, ifconfig,
set up routes, etc.). Just pointing this out for the sake of the
archives.
For reference: this is what you'd do on Linux to set up VLAN subinterfaces
(vlan 200 on tap9)
# modprobe 8021q
# ip link add link tap9 name tap9.200 type vlan id 200
# ip addr add 10.204.4.1/24 dev tap9.200
# ip addr add fd00:abcd:204:4::1/64 dev tap9.200
# ip link set up dev tap9.200
(openvpn running on "--dev tap9")
That said, tagged mode works nicely - client packets are sent to tap0
with "vlan 207" visible in tcpdump, and linux "tap9.207" picks them
up correctly and clients can talk. Clients in a different VLAN show
up with a different vlan tag, etc. - as one would expect. If you want
"clients in vlan 200" to talk to "clients in vlan 207", it needs to be
done with linux routing between "tap9.200" and "tap9.207" - which I did
test, and it also works as expected.
Full set of t_server test passed with enabled vlan tagging (rearranging
tap clients into different vlans and adding IP forwarding etc)
Your patch has been applied to the master branch.
commit e375a5ce555a66c8b6b2ac2869977e723a65982f
Author: Antonio Quartulli
Date: Wed Oct 9 16:34:19 2019 +0200
VLAN: implement support for forwarding only pre-tagged VLAN packets
Signed-off-by: Fabian Knittel
Signed-off-by: Antonio Quartulli
Acked-by: Gert Doering
Message-Id: <20191009143422.9419-...@unstable.cc>
URL:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18918.html
Signed-off-by: Gert Doering
--
kind regards,
Gert Doering
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH v3] wintun: add --windows-driver config option
Hi,
On 08-11-2019 18:37, Lev Stipakov wrote:
> From: Lev Stipakov
>
> This allows to specify which tun driver openvpn should use,
> tap-windows6 (default) or wintun.
>
> Note than wintun support will be added in follow-up patches.
>
> Signed-off-by: Lev Stipakov
> ---
>
> v3:
> - added man page
> - removed unneccesary assignment
> - make method static
> - removed unneeded _WIN32 define
>
> v2:
> - rebased on top of latest master
>
> doc/openvpn.8 | 8
> src/openvpn/init.c| 4
> src/openvpn/options.c | 46 --
> src/openvpn/options.h | 1 +
> src/openvpn/tun.h | 1 +
> 5 files changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index 11daa92..8a7e70f 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -6147,6 +6147,14 @@ Note that pushing unknown options from server does not
> trigger
> fatal errors.
> .\"*
> .TP
> +.B \-\-windows\-driver
> +Specifies which tun driver to use. Values are
> +.B tap-windows6
> +(default) and
> +.B wintun.
> +This is Windows-only option.
> +.\"*
> +.TP
> .B \-\-dhcp\-renew
> Ask Windows to renew the TAP adapter lease on startup.
> This option is normally unnecessary, as Windows automatically
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index ae7bd63..0bdb0a9 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -1733,6 +1733,10 @@ do_init_tun(struct context *c)
> c->c2.es,
> >net_ctx);
>
> +#ifdef _WIN32
> +c->c1.tuntap->wintun = c->options.wintun;
> +#endif
> +
> init_tun_post(c->c1.tuntap,
>>c2.frame,
>>options.tuntap_options);
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 1838a69..a70a822 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -747,9 +747,10 @@ static const char usage_message[] =
> " optional parameter controls the initial state of
> ex.\n"
> "--show-net-up : Show " PACKAGE_NAME "'s view of routing table and net
> adapter list\n"
> " after TAP adapter is up and routes have been added.\n"
> -#ifdef _WIN32
> +"--windows-driver : Which tun driver to use?\n"
> +" tap-windows6 (default)\n"
> +" wintun\n"
> "--block-outside-dns : Block DNS on other network adapters to prevent
> DNS leaks\n"
> -#endif
> "Windows Standalone Options:\n"
> "\n"
> "--show-adapters : Show all TAP-Windows adapters.\n"
> @@ -851,6 +852,7 @@ init_options(struct options *o, const bool init_gc)
> o->tuntap_options.dhcp_masq_offset = 0; /* use network address as
> internal DHCP server address */
> o->route_method = ROUTE_METHOD_ADAPTIVE;
> o->block_outside_dns = false;
> +o->wintun = false;
> #endif
> o->vlan_accept = VLAN_ONLY_UNTAGGED_OR_PRIORITY;
> o->vlan_pvid = 1;
> @@ -2994,6 +2996,12 @@ options_postprocess_mutate_invariant(struct options
> *options)
> options->ifconfig_noexec = false;
> }
>
> +/* for wintun kernel doesn't send DHCP requests, so use ipapi to set IP
> address and netmask */
> +if (options->wintun)
> +{
> +options->tuntap_options.ip_win32_type = IPW32_SET_IPAPI;
> +}
> +
> remap_redirect_gateway_flags(options);
> #endif
>
> @@ -4039,6 +4047,33 @@ foreign_option(struct options *o, char *argv[], int
> len, struct env_set *es)
> }
> }
>
> +#ifdef _WIN32
> +/**
> + * Parses --windows-driver config option
> + *
> + * @param str value of --windows-driver option
> + * @param msglevel msglevel to report parsing error
> + * @return bool true if --windows-driver is wintun, false otherwise
> + */
> +static bool
> +parse_windows_driver(const char *str, const int msglevel)
> +{
> +if (streq(str, "tap-windows6"))
> +{
> +return false;
> +}
> +else if (streq(str, "wintun"))
> +{
> +return true;
> +}
> +else
> +{
> +msg(msglevel, "--windows-driver must be tap-windows6 or wintun");
> +return false;
> +}
> +}
> +#endif
> +
> /*
> * parse/print topology coding
> */
> @@ -5281,6 +5316,13 @@ add_option(struct options *options,
> VERIFY_PERMISSION(OPT_P_GENERAL);
> options->dev_type = p[1];
> }
> +#ifdef _WIN32
> +else if (streq(p[0], "windows-driver") && p[1] && !p[2])
> +{
> +VERIFY_PERMISSION(OPT_P_GENERAL);
> +options->wintun = parse_windows_driver(p[1], M_FATAL);
> +}
> +#endif
> else if (streq(p[0], "dev-node") && p[1] && !p[2])
> {
> VERIFY_PERMISSION(OPT_P_GENERAL);
> diff --git a/src/openvpn/options.h b/src/openvpn/options.h
> index ff7a5bb..0a24e5e 100644
> ---
