dnl Process this file with m4 dnl to make real html. include(header.html) include(defs.html) define(sidebar_ad) openvpn_header(OpenVPN Release Notes, openvpn_tm Release Notes)
OpenVPN 2.0 focuses on improving scalability and offering centralized management for VPN configurations having a large numbers of clients, including features such as:
A highly scalable server for handling multiple TCP/UDP clients over point-to-point TUN interfaces, all using a single port number. The server has been designed for maximum efficiency and scalability, and should scale to hundreds or even thousands of clients where the hardware and network bandwidth can support it. The code includes a new O(N) scheduler based on a randomized treap binary tree algorithm plus efficient hash tables for looking up client instances.
The server configuration file is only slightly more complex than a configuration file for a single tunnel instance. The server-side crypto configuration is simplified by the use of TLS which allows any incoming client to be accepted if
The server is able to handle an arbitrary number of clients using a single TCP or UDP port, a single tun interface, and a single config file. As such, it is designed to not overly stress the OS even when its own client load is high. This means that the server can also run well on Windows which is not capable of scaling up to a large number of tun/tap interfaces.
The server configuration file adds serveral new options:
On the client side, pull has been added, which basically says "accept certain config file options which the server pushes back to you." There is obviously a security implication with push/pull in that the client is trusting the server to control its configuration. As such, the client is strict about what kind of options it will accept from the server, and (by default) will not accept any option which would cause file modification or script execution. The major win of the push/pull capability is that the same client configuration file can be used on each client provided each client has its own set of SSL/TLS keys which have been signed by the master CA.
A management interface has been developed which can be used to remotely control or centrally manage an OpenVPN daemon. The management interface can also be used to develop a GUI or web-based front-end application for OpenVPN.
The Windows TAP-Win32 driver has been extensively reworked based on some very good feedback I received from the microsoft.public.development.device.drivers newsgroup. The goal is to eliminate required reboots after install or uninstall on certain platforms such as Win2K. I would especially like to get feedback on whether this new driver fixes the rare problem of winsock corruption which has been reported to me by 3 users, but never reproduced by myself. Also, this driver lets you explicitly set the TAP adapter MAC address in the adapter advanced properties dialog, a feature that has been suggested by several of you. This driver should be backportable to OpenVPN 1.x.
The server mode requires TLS usage and will not work with static keys. I don't see this as really being a disadvantage because the major reason to use static keys in the first place is that they are very easy to configure. This advantage is lost in a scalable environment where potentially hundreds or thousands of client keys would need to be maintained by the server. On the other hand, SSL/TLS is a big win for scalability and server-side managment because the server only needs a single pair of SSL/TLS keys. It doesn't need to be personally familiar with every possible client, it only needs to check that a client's certificate was signed by the master CA certificate and that the client certificate is not in the CRL (certificate revocation list).
Note that static keys still work in 2.0 for point-to-point tunnels, just as they do in 1.x.
The server has been designed so that it can run with reduced privilege.
All 1.x features have been carried over to 2.0 except for the TLS thread feature.
For those of you who look at the source code, you will see major changes. In OpenVPN 1.x the tunnel state is basically maintained on the stack in the openvpn() function. In 2.0 an object has been added (called struct context) that fully encapsulates the state information of a tunnel instance. The openvpn() function is now small and consise, with most support code having been moved to init.c and forward.c.
remote can now specify a set of machines, or a hostname can be configured with multiple addresses in DNS. A server will be randomly chosen from the list, and if the connect fails, another will be tried (see the remote-random option).
To get OpenVPN 2.0 to talk with the 1.5/1.6 versions, put this in the 1.x config file:openvpn_command( [[tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 key-method 2]])
For TLS usage, key-method 2 is now the default.
Sample OpenVPN Configuration Files:
This release includes minor feature improvements and bugfixes.
See the Change Log for details.
This release contains some major additions, including:
See Compatibility Notes for information on protocol compatibility between different OpenVPN versions.
Also see the Compatibility Notes for an important change in the RedHat init script.
This is a bugfix release which fixes a build problem on 1.4.2 that affected some platforms, and which caused a compiler error in crypto.c. You don't need to upgrade unless you are affected by this problem.
See Compatibility Notes for information on protocol compatibility between different OpenVPN versions.
This maintenance release fixes a serious efficiency bug which occurs in previous 1.4.x releases under compilers which lack ISO C99 vararg macros. When you run ./configure, a line is output showing whether or not ISO C99 vararg macros are supported. If you are running 1.4.0 or 1.4.1 and ./configure shows that ISO C99 vararg macros are not supported, then you are affected by this bug.
A minimal patch exists to repair this bug in 1.4.0 or 1.4.1 distributions, for those who do not want a full upgrade.
Other changes include further stabilization of the experimental --mtu-dynamic option which causes OpenVPN to perform internal datagram fragmentation in cases where native IP fragmentation is broken.
New additions include an init script for Gentoo Linux.
This release fixes two bugs in 1.4.0, including a build issue on OpenBSD, and a bug under Linux 2.4 that can cause 100% CPU utilization if the --verb 0 option is used to suppress all output.
In addition, if a Linux 2.4 TUN/TAP open attempt fails, the code will now fall back to the 2.2 TUN/TAP interface and try again.
This release adds options for persistence of replay protection information across sessions, pass through of IPv4 TOS bits from the TUN/TAP device to the UDP link, some advanced MTU control options, moderate revamping of the build system to improve portability, and misc bug fixes and web site additions.
Also new is a major restructuring of MTU and fragmentation handling. Much of this code is experimental and must be explicitly enabled by defining FRAGMENT_ENABLE and rebuilding.
This release introduces a NetBSD port, IPv6 over tun support for Linux, support for inetd/xinetd instantiation of the openvpn daemon, a new RSA script that generates intermediate CAs, minor bug fixes, and documentation additions.
If you are trying to upgrade OpenVPN via an RPM package, there is a bug in the RPM uninstall script from 1.2.1 that doesn't handle RPM upgrades properly. The fix is to uninstall and reinstall using rpm -e and rpm -i. Once the 1.3.1 RPM is installed, then future RPM upgrades will work correctly, including the automatic restart logic that will shut down open tunnels and reopen them with the new version (using the openvpn.init script).
This is a housekeeping release containing minor fixes and finishing touches on larger features introduced in previous versions. The version number has incremented to 1.3.x due to a change in default MTU values.
The default values for --udp-mtu and --tun-mtu have been lowered to 1300 as a conservative measure to reduce the possibility of packet fragmentation and loss for users who do not explicitly set a value.
If you are using OpenVPN 1.3.0 to connect to previous versions of OpenVPN, you should set the MTU explicitly on both peers, keeping in mind that in pre-1.3.0 versions of OpenVPN, --udp-mtu defaulted to 1500 and --tun-mtu defaulted to 1450.
Binary RPMs are now provided for Red Hat 7.2 and 7.3 on the download page. See the INSTALL file for more information on building RPMs for other distributions.
OpenVPN 1.2.1 has been successfully tested with OpenSSL 0.9.7 Beta 1 and the AES cipher.
OpenVPN 1.2.1 revamps SIGUSR1 signal processing to make it like SIGHUP except with more fine-grained control over which OpenVPN subsystems are reset. It also allows a SIGUSR1 to be generated internally based on --ping and --ping-restart. The goal is to make OpenVPN as robust as possible on dynamic networks where DHCP, NAT, and firewalls must all be negotiated in a dynamic context. The --persist-tun option allows a reset without closing and reopening the tun device (which allows seamless connectivity through the tunnel across DHCP resets). The --persist-remote-ip option allows for preservation of remote IP address across DHCP resets. This allows both OpenVPN peers to be DHCP clients. The --persist-key option doesn't re-read key files on restart (which allows an OpenVPN daemon to be restarted even if its privileges were downgraded with --user).
Hostname resolution errors are now non-fatal, and the --resolv-retry option allows control over how many seconds we retry before we give up.
The --mute option has been added to limit repetitive logging of similar message types.
The --group option now allows a group ID downgrade after initialization, similar to the way that --user allows for a user ID downgrade.
Also changed is the pthread handling in the configure script. The script now uses the ACX_PTHREAD macro from the autoconf macro archive to intelligently figure out which cc/gcc option to use when building with POSIX thread support. Some problems were reported when trying to build OpenVPN with pthread support using gcc3.
OpenVPN 1.2.0 adds pthread support for background processing of SSL/TLS key negotiations, allowing efficient usage of large RSA keys (i.e. 2048 bits or larger). The OpenVPN web site has been considerably expanded, including a new HOWTO page that gives detailed instructions for setting up a complete telecommuting solution with firewall, VPN, NAT, and DHCP support. OpenVPN 1.2.0 has additional feature improvements including configuration file support and running daemon statistics via SIGUSR2.
Since version 1.1.1, OpenVPN has seen extensive porting activity, including ports to Solaris, OpenBSD, Mac OS X (Darwin), and 64-bit Linux.
NOTE: This version of OpenVPN no longer requires GNU automake/autoconf, so you can build with ./configure, make, and make install. If you are a developer or you would like to rebuild configure, then you will need at least version 1.6 of GNU automake and version 2.50 of GNU autoconf.openvpn_footer()