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>
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>
The new element ClientAPI::Config::protoVersionOverride can be set
to 4 or 6 respectively, to override the transport protocol IP version
used by RemoteList::Item entries. Clients can force all --remotes
to use IPv4 or IPv6 using this entry, if they know that only one of
the two is available in the current network.
Signed-off-by: Heiko Hund <heiko@openvpn.net>
Extend struct ProvideCreds so that it can also hold HTTP proxy
credentials. This makes it possible to use proxy settings from
options, but provide credentials separately.
This is in contrast to the already existing struct Config::proxy*
which need to be given as a complete set to override eventual
HTTP proxy options.
Signed-off-by: Heiko Hund <heiko@openvpn.net>
Although the init calls were protected by a mutex more than consumer of
the API will the second one if the uninit was called too early.
While at it, move from explicit init/uninit calls to RAII.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
Add tun/transport client skeleton for ovpn-dco,
which doesn't do any work except creating/removing
ovpn-dco device.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
When VPN server is in local network and
not accessible via default gateway, adding bypass route
via default gw (as we do on windows/mac) makes server
inaccessible.
This handles client-side config option "redirect-gw local"
and skips adding bypass route via agent.
Fixes OVPN3-653
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This option has been very likely been to fix some incompatibilities
between some TLS libraries. But nobody really remember what it fixes
and its usage today is questionable. So remove the option instead
of supporting an option we cannot even test anymore.
Signed-off-by: Arne Schwabe <arne@openvpn.net>
Parse --windows-driver and set corresponding
value of config properties.
Could be used by clients to replicate openvpn2
behavior - use wintun driver if config contains
"--windows-driver wintun".
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This is used to enable connectivity to a different remote
when force-tunneling is used and current VPN connection is broken.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This is used to enable connectivity to a different remote
when force-tunneling is used and current VPN connection is broken.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
socket_protect() is called before connecting to remote and this
makes sure that we will be able to (re)connect when there is
existing VPN connection and tunnel is broken.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This enables socket_protect call for all transports / platforms
with default implemenation being no-op.
This is needed for better round-robin DNS
fix for Connect clients (OVPN3-427).
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Prefix error messages with a predefined string of the form:
ERR_PROFILE_xxxxx:
This way a user can parse the prefix and get a better understanding of
the error, without relying on the sole message.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
