OpenVPN 2.5 released - Overview of changes



  • yes, i have upgrade to 2.5 in ubuntu system for test.

    Overview of changes in 2.5
    New features
    Client-specific tls-crypt keys (--tls-crypt-v2)
    tls-crypt-v2 adds the ability to supply each client with a unique tls-crypt key. This allows large organisations and VPN providers to profit from the same DoS and TLS stack protection that small deployments can already achieve using tls-auth or tls-crypt.
    ChaCha20-Poly1305 cipher support
    Added support for using the ChaCha20-Poly1305 cipher in the OpenVPN data channel.
    Improved Data channel cipher negotiation
    The option ncp-ciphers has been renamed to data-ciphers. The old name is still accepted. The change in name signals that data-ciphers is the preferred way to configure data channel ciphers and the data prefix is chosen to avoid the ambiguity that exists with --cipher for the data cipher and tls-cipher for the TLS ciphers.

    OpenVPN clients will now signal all supported ciphers from the data-ciphers option to the server via IV_CIPHERS. OpenVPN servers will select the first common cipher from the data-ciphers list instead of blindly pushing the first cipher of the list. This allows to use a configuration like data-ciphers ChaCha20-Poly1305:AES-256-GCM on the server that prefers ChaCha20-Poly1305 but uses it only if the client supports it.

    See the data channel negotiation section in the manual for more details.

    Removal of BF-CBC support in default configuration:
    By default OpenVPN 2.5 will only accept AES-256-GCM and AES-128-GCM as data ciphers. OpenVPN 2.4 allows AES-256-GCM,AES-128-GCM and BF-CBC when no --cipher and --ncp-ciphers options are present. Accepting BF-CBC can be enabled by adding

    data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
    and when you need to support very old peers also

    data-ciphers-fallback BF-CBC
    To offer backwards compatibility with older configs an explicit

    cipher BF-CBC
    in the configuration will be automatically translated into adding BF-CBC to the data-ciphers option and setting data-ciphers-fallback to BF-CBC (as in the example commands above). We strongly recommend to switching away from BF-CBC to a more secure cipher.

    Asynchronous (deferred) authentication support for auth-pam plugin.
    See src/plugins/auth-pam/README.auth-pam for details.
    Deferred client-connect
    The --client-connect option and the connect plugin API allow asynchronous/deferred return of the configuration file in the same way as the auth-plugin.
    Faster connection setup
    A client will signal in the IV_PROTO variable that it is in pull mode. This allows the server to push the configuration options to the client without waiting for a PULL_REQUEST message. The feature is automatically enabled if both client and server support it and significantly reduces the connection setup time by avoiding one extra packet round-trip and 1s of internal event delays.
    Netlink support
    On Linux, if configured without --enable-iproute2, configuring IP addresses and adding/removing routes is now done via the netlink(3) kernel interface. This is much faster than calling ifconfig or route and also enables OpenVPN to run with less privileges.

    If configured with --enable-iproute2, the ip command is used (as in 2.4). Support for ifconfig and route is gone.

    Wintun support
    On Windows, OpenVPN can now use wintun devices. They are faster than the traditional tap9 tun/tap devices, but do not provide --dev tap mode - so the official installers contain both. To use a wintun device, add --windows-driver wintun to your config (and use of the interactive service is required as wintun needs SYSTEM privileges to enable access).
    IPv6-only operation
    It is now possible to have only IPv6 addresses inside the VPN tunnel, and IPv6-only address pools (2.4 always required IPv4 config/pools and IPv6 was the "optional extra").
    Improved Windows 10 detection
    Correctly log OS on Windows 10 now.
    Linux VRF support
    Using the new --bind-dev option, the OpenVPN outside socket can now be put into a Linux VRF. See the "Virtual Routing and Forwarding" documentation in the man page.
    TLS 1.3 support
    TLS 1.3 support has been added to OpenVPN. Currently, this requires OpenSSL 1.1.1+. The options --tls-ciphersuites and --tls-groups have been added to fine tune TLS protocol options. Most of the improvements were also backported to OpenVPN 2.4 as part of the maintainance releases.
    Support setting DHCP search domain
    A new option --dhcp-option DOMAIN-SEARCH my.example.com has been defined, and Windows support for it is implemented (tun/tap only, no wintun support yet). Other platforms need to support this via --up script (Linux) or GUI (OSX/Tunnelblick).
    per-client changing of --data-ciphers or data-ciphers-fallback
    from client-connect script/dir (NOTE: this only changes preference of ciphers for NCP, but can not override what the client announces as "willing to accept")
    Handle setting of tun/tap interface MTU on Windows
    If IPv6 is in use, MTU must be >= 1280 (Windows enforces IETF requirements)
    Add support for OpenSSL engines to access private key material (like TPM).

    HMAC based auth-token support
    The --auth-gen-token support has been improved and now generates HMAC based user token. If the optional --auth-gen-token-secret option is used clients will be able to seamlessly reconnect to a different server using the same secret file or to the same server after a server restart.
    Improved support for pending authentication
    The protocol has been enhanced to be able to signal that the authentication should use a secondary authentication via web (like SAML) or a two factor authentication without disconnecting the OpenVPN session with AUTH_FAILED. The session will instead be stay in a authenticated state and wait for the second factor authentication to complete.

    This feature currently requires usage of the managent interface on both client and server side. See the management-notes.txt client-pending-auth and cr-response commands for more details.

    VLAN support
    OpenVPN servers in TAP mode can now use 802.1q tagged VLANs on the TAP interface to separate clients into different groups that can then be handled differently (different subnets / DHCP, firewall zones, ...) further down the network. See the new options --vlan-tagging, --vlan-accept, --vlan-pvid.

    802.1q tagging on the client side TAP interface is not handled today (= tags are just forwarded transparently to the server).

    Support building of .msi installers for Windows

    Allow unicode search string in --cryptoapicert option (Windows)

    Support IPv4 configs with /31 netmasks now
    (By no longer trying to configure ``broadcast x.x.x.x'' in ifconfig calls, /31 support "just works")
    New option --block-ipv6 to reject all IPv6 packets (ICMPv6)
    this is useful if the VPN service has no IPv6, but the clients might have (LAN), to avoid client connections to IPv6-enabled servers leaking "around" the IPv4-only VPN.
    --ifconfig-ipv6 and --ifconfig-ipv6-push will now accept
    hostnames and do a DNS lookup to get the IPv6 address to use
    Deprecated features
    For an up-to-date list of all deprecated options, see this wiki page: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions

    ncp-disable has been deprecated
    With the improved and matured data channel cipher negotiation, the use of ncp-disable should not be necessary anymore.
    inetd has been deprecated This is a very limited and not-well-tested way to run OpenVPN, on TCP and TAP mode only, which complicates the code quite a bit for little gain. To be removed in OpenVPN 2.6 (unless users protest).
    no-iv has been removed This option was made into a NOOP option with OpenVPN 2.4. This has now been completely removed.
    --client-cert-not-required has been removed This option will now cause server configurations to not start. Use --verify-client-cert none instead.
    --ifconfig-pool-linear has been removed This option is removed. Use --topology p2p or --topology subnet instead.
    --compress xxx is considered risky and is warned against, see below.
    --key-method 1 has been removed
    User-visible Changes
    If multiple connect handlers are used (client-connect, ccd, connect plugin) and one of the handler succeeds but a subsequent fails, the client-disconnect-script is now called immediately. Previously it was called, when the VPN session was terminated.
    Support for building with OpenSSL 1.0.1 has been removed. The minimum supported OpenSSL version is now 1.0.2.
    The GET_CONFIG management state is omitted if the server pushes the client configuration almost immediately as result of the faster connection setup feature.
    --compress is nowadays considered risky, because attacks exist leveraging compression-inside-crypto to reveal plaintext (VORACLE). So by default, --compress xxx will now accept incoming compressed packets (for compatibility with peers that have not been upgraded yet), but will not use compression outgoing packets. This can be controlled with the new option --allow-compression yes|no|asym.
    Stop changing --txlen aways from OS defaults unless explicitly specified in config file. OS defaults nowadays are actually larger then what we used to configure, so our defaults sometimes caused packet drops = bad performance.
    remove --writepid pid file on exit now
    plugin-auth-pam now logs via OpenVPN logging method, no longer to stderr (this means you'll have log messages in syslog or openvpn log file now)
    use ISO 8601 time format for file based logging now (YYYY-MM-DD hh:mm:dd) (syslog is not affected, nor is --machine-readable-output)
    --clr-verify now loads all CRLs if more than one CRL is in the same file (OpenSSL backend only, mbedTLS always did that)
    when --auth-user-pass file has no password, and the management interface is active, query management interface (instead of trying console query, which does not work on windows)
    skip expired certificates in Windows certificate store (--cryptoapicert)
    --socks-proxy + --proto udp* will now allways use IPv4, even if IPv6 is requested and available. Our SOCKS code does not handle IPv6+UDP, and before that change it would just fail in non-obvious ways.
    TCP listen() backlog queue is now set to 32 - this helps TCP servers that receive lots of "invalid" connects by TCP port scanners
    do no longer print OCC warnings ("option mismatch") about key-method, keydir, tls-auth and cipher - these are either gone now, or negotiated, and the warnings do not serve a useful purpose.
    dhcp-option DNS and dhcp-option DNS6 are now treated identically (= both accept an IPv4 or IPv6 address for the nameserver)
    Maintainer-visible changes
    the man page is now in maintained in .rst format, so building the openvpn.8 manpage from a git checkout now requires python-docutils (if this is missing, the manpage will not be built - which is not considered an error generally, but for package builders or make distcheck it is). Release tarballs contain the openvpn.8 file, so unless some .rst is changed, doc-utils are not needed for building.
    OCC support can no longer be disabled
    AEAD support is now required in the crypto library
    --disable-server has been removed from configure (so it is no longer possible to build a client-/p2p-only OpenVPN binary) - the saving in code size no longer outweighs the extra maintenance effort.
    --enable-iproute2 will disable netlink(3) support, so maybe remove that from package building configs (see above)
    support building with MSVC 2019
    cmocka based unit tests are now only run if cmocka is installed externally (2.4 used to ship a local git submodule which was painful to maintain)
    --disable-crypto configure option has been removed. OpenVPN is now always built with crypto support, which makes the code much easier to maintain. This does not affect --cipher none to do a tunnel without encryption.
    --disable-multi configure option has been removed


  • OpenVPN 2.5.0 just released.
    Do pfSense developers already have any plans for implementation OpenVPN 2.5.0 ?

  • Rebel Alliance Developer Netgate

    No specific plans, but we'll likely bring it into pfSense 2.5.0 once it makes its way into FreeBSD ports.


  • Is it safe to work with OVPN-Software 2.4.* in general or is it deprecated with this release of 2.5?


  • 2.5 ( edit : pfSense 2.5.0 that is) isn't out. It's only available to be "beta tested".

    If OpenVPN :

    OpenVPN 2.4.9 amd64-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] > built on May 4 2020

    wasn't 'safe', a newer version would be incorporated / back ported into pfSense 2.4.5-p1 - which would probably become 2.4.5-p2 and that's it.

    Guess what ? That isn't the case !
    So, I tend to say : it's safe.

    For the real answers : see the OpenVPN support sites.

  • Rebel Alliance Developer Netgate

    @Gertjan said in OpenVPN 2.5-beta 1 released - Overview of changes in 2.5:

    2.5 isn't out yet. Only available to be beta tested.

    No, it's released: https://openvpn.net/community-downloads/

    It's backward compatible as always, but there are some potential gotchas, mostly if you rely on something super weak like not specifying a ciper and expecting BF-CBC to be used by default everywhere. I'm not sure that applies to many people in practice, though.


  • My 2.5 was short for pfSense 2.5.0, as this version would use OpenVPN 2.5.
    2.4.5-p1 is using ..... well, you know.

    Sorry for the confusion.


  • @jimp said in OpenVPN 2.5-beta 1 released - Overview of changes in 2.5:

    It's backward compatible as always

    So it is good practice to use OVPN 2.5 in conjunction with pfSenses OVPN 2.4.*.


  • @Bob-Dig said in OpenVPN 2.5-beta 1 released - Overview of changes in 2.5:

    So it is good practice to use 2.5 in conjunction with pfSenses 2.4.*.

    As a client VPN in front of pfSense ?
    Or in-place upgrading of the pfSense - OpenVPN - core files ?? From 2.4.9 to 2.5.
    I which you good luck - tell us how you did it ;)

  • LAYER 8 Moderator

    @jimp isn't the data-ciphers parameter another problem? Current export packages export configs for 2.5.0clients with data-ciphers instead of ncp-ciphers. But even the config files for the 2.4.9 buttons contain that config statement that result in a

    Options error: Unrecognized option or missing or extra parameter(s) in fwl01-UDP4-1194-<username>.ovpn:5: data-ciphers (2.4.9)

    Isn't that something that needs to still be fixed?

  • Rebel Alliance Developer Netgate

    There is probably a flaw in my logic in there, I made it so that if you checked the Legacy box it changed over to ncp- rather than data- but I must have missed making it assume legacy mode when exporting 2.4.x.

  • LAYER 8 Moderator

    @jimp said in OpenVPN 2.5 released - Overview of changes in 2.5:

    There is probably a flaw in my logic in there, I made it so that if you checked the Legacy box it changed over to ncp- rather than data- but I must have missed making it assume legacy mode when exporting 2.4.x.

    Ah thought so :)
    That exploded at a customers location today as the exported the config to a system that is still on 2.4.9 that threw errors. Then exported the 2.4.9 exe again - still errors. Fixed it after calling us by installing 2.5.0 over it but it's a weak point ATM. Perhaps the legacy section needs a config only point to export 2.4.x compat config. Not all admins have access to all clients' PCs or laptops. Mostly they already have ovpn installed so only send new configs that now don't work anymore but users may not be able to install new software themselves.

  • Rebel Alliance Developer Netgate

    I found a few problems with how I was building the cipher list for pfSense 2.5.0/2.4.5 and OpenVPN 2.5.0/2.4.x. I just pushed a fix, it'll be up shortly and should hopefully work for everyone.

  • Rebel Alliance Developer Netgate

    And just when I thought I found them all, I came up with a couple more edge cases/incompatible cases that I addressed. New package is building and will be up shortly.

    Hopefully now it's impossible to create a config with an empty cipher set or incompatible ciphers. For example now you can't set CHACHA20-POLY1305 on legacy clients (OpenVPN 2.4.x and older)