Skip to content
GitLab
Expand all Show whitespace changes
Inline Side-by-side
PORTS
View file @ e1e1377b
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 deleted 100644 → 0
View file @ e3856827
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 0 → 100644
View file @ e1e1377b
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 0 → 100644
View file @ e1e1377b
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
View file @ e1e1377b
......@@ -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 0 → 100644
View file @ e1e1377b
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 deleted 100644 → 0
View file @ e3856827
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"
aclocal.m4 deleted 100644 → 0
View file @ e3856827
This diff is collapsed.
build/Makefile.am
View file @ e1e1377b
......@@ -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/Makefile.in deleted 100644 → 0
View file @ e3856827
This diff is collapsed.
build/msvc/Makefile.am
View file @ e1e1377b
......@@ -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/Makefile.in deleted 100644 → 0
View file @ e3856827
This diff is collapsed.
build/msvc/msvc-generate/Makefile.am
View file @ e1e1377b
......@@ -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.in deleted 100644 → 0
View file @ e3856827
This diff is collapsed.
build/msvc/msvc-generate/Makefile.mak
View file @ e1e1377b
This diff is collapsed.
build/msvc/msvc-generate/version.m4.in 0 → 100644
View file @ e1e1377b
define([OPENVPN_VERSION_MAJOR], [@PRODUCT_VERSION_MAJOR@])
define([OPENVPN_VERSION_MINOR], [@PRODUCT_VERSION_MINOR@])
define([OPENVPN_VERSION_PATCH], [@PRODUCT_VERSION_PATCH@])
compat.m4
View file @ e1e1377b
This diff is collapsed.
compile deleted 100755 → 0
View file @ e3856827
This diff is collapsed.
config-msvc-version.h.in
View file @ e1e1377b
......@@ -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@"
......