PORTS

 OpenVPN
-Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
+Copyright (C) 2002-2022 OpenVPN Inc <sales@openvpn.net>
 
   OpenVPN has been written to try to avoid features
   that are not standardized well across different

README.IPv6

-Since 2.3.0, OpenVPN officially supports IPv6, and all widely used
-patches floating around for older versions have been integrated.
-
-IPv6 payload support
---------------------
-
-This is for "IPv6 inside OpenVPN", with server-pushed IPv6 configuration
-on the client, and support for IPv6 configuration on the tun/tap interface
-from within the openvpn config.
-
-The code in 2.3.0 supersedes the IPv6 payload patches from Gert Doering,
-formerly located at http://www.greenie.net/ipv6/openvpn.html
-
-
-The following options have been added to handle IPv6 configuration,
-analogous to their IPv4 counterparts (--server <-> --server-ipv6, etc.)
-
-     - server-ipv6
-     - ifconfig-ipv6
-     - ifconfig-ipv6-pool
-     - ifconfig-ipv6-push
-     - route-ipv6
-     - iroute-ipv6
-
-see "man openvpn" for details how they are used.
-
-
-
-IPv6 transport support
-----------------------
-
-This is to enable OpenVPN peers or client/servers to talk to each other
-over an IPv6 network ("OpenVPN over IPv6").
-
-The code in 2.3.0 supersedes the IPv6 transport patches from JuanJo Ciarlante,
-formerly located at http://github.com/jjo/openvpn-ipv6
-
-OpenVPN 2.4.0 includes a big overhaul of the IPv6 transport patches
-originally implemented for the Android client (ics-openvpn)
-
-IPv4/IPv6 transport is automatically is selected when resolving addresses.
-Use a 6 or 4 suffix to force IPv6/IPv4:
-
-  --proto udp6
-  --proto tcp4
-  --proto tcp6-client
-  --proto tcp4-server
-  --proto tcp6 --client / --proto tcp6 --server
-
-On systems that allow IPv4 connections on IPv6 sockets
-(all systems supporting IPV6_V6ONLY setsockopt), an OpenVPN server can
-handle IPv4 connections on the IPv6 socket as well, making it a true
-dual-stacked server. Use bind ipv6only to disable this behaviour.
-
-On other systems, as of 2.3.0, you need to run separate server instances
-for IPv4 and IPv6.

README.dco.md

+OpenVPN data channel offload
+============================
+2.6.0+ implements support for data-channel offloading where the data packets
+are directly processed and forwarded in kernel space thanks to the ovpn-dco
+kernel module. The userspace openvpn program acts purely as a control plane
+application.
+
+
+Overview of current release
+---------------------------
+- See the "Limitations by design" and "Current limitations" sections for
+  features that are not and/or will not be supported by OpenVPN + ovpn-dco
+
+
+Getting started (Linux)
+-----------------------
+
+- Use a recent Linux kernel. Linux 5.4.0 and newer are known to work with
+  ovpn-dco.
+
+Get the ovpn-dco module from one these urls and build it:
+
+* https://gitlab.com/openvpn/ovpn-dco
+* https://github.com/OpenVPN/ovpn-dco
+
+e.g.
+
+    git clone https://github.com/OpenVPN/ovpn-dco
+    cd ovpn-dco
+    make
+    sudo make install
+
+If you want to report bugs please ensure to compile ovpn-dco with
+`make DEBUG=1` and include any debug message being printed by the
+kernel (you can view those messages with `dmesg`).
+
+Clone OpenVPN and build dco branch. For example:
+
+    git clone -b dco https://github.com/openvpn/openvpn.git
+    cd openvpn
+    autoreconf -vi
+    ./configure --enable-dco
+    make
+    sudo make install # Or run just src/openvpn/openvpn
+
+If you start openvpn it should automatically detect DCO support and use the
+kernel module. Add the option `--disable-dco` to disable data channel offload
+support. If the configuration contains an option that is incompatible with
+data channel offloading OpenVPN will automatically disable DCO support and
+warn the user.
+
+Should OpenVPN be configured to use a feature that is not supported by ovpn-dco
+or should the ovpn-dco kernel module not be available on the system, you will
+see a message like
+
+    Note: Kernel support for ovpn-dco missing, disabling data channel offload.
+
+in your log.
+
+
+Getting started (Windows)
+-------------------------
+Getting started under windows is currently for brave people having experience
+with windows development. You need to compile openvpn yourself and also need 
+to get the test driver installed on your system.
+
+
+DCO and P2P mode
+----------------
+DCO is also available when running OpenVPN in P2P mode without --pull/--client option.
+The P2P mode is useful for scenarios when the OpenVPN tunnel should not interfere with
+overall routing and behave more like a "dumb" tunnel like GRE.
+
+However, DCO requires DATA_V2 to be enabled. This requires P2P with NCP capability, which
+is only available in OpenVPN 2.6 and later.
+
+OpenVPN prints a diagnostic message for the P2P NCP result when running in P2P mode:
+
+    P2P mode NCP negotiation result: TLS_export=1, DATA_v2=1, peer-id 9484735, cipher=AES-256-GCM
+
+Double check that your have `DATA_v2=1` in your output and a supported AEAD cipher
+(AES-XXX-GCM or CHACHA20POLY1305).
+
+
+Routing with ovpn-dco
+---------------------
+The ovpn-dco kernel module implements a more transparent approach to
+configuring routes to clients (aka 'iroutes') and consults the kernel
+routing tables for forwarding decisions.
+
+- Each client has an IPv4 and/or an IPv6 VPN IP assigned to it.
+- Additional IP ranges can be routed to a client by adding a route with
+  a client VPN IP as the gateway/nexthop (i.e. ip route add a.b.c.d/24 via $VPNIP).
+- Due to the point above, there is no real need to add a companion --route for
+  each --iroute directive, unless you want to blackhole traffic when the specific
+  client is not connected.
+- No internal routing is available. If you need truly internal routes, this can be
+  achieved either with filtering using `iptables` or using `ip rule`.
+- client-to-client behaviour, as implemented in userspace, does not exist: packets
+  always reach the tunnel interface and are then re-routed to the destination peer
+  based on the system routing table.
+
+
+Limitations by design
+----------------------
+- Layer 3 (dev tun only)
+- only AEAD ciphers are supported and currently only
+  Chacha20-Poly1305 and AES-GCM-128/192/256
+- no support for compression or compression framing
+  - see also `--compress migrate` option to move to a setup without compression
+- various features not implemented since they have better replacements
+  - --shaper, use tc instead
+  - packet manipulation, use nftables/iptables instead
+- OpenVPN 2.4.0 is the minimum peer version.
+  - older versions are missing support for the AEAD ciphers
+- topology subnet is the only supported `--topology` for servers
+- iroute directives install routes on the host operating system, see also
+  Routing with ovpn-dco
+- (ovpn-dco-win) client and p2p mode only
+- (ovpn-dco-win) Chacha20-Poly1305 support available starting with Windows 11
+
+
+Current implementation limitations
+-------------------
+- --persistent-tun not tested/supported
+- fallback to non-dco in client mode missing
+- IPv6 mapped IPv4 addresses need Linux 5.4.189+/5.10.110+/5.12+ to work
+- Some incompatible options may not properly fallback to non-dco
+- TCP performance with ovpn-dco can still exhibit bad behaviour and drop to a
+  few megabits per seconds
+- Not all incompatible options are currently identified
+- No per client statistics. Only total statistics available on the interface

README.ec

+Since 2.4.0, OpenVPN has official support for elliptic curve crypto. Elliptic
+curves are an alternative to RSA for asymmetric encryption.
+
+Elliptic curve crypto ('ECC') can be used for the ('TLS') control channel only
+in OpenVPN; the data channel (encrypting the actual network traffic) uses
+symmetric encryption. ECC can be used in TLS for authentication (ECDSA) and key
+exchange (ECDH).
+
+Key exchange (ECDH)
+-------------------
+OpenVPN 2.4.0 and newer automatically initialize ECDH parameters. When ECDSA is
+used for authentication, the curve used for the server certificate will be used
+for ECDH too. When autodetection fails (e.g. when using RSA certificates)
+OpenVPN lets the crypto library decide if possible, or falls back to the
+secp384r1 curve. The list of groups/curves that the crypto library will choose
+from can be set with the --tls-groups <grouplist> option.
+
+An administrator can force an OpenVPN/OpenSSL server to use a specific curve
+using the --ecdh-curve <curvename> option with one of the curves listed as
+available by the --show-groups option. Clients will use the same curve as
+selected by the server.
+
+Note that not all curves listed by --show-groups are available for use with TLS;
+in that case connecting will fail with a 'no shared cipher' TLS error.
+
+Authentication (ECDSA)
+----------------------
+Since OpenVPN 2.4.0, using ECDSA certificates works 'out of the box'. Which
+specific curves and cipher suites are available depends on your version and
+configuration of the crypto library. The crypto library will automatically
+select a cipher suite for the TLS control channel.
+
+Support for generating an ECDSA certificate chain is available in EasyRSA (in
+spite of it's name) since EasyRSA 3.0. The parameters you're looking for are
+'--use-algo=ec' and '--curve=<curve_name>'. See the EasyRSA documentation for
+more details on generating ECDSA certificates.

README.mbedtls

@@ -11,6 +11,24 @@ This version depends on mbed TLS 2.0 (and requires at least 2.0.0).
 
 *************************************************************************
 
+Warning:
+
+As of mbed TLS 2.17, it can be licensed *only* under the Apache v2.0 license.
+That license is incompatible with OpenVPN's GPLv2.
+
+If you wish to distribute OpenVPN linked with mbed TLS, there are two options:
+
+ * Ensure that your case falls under the system library exception in GPLv2, or
+
+ * Use an earlier version of mbed TLS. Version 2.16.12 is the last release
+   that may be licensed under GPLv2. Unfortunately, this version is
+   unsupported and won't receive any more updates.
+
+If nothing changes about the license situation, mbed TLS support may be
+deprecated in a future release of OpenVPN.
+
+*************************************************************************
+
 Due to limitations in the mbed TLS library, the following features are missing
 in the mbed TLS version of OpenVPN:
 

README.wolfssl

+Support for wolfSSL is implemented and maintained by wolfSSL Inc. The support is
+implemented using wolfSSL's compatibility layer. The wolfSSL support in OpenVPN
+receives very limited testing/support from the OpenVPN community itself.
+
+If bugs in OpenVPN when using wolfSSL are encountered, the user should try to
+also compile OpenVPN with OpenSSL to determine if these are bugs in the
+wolfSSL TLS implementation or OpenVPN itself. If bugs are caused by compiling
+with wolfSSL, please contact support@wolfssl.com directly.
+
+To Build and Install,
+
+	./configure --with-crypto-library=wolfssl
+	make
+	make install
+
+
+The wolfSSL library will include the installed options.h file by default.
+To include a custom user_settings.h file for wolfSSL,
+
+./configure --with-crypto-library=wolfssl --disable-wolfssl-options-h
+make
+make install
+
+*************************************************************************
+Due to limitations in the wolfSSL TLS library or its compatibility layer, the
+following features are missing
+
+ * blowfish support (BF-CBC), you must use something like
+   cipher AES-128-CBC to avoid trying to use BF-CBC
+ * Windows CryptoAPI support

TODO.IPv6

-TODO for IPv6 payload support
------------------------------
-
-1.) "--topology subnet" doesn't work together with IPv6 payload on FreeBSD
-    (verified for FreeBSD server, Linux/ifconfig client, problems 
-    with ICMP6 neighbor solicitations from BSD not being answered by Linux)
-
-    * 2012-01-22 fixed in platform cleanup, commit 62c613d46dc495d74
-
-2.) NetBSD IPv6 support doesn't work
-    ("connected" route is not auto-created, "route-ipv6" adding fails)
-
-    * fixed, 3.1.10 *
-
-3.) route deletion for IPv6 routes is not yet done
-
-    * fixed for configured routes, 3.1.10 *
-    * missing for manual-ifconfig-connected (NetBSD, Darwin, Win32)
-
-    * 2012-06-10 - fixed somewhere in 2010
-
-4.) do "ifconfig tun0 inet6 unplumb"  or "ifconfig tun0 destroy" for
-    Solaris, *BSD, ... at program termination time, to clean up leftovers
-    (unless tunnel persistance is desired).
-
-    For Solaris, only the "ipv6 tun0" is affected, for the *BSDs all tun0
-    stay around.
-
-    * 2012-06-10 - fixed in individual platform cleanups early-2012
-
-4a.) deconfigure IPv6 on tun interface on session termination, otherwise
-    one could end up with something like this (on NetBSD):
-
-tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
-        inet 10.9.0.18 -> 10.9.0.17 netmask 0xffffffff
-        inet6 fe80::a00:20ff:fece:d299%tun0 ->  prefixlen 64 scopeid 0x3
-        inet6 2001:608:4:eff::2000:3 ->  prefixlen 64
-        inet6 2001:608:4:eff::1:3 ->  prefixlen 64
-
-    (pool was changed, previous address still active on tun0, breakage)
-
-    * semi-fixed for NetBSD, 28.2.10, always do tun0 destroy / tun0 create
-      before actual ifconfig -- tunnel still lingers after OpenVPN quits
-
-    * 2011-09-16 fixed in platform cleanup, commit 8ca19c014c149cf69
-
-4b.) verify this - on FreeBSD, tun0 is auto-destroyed if created by
-     opening /dev/tun (and lingers if created by "ifconfig tun0 create")
-
-     -> use for persistant tunnels on not-linux?
-
-    * 2012-06-10 tun interface behaviour is documented in "man tun(4)"
-
-5.) add new option "ifconfig-ipv6-push"
-    (per-client static IPv6 assignment, -> radiusplugin, etc)
-
-    * implemented, 14.1.10 *
-
-6.) add new option "route-ipv6-gateway"
-
-    * 2012-06-09 - decided there is no current need (but fairly trivial)
-
-7.) add "full" gateway handling for IPv6 in route.c 
-    (right now, the routes are just sent down the tun interface, if the
-    operating system in questions supports that, without care for the
-    gateway address - which does not work for gateways that are supposed
-    to point elsewhere.  Also, it doesn't work for TAP interfaces.
-
-    * 2012-06-09 use "dev tun" for tun devices, "via $gateway" for tap
-		 (and purposely do not support off-link routes)
-
-8.) full IPv6 support for TAP interfaces 
-    (main issue should be routes+gateway - and testing :-) )
-
-    test 2010/09/24: TAP itself works on linux/ifconfig+iproute2, but 
-    route-via-tap doesn't work at all (route points to "tap0" which fails)
-
-17:51:14.075412 fe:ab:6e:c5:53:71 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: 2001:608:4:a053::1:0 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:608:4:a001::1, length 32
-
-    * 2012-06-09 missing gateway support implemented
-
-8a.)
-    how is iroute-via-tap supposed to work??
-
-    * 2012-06-10 - answer: not at all, OpenVPN doesn't do "iroute" in
-    tap mode - set up "route-ipv6" with gateway address = individual
-    client's tap0 address to get the per-client routes
-
-
-9.) verify that iroute-ipv6 and route-ipv6 interact in the same way as
-    documented for iroute/route:
-
-    A's subnet, OpenVPN must push this route to all clients
-    EXCEPT for A, since the subnet is already owned by A.
-    OpenVPN accomplishes this by not
-    not pushing a route to a client
-    if it matches one of the client's iroutes.
-
-10.) extend "ifconfig-ipv6" to handle specification of /netbits, pushing
-    of /netbits, and correctly ifconfig'ing this
-    (default, if not specified: /64)
-
-    * done * 2012-02-03
-
-11.) do not add ipv6-routes if tun-ipv6 is not set - complain instead
-
-     * done * 12.1.10
-
-12.) handle incoming [::] and [fe80:...] packets in tun-p2mp MULTI mode
-     (most likely those are DAD packets)
-     silently ignore DAD?  
-        Or accept-and-forward iff (multicast && client2client)?
-     handle NS/NA
-
-13.) from Martin List-Petersen:
-
-	One thing, and I guess this requires modifications in
-	network-manager-openvpn: It also works, BUT ignores "push
-	route-ipv6-gateway" and "push route-ipv6 ...." (obviously routes pushed
-	from the server) entirely.
-
-14.) from ##openvpn-discussion:
-
-	new features should be #ifdef'ed
-
-	(check whether this is feasible at all)
-
-15.) IPv6 related environment variables
-
-	- document all of them in openvpn.8
-	- make sure that all existing IPv4 stuff has IPv6 counterparts
-
-16.) OpenBSD
-	- implement ifconfig/route for IPv6
-	- revert ifconfig/open_tun order to "normal" (separate commit!!!)
-	  (openvpn-devel, Subject: OpenBSD)
-	- test
-
-    * 2012-02-05 platform cleanup, commit 82d4e12068774b0a6ca
-
-17.) client-option (Elwood)
-	- ignore-v6-push-options yes/no
-	- ignore-v6-route-push  ("as for IPv4 routes")
-
-18.) fail-save?  "what if 'ip -6 addr add' fails" -> fail, or fallback to v4?
-	(-> recomment setting "ignore-v6-push-options yes")
-
-19.) safety check: if connecting over IPv6 (v6 transport) and the pushed
-     route-ipv6 network encompasses the server IPv6 address, make sure 
-     we at least log a warning (until we can fiddle with external routing
-     to make this work correctly).
-
-20.) show "route add" / "route delete" commands for IPv6 in log file
-     (we show the "ifconfig" commands, so why not the routes?)
-
-     2010-08-07: this is a null-feature - it's already there, but with
-                 different debug level (M_INFO vs. D_ROUTE) so user 
-                 didn't notice
-
-21.) enable ipv6-only server operations
-      - decouple ipv6 pool handling from ipv4 pool
-      - make sure Rest of OpenVPN doesn't assume "there will always be IPv4"
-
-22.) implement --learn-address for IPv6
-
-23.) FreeBSD 8 seems to require explicit setting of the "ifconfig" IPv6
-     route, while FreeBSD 6+7 don't --> more testing, and code fix
-
-     workaround for the time being: just add
-
-	server-ipv6 2001:608:4:a051::/64
-	route-ipv6 2001:608:4:a051::/64
-
-    to the config
-
-    (problem + workaround applies both to tun and tap style devices)
-
-    * 2012-06-09 - this got fixed in one of the platform cleanups
-
-
-
-
-TODO for IPv6 transport support
--------------------------------
-
-[ Last updated: 2014-01-03. ]
-
-* All platforms:
-  o mgmt console: as currently passes straight in_addr_t bits around
-
-  o make possible to get AF from getaddrinfo() answer, ie allow openvpn to
-    use ipv4/6 if DNS returns A/AAAA without specifying protocol.
-    Hard: requires deep changes in initialization/calling logic
-    - Done by dual stack patches
-
-  o use AI_PASSIVE
-    - Done by dual stack patches
-
-  o the getaddr()/getaddr6() interface is not prepared for handling socktype
-    "tagging", currently I abuse the sockflags bits for getting the ai_socktype
-    downstream.
-    - Still done by flags, seems clean enough.
-
-  o implement comparison for mapped addesses: server in dual stack
-    listening IPv6 must permit incoming streams from allowed IPv4 peer,
-    currently you need to pass eg:  --remote ffff::1.2.3.4
-    - OpenVPN will compare all address of a remote
-      but will still fail on mapped addresses
-
-* win32:
-  o find out about mapped addresses, as I can't make it work
-    with bound at ::1 and connect to 127.0.0.1
-    - Should be fixed by 8832c6c - "Implement listing on IPv4/IPv6 dual 
-      socket on all platform"
-

