Release Notes for OpenVPN 2.0
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 client's certificate was signed by the master VPN CA, and
- the client certificate is not explicitly disallowed by a CRL
(certificate revocation list).
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:
- server, server-bridge, or ifconfig-pool
allows the server to manage a DHCP-like
pool of /30 subnets to be dynamically
allocated to client instances,
- push allows the server to push certain
options back to the client such as routes,
ifconfig endpoints, and DHCP
options for Windows machines without actually
requiring a DHCP server, and
- the new mode directive controls whether OpenVPN
will run in multi-client
UDP mode or classic peer-to-peer mode.
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).
Caveats:
To get OpenVPN 2.0 to talk with the 1.5/1.6 versions, put this in the 1.x
config file:
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:
http://openvpn.net/examples.html
Release Notes for OpenVPN 1.6.0
This release includes minor feature improvements and bugfixes.
See the Change Log for details.
Release Notes for OpenVPN 1.5.0
This release contains some major additions, including:
- Windows 2000/XP Support, including
support for running OpenVPN as a Windows service.
- Support for TCP as a tunnel transport protocol, using the
new --proto option.
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.
Release Notes for OpenVPN 1.4.3
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.
Release Notes for OpenVPN 1.4.2
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.
Release Notes for OpenVPN 1.4.1
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.
Release Notes for OpenVPN 1.4.0
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.
Release Notes for OpenVPN 1.3.2
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.
Release Notes for OpenVPN 1.3.1
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).
Release Notes for OpenVPN 1.3.0
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.
Release Notes for OpenVPN 1.2.1
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.
Release Notes for OpenVPN 1.2.0
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.
Copyright © 2002-2006 by OpenVPN Solutions LLC
<info@openvpn.net>.
OpenVPN is a trademark of OpenVPN Solutions LLC.
| 
