The reauthentication logic differs from openvpn2
and the code is a bit hard to follow. Simplify
the code and make it behave like in openvpn2.
- password is cached by default
- password is purged when auth-nocache is presented in a local config or pushed
- when AUTH_FAILED is received and we have no session-id, throw a fatal error
- when AUTH_FAILED is received and user interaction is required for
authentication (MFA), throw a fatal error
- when AUTH_FAILED is received, user interaction is not required
for authentication and either we have a cached password OR password is not
needed, we reconnect.
Password is "needed" when non-empty password is provided.
User interaction is required for static/dynamic challenge and SAML.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This allows the test_proto.cpp to supress all the logging of this
class. This is also the only place in our project that actually uses
a non-default loglevel for this class. A lot of files were defining the
OPENVPN_LOG_SSL(x) macro to be what the also remove ssllog.hpp would do
anyway if it were not defined.
The removed debug_level field only controlled the mssfix
logging and is now controlled by the general protocol logging instead.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
A few minor changes:
- add ORGANIZATION meta option to ignore list
- remove excessive OVPN_ACCESS_SERVER_ prefix from NO_WEB meta option
- Increase status message length from 256 to 2048 to be able to show
the full list of unsupported options
Signed-off-by: Lev Stipakov <lev@openvpn.net>
On modern CMake this gets us swig dependency management,
which should reduce problems for incremental builds.
Also it is just cleaner.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
(cherry picked from commit 72275db1d5)
The earlier were deprecated since CMake 3.12.
Since CMake 3.27 this causes deprecation warnings.
Should be safe nowadays to require CMake 3.12.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
(cherry picked from commit bb61350ae5)
Currently we error out on the first unsupported
option which belongs to the "fatal" category, such as
"removed deprecated option" or "Option allowed only to
be pushed by the server".
To improve user experice and allow application code
to display all problematic options and their categories,
collect options into a category->options map and then
serialize it into multiline string:
cat1: opt1,opt2
cat2: opt3
Introduce a new error code UNUSED_OPTIONS, which is
placed into ClientAPI::Status::status. The serialized
options map is placed into ClientAPI::Status::message.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This adds the capability to implement a custom app level protocol
that support message passing over the OpenVPN control channel.
The protocol is agnostic to the data that is transported over it
and the message splitting/reassmbly is handled transparently by the
OpenVPN library itself.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
On modern CMake this gets us swig dependency management,
which should reduce problems for incremental builds.
Also it is just cleaner.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
This might have been used or intended to be used for more than compression
but currently it is only used for compression, so rename it accordingly.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The earlier were deprecated since CMake 3.12.
Since CMake 3.27 this causes deprecation warnings.
Should be safe nowadays to require CMake 3.12.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
This makes this option have the same style as the other options in
the client config to ensure consistencyv
Signed-off-by: Arne Schwabe <arne@openvpn.net>
This is not required in ClientConfigParsed, and actually makes
the object significantly bigger, due to the contained certificates.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The current passing of client options is very confusing since it is
three classes that largely have the same attributes and the code is
copying them around between the classes.
Instead create a new base class that hold the settings that can be shared
between the classes and only parse/copy the settings that need special
handling. This might keep an extra copy of some settings around but in
constract greatly reduces the code complexity of the options handling.
Also move the check_dco_compatibility function to client options to
be able to avoid carrying around the dco_compatiblity flag.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
When parsing config, check DCO compatibility. Following
options break DCO compatibility:
- http-proxy
- compress
- comp-lzo
Same for config settings:
- non-preferred-algorithms
- legacy-algorithms
- proxyHost
DCO compatibility could be checked with
- bool EvalConfig::dcoCompatible
- std::string dcoIncompatibilityReason
If client nevertheless tries to connect, an exception
will be thrown:
connect error: option_error: dco_compatibility: config/options are not
compatible with dco
Fixes OVPN3-960.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This ensure that client that want to set a miminum level of TLS
version do not accidentially lower the version when the profile already
requires a higher version.
Also make the tls version enum an enum class for better type safety.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
This is the result after running 'clang-format -i' on all C++ files and
headers, with the defined formatting rules in .clang-format.
Only the openvpn/common/unicode-impl.hpp has been excluded, as that is
mostly a copy of an external project.
Signed-off-by: David Sommerseth <davids@openvpn.net>
This allows disabling the route emulation for Andorid API 33
(Tiramisu/API 33) or if the app implements its own emulation (ics-openvpn)
Signed-off-by: Arne Schwabe <arne@openvpn.net>
OpenVPN 3.x has the same approach/problem for buffer allocation for the
tunnel packets that OpenVPN 2.x uses. Buffers are allocated very early
in the setup, so resizing/reacting to different frame sizes is not
really possible without major refactoring.
Therefore we use the same approach as with OpenVPN 2.x and allow a
MTU of up to 1600 by default and require setting tun-mtu-max in the
configuration file to allow larger values and allocate larger buffers.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The xkey provider has been originally implemented by Selva Nair for
OpenVPN 2.x and he has agreed to allow me to reuse the provider for
OpenSSL 3.0
This brings the xkey provider to OpenSSL to Openvpn3. The xkey_provider.c
file is kept as close as possible to the original OpenVPN 2 source.
From xkey_helper only the parts that were needed were picked up and used
in xkey.hpp.
This also changes the requests for clients wanting to implementing the
API, generally making them more work (adding PSS/PKCS1 padding and hashing)
but this is a good thing since especially external keys/HSM often do not
like doing raw signatures and often require to do padding/hashing themselves.
This commit also updates the test client's EPKI implementation to work
with the new requirements of the new API.
Since most of OpenVPN3's code base assumes having only one compilation unit
and the xkey_provider.c, this commit introduces the ENABLE_EXTERNAL_PKI
define. Only if this is set external key support is supported (and the
xkey_provider.c compilation unit needed).
This commit furthermore removes the pragma statements from extpki.hpp that
supressed warnings when being compiled with OpenSSL 3.0+ as this is header file
longer compiled with OpenSSL 3.0+. (Technically xkey is >= 3.0.1 but we have
no target that is OpenSSL 3.0.0).
Signed-off-by: Arne Schwabe <arne@openvpn.net>
The event is of type INFO_JSON and is formatted:
TUN_BUILDER_CAPTURE:{...}
This info is useful to determine the properties of a
VPN client session such as VPN IPs, Gateway IPs,
and DNS resolvers, and can be directly used as
a VPN Connection Profile.
This patch also adds the
cli --tbc <file>
option to write the TunBuilderCapture JSON to a file.
Signed-off-by: James Yonan <james@openvpn.net>
CID 10065 (#6 of 6): Uninitialized scalar field (UNINIT_CTOR)
2. uninit_member: Non-static class member proto_version_override
is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
Swig library build uses Python library which has the the same arch
as build machine arch, which in our case is always x64.
Building for other archs causes machine type conflicts.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Commit 9ad98bae8f ("Add building ovpncli swig library to cmake build")
added GCC-specific compiler flags which are unknown on Windows.
Remove those flags from Windows build.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
We saw problems with this on our RHEL7 builds because
we upgraded gcc but not swig. Work-around the issue
for now until we can require SWIG 4.0.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
CID 11125 (#1 of 1): Uninitialized scalar variable (UNINIT)
8. uninit_use_in_call: Using uninitialized value
config_templ.enableNonPreferredDCAlgorithms when calling Config.
flood.cpp:1320
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
With OpenSSL3, these algorithms are no longer allowed. With this change
we do the same regardless of the crypto library. Note that in contrast
to OpenSSL3, we include here 3DES into the legacy algorithms.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
This also makes most of them non-static to avoid the problem that these
functions depend on Initprocess::Init being instantiated before being
called.
Rename the local variables eval to eval_cfg to avoid shadowing the
class field of the same name.
Since IPv4/IPv6 should be treated equally, we should have also
the opportunity to block IPv4. With this change we follow the API
that also Android provides and expliticly tell tunbuilder what to
do with address families that are not used by the VPN. If a
address family is used by the VPN, nothing changes.
This also remove IV_IPV6 as it is not used.
Local DNS resolvers, such as Umbrella Roaming Client,
change DNS settings on adapters to 127.0.0.1.
This may not work with openvpn3 because:
- NRPT rule might be created for "." zone,
which redirects all DNS requests to the server
specified in rule. This takes precendence over adapters'
DNS settings.
- DNS requests might be blocked on all adapters
except TAP (tap-windows6/wintun/ovpn-dco-win) to prevent
DNS leaks.
To enable compatibility with local DNS resolvers, add
"allowLocalDnsResolvers" core config option, which,
when enabled, makes core to
- avoid creating NRPT rule for "." zone
- permit DNS requests to 127.0.0.1 / ::1
Signed-off-by: Lev Stipakov <lev@openvpn.net>
If DCO support is compiled in, detect if it is available (i.e. Windows driver
or Linux kernel module is loaded) and then use it, if it is.
This changes the default configuration for DCO from off to on, so users of
the library need to set ClientAPI::Config::dco to false in case they do not
want to use dco for a connection.
The change is also reflected in the reference client "ovpncli". If DCO is
enabled in a build, it will detect and use it. The previously available
"ovpncliovpndco" and "ovpncliovpndcowin" clients have thus been removed.
Signed-off-by: Heiko Hund <heiko@openvpn.net>