build/Makefile.am

@@ -5,7 +5,7 @@
 #             packet encryption, packet authentication, and
 #             packet compression.
 #
-#  Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
+#  Copyright (C) 2002-2022 OpenVPN Inc <sales@openvpn.net>
 #
 
 MAINTAINERCLEANFILES = \

build/msvc/Makefile.am

@@ -5,7 +5,7 @@
 #             packet encryption, packet authentication, and
 #             packet compression.
 #
-#  Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
+#  Copyright (C) 2002-2022 OpenVPN Inc <sales@openvpn.net>
 #  Copyright (C) 2006-2012 Alon Bar-Lev <alon.barlev@gmail.com>
 #
 

build/msvc/msvc-generate/Makefile.am

@@ -5,7 +5,7 @@
 #             packet encryption, packet authentication, and
 #             packet compression.
 #
-#  Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
+#  Copyright (C) 2002-2022 OpenVPN Inc <sales@openvpn.net>
 #  Copyright (C) 2006-2012 Alon Bar-Lev <alon.barlev@gmail.com>
 #
 

build/msvc/msvc-generate/version.m4.in

+define([OPENVPN_VERSION_MAJOR], [@PRODUCT_VERSION_MAJOR@])
+define([OPENVPN_VERSION_MINOR], [@PRODUCT_VERSION_MINOR@])
+define([OPENVPN_VERSION_PATCH], [@PRODUCT_VERSION_PATCH@])

config-msvc-version.h.in

@@ -5,8 +5,8 @@
 #define PRODUCT_VERSION_MAJOR "@PRODUCT_VERSION_MAJOR@"
 #define PRODUCT_VERSION_MINOR "@PRODUCT_VERSION_MINOR@"
 #define PRODUCT_VERSION_PATCH "@PRODUCT_VERSION_PATCH@"
-#define PACKAGE_VERSION "@PRODUCT_VERSION_MAJOR@.@PRODUCT_VERSION_MINOR@.@PRODUCT_VERSION_PATCH@"
-#define PRODUCT_VERSION "@PRODUCT_VERSION_MAJOR@.@PRODUCT_VERSION_MINOR@.@PRODUCT_VERSION_PATCH@"
+#define PACKAGE_VERSION "@PRODUCT_VERSION_MAJOR@.@PRODUCT_VERSION_MINOR@@PRODUCT_VERSION_PATCH@"
+#define PRODUCT_VERSION "@PRODUCT_VERSION_MAJOR@.@PRODUCT_VERSION_MINOR@@PRODUCT_VERSION_PATCH@"
 #define PRODUCT_BUGREPORT "@PRODUCT_BUGREPORT@"
 #define OPENVPN_VERSION_RESOURCE @PRODUCT_VERSION_RESOURCE@
 #define TAP_WIN_COMPONENT_ID "@PRODUCT_TAP_WIN_COMPONENT_ID@"