openvpn/Changes.rst

255 lines
12 KiB
ReStructuredText
Raw Normal View History

Version 2.4.0
=============
New features
------------
Peer ID support
Added new packet format P_DATA_V2, which includes peer-id. If
server and client support it, client sends all data packets in
the new format. When data packet arrives, server identifies peer
by peer-id. If peer's ip/port has changed, server assumes that
client has floated, verifies HMAC and updates ip/port in internal structs.
Cipher negotiation
Data channel ciphers are now by default negotiated. If a client advertises
support for Negotiable Crypto Parameters (NCP), the server will choose a
cipher (by default AES-256-GCM) for the data channel, and tell the client
to use that cipher. Data channel cipher negotiation can be controlled
using ``--ncp-ciphers`` and ``--ncp-disable``.
Add an option to filter options received from server v2 changes: - Add the flag "ignore" and have "reject" trigger a restart. - Unlimited number of filters: yes, going against the consensus, but the code looks simpler and cleaner this way. - New commit message to reflect the changes. Usage: --pull-filter accept|ignore|reject "option" Permit a client to selectively accept, ignore or reject options pushed by the server. May be used multiple times. The filters are applied in the order specified to each pushed option received. The filtering stops as soon as a match is found. The action "ignore" removes the option and continues processing the next option, while "reject" flags an error and restarts the connection with SIGUSR1. Prefix matching is used so that all options starting with the specified "option" string are filtered. Example: pull-filter accept "route 192.168." pull-filter ignore "route " pull-filter accept "ifconfig 10.9.0." pull-filter reject "ifconfig " will ignore all pushed routes except those starting with "192.168." and reject the assigned ip unless its in the "10.9.0.0/24" range. A match of the reject filter will trigger a restart. SIGUSR1 restart is used instead of SIGHUP so as to try the next remote for reconnection. Note the space at the end of "route " to not reject "route-gateway", for example. All options not matched by any filter are accepted. Acknowledges shameless imitation of --push-remove. Inspired by Trac #682. Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <1465162884-32520-1-git-send-email-selva.nair@gmail.com> URL: http://article.gmane.org/gmane.network.openvpn.devel/11808 Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-06-06 05:41:23 +08:00
A more limited version also works in client-to-server and server-to-client
scenarios where one of the end points uses a v2.4 client or server and the
other side uses an older version. In such scenarios the v2.4 side will
change to the ``--cipher`` set by the remote side, if permitted by by
``--ncp-ciphers``. For example, a v2.4 client with ``--cipher BF-CBC``
and ``ncp-ciphers AES-256-GCM:AES-256-CBC`` can connect to both a v2.3
server with ``cipher BF-CBC`` as well as a server with
``cipher AES-256-CBC`` in its config. The other way around, a v2.3 client
with either ``cipher BF-CBC`` or ``cipher AES-256-CBC`` can connect to a
v2.4 server with e.g. ``cipher BF-CBC`` and
``ncp-ciphers AES-256-GCM:AES-256-CBC`` in its config. For this to work
it requires that OpenVPN was built without disabling OCC support.
AEAD (GCM) data channel cipher support
The data channel now supports AEAD ciphers (currently only GCM). The AEAD
packet format has a smaller overhead than the CBC packet format, (e.g. 20
bytes per packet for AES-128-GCM instead of 36 bytes per packet for
AES-128-CBC + HMAC-SHA1).
ECDH key exchange
The TLS control channel now supports for elliptic curve diffie-hellmann
key exchange (ECDH).
Dualstack client connect
Instead of only using the first address of each ``--remote`` OpenVPN
will now try all addresses (IPv6 and IPv4) of a ``--remote`` entry.
Support for providing IPv6 DNS servers
A new DHCP sub-options ``DNS6`` is added alongside with the already existing
``DNS`` sub-option. This is used to provide DNS resolvers available over
IPv6. This will be pushed to clients and `` --up`` scripts and ``--plugin``
can act upon it through the ``foreign_option_<n>`` environment variables.
Support for the Windows client picking up this new sub-option is added,
however IPv6 DNS resolvers needs to be configured via ``netsh`` which requires
administrator privileges if the new interactive services on Windows is not
being used. If the interactive services is used, this service will execute
``netsh`` in the background with the proper privileges.
New improved Windows Background service
The new OpenVPNService is based on openvpnserv2, a complete rewrite of the OpenVPN
service wrapper. It is intended for launching OpenVPN instances that should be
up at all times, instead of being manually launched by a user. OpenVPNService is
able to restart individual OpenVPN processes if they crash, and it also works
properly on recent Windows versions. OpenVPNServiceLegacy tends to work poorly,
if at all, on newer Windows versions (8+) and its use is not recommended.
New interactive Windows service
The installer starts OpenVPNServiceInteractive automatically and configures
it to start at system startup.
The interactive Windows service allows unprivileged users to start
OpenVPN connections in the global config directory (usually
C:\Program Files\OpenVPN\config) using OpenVPN GUI without any
extra configuration.
Users who belong to the built-in Administrator group or to the
local "OpenVPN Administrator" group can also store configuration
files under %USERPROFILE%\OpenVPN\config for use with the
interactive service.
redirect-gateway ipv6
OpenVPN has now feature parity between IPv4 and IPv6 for redirect
gateway including the handling of overlapping IPv6 routes with
IPv6 remote VPN server address
LZ4 Compression and pushable compression
Additionally to LZO compression OpenVPN now also supports LZ4 compression.
Compression options are now pushable from the server.
pull-filter
New option to explicitly allow or reject options pushed by the server.
May be used multiple times and is applied in the order specified.
push-remove
new option to remove options on a per-client basis from the "push" list
(more fine-grained than ``--push-reset``)
Http proxy password inside config file
Http proxy passwords can be specified with the inline file option
``<http-proxy-user-pass>`` .. ``</http-proxy-user-pass>``
Windows version
Windows version is detected, logged and possibly signalled to server
(IV_PLAT_VER=<nn> if ``--push-peer-info`` is set on client)
Authentication tokens
In situations where it is not suitable to save users passwords on the client
OpenVPN have since v2.3 had support for --auth-token. This option is
pushed from the server to the client with a token value to be used instead
of the users password. For this to work, the authentication plug-in would
need to implement this support as well. In OpenVPN 2.4 --auth-gen-token
is introduced, which will allow the OpenVPN server to generate a random
token and push it to the client without any changes to the authentication
modules. When the clients need to re-authenticate the OpenVPN server will
instead of sending the re-authentication request to the authentication
module do the authentication internally. This feature is especially
useful in configurations which adds One Time Password (OTP) authentication
schemes, as this allows the tunnel to be renegotiated regularly without
any need to supply new OTP codes.
keying-material-exporter
Keying Material Exporter [RFC-5705] allow additional keying material to be
derived from existing TLS channel.
Add AEAD cipher support (GCM) Add Authenticated Encryption with Additional Data (AEAD) support for ciphers, which removes the need for a separate HMAC step. The MAC is integrated into the cipher and the MAC tag is prepended to the payload. This patch is inspired by the patch originally submitted by Kenny Root on the openvpn-devel mailinglist, but does a number things differently: * Don't support XTS (makes no sense for VPN) * Don't support CCM (needs extra code to make it actually work) * Don't force the user to specify "auth none" (that would break tls-auth) * Add support for PolarSSL (and change internal API for this) * Update openvpn frame size ('link mtu') calculation for AEAD modes * Use the HMAC key as an implicit part of the IV to save 8 bytes per data channel network packet. * Also authenticate the opcode/peer-id as AD in P_DATA_V2 packets. By using the negotiated HMAC key as an implicit part of the IV for AEAD-mode ciphers in TLS mode, we can save (at least) 8 bytes on each packet sent. This is particularly interesting for connections which transfer many small packets, such as remote desktop or voip connections. The current AEAD-mode ciphers (for now GCM) are based on CTR-mode cipher operation, which requires the IV to be unique (but does not require unpredictability). IV uniqueness is guaranteed by using a combination of at least 64-bits of the HMAC key (unique per TLS session), and a 32-bit packet counter. The last 32-bit word of the 128-bit cipher block is not part of the IV, but is used as a block counter. AEAD cipher mode is not available for static key mode, since IV uniqueness is harder the guarantee over sessions, and I believe supporting AEAD in static key mode too is not worth the extra complexity. Modern setups should simply use TLS mode. OpenSSL 1.0.1-1.0.1c will not work with AEAD mode, because those versions have an unnecessary check that fails to update the cipher if the tag was not already set. 1.0.1d, which fixes that, was released in February 2013. People should have updated, and distros should have backported the fix by now. Changes in v2: * Remove extra code that was just for making OpenSSL 1.0.1-1.0.1c work in AEAD mode. * Do not make AEAD support configurable in ./configure. * Get rid of '12' magic constant in openvpn_encrypt_aead(). * Update manpage to explain that --auth is ignored for the data channel when using an AEAD cipher. * Move setting the IV in AEAD cipher modes to the IV generation code. This is a more natural place and now we can pull iv[] into the IV generation scope. * Read packet ID directly from packet buffer instead of from iv buffer, to remove the need for an extra buffer. Signed-off-by: Steffan Karger <steffan@karger.me> Acked-by: Arne Schwabe <arne@rfc2549.org> Message-Id: <CAA1AbxL_S4umZr5Nd0VTvUvXEHjoWmji18GqM6FgmWqntOKqaA@mail.gmail.com> URL: http://article.gmane.org/gmane.network.openvpn.devel/11162 Signed-off-by: Gert Doering <gert@greenie.muc.de>
2015-10-24 22:44:09 +08:00
Mac OS X Keychain management client
added contrib/keychain-mcd which allows to use Mac OS X keychain
certificates with OpenVPN
Android platform support
Support for running on Android using Android's VPNService API has been added.
See doc/android.txt for more details. This support is primarily used in
the OpenVPN for Android app (https://github.com/schwabe/ics-openvpn)
AIX platform support
AIX platform support has been added. The support only includes tap
devices since AIX does not provide tun interface.
Add control channel encryption (--tls-crypt) This adds a --tls-crypt option, which uses a pre-shared static key (like the --tls-auth key) to encrypt control channel packets. Encrypting control channel packets has three main advantages: * It provides more privacy by hiding the certificate used for the TLS connection. * It is harder to identify OpenVPN traffic as such. * It provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy). Control channel packet encryption --------------------------------- We propose to use the following encryption method, based on the SIV construction [0], to achieve nonce misuse-resistant authenticated encryption: msg = control channel plaintext header = opcode (1 byte) || session_id (8 bytes) || packet_id (8 bytes) Ka = authentication key (256 bits) Ke = encryption key (256 bits) (Ka and Ke are pre-shared keys, like with --tls-auth) auth_tag = HMAC-SHA256(Ka, header || msg) IV = 128 most-significant bits of auth_tag ciph = AES256-CTR(Ke, IV, msg) output = Header || Tag || Ciph This boils down to the following on-the-wire packet format: -opcode- || -session_id- || -packet_id- || auth_tag || * payload * Where - XXX - means authenticated, and * XXX * means authenticated and encrypted. Which is very similar to the current tls-auth packet format, and has the same overhead as "--tls-auth" with "--auth SHA256". The use of a nonce misuse-resistant authenticated encryption scheme allows us to worry less about the risks of nonce collisions. This is important, because in contrast with the data channel in TLS mode, we will not be able to rotate tls-crypt keys often or fully guarantee nonce uniqueness. For non misuse-resistant modes such as GCM [1], [2], the data channel in TLS mode only has to ensure that the packet counter never rolls over, while tls-crypt would have to provide nonce uniqueness over all control channel packets sent by all clients, for the lifetime of the tls-crypt key. Unlike with tls-auth, no --key-direction has to be specified for tls-crypt. TLS servers always use key direction 1, and TLS clients always use key direction 2, which means that client->server traffic and server->client traffic always use different keys, without requiring configuration. Using fixed, secure, encryption and authentication algorithms makes both implementation and configuration easier. If we ever want to, we can extend this to support other crypto primitives. Since tls-crypt should provide privacy as well as DoS protection, these should not be made negotiable. Security considerations: ------------------------ tls-crypt is a best-effort mechanism that aims to provide as much privacy and security as possible, while staying as simple as possible. The following are some security considerations for this scheme. 1. The same tls-crypt key is potentially shared by a lot of peers, so it is quite likely to get compromised. Once an attacker acquires the tls-crypt key, this mechanism no longer provides any security against the attacker. 2. Since many peers potentially use the tls-crypt key for a long time, a lot of data might be encrypted under the tls-crypt key. This leads to two potential problems: * The "opcode || session id || packet id" combination might collide. This might happen in larger setups, because the session id contains just 64 bits or random. Using the uniqueness requirement from the GCM spec [3] (a collision probability of less than 2^(-32)), uniqueness is achieved when using the tls-crypt key for at most 2^16 (65536) connections per process start. (The packet id includes the daemon start time in the packet ID, which should be different after stopping and (re)starting OpenPVN.) And if a collision happens, an attacker can *only* learn whether colliding packets contain the same plaintext. Attackers will not be able to learn anything else about the plaintext (unless the attacker knows the plaintext of one of these packets, of course). Since the impact is limited, I consider this an acceptable remaining risk. * The IVs used in encryption might collide. When two IVs collide, an attacker can learn the xor of the two plaintexts by xorring the ciphertexts. This is a serious loss of confidentiality. The IVs are 128-bit, so when HMAC-SHA256 is a secure PRF (an assumption that must also hold for TLS), and we use the same uniqueness requirement from [3], this limits the total amount of control channel messages for all peers in the setup to 2^48. Assuming a large setup of 2^16 (65536) clients, and a (conservative) number of 2^16 control channel packets per connection on average, this means that clients may set up 2^16 connections on average. I think these numbers are reasonable. (I have a follow-up proposal to use client-specific tls-auth/tls-crypt keys to partially mitigate these issues, but let's tackle this patch first.) References: ----------- [0] Rogaway & Shrimpton, A Provable-Security Treatment of the Key-Wrap Problem, 2006 (https://www.iacr.org/archive/eurocrypt2006/40040377/40040377.pdf) [1] Ferguson, Authentication weaknesses in GCM, 2005 (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferg uson2.pdf) [2] Joux, Authentication Failures in NIST version of GCM, 2006 (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/800-38_Serie s-Drafts/GCM/Joux_comments.pdf) [3] Dworking, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 2007 (http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf) Patch history: -------------- v2 - processed Arne's review comments: * Error out early with a clear error message when AES-256-CTR or HMAC-SHA-256 are not supported by the crypto library. * Clarify that cipher_ctx_reset() sets the IV. v3 - actually add error messages promised in v2... Signed-off-by: Steffan Karger <steffan.karger@fox-it.com> Acked-by: Arne Schwabe <arne@rfc2549.org> Message-Id: <1479216586-20078-1-git-send-email-steffan.karger@fox-it.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13069.html Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-11-15 21:29:46 +08:00
Control channel encryption (``--tls-crypt``)
Use a pre-shared static key (like the ``--tls-auth`` key) to encrypt control
channel packets. Provides more privacy, some obfuscation and poor-man's
post-quantum security.
Add AEAD cipher support (GCM) Add Authenticated Encryption with Additional Data (AEAD) support for ciphers, which removes the need for a separate HMAC step. The MAC is integrated into the cipher and the MAC tag is prepended to the payload. This patch is inspired by the patch originally submitted by Kenny Root on the openvpn-devel mailinglist, but does a number things differently: * Don't support XTS (makes no sense for VPN) * Don't support CCM (needs extra code to make it actually work) * Don't force the user to specify "auth none" (that would break tls-auth) * Add support for PolarSSL (and change internal API for this) * Update openvpn frame size ('link mtu') calculation for AEAD modes * Use the HMAC key as an implicit part of the IV to save 8 bytes per data channel network packet. * Also authenticate the opcode/peer-id as AD in P_DATA_V2 packets. By using the negotiated HMAC key as an implicit part of the IV for AEAD-mode ciphers in TLS mode, we can save (at least) 8 bytes on each packet sent. This is particularly interesting for connections which transfer many small packets, such as remote desktop or voip connections. The current AEAD-mode ciphers (for now GCM) are based on CTR-mode cipher operation, which requires the IV to be unique (but does not require unpredictability). IV uniqueness is guaranteed by using a combination of at least 64-bits of the HMAC key (unique per TLS session), and a 32-bit packet counter. The last 32-bit word of the 128-bit cipher block is not part of the IV, but is used as a block counter. AEAD cipher mode is not available for static key mode, since IV uniqueness is harder the guarantee over sessions, and I believe supporting AEAD in static key mode too is not worth the extra complexity. Modern setups should simply use TLS mode. OpenSSL 1.0.1-1.0.1c will not work with AEAD mode, because those versions have an unnecessary check that fails to update the cipher if the tag was not already set. 1.0.1d, which fixes that, was released in February 2013. People should have updated, and distros should have backported the fix by now. Changes in v2: * Remove extra code that was just for making OpenSSL 1.0.1-1.0.1c work in AEAD mode. * Do not make AEAD support configurable in ./configure. * Get rid of '12' magic constant in openvpn_encrypt_aead(). * Update manpage to explain that --auth is ignored for the data channel when using an AEAD cipher. * Move setting the IV in AEAD cipher modes to the IV generation code. This is a more natural place and now we can pull iv[] into the IV generation scope. * Read packet ID directly from packet buffer instead of from iv buffer, to remove the need for an extra buffer. Signed-off-by: Steffan Karger <steffan@karger.me> Acked-by: Arne Schwabe <arne@rfc2549.org> Message-Id: <CAA1AbxL_S4umZr5Nd0VTvUvXEHjoWmji18GqM6FgmWqntOKqaA@mail.gmail.com> URL: http://article.gmane.org/gmane.network.openvpn.devel/11162 Signed-off-by: Gert Doering <gert@greenie.muc.de>
2015-10-24 22:44:09 +08:00
Deprecated features
-------------------
- ``--key-method 1`` is deprecated in 2.4 and will be removed in 2.5. Migrate
away from ``--key-method 1`` as soon as possible. The recommended approach
is to remove the ``--key-method`` option from the configuration files, OpenVPN
will then use ``--key-method 2`` by default. Note that this requires changing
the option in both the client and server side configs.
- CRLs are now handled by the crypto library (OpenSSL or mbed TLS), instead of
inside OpenVPN itself. The crypto library implementations are more strict
than the OpenVPN implementation was. This might reject peer certificates
that would previously be accepted. If this occurs, OpenVPN will log the
crypto library's error description.
- ``--tls-remote`` is removed in 2.4, as indicated in the 2.3 man-pages. A similar
functionality is provided via ``--verify-x509-name`` which does the same job in
a better way.
- ``--compat-names`` and ``--no-name-remapping`` was deprecated in 2.3 and will
be removed in 2.5. All scripts and plug-ins depending on the old non-standard
X.509 subject formatting must be updated to the standardized formatting. See
the man page for more information.
User-visible Changes
--------------------
- For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields
are now exported to the environment, where each second and later occurrence
of a field get _$N appended to it's field name, starting at N=1. For the
example above, that would result in e.g. X509_0_OU=one, X509_0_OU_1=two.
Note that this breaks setups that rely on the fact that OpenVPN would
previously (incorrectly) only export the last occurence of a field.
- proto udp and proto tcp specify to use IPv4 and IPv6. The new
options proto udp4 and tcp4 specify to use IPv4 only.
- ``--sndbuf`` and ``--recvbuf`` default now to OS defaults instead of 64k
- OpenVPN exits with an error if an option has extra parameters;
previously they were silently ignored
- The default of ``--tls-cipher`` is now "DEFAULT:!EXP:!PSK:!SRP:!kRSA"
instead of "DEFAULT" to always select perfect forward security
cipher suites
- ``--tls-auth`` always requires OpenVPN static key files and will no
longer work with free form files
- ``--proto udp6/tcp6`` in server mode will now try to always listen to
both IPv4 and IPv6 on platforms that allow it. Use ``--bind ipv6only``
to explicitly listen only on IPv6.
- Removed ``--enable-password-save`` from configure. This option is now
always enabled.
- Stricter default TLS cipher list (override with ``--tls-cipher``), that now
also disables:
* Non-ephemeral key exchange using static (EC)DH keys
* DSS private keys
- mbed TLS builds: changed the tls_digest_N values exported to the script
environment to be equal to the ones exported by OpenSSL builds, namely
the certificate fingerprint (was the hash of the 'to be signed' data).
- mbed TLS builds: minimum RSA key size is now 2048 bits. Shorter keys will
not be accepted, both local and from the peer.
- ``--connect-timeout`` specifies now the timeout until the first TLS packet
is received (identical to ``--server-poll-timeout``) and this timeout now
includes the removed socks proxy timeout and http proxy timeout.
In ``--static`` mode connect-timeout specifies the timeout for TCP and
proxy connection establishment
- ``--connect-retry-max`` now specifies the maximum number of unsuccessful
attempts of each remote/connection entry before exiting.
- ``--http-proxy-timeout`` and the static non-changeable socks timeout (5s)
have been folded into a "unified" ``--connect-timeout`` which covers all
steps needed to connect to the server, up to the start of the TLS exchange.
The default value has been raised to 120s, to handle slow http/socks
proxies graciously. The old "fail TCP fast" behaviour can be achieved by
adding "``--connect-timeout 10``" to the client config.
- ``--http-proxy-retry`` and ``--sock-proxy-retry`` have been removed. Proxy connections
will now behave like regular connection entries and generate a USR1 on failure.
- ``--connect-retry`` gets an optional second argument that specifies the maximum
Exponentially back off on repeated connect retries - When the number of retries per remote exceeds a limit (hard coded to 5), double the restart pause interval for each additional retry per remote. - Trigger a SIGHUP to reset the retry count when the pause interval exceeds 1024 times the base value of restart pause. (removed in v2 of the patch) The base value of restart pause is set using --connect-retry (5 seconds by default). v2 changes (based on suggestions from Arne Schwabe <arne@rfc2549.org>) - Do not throw SIGHUP. - Add an optional argument to "--connect-retry n [m]" where 'm' specifies the max value of restart pause interval (default 300 sec). E.g., "--connect-retry 5 1800" will cause the restart pause to scale up starting at 5 until it exceeds 1800 seconds at which point it gets capped at 1800. - If n == m no slow down will occur. - While at it, fix typos and clarify the description of connect-retry-max in the man page and Changes.rst v3 changes (on further feedback from arne@rfc2549.org): - Limiting the base value of retry wait interval to 16 bits moved to options.c - Apply backoff only in the udp and tcp-client modes. Backing off on tcp-server could be exploited by a client in p2p-mode to maliciously slow it down (thanks to Arne Schwabe for pointing this out. - Fix typo in Changes.rst: "third argument" -> "second argument" Signed-off-by: Selva Nair <selva.nair@gmail.com> Acked-by: Arne Schwabe <arne@rfc2549.org> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <1467732770-19110-1-git-send-email-selva.nair@gmail.com> URL: http://article.gmane.org/gmane.network.openvpn.devel/12050 Signed-off-by: Gert Doering <gert@greenie.muc.de>
2016-07-05 23:32:50 +08:00
time in seconds to wait between reconnection attempts when an exponential
backoff is triggered due to repeated retries. Default = 300 seconds.
- Data channel cipher negotiation (see New features section) can override
ciphers configured in the config file. Use ``--ncp-disable`` if you do not want
this behavior.
Remove tun-ipv6 Option. Instead assume that IPv6 is always supported. This option was useful when IPv6 tun support was non standard and was an internal/user specified flag that tracked the Ipv6 capability of the tun device. All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so not putting tun-ipv6 does not forbid ipv6 addresses. This commit also clean up a bit of the ipv6 related tun.c. Changes for most platforms are minimal. For linux a bit more cleanup is done: - Remove compatibility defines that were added 2008 - Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun setups (Android also always IFF_NO_PI works fine with Ipv6). This commit also remove a non ipv6 fallback for tap driver from OpenVPN 2.2-beta or earlier and only warns. Patch V2: Integrate Gert's comments Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there it was wrong since it should on the transport protocol if at all Patch V4: Completely remove support for NetBSD <= 4.0 and remove NETBSD_MULTI_AF defines Patch V5: Assume generic OS in tun.c is also IPv6 capable. Add changes to man page. Fix typos/change message as suggest by David. Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <1476377656-3150-1-git-send-email-arne@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12695.html Signed-off-by: David Sommerseth <davids@openvpn.net>
2016-10-14 00:54:16 +08:00
- All tun devices on all platforms are always considered to be IPv6
capable. The ``--tun-ipv6`` option is ignored (behaves like it is always
Remove tun-ipv6 Option. Instead assume that IPv6 is always supported. This option was useful when IPv6 tun support was non standard and was an internal/user specified flag that tracked the Ipv6 capability of the tun device. All supported OS support IPv6. Also tun-ipv6 is pushable by the remote so not putting tun-ipv6 does not forbid ipv6 addresses. This commit also clean up a bit of the ipv6 related tun.c. Changes for most platforms are minimal. For linux a bit more cleanup is done: - Remove compatibility defines that were added 2008 - Always use IFF_NO_PI for the linux tun and not only for IPv4 only tun setups (Android also always IFF_NO_PI works fine with Ipv6). This commit also remove a non ipv6 fallback for tap driver from OpenVPN 2.2-beta or earlier and only warns. Patch V2: Integrate Gert's comments Patch V3: Remove tun_ipv4 option. It only used for MTU discovery and there it was wrong since it should on the transport protocol if at all Patch V4: Completely remove support for NetBSD <= 4.0 and remove NETBSD_MULTI_AF defines Patch V5: Assume generic OS in tun.c is also IPv6 capable. Add changes to man page. Fix typos/change message as suggest by David. Signed-off-by: Arne Schwabe <arne@rfc2549.org> Acked-by: David Sommerseth <davids@openvpn.net> Acked-by: Gert Doering <gert@greenie.muc.de> Message-Id: <1476377656-3150-1-git-send-email-arne@rfc2549.org> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12695.html Signed-off-by: David Sommerseth <davids@openvpn.net>
2016-10-14 00:54:16 +08:00
on).
- On the client side recursively routed packets, which have same destination
as the VPN server, are dropped. This could be disabled with
--allow-recursive-routing option.
Maintainer-visible changes
--------------------------
- OpenVPN no longer supports building with crypto support, but without TLS
support. As a consequence, OPENSSL_CRYPTO_{CFLAGS,LIBS} and
OPENSSL_SSL_{CFLAGS,LIBS} have been merged into OPENSSL_{CFLAGS,LIBS}. This
is particularly relevant for maintainers who build their own OpenSSL library,
e.g. when cross-compiling.