Commit ae99307 ("tun: add persis-tun support for dco-win")
broke handling of premature exit of agent process. Introduced
"tun_persist->close_destructor()" call in "tun_start() " also closes
agent process handle within WinCommandAgent,
which triggers fail handler (without error code).
Fix by "re-arming" fail handler after "close_destructor()"
call in "tun_start()".
Signed-off-by: Lev Stipakov <lev@openvpn.net>
This commit changes the way the core deals with UV_ variables. They
now also respect push-peer-info (like in OpenVPN 2.x) and if variables
are present in both client.peerInfo and as setenv in the configuration
content, only the ones from peerInfo are send to the server.
The new behaviour can be tested with
ovpncli -I UV_TEST=cmdline conf.ovpn
and conf.ovpn having a setenv UV_TEST foobar in it as well
Signed-off-by: Arne Schwabe <arne@openvpn.net>
parent->transport_connecting() might trigger stop(),
reset device handle and set halt to true if TCP server
is down. In this case we should not queue read.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Add DcoTunPersist object to DCO::TunConfig.
DcoTunPersist stores:
- device handle
- tun settings
- adapter index/name
- pointer to TunSetup object, which itself
stores commands to undo tun settings
When intializing client options, instantiate DcoTunPersist
object within the scope of ClientConfig, which serves as
transport and tun factory for dco. Indicate that "sock" object
(device handle) should be preserved - not replaced when persisting
tun settings.
When establishing dco-win connection in OvpnDcoWinClient,
either use tun_persist created above (if persistance is enabled)
or instantiate it in-place (no persistance).
If nothing is stored in tun_persist (means this is first
connection or reconnect without persistance), acquire device
handle from tun_setup, wrap it into ASIO's basic_stream_handle
and store it in OvpnDcoWinClient - no need to persist it yet.
When starting tun, check if persisted tun session matches
to-be-created session. If no - clear previous tun settings,
set up tun and persist tun state. If device handle is already
stored in tun_persist, it won't be replaced.
On tun stop, send DEL_PEER command, which deletes peer
from the driver but keeps adapter in connected state. Then
close locally stored ASIO handle and reset tun_persist.
In case of "short term persistance" this will undo tun settings
and close device handle. For long term persistence, tun_persist
is also stored in ClientConfig and handle won't be closed yet.
In case of disconnect, ClientConfig::finalize(disconnect=true)
is called, which resets tun_persist, which in turn
undoes tun settings and closes device handle.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
In case of dco-win persist tun, adapter state (index and name)
persists over lifetime on TunSetup object. Add setter/getter
for adapter state to TunSetup.
While on it, ensure that TunSetup::establish() doesn't
acquire adapter handle for dco - this is done by another
dco-specific "get_handle" method. The handle is not
really used by establish() method when using dco-win.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Replace wintun-specific hardcoded RingBuffer with
ADAPTER_STATE template. This will be used later
for dco-win tun persist support.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Previously, we only supported int64 serial numbers.
This change renames get_sn() method to serial_number_as_int64()
for code that cares about 64-bit serial numbers.
Signed-off-by: James Yonan <james@openvpn.net>
This commit add several improvements to dealing with unknown options
in client configuration files:
- implement ignore-unknown-option
- categorise the OpenVPN2 options in multiple categories and
warn/error out depending on the category
- error out when unsupported/unknown options are found. This avoids
problems like with --tls-crypt/--tls-crypt-v2 before where client
would ignore these options and not connect at all
Signed-off-by: Arne Schwabe <arne@openvpn.net>
If "state" is given without parameters, treat it as "state 1",
same as in openvpn 2.
This is sent, for example, but openvpn-gui.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
We already use IPAPI to add routes, so there is no reason
not to use it to add excluded routes. Example from server config:
push "redirect-gateway def1"
push "route 192.168.0.0 255.255.0.0 net_gateway"
This should redirect all traffic to VPN except one route. What
we should see in logs is:
IPHelper: add route 192.168.0.0/16 21 100.64.0.1 metric=-1
(where 100.64 is a default gw on my machine)
Reported-by: Arul Thileeban <arulthileeban@vt.edu>
Signed-off-by: Lev Stipakov <lev@openvpn.net>
- test_cpu_time: fix unused variable
- Allow GIT version to be reported as part of platform (version) string
- Update OpenSSL to 3.0.5, build fat lib for macos, drop 32 bit on iOS
- README.rst: some fixes for macOS instructions
- extpki.hpp: ignore deprecated EC_KEY_* functions
- mingw: fix OpenSSL on x86_64
- mingw: fix broken OpenSSL checkout
- test_ssl: fix ssl.enablelegacyProvider
- dco/GeNL: ignore message for unrelated interfaces
Signed-off-by: David Sommerseth <davids@openvpn.net>
dco-win adapter creates multiple device interfaces and in some
cases the right one is not the first one. Enumerate all interfaces
and pick the one with correct reference string.
Signed-off-by: Lev Stipakov <lev@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>
Since we do not operate any servers on macOS, we
do not want to invest time in fixing this.
In most cases you would want to use launchd anyway
and not use damonize().
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
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>
Doing first -Werror builds on Linux against OpenSSL 3.0.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.com>
(cherry picked from commit ab55c9fdb2)
DCO device is "exclusive" device, meaning that only one app at the time can access it
and device is considered opened until pending IO is complete.
start_impl_() might be called on reconnect, in the same stack with closing device handle.
Closing handle also triggers completion of pending IO, such as async read. However this happens
in the next iteration of ASIO even loop. Therefore we defer opening DCO device
(i.e. calling start_impl_) to let ASIO complete pending IO.
Note that this is not required when async resolve is performed, since this implies deferring.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
When enabled, retry_on_http_4xx indicates that HTTP status
codes between 400 and 499 should be considered a
retryable error. AWS appears to need this.
Note that error codes between 500 and 599 are always
considered to be retryable.
Signed-off-by: James Yonan <james@openvpn.net>
VPN Binding Profiles (previously committed as VPN Connection
Profiles) contain information on an active VPN client session
such as local VPN IPs, gateway, and DNS resolver addresses
that can be directly used by higher-layer HTTP/REST-API
clients to (a) ensure that sessions are routed over the VPN,
and (b) privately use the VPN-server-pushed DNS resolvers
without publishing them in /etc/resolv.conf.
Signed-off-by: James Yonan <james@openvpn.net>
As a response for correct password, omiclient
must send SUCCESS: with \r\n line ending.
This bug went unnoticed for a while because
the only user of this code as for now is openvpn-gui
with openvpn3 support, which hasn't got much
traction until recently.
Missing line ending didn't trigger certain callback
in -gui code which enables logging, and logging
was enabled in a different way (one can call it
openvpn3-specific hack). With that change a -gui callback,
which enables logging, is called and hack could be removed.
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Signed-off-by: Christopher Ng <facboy@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Patchwork-Id: 2509
URL: https://patchwork.openvpn.net/patch/2509/
Message-Id: <20220607163049.10056-2-facboy@gmail.com>
Signed-off-by: David Sommerseth <davids@openvpn.net>
Signed-off-by: Christopher Ng <facboy@gmail.com>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Patchwork-Id: 2510
URL: https://patchwork.openvpn.net/patch/2510/
Message-Id: <20220607163049.10056-1-facboy@gmail.com>
Signed-off-by: David Sommerseth <davids@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>
Some netlink messages are sent as multicast by the kernel and will reach
all listening userspace processes. For this reason, the receiving
handler should discard non-interesting messages to avoid messing up the
local state.
Reported-by: David Sommerseth <davids@openvpn.net>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
A VPN connection profile is basically a JSON representation
of the server-pushed parameters of a VPN session such as
VPN IPs, Gateway IPs, and DNS servers. It can be obtained
on the client via TunBuilderCapture::to_json()
This patch allows an HTTP client or server to bind to the
VPN connection profile, so that the VPN IP is used as the
local address, the Gateway IP is optionally used as the
destination address, and DNS lookups are performed using
the pushed DNS servers (without needing to overwrite
/etc/resolv.conf).
For example, suppose the VPN connection profile
is in /pg/uplink-connection-info
Then we can bind to the VPN IP addresses on the server side:
http-listen @/pg/uplink-connection-info 8443 tcp4 ssl
http-listen @/pg/uplink-connection-info 8443 tcp6 ssl
Or connect to a remote REST API using the VPN session
and VPN server-provided resolvers.
<aws-client>
host mybucket.s3.amazonaws.com
port 443
vpn-connection-info /pg/uplink-connection-info
...
</aws-client>
Signed-off-by: James Yonan <james@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>
AllowVPNClientConnectionProfile tells us to support
special address case for WS::ViaVPN, where address
begins with '@' followed by a client connection
profile filename.
Signed-off-by: James Yonan <james@openvpn.net>
