Arne Schwabe [Wed, 26 Apr 2023 09:49:31 +0000 (11:49 +0200)]
Add Apache2 linking with for new commits
After first round of mailing people with more than 10 commits we have
almost all committers have agreed. This put this license in the realm
of having a realistic change to work. Had any of these contributers
disagreed, rewriting all their code might have been not feasible.
The rationale of adding this exception now is to avoid having to
have a second round of agreement for new contributers and ensure
that all new code will include the exemption.
patch v2: add explaination and use exception rather than excemption
patch v3: actually send v3
Change-Id: Ide83f914f383b53ef37ddf628e4da5a78e241bf0 Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20230426094931.1168078-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26610.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7b21c69dbe1e1ecfb5bed564417387892b42108a)
Arne Schwabe [Thu, 15 Dec 2022 19:01:38 +0000 (20:01 +0100)]
Ensure that argument to parse_line has always space for final sentinel
This fixes two places were we do not have enough space in the array
of parameters given to parse_line for the final NULL parameter that
signal the end of the parsed argument errors.
Both these cases can lead to a buffer overflow. But both of these
cases require root/admin access to OpenVPN:
- parse_argv, only able to trigger if starting openvpn from the command
line, at this point you cannot gain more privileges than you already
have.
Way to reproduce, compile with ASAN and run:
openvpn --tls-verify a a a a a a a a a a a a a a a
- remove_iroutes_from_push_route_list
This operates on the list of pushed entries that is generated
by the server itself. So trigger this, you need to have control
over config, management interface, a plugin or cdd files.
The parse_argv problem was found by Trial of Bits. I found the
remove_iroutes_from_push_route_list problem by looking for similar
problems.
Reported-By: Trial of Bits (TOB-OVPN-4) Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20221215190143.2107896-4-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25734.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 749beb6d0cb9f8628997bb656ba2f64e31cac377)
The plug-in API in OpenVPN 2.x is not designed for running multiple
deferred authentication processes in parallel. The authentication
results of such configurations are not to be trusted. For now we bail
out when this discovered with an error in the log.
This is a backport of commit 282ddbac54f8d4923844f699 (master), taking
the different man-page format into account. The code change is the same.
CVE: 2022-0547 Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20220315155344.37787-3-openvpn@sf.lists.topphemmelig.net>
URL: https://www.mail-archive.com/search?l=mid&q=20220315155344.37787-3-openvpn@sf.lists.topphemmelig.net Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering [Tue, 22 Feb 2022 11:38:32 +0000 (12:38 +0100)]
Fix --mtu-disc maybe|yes on Linux.
--mtu-disc (on Linux) needs two components to work:
- setsockopt() with IP_MTU_DISCOVER or IPV6_MTU_DISCOVER
- "extended error reporting" (setsockopt(IP_RECVERR) and
then via mtu.c/format_extended_socket_error()) to react on
"packet too big" errors on sendto() / sendmsg()
Some configure.ac reorganization broke detection of <linux/errqueue.h>
and "struct sock_extended_err". Re-add <linux/errqueue.h> to configure.ac,
remove all the other conditionals in syshead.h, and remove the
"struct sock_extended_err" check completely (assumption: if errqueue.h
exists, it contains what we need).
Thus, the "non-helpful" socket error message turns into:
2022-02-22 12:31:42 write UDPv4 [EMSGSIZE Path-MTU=800]: Message too long (fd=3,code=90)
2022-02-22 12:31:42 Note adjusting 'mssfix 1400 mtu' to 'mssfix 800 mtu' according to path MTU discovery
2022-02-22 12:31:42 Note adjusting 'fragment 1400 mtu' to 'fragment 800 mtu' according to path MTU discovery
... while at it, fix extra space in first part of these messages, and
print o->ce.fragment for the "fragment" message...
v2: assume that "if it's linux, and has these two headers, everything
else will be there as well" and get rid of most of the #ifdef checks
Trac: #1452
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20220222113832.13383-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23863.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 4225114b96723bdecd68398f7a89765879b31b5d)
(cherry picked from commit 3e0c506e5d9135ef4b08547db8679cc5bd2a7582)
doc openvpn.8: Use free open-source dynamic-DNS provider URL
Trac: #1417
Signed-off-by: Richard T Bonhomme <tincantech@protonmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20211103211820.1147661-1-tincantech@protonmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23096.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Selva Nair [Sat, 23 Oct 2021 00:07:06 +0000 (20:07 -0400)]
Ensure the current common_name is in the environment for scripts
When username-as-common-name is in effect, the common_name
is "CN" from the certificate for auth-user-pass-verify. It gets
changed to "username" after successful authentication. This
changed value gets into the env when client-connect script is
called.
However, "common_name" goes through the cycle of being
"CN", then "username" during every reauth (renegotiation).
As the client-connect script is not called during reneg, the changed
value never gets back into the env. The end result is that the
disconnect script gets "common_name=<CN>" instead of the username.
Unless no reneg steps have happened before disconnect.
(For a more detailed analysis see
https://community.openvpn.net/openvpn/ticket/1434#comment:12)
Fix by adding common_name to env whenever it changes.
Trac: #1434
Very likely applies to #160 as well, but that's too old and
some of the relevant code path has evolved since then.
Same as commit fa5ab2438a in master, except for the context change
due to PF.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20211023000706.25016-2-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg23050.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a2412bf4a6bb6ac7a6f26128d00fe81b0fa4a18e)
Selva Nair [Wed, 2 Jun 2021 19:47:39 +0000 (15:47 -0400)]
Apply the connect-retry backoff to only one side of a connection
p2p connections with both ends backing off seldom succeed
as their connection attempt durations becomes increasingly
unlikely to overlap when the retry wait time is long.
Avoid this by applying the backoff logic only on TCP clients
or the tls_client side for UDP.
Regression warning: shared secret setups are left out of the
backoff logic.
Trac: #1010, #1384
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20210602194739.29488-1-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22485.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 063d55afeea723fc6df0af29a19df257a8ab6920)
This reverts commit 1bdd09e7e019ac6d8fdc1b009bdec818b9183e76 - it was
not indended to be ever merged to release/2.4, but only as a refactoring
commit intended to go to master.
Gert Doering [Fri, 2 Apr 2021 17:34:14 +0000 (19:34 +0200)]
Fix potential NULL ptr crash if compiled with DMALLOC
In the unlikely case that we are compiled with -DDMALLOC *and*
malloc() returns NULL, there is an uncaught memset() which would
crash then. Remove the memset(), as the right the next operation
after check_malloc_return() is a mempcy() which will overwrite
the whole memory block anyway.
Trac: #586
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20210402173414.14216-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21981.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit e2acfad40c0d79ce7fd431c380d7466d383bcefa)
Greg Cox [Mon, 1 Feb 2021 07:09:49 +0000 (07:09 +0000)]
Explain structver usage in sample defer plugin.
sample-plugins/defer/simple.c uses OPENVPN_PLUGINv3_STRUCTVER settings
that may not be obvious to a new author. Add a comment to reduce
possible confusion. Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1612163389-16421-1-git-send-email-gcox@mozilla.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21540.html
Greg Cox [Wed, 27 Jan 2021 20:21:49 +0000 (20:21 +0000)]
More explicit versioning compatibility in sample-plugins/defer/simple.c
While not required, adding openvpn_plugin_min_version_required_v1 helps
by making an example for others to copy, and helps to explicitly call
attention to the difference between the API version number and the
struct version number in v3 calls. Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1611778909-20630-2-git-send-email-gcox@mozilla.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21508.html
Greg Cox [Wed, 27 Jan 2021 20:21:48 +0000 (20:21 +0000)]
Update openvpn_plugin_func_v2 to _v3 in sample-plugins/defer/simple.c
This isn't strictly required, but it modernizes the functions used.
This change makes _open the same parameter form as _func (for better
parallelism in function writing) and includes a check for the correct
struct version, as recommended by openvpn-plugin.h Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1611778909-20630-1-git-send-email-gcox@mozilla.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21507.html
Greg Cox [Sun, 24 Jan 2021 23:46:13 +0000 (23:46 +0000)]
Documentation fixes around openvpn_plugin_func_v3 in openvpn-plugin.h.in
The comments refered to parameters found in openvpn_plugin_func_v2 but not
in v3 Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <1611531973-443-1-git-send-email-gcox@mozilla.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21481.html
Gert Doering [Thu, 21 Jan 2021 17:25:36 +0000 (18:25 +0100)]
clean up / rewrite sample-plugins/defer/simple.c
If we ship something that we consider a form of documentation
"this is how to write an OpenVPN plugin" it should meet our standards
for secure and modern code. This plugin did neither.
- get rid of system() calls, especially those that enabled a
remote-root exploit if this code was used "as is"
- change logging from printf() to OpenVPN's plugin_log()
- this requires changing to openvpn_plugin_open_v3() to get
to the function pointers
- change wacky "background and sleep in the shell call" to the
double-fork/waitpid model we use in plugins/auth-pam
(copy-paste code reuse)
- OpenVPN 2.5 and later react badly to OPENVPN_PLUGIN_FUNC_ERROR
returns to OPENVPN_PLUGIN_ENABLE_PF calls (SIGSEGV crash), so
always return SUCCESS. Only hook ENABLE_PF if that functionality
is actually requested ("setenv test_packet_filter NN").
- change deeply-nested functions auth_user_pass_verify() and
tls_final() to use early-return style
- actually make defered PF setup *work* with recent OpenVPNs
(pre-creating temp files broke this, so unlink() the pre-created
file in the ENABLE_PF hook, and re-create asyncronously later)
- add lots of comments explaining why we do things this way
Security issue reported by "oxr463" on HackerOne.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20210121172536.32500-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21466.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 452e016cba977cb1c109e74977029b9c0de33de2)
Gert Doering [Sun, 6 Dec 2020 12:57:11 +0000 (13:57 +0100)]
Fix line number reporting on config file errors after <inline> segments
<inline> segments neglected to increment the "current line number
in config file" variable (line_num), so after the first <inline>,
errors reported have the wrong line number.
Fix by introducing an extra argument to read_inline_file() function:
"so many lines in the inline block", and changing the return values of
the "check_inline*()" functions to "int", changing this from "false/true"
to "0 = no inline, 1...N = inline with <N> lines".
On calling add_options() this is implicitly converted back to bool.
v2: use int return value, not extra call-by-reference parameter
Trac: #1325 Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20201206125711.12071-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21334.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a686f7e29af012783371f401f394ac1e62e5b75f)
Arne Schwabe [Wed, 2 Dec 2020 11:59:28 +0000 (12:59 +0100)]
Remove auth_user_pass.wait_for_push variable
This variable was first introduce in earlier attempt to fix the
auth-token problems with auth-nocache before user_password and
auth_token were split into two variables. The idea of the variable it
is being set if --pull is in use. However the variable was not always
set correctly, especially if username/password are queried after an
expired auth-token. Instead using that variable use session->opt->pull
directly.
Patch V2: rename delayed_auth_pass_purge to ssl_clean_user_pass to give
a more fitting name since this function is not only used in
the delayed code path and also the new name aligns with
ssl_clean_auth_token. Also fix a leftover wait_for_push
in that function
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20201202115928.16615-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21297.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit dfd624b52bce7ddd0eeaab516df9848e432f3242)
Arne Schwabe [Mon, 30 Nov 2020 12:39:28 +0000 (13:39 +0100)]
Fix auth-token not being updated if auth-nocache is set
This fixes the auth-token not being updated if auth-nocache is set. Our
set_auth_token method ensures that the auth-token always has a username
but is a little bit too strict in the check.
Also add doxygen documentation and remove null checks. We use this function
only with non-null pointers and it makes it a bit nicer to read.
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20201130123928.21837-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21291.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit fb789947ab1eba3e68fb8e4b3551d095a53962bd)
Arne Schwabe [Sun, 30 Aug 2020 14:07:36 +0000 (16:07 +0200)]
Also announce IV_CIPHERS as client in OpenVPN 2.4
This improves compatbility to a OpenVPN 2.5 server and
allows to negotiate a different cipher than AES-128/256-GCM
without abusing the poor man's NCP support with --cipher.
We keep the IV_NCP=2 flag logic as broken as it is since 2.5 server
ignore the flag if IV_CIPHERS is set and this might break existing
2.4 setups.
Server support for IV_CIPHERS is not added since it would be quite
intrusive and users should rather upgrade to 2.5 on the server
if they want the full benefits.
Arne Schwabe [Sun, 30 Aug 2020 14:07:35 +0000 (16:07 +0200)]
Normalise ncp-ciphers option and restrict it to 127 bytes
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.
Gert Doering [Fri, 2 Oct 2020 17:57:36 +0000 (19:57 +0200)]
Fix redirecting of IPv4 default gateway if connecting over IPv6.
Commit aa34684972eb0 fixed a long-standing bug in setting the
"route-list" flag RTSA_REMOTE_HOST for IPv4 ("we have a well-defined
remote_host == VPN server IP address") even if connecting over IPv6.
Unfortunately the logic in redirect_default_route_to_vpn() was also
wrong, and refused cooperation if that flag is not set, triggering
the message
"NOTE: unable to redirect IPv4 default gateway -- Cannot
obtain current remote host address"
Correct operation: if RTSA_REMOTE_HOST is not set, or remote_host
is IPV4_INVALID_ADDR (= 255.255.255.255), do not try to install a
host route for continued connectivity to the VPN server - which is
not needed when connecting over IPv6. But the actual *routes*
(/0 or 2 x /1) can be installed just fine.
There is a second bug here, which hits if there is no IPv4 gateway
at all. In that case, the same function triggers the message
"NOTE: unable to redirect IPv4 default gateway -- Cannot
read current default gateway from system"
This is caused by using "IPV4_INVALID_ADDR" as a flag for "do we
know the remote_host?" - which worked before, but after the commit
referenced above, the "remote_host" field is not well-defined unless
RTSA_REMOTE_HOST is set. So, change the condition to check that.
Reported-By: François Kooman <fkooman@tuxed.net> Reported-By: Thomas Schäfer <tschaefer@t-online.de>
Trac: #1332
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <a@unstable.cc>
Message-Id: <20201002175736.82609-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21152.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 23e11e591347080efa3b933beca7f620dd059d5c)
(cherry picked from commit 7b4f53095c761bde8c6b39cf645cade4c1c0c5d4)
It's a long while since the bundled lz4 library has received an update.
It pulls in a lot of various fixes and enhancements, some of the changes
fixes compiler warnings and hardens the code a bit too.
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20201001154658.9798-1-davids@openvpn.net>
URL: https://www.mail-archive.com/search?l=mid&q=20201001154658.9798-1-davids@openvpn.net Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 0f44a9080530df70410106c244e9efc7f2d8a802)
If remote server has been resolved to multiple addresses, at
least one connection attempt has been made and connection to
the last address was skipped by management - resolved earlier
link socket addrinfo objects will not be cleared neither on
instance close nor in the next connection entry loop.
This causes fatal error assert:
Gert Doering [Wed, 9 Sep 2020 12:22:23 +0000 (14:22 +0200)]
socks.c: fix alen for DOMAIN type addresses, bump up buffer sizes
When a SOCKS5 server sends back a reply, it encodes an "address",
which can be IPv4 (4 bytes), IPv6 (16 bytes) or "a domain name",
which has a lenght (1 byte) and "a string of length <length>" - so
when copying bytes, we need to hande "length +1" bytes.
Our code totally doesn't use this variant of addresses on reception,
but since this has been pointed out by "tpw_rules" in Trac, fix it,
so if/when someone works on this again, the foundation is correct.
While at it, increase buffer size used for sending to handle domain
names longer than 122 characters (length was already checked, so a
longer name would not overflow but just "not work").
v2: increase buf[] len in recv_socks_reply() from 22 to 270 so it
is large enough to actually copy a domain name
v3: increase buf[] len in establish_socks_proxy_passthru() from 128 to
270, to handle long domain names in queries
Reported-By: tpw_rules in Trac
Trac: #848
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <a@unstable.cc>
Message-Id: <20200909122223.9222-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20928.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit eebeaa02367d247fc2549df3edf8e598c58c3572)
Gert Doering [Sun, 13 Sep 2020 14:56:21 +0000 (16:56 +0200)]
Fix --show-gateway for IPv6 on NetBSD/i386.
Our ROUNDUP() macro to achieve the required system-specific alignment
for data structures sent to the routing socket was wrong for NetBSD -
unlike OpenBSD/FreeBSD, NetBSD is not using "long" (32/64 bit depending
on OS architecture), and not "uint32_t" either (32/32) like MacOS, but
uint64_t.
So our use of "long" always worked on NetBSD/amd64 and stopped working
on NetBSD/i386 when this was changed on the OS side...
NetBSD conveniently exports a RT_ROUNDUP() macro from <net/route.h> - use
that, and avoid trying to second-guess OS requirements.
While at it, add M_ERRNO to ominous "GDG6: problem writing to routing
socket"
error message to differenciate between "EINVAL" and other errors.
Trac: #734
Signed-off-by: Gert Doering <gert@greenie.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200913145621.12125-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20983.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 37aab49b083a9e385970e3ab2dd727ea1a95ff35)
Gert Doering [Wed, 9 Sep 2020 10:48:37 +0000 (12:48 +0200)]
Handle NULL returns from calloc() in sample plugins.
This is basic housekeeping, adding NULL checks to context initialization
of the sample plugin collection which are missing it. Realistically,
this can never happen, but since these are supposed to be "good examples",
not checking calloc() return isn't one.
Trac: #587
Reported-By: Dogbert (in Trac) Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20200909104837.6123-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20922.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a61c08a2c80d95dcc2bc30ddcb9a54a462e565ed)
Gert Doering [Wed, 9 Sep 2020 12:29:26 +0000 (14:29 +0200)]
Fix description of --client-disconnect calling convention in manpage.
The man page claimed that --client-disconnect "is passed the same
pathname as the corresponding --client-connect command", which is
not what the code does. Fix.
Reported-By: hvenev in Trac
Trac: #884
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <a@unstable.cc>
Message-Id: <20200909122926.9523-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20929.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 50c7700da09a1f83474e18f8709d59dbc4b509e2)
Gert Doering [Fri, 11 Sep 2020 08:59:07 +0000 (10:59 +0200)]
Fix handling of 'route remote_host' for IPv6 transport case.
If we connect to a VPN server over IPv6, and the config has a
route like this:
route remote_host default net_gateway
OpenVPN would try to install a route to "255.255.255.255", which
is obviously bogus.
The bug is twofold: init_route_list() should not set RTSA_REMOTE_HOST
for an "IPV4_INVALID_ADDR" remote_host (wrong condition, this is not
a pointer but an integer, and "invalid" is "-1" numerically here),
and init_route() must not ignore "status = false" returns from
get_special_addr().
I have just added the "if (!status)" check, not done refactoring for
init_route() to see whether I could make it "more pretty".
Trac: #1247
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200911085907.26004-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20958.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit aa34684972eb01bfa5c355d1c8a8a9d384bf0175)
Gert Doering [Tue, 8 Sep 2020 10:51:30 +0000 (12:51 +0200)]
Fix error detection / abort in --inetd corner case.
Calling "openvpn --inetd" from the CLI (= no socket on stdin) will
lead to endless looping in the accept(4) loop.
Instead of cluttering that function further, detect failure to call
getsockame() in phase2_inetd() already, and trigger a M_FATAL abort
on "errno == ENOTSOCK" ("The argument s is a file, not a socket").
While at it, uncrustify the --bind-dev code (whitespace only).
Trac: #350
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200908105130.24171-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20897.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a09a2fadbadb5dc435f6fccc581163e1f637f43f)
Gert Doering [Wed, 9 Sep 2020 06:41:56 +0000 (08:41 +0200)]
Document that --push-remove is generally more suitable than --push-reset
It's a long-standing and well-known problem that --push-reset removes
"critical" options from the push list (like "topology subnet") which
will then lead to non-working client configs. This can not be
reasonably fixed, because the list of "critical" options depends on
overall server config.
So just document the fact, and point people towards --push-remove as
a more selective tool.
Trac: #29
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org> Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20200908111511.9271-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20899.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 5fd66510dfdef628fa95f156c5f9d80af9ae1531)
Gert Doering [Thu, 13 Aug 2020 10:13:01 +0000 (12:13 +0200)]
Fix stack overflow in OpenSolaris NEXTADDR()
Commit 5fde831c5807 fixed NEXTADDR() for all *BSDs and MacOS.
OpenSolaris has to use a slightly different macro due to lack of
sockaddr->sa_len - but it has the same problem, first rounding up,
then memmove()'ing. Switch order.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200813101301.12720-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20731.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7e65483d1227adfb855844467e4d30894ffc355d)
In most of situations admin of OpenVPN server needs to know which
particular certificate is used by client.
In the case when certificate is valid, environment variable can be
used for that but once it is revoked, no user scripts are invoked
so there is no way to get serial number, only subject is logged.
Let's log certificate serial in case it is revoked and additionally
log certificate depth & subject in crl-verify "dir" mode for better
consistency with crl file (non-dir) mode.
v2: log if serial is not availble, require it in crl-verify dir mode
Signed-off-by: Vladislav Grishenko <themiron@yandex-team.ru> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200805102333.3109-1-themiron@yandex-team.ru>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20642.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 992e9cec40539a155afa9eae10502aa62f617965)
Jeremy Evans [Wed, 20 May 2020 18:34:04 +0000 (11:34 -0700)]
Switch assertion failure to returning false
This assertion failure can be hit in production, which causes the
openvpn server process to stop and all clients to be disconnected.
Bug #1270 has been filed for this issue on Trac by another user
who has experienced the issue, and this patch attempts to address it.
Tracing callers, it appears that some callers check ks->authenticated
before calling, but others do not. It may be possible to add the check
for the callers that do not check, but this seems to be a simpler
solution.
To give some background, we hit this assertion failure, with the
following log output:
```
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 PUSH: Received
control message: 'PUSH_REQUEST'
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 SENT CONTROL
[username]: 'PUSH_REPLY,redirect-gateway
def1,comp-lzo,persist-key,persist-tun,route-gateway 10.28.47.1,topology
subnet,ping 10,ping-restart 120,ifconfig 10.28.47.38 255.255.255.0,peer-id
89' (status=1)
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 Assertion failed at
/path/to/openvpn-2.4.7/src/openvpn/ssl.c:1944 (ks->authenticated)
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 Exiting due to fatal
error
Tue May 19 15:57:05 2020 username/73.135.141.11:1194 Closing TUN/TAP
interface
```
using the following OpenVPN server configuration:
```
port 1194
proto udp
dev-type tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
topology subnet
push "redirect-gateway def1"
push "comp-lzo"
push "persist-key"
push "persist-tun"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
cd /home/openvpn/server
chroot /var/empty
daemon
verb 3
crl-verify crl.pem
tls-auth ta.key 0
cipher AES-256-CBC
tls-version-min 1.2
tls-cipher ECDHE-RSA-AES256-GCM-SHA384
ncp-disable
mute-replay-warnings
script-security 3
auth-user-pass-verify "ldap-auth/ldap-auth" via-env
auth-user-pass-optional
```
The failed assertion is inside the function
`tls_session_generate_data_channel_keys`, which is called 3 other places
in `ssl.c.`:
* `key_method_2_write`: checks for `ks->authenticated` before calling
* `key_method_2_read`: appears to run in client mode but not in server
mode
* `tls_session_update_crypto_params`: runs in server mode and does not
check before calling
That leads me to believe the problem caller is
`tls_session_update_crypto_params`. There.s three callers of
`tls_session_update_crypto_params`:.
* `incoming_push_message` (`push.c`): Probably this caller, since the
server pushes configuration to clients, and the log shows the
assertion failure right after the push reply.
* `multi_process_file_closed` (`multi.c`): Not this caller. NCP is
disabled in config, and async push was not enabled when compiling.
* `do_deferred_options` (`init.c`): Not this caller. The server
configuration doesn't pull.
Changing the assertion to returning false appears to be the simplest
fix. Another approach would be changing callers to check
`ks->authenticated` before calling, either
`tls_session_update_crypto_params` or `incoming_push_message`.
Signed-off-by: Jeremy Evans <code@jeremyevans.net> Acked-by: Steffan Karger <steffan.karger@foxcrypto.com>
Message-Id: <20200520183404.54822-1-code@jeremyevans.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19914.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 984bd1e1601e4b9562dbc88b02a8db60b884286f)
Selva Nair [Fri, 21 Feb 2020 03:00:28 +0000 (22:00 -0500)]
Persist management-query-remote and proxy prompts
Currently this prompt is only output once, not re-written to the
management interface when the management client connects. It is thus
not seen by a client that connects after the prompt is output or one that
disconnects and reconnects. This leads to a deadlock: the daemon waiting
for the "remote" command from the client, the latter not aware of it.
Resolve by adding the ">REMOTE" and ">PROXY" prompt to
man.persist.special_state_msg as done for other persisted prompts such
as ">PASSWORD"
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1582254028-7763-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19497.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 93ba6ccddafcc87f336f50dadde144ea4f6178ad)
Parse static challenge response in auth-pam plugin
If static challenge is in use, the password passed to the plugin by openvpn
is of the form "SCRV1:base64-pass:base64-response". Parse this string to
separate it into password and response and use them to respond to queries
in the pam conversation function.
On the plugin parameters line the substitution keyword for the static
challenge response is "OTP". For example, for pam config named "test" that
prompts for "user", "password" and "pin", use
plugin openvpn-auth-pam.so "test user USERNAME password PASSWORD pin OTP"
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1532486093-24793-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17307.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7369d01bf360bcfa02f26c05b86dde5496d120f6)
Arne Schwabe [Tue, 21 Apr 2020 10:11:22 +0000 (12:11 +0200)]
Fix tls_ctx_client/server_new leaving error on OpenSSL error stack
In the corner case that the global OpenSSL has an invalid command like
MinProtocol = TLSv1.0
(due to OpenSSL's idiosyncrasies MinProtocol = TLSv1 would be correct)
the SSL_ctx_new function leaves the errors for parsing the config file
on the stack.
OpenSSL: error:14187180:SSL routines:ssl_do_config:bad value
Since the later functions, especially the one of loading the
certificates expected a clean error this error got reported at the
wrong place.
Print the warnings with crypto_msg when we detect that we are in this
situation (this also clears the stack).
Lev Stipakov [Wed, 15 Apr 2020 07:30:17 +0000 (10:30 +0300)]
Fix illegal client float (CVE-2020-11810)
There is a time frame between allocating peer-id and initializing data
channel key (which is performed on receiving push request or on async
push-reply) in which the existing peer-id float checks do not work right.
If a "rogue" data channel packet arrives during that time frame from
another address and with same peer-id, this would cause client to float
to that new address. This is because:
- tls_pre_decrypt() sets packet length to zero if
data channel key has not been initialized, which leads to
- openvpn_decrypt() returns true if packet length is zero,
which leads to
- process_incoming_link_part1() returns true, which
calls multi_process_float(), which commits float
Note that problem doesn't happen when data channel key is initialized,
since in this case openvpn_decrypt() returns false.
The net effect of this behaviour is that the VPN session for the
"victim client" is broken. Since the "attacker client" does not have
suitable keys, it can not inject or steal VPN traffic from the other
session. The time window is small and it can not be used to attack
a specific client's session, unless some other way is found to make it
disconnect and reconnect first.
CVE-2020-11810 has been assigned to acknowledge this risk.
Fix illegal float by adding buffer length check ("is this packet still
considered valid") before calling multi_process_float().
Trac: #1272
CVE: 2020-11810
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Antonio Quartulli <antonio@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200415073017.22839-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19720.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 37bc691e7d26ea4eb61a8a434ebd7a9ae76225ab)
Lev Stipakov [Fri, 13 Mar 2020 16:59:13 +0000 (18:59 +0200)]
Fix broken async push with NCP is used
With NCP and deferred auth, we perform cipher negotiation and generate
data channel keys on incoming push request, assuming that auth succeeded.
With async push, when auth succeeds in between push requests, we send
push reply immediately.
The code which generates data channel keys is only called on handling
incoming push requests (incoming_push_message). It might not be called
with NCP, deferred auth and async push, because on incoming push request,
auth might not be complete yet. When auth is complete in between push
requests, push reply is sent and it is assumed that connection is
established. However, since data channel keys are not generated on the
server side, connection doesn't work.
Fix by adding a call to generate data channel keys when async push is
triggered.
Also, all the "session->key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized"
checks have been moved into tls_session_update_crypto_params(), which
is just reducing duplicate code, no actual code change (*all* callers
had this pre-check).
Trac: #1259
Reported-by: smaxfield@duosecurity.com Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20200313165913.12682-1-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19553.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 3b06b57d9f1d972ec16f0893d06697439c1bb1fe)
Selva Nair [Wed, 12 Feb 2020 15:06:07 +0000 (10:06 -0500)]
Allow unicode search string in --cryptoapicert option
Currently when the certificate is specified as "SUBJ:foo", the
string foo is assumed to be ascii. Change that and interpret
it as utf-8, convert to a wide string, and flag it as unicode
in CertFindCertifcateInStore().
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581519967-16950-2-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19405.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit aa6affe6df811db11577847366a569def0a3e314)
Selva Nair [Wed, 12 Feb 2020 15:06:06 +0000 (10:06 -0500)]
Skip expired certificates in Windows certificate store
Have the cryptoapicert option find the first matching certificate
in store that is valid at the present time. Currently the first
found item, even if expired, is returned.
This makes it possible to update certifiates in store without having
to delete old ones. As a side effect, if only expired certificates are
found, the connection fails.
Also remove some unnecessary casts.
Tested on Windows 10.
Trac #966
v4: Handle the case when an unknown certificate specification is passed
to find_certificate_in_store().
Note: Warnings printed from find_certificate_in_store() could show up
multiple times as its called for each certificate store. This could
be improved in a future patch.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1581519967-16950-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19404.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 7b63984d51a2582ba2d406e46a7debb11df7f478)
Selva Nair [Thu, 20 Feb 2020 01:56:43 +0000 (20:56 -0500)]
Fix possible access of uninitialized pipe handles
Compile time warning for openvpnserv.exe
interactive.c: In function ‘RunOpenvpn’:
interactive.c:160:27: warning: ‘svc_pipe’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
When RunOpenvpn exits early due to errors, uninitialized svc_pipe and
ovpn_pipe vars could get passed to CloseHandleEx(). Fix by initializing
to NULL.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1582163803-3342-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19480.html Signed-off-by: David Sommerseth <davids@openvpn.net>
(cherry picked from commit 32723d29b2775d63d3fe329d017e7a08e0cdcb72)
Arne Schwabe [Sat, 28 Mar 2020 04:08:58 +0000 (05:08 +0100)]
Fix OpenSSL 1.1.1 not using auto elliptic curve selection
Commit 8a01147ff attempted to avoid calling the deprecated/noop
operation SSL_CTX_set_ecdh_auto by surrounding it with #ifdef.
Unfortunately, that change also made the return; that would exit
the function no longer being compiled when using OpenSSL 1.1.0+.
As consequence OpenVPN with OpenSSL 1.1.0+ would always set
secp384r1 as ecdh curve unless otherwise specified by ecdh
This patch restores the correct/previous behaviour. Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20200328040858.16505-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19630.html
OpenSSL: Fix --crl-verify not loading multiple CRLs in one file
Lack of this led people accepting multiple CAs to use capath,
which already supports multiple CRLs. But capath mode itself
is somewhat ugly: you have to create new file/symlink every time
CRL is updated, and there's no good way to clean them up without
restarting OpenVPN, since any gap in the sequence would cause it
to lose sync (see trac 623).
mbedtls crypto backend already loads multiple CRLs as is, so
it doesn't need this fix.
The patch also includes some logging changes which I think are useful.
Trac: #623
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200407174436.238933-1-wgh@torlan.ru>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19710.html
Selva Nair [Mon, 30 Mar 2020 18:05:27 +0000 (14:05 -0400)]
When auth-user-pass file has no password query the management interface
(if available).
When only username is found in the file, redirect the auth-user-pass
query to the management interface if management-query-passwords is
enabled. Otherwise the user is prompted on console, if available,
as before.
This changes the behaviour for those who run from the command line,
with --management-query-passwords, but still expect the prompt
on the console.
Note that the management interface will prompt for both username and
password ignoring the username read from the file. As most GUIs can
save the the username, this is a one-time inconvenience.
Currently, the password is queried on the console (or systemd)
in such cases. This is not sensible when console is not available
(windows GUI, tunnelblick etc.) or when the log is redirected
to a file on Windows (for some reason prompt goes to the log file).
Trac # 757
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1585591527-23734-2-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19655.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 57578310992d1fbe8eff97049087c5308089acb5)
Arne Schwabe [Thu, 2 Apr 2020 10:38:21 +0000 (12:38 +0200)]
Fix OpenSSL error stack handling of tls_ctx_add_extra_certs
Commit f67efa94 exposed that tls_ctx_add_extra_certs will always leave
an error of PEM_R_NO_START_LINE on the stack that will printed the next
time that the error is printed.
Fix this by discarding this error. Also clean up the logic to report
real error on other errors and also the no start line error if no
certificate can be found at all and it is required (--extra-certs
config option)
Patch V2: fix optional flag was flipped betwen --cert and --extra-certs
Patch V3: Make logic more easy to follow, no functional changes
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20200402103821.10347-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19685.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 3608d890583549dbdbefc40ed41bf617fa518aa1)
Arne Schwabe [Wed, 1 Apr 2020 12:40:19 +0000 (14:40 +0200)]
Fetch OpenSSL versions via source/old links
New versions are already available as source/old but old version at
some point disappear from the normal download path. Use the source/old
path for all OpenSSL versions to avoid this problem.
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200401124019.10529-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/search?l=mid&q=20200401124019.10529-1-arne@rfc2549.org Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 3e0e169254427c4fdcd667e23b110fb939f9fbde)
Tom van Leeuwen [Tue, 31 Mar 2020 07:14:37 +0000 (09:14 +0200)]
mbedTLS: Make sure TLS session survives move
When a client disconnects from a server compiled with mbedTLS, the server
cannot process the PUSH_REQUEST from a new connection with the same client
IP and port number. This is the case when the client binds to a static
port.
This behavior is initiated by move_session(), which copies the content of
the tls_session to a new session and re-initializes the old session once the
new session is authenticated.
This tls_session contains, among other things, an mbedtls_ssl_config and
bio_ctx structure. However, the mbedtls context has internal pointers to
the mbedtls_ssl_config and bio_ctx. When the session is moved, these internal
pointers point to the reinitialized session and as a result all received
packets that are stored in the bio_ctx of the moved session can never be
read by the mbedtls session. The PUSH_REQUEST is therefore never seen by the
server.
Since there is no public method to update these internal pointers, this
patch dynamically allocates the mbedtls_ssl_config and bio_ctx and stores
the pointers to those structures in the tls_session instead.
Trac #880
Signed-off-by: Tom van Leeuwen <tom.van.leeuwen@technolution.eu> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200331071437.12708-1-tom.van.leeuwen@technolution.nl>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19661.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit a59e0754afd37a606d96cf24cea771ace3467289)
WGH [Wed, 25 Mar 2020 12:26:24 +0000 (15:26 +0300)]
docs: Add reference to X509_LOOKUP_hash_dir(3)
This is probably the best description of the rather confusing
capath directory structure OpenSSL manual has to offer. Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20200325122624.3142017-1-wgh@torlan.ru>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19615.html
Santtu Lakkala [Mon, 21 Oct 2019 11:35:06 +0000 (14:35 +0300)]
Fix OpenSSL private key passphrase notices
Clear error stack on successful certificate loading in
tls_ctx_load_cert_file_and_copy() and handle errors also for
PEM_read_bio_PrivateKey() call in tls_ctx_load_priv_file().
Due to certificate loading possibly leaking non-fatal errors on OpenSSL
error stack, and some slight oversights in error handling, the
>PASSWORD:Verification Failed: 'Private Key'
line was never produced on the management channel for PEM formatted keys.
Selva Nair [Wed, 19 Feb 2020 01:54:21 +0000 (20:54 -0500)]
Swap the order of checks for validating interactive service user
Check the config file location and command line options first
and membership in OpenVPNAdministrators group after that as
the latter could be a slow process for active directory users.
When connection to domain controllers is poor or unavailable, checking
the group membership is slow and causes timeouts in the GUI (Trac
1051). However, in cases where the config is in the global directory,
no group membership check should be required. The re-ordering here
avoids the redundant check in such cases.
In addition to this, its also proposed to improve the timeout handling
in the GUI, but this change is still useful as it should completely
eliminate the timeout issue for many users.
v3: Do not send error message to the client pipe from ValidateOptions().
Instead save the error and send it on only if user authorization also
fails. The error buffer size is increased to 512 wide chars as these
messages could get long in some cases and may get truncated otherwise.
Also see: https://github.com/OpenVPN/openvpn-gui/issues/332
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <1582077261-9467-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19474.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Lev Stipakov [Wed, 30 Oct 2019 12:44:59 +0000 (14:44 +0200)]
Fix broken fragmentation logic when using NCP
This is the 2.4 backport of master patch (commit d22ba6b).
NCP negotiation replaces worst case crypto overhead
with actual one in data channel frame. That frame
params are used by mssfix. Fragment frame still contains
worst case overhead.
Without this patch, fragmentation logic incorrectly uses
max crypto overhead when calculating packet size. It exceeds
fragment size and openvpn peforms fragmentation:
> sudo tcpdump port 1194
13:59:06.956394 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 652
13:59:06.956489 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 648
This patch fixes fragmentation calculation by
setting actual crypto overhead, and no unnecessary
fragmentation is performed:
> sudo tcpdump port 1194
13:58:08.685915 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 1272
13:58:08.686007 IP server.fi.openvpn > nat2.panoulu.net.openvpn: UDP,
length 1272
Trac #1140
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1572439499-16276-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18975.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
mbedtls: fix segfault by calling mbedtls_cipher_free() in cipher_ctx_free()
Commit ("openssl: Fix compilation without deprecated OpenSSL 1.1 APIs")
has removed the cipher_ctx_cleanup() API, as it is not anymore required
to be a distinct call. However, while doing so it also touched the
mbedtls backend in a wrong way causing a systematic segfault upon
connection.
Basically mbedtls_cipher_free(ctx) was moved from the defunct
cipher_ctx_cleanup()
to md_ctx_free(), while it was supposed to go into cipher_ctx_free().
This was clearly wrong as also the type of the ctx variable was not
correct anymore.
Fix this mistake by actually moving mbedtls_cipher_free(ctx) to
cipher_ctx_free().
Signed-off-by: Antonio Quartulli <a@unstable.cc> Acked-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190816204945.7937-1-a@unstable.cc>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18781.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 2a74fc3f66bb9f73fc957719d187256922ca003f)
openssl: Fix compilation without deprecated OpenSSL 1.1 APIs
EVP_CIPHER_CTX_init and _cleanup were deprecated in 1.1 and both were
replaced with _reset.
EVP_CIPHER_CTX_free in OpenSSL 1.1 replaces the cleanup/free combo of
earlier OpenSSL version. And OpenSSL 1.0.2 already calls cleanup as part
of _free.
Therefore we can remove the _cleanup calls and use the OpenSSL 1.1. API
everywhere.
Also removed initialisation with OpenSSL 1.1 as it is no longer
needed and causes compilation errors when disabling deprecated APIs.
Same with SSL_CTX_set_ecdh_auto as it got removed.
Patch V3: Use EVP_CIPHER_CTX_reset instead of init/cleanup
Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Rosen Penev <rosenp@gmail.com> Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20190724152934.9884-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18700.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 8a01147ff77e4ae2e377744b89fbe4b6841b2bb0)
Gert Doering [Wed, 9 Oct 2019 09:52:00 +0000 (11:52 +0200)]
Fix IPv6 routes on tap interfaces on OpenSolaris/OpenIndiana
The "route add" code always used "metric 0" on OpenSolaris, because
(on tun interfaces) it was required to make the route work on
"non-ethernet" interfaces (connected, no NDP).
This breaks routes via tap interfaces on recent Solaris versions
(tested on OpenIndiana 2019) - there, routes only work if metric
is != 0 (or just not set). Otherwise it tries to map the gateway
address to a local address and fails.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191009095200.9337-2-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18906.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 01b3a48c29df6dc4bade3d8fb7903346a3f77887)
Gert Doering [Sun, 20 Oct 2019 15:00:39 +0000 (17:00 +0200)]
Force combinationation of --socks-proxy and --proto UDP to use IPv4.
Our current socks.c code does not handle IPv6 + UDP mode (socket
negotiated with server is IPv4-only, addresses passed in the
packets are IPv4-only). If this combination is specified, print
an explanatory message and force IPv4-only.
While at it, extend socks.c code to print address+port of auxiliary
UDP connection to SOCKS server (helps debugging).
Trac: #1221
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20191020150039.21516-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18952.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 57623b4e40e68de983b9dfd82914dadcbe096f7b)
For PSS padding, CNG requires the digest to be signed
and the digest algorithm in use, which are not accessible
via the rsa_sign and rsa_priv_enc callbacks of OpenSSL.
This patch uses the EVP_KEY interface to hook to
evp_pkey_sign callback if OpenSSL version is > 1.1.0.
Mapping of OpenSSL hash algorithm types to CNG is moved
to a function for code-reuse.
To test, both the server and client should be built with
OpenSSL 1.1.1 and use TLS version >= 1.2
Tested on Windows 7 client against a Linux server.
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1564346061-5683-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18715.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Matthias Andree [Sun, 18 Aug 2019 11:18:11 +0000 (13:18 +0200)]
Fix regression, reinstate LibreSSL support.
OpenVPN 2.4.6 could be compiled with LibreSSL, 2.4.7 cannot. This was
broken
since 9de7fe0a "Add support for tls-ciphersuites for TLS 1.3".
This patch avoids using TLS 1.3 directly, be it that OpenSSL was compiled
without TLS 1.3 support, or LibreSSL was used.
This patch was based on an OpenBSD patch by
Jeremie Courreges-Anglas <jca@openbsd.org>, see
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-s
rc_openvpn_ssl_openssl_c
but was revised to be more obvious and check actual feature macros,
do not rely on current LibreSSL implementation details alone.
Franco Fichtner reports that OPNsense has been a long-time user
of LibreSSL without reported breakage, see also:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238382#c10
Signed-off-by: Matthias Andree <matthias.andree@gmx.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190818111811.8853-2-matthias.andree@gmx.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18790.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering [Thu, 15 Aug 2019 15:53:19 +0000 (17:53 +0200)]
Increase listen() backlog queue to 32
For reasons historically unknown, OpenVPN sets the listen() backlog
queue to "1", which signals the kernel "while there is one TCP connect
waiting for OpenVPN to handle it, refuse all others" - which, on
restarting a busy TCP server, will create connection issues.
The exact "best" value of the backlog queue is subject of discussion,
but for a server that is not extremely busy with many connections
coming in in parallel, there is no real difference between "10" or "500",
as long as it's "more than 1".
Found and debugged by "mjo" in Trac.
Trac: #1208
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net> Acked-by: David Sommerseth <davids@openvpn.net>
Message-Id: <20190815155319.28249-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18758.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 6d8380c78bf77766454b93b49ab2ebf713b0be48)
Hilko Bengen [Mon, 18 Feb 2019 15:31:28 +0000 (16:31 +0100)]
Do not set pkcs11-helper 'safe fork mode'
From the pkcs11-helper API documentation about pkcs11h_setForkMode():
> This funciton is releavant if PKCS11H_FEATURE_MASK_THREADING is
> set. If safe mode is on, the child process can use the loaded
> PKCS#11 providers but it cannot use fork(), while it is in one of
> the hooks functions, since locked mutexes cannot be released.
As far as I can tell, pkcs11-helper functionality is not used in a
child process that is created after initialization. Even if OpenVPN is
turned into a daemon, the pkcs11-helper library is only initialized
after calling possibly_become_daemon(), i.e. in the child process. All
other uses of fork() are immediately followed by an exec()
This simple change fixes the symptoms described in both
<https://community.openvpn.net/openvpn/ticket/538> (hang on password
prompt when systemd support is enabled) and
<https://community.openvpn.net/openvpn/ticket/1157> (hang on
initialization with newer versions of pkcs11-helper).
I have successfully tested that this makes the described symptoms go
away. For this, I used a YubiKey NEO on Debian/stable, a rebuild of
OpenVPN 2.4.6 and two versions of libpkcs11-helper:
- libpkcs11-helper 1.21-1 from Debian/stretch
- a backport of libpkcs11-helper 1.25-1 from Debian/buster Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20190218153129.3818-1-bengen@hilluzination.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18218.html
Gert Doering [Fri, 5 Jul 2019 13:00:01 +0000 (15:00 +0200)]
repair windows builds (2.4)
commit 0c1cc8d65539f removed "DWORD len;" from service_enable_dhcp(),
but that variable is far from "unused" - breaking compilation.
The problem here was that it's a larger "cleanup compiler warnings"
patch which was fully correct for master, but this particular function
looks different in release/2.4 because the whole iservice call
refactoring patch isn't in release/2.4 - so master does not need the
DWORD len, but release/2.4 does.
More care needed with "warning cleanup"...
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190705130001.30741-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18652.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Arne Schwabe [Fri, 5 Jul 2019 11:42:43 +0000 (13:42 +0200)]
Remove -no-cpp-precomp flag from Darwin builds
GCC 9 no longer accepts this flag and trying to find out what it does do
leads to an article
"-no-cpp-precomp: the compiler flag that time forgot"
that also no longer on the Internet. And most other things are
PRs/commits from over ten years ago that remove the flag since it
is no longer needed. Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190705114243.9481-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18650.html
Michal Soltys [Tue, 9 Apr 2019 14:34:38 +0000 (16:34 +0200)]
man: correct the description of --capath and --crl-verify regarding CRLs
The man page states that when using --capath, the user is required to
provide CRLs for CAs. This is not true and providing CRLs is optional -
both in case of --capath as well as --crl-verify options. When relevant
CRL is not found OpenVPN simply logs the warning in the logs while
allowing the connection, e.g.:
VERIFY WARNING: depth=0, unable to get certificate CRL
This patch clarifies the behavior.
Signed-off-by: Michal Soltys <soltys@ziu.info> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <20190409143438.25348-2-soltys@ziu.info>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18343.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit b3cfc43da3583ae8aa761beb29f016311b2ba64f)
Lev Stipakov [Tue, 30 Oct 2018 08:53:35 +0000 (10:53 +0200)]
Fix various compiler warnings
This patch fixes "unused variable/unreferenced format parameter"
warnings in different places, kudos to Visual Studio compiler
for discoveing some of those.
This also also removes unneeded uninit_management_callback_multi()
wrapper.
Signed-off-by: Lev Stipakov <lev@openvpn.net> Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1540889615-24868-1-git-send-email-lstipakov@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17855.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 91ba1add2f8f231a7ccf4557cdd593547e625723)
The mock_msg.h file was not enlisted in the _SOURCES lists in
Makefile.am for the unit tests. This caused the mock_msg.h file to not
be present in the .tar.gz file created by 'make dist'.
This was not noticed earlier as we haven't really tried much to run git
clone of the cmocka project manually in vendor/ from an unpacked
tarball.
With this fix the cmocka unit tests can also run from tarballs, with
manually extracting/fetching the cmocka source code in vendor/cmocka.
Signed-off-by: David Sommerseth <davids@openvpn.net> Cc: Steffan Karger <steffan.karger@foxcrypto.com>
----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----
How to test:
- Create a tarball: make distcheck (or just 'dist')
- Extract openvpn-2.4.*.tar.gz in a clean directory
- cd openvpn-2.4.*/vendor
- git clone https://git.cryptomilk.org/projects/cmocka.git
- cd ..
- ./configure
- make check
- Observe that the cmocka unit tests ran as expected
Depending on the CMake version, you might want to check out cmocka git
commit b2732b52202ae48f; which is the one we use in the git submodule. Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190507200434.24931-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18430.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
David Sommerseth [Fri, 12 Apr 2019 20:20:20 +0000 (22:20 +0200)]
docs: Update INSTALL
The INSTALL file contained several minor errors, typos and was generally
not up-to-date in regards to what ./configure provides today. In
addition, several URL references have moved around to new homes.
This is just a backport of git master 6099ab67122429c0 adjusting for the
slight changes in release/2.4. The contents is the same as git master,
as it is still valid for v2.4.
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190412202020.24045-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18364.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Ubuntu Trusty reaches End of Life on April 30, 2019
Let us switch to xenial. Also, it simplifies mingw builds.
We do not need to add xenial mingw manually anymore
David Sommerseth [Wed, 20 Feb 2019 13:19:06 +0000 (14:19 +0100)]
cleanup: Remove RPM openvpn.spec build approach
Linux packaging is quite a comprehensive task these days, with many
Linux distributions and each with their own packaging guidelines. In
addition OpenVPN is packaged for most important Linux distributions
already.
The OpenVPN developers is not capable of keeping track of how all the
various recommend packaging guidelines evoloves and our RPM build
process is no longer consistent with guidelines from Fedora, RHEL or
SUSE packaging. We also don't receive any updates improving this
situation. Most likely due to packaging being handled fairly well by
the Linux distributions directly.
In addition comes systemd into play, which more and more Linux
distributions embraces - and even our own RPM openvpn.spec file didn't
account for that move.
This removes all RPM related packaging files and updates the INSTALL
file with pointers to several popular Linux distributions with
accessible information of the OpenVPN packages they provide. Linux
distributions is most likely much better at keeping the packaging
up-to-shape much better than we.
Signed-off-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20190220131906.22970-1-davids@openvpn.net>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18222.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 57ec6cec85b92e6af35a7871d105d84a753d6549)
Selva Nair [Fri, 1 Mar 2019 05:32:24 +0000 (00:32 -0500)]
Better error message when script fails due to script-security setting
- Add a new return value (-2) for openvpn_execve() when external
program execution is not allowed due to a low script-security
setting.
- Add a corresponding error message
Errors and warnings in such cases will now display as
"WARNING: failed running command (<cmd>) :" followed by
"disallowed by script-security setting" on all platforms
instead of the current
"external program did not execute -- returned error code -1"
on Windows and
"external program fork failed" on other platforms.
The error is FATAL for some scripts and that behaviour is unchanged.
This helps the Windows GUI to detect when a connection failure
results from a safer script-security setting enforced by the GUI,
and show a relevant message.
Note: Same as commit 01a3c876d4911 in master except for
script_security() --> script_security and context change:
run_command.[ch] --> misc.[ch]
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1551418344-16317-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18259.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
Thomas Quinot [Fri, 1 Feb 2019 20:43:48 +0000 (21:43 +0100)]
Fix documentation of tls-verify script argument
The second argument is the entire subject DN, not just the CN. Acked-by: Steffan Karger <steffan.karger@fox-it.com>
Message-Id: <20190201204348.22326-1-openvpn-devel=lists.sourceforge.net@thomas.quinot.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18195.html
Selva Nair [Tue, 22 Jan 2019 15:50:32 +0000 (10:50 -0500)]
White-list pull-filter and script-security in interactive service
This allows the Windows GUI to use these options on the command
line without triggering user authorization errors.
Useful for
(i) ignoring certain pushed options such as "route-method" which
could otherwise bypass the interactive service
(ii) enforcing a safer script-security setting from the GUI
See also:
https://github.com/OpenVPN/openvpn-gui/issues/235#issuecomment-456142928
Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <1548172232-11268-1-git-send-email-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg18154.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 0d94d433438f239ff7cf0749f765a503c698f5e8)
Simon Rozman [Tue, 16 Oct 2018 10:26:27 +0000 (12:26 +0200)]
Detect TAP interfaces with root-enumerated hardware ID
This patch extends the TAP interface enumerating to detect the TAP
interfaces registered using "root\tap0901" hardware ID. Before, only TAP
interfaces with legacy "tap0901" HWID were detected by openvpn.exe.
The openvpnmsica.dll and tapctl.exe install TAP interfaces using root-
enumerated HWIDs, and were not detected by openvpn.exe. Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20181016102627.18676-5-simon@rozman.si>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17762.html
Gert Doering [Fri, 7 Dec 2018 12:33:03 +0000 (13:33 +0100)]
Add 'printing of port number' to mroute_addr_print_ex() for v4-mapped v6.
For whatever reason, this function never printed port numbers for
IPv6 addresses (but it did for IPv4) - which creates a bit of
confusion for IPv6-mapped v4 addresses on a dual stack socket,
that will have ports numbers printed or not, depending on whether
it's a dual-stack v6 socket or single-stack v4.
This will not(!) add printing of port numbers for "proper" v6
addresses yet, because that might have adverse side effects to address
parsing elsewhere.
Signed-off-by: Gert Doering <gert@greenie.muc.de> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20181207123303.70827-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17996.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit 4543b13b8540836f6faf67a03b5358bb8bb94a4a)
Arne Schwabe [Wed, 10 Oct 2018 14:30:51 +0000 (16:30 +0200)]
Fallback to password authentication when auth-token fails
Under some circumstances, the auth-token stored by a client may not
be valid anymore.
For example, if the server is restarted, the client will try to
reconnect and resend the old token during authentication. Unfortunately
this attempt will fail, because the server does not keep track of tokens
used during previous runs.
With the current behaviour, depending on how auth-retry was configured,
the client will either just quit, prompt the user for username and password
as the original values are overwritten by the token, or endelessly fail
authentication by sending the old token over and over.
This patch changes the behaviour of the client so that, upon failed
authentication using a token, it will drop the token, perform a soft
restart (USR1) and attempt re-authenticating with the original password
provided by the user if auth-nocache was not specified.
Patch V3: remove all server changes, include only minimal non
intrusive client changes that only improve error recovery but don't
change overall behaviour.
Patch V4: forget add push.c to git index, now also included
Patch V5: is fixing overlong lines and one minor style problem.
Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Antonio Quartulli <antonio@openvpn.net>
Message-Id: <20181010143051.27163-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17718.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit e61b401ac50d2a9cfabf0289811ad14cf3bd2751)
projects / thirdparty / openvpn.git / log
