install-win32.txt

OpenVPN is a robust and highly flexible tunneling application that uses all of the encryption, authe

Note that OpenVPN 1.5-beta8 and higher will execute the
"arp -d *" command automatically, unless explicitly
disabled with the --no-arp-del option.

Notes -- Limitations
--------------------

The following features which are normally available in the
Posix version of OpenVPN are either missing or implemented
differently in the Windows version as of 1.5-beta3.

(1) Only TAP virtual devices are supported on Windows, not
    TUN devices.  This means that OpenVPN on Windows can
    only connect to other platforms which also support
    TAP devices.

(2) --shaper doesn't work yet due to the lack of a
    gettimeofday library function.  This is not difficult
    to fix and could be implemented by borrowing some code
    from the cygwin library.

(3) Windows doesn't support Posix-style signals directly, however
    when OpenVPN is run from a command prompt window,
    keyboard shortcuts have been set up to simulate signals
    using the following mapping: F1:USR1 F2:USR2 F3:HUP F4:TERM.
    When running as a service, the OpenVPN service wrapper
    will send a terminate signal to all OpenVPN subprocesses when
    it gets a stop signal from the SCM (Service Control Manager).

Notes -- Differences between TAP-Win32 driver and CIPE driver
-------------------------------------------------------------

The TAP-Win32 driver distributed with OpenVPN 1.5-beta5 and
later is derived from Cipe-Win32 2.0-pre15 with some
significant changes:

(1)  Stability is much improved, especially with sleep/resume,
     using Michael Clarke's patch which upgrades the driver
     to NDIS5, properly implements sleep/resume OIDs, and fixes
     a race condition between AdapterTransmit and IRP_MJ_READ.

(2)  Added Christof Meerwald's "Media Status" patch which shows
     a given TAP-Win32 adapter as being "unplugged" when it is
     not currently open by an OpenVPN instance.

(3)  Modified the MAC generation code to follow the Linux
     algorithm for generating MACs, using 0:FF:XX:XX:XX:XX
     where XX:XX:XX:XX is random.

(4)  Added code to lock the TAP device so that only one
     OpenVPN instance can have it open at a time.

(5)  Added an MTU parameter which acts like the ifconfig
     mtu parameter under Linux.  The MTU defaults to
     1500 and can be changed through the adapter advanced
     properties dialog.

(6)  Set up the driver to keep track of its Rx/Tx stats
     rather than depending on userspace to set them.

(7)  Ran the driver through the windows driver verifier
     with all testing modes enabled, including low-resource
     simulation mode.  Based on the resulting bug checks,
     I was able to fix a number
     of problems including using MmGetSystemAddressForMdlSafe
     instead of MmGetSystemAddressForMdl, fixing several places
     in the code where the return status of
     NdisAllocateMemory is not checked, and making the flags
     match between NdisAllocateMemory and NdisFreeMemory calls.

(8)  Renamed the driver so that it shows up as a "TAP-Win32" adapter
     in the network control panel, and does not conflict with the
     CIPE driver.

(9)  Brought the driver up to SMP standards (beta8), redid
     the packet queueing subroutines as a circular queue
     for better efficiency and more straightforward
     locking semantics under SMP.

(10) Fixed dangling IRP bug that could potentially
     cause a bug check if driver was unloaded or disabled
     while still open by a userspace process (beta8).

(11) Fixed bug that rendered an adapter instance unusable
     if a userspace process tried to read a packet
     of data but provided a buffer that was too small
     to completely return the packet (beta8).

(12) Added several new ioctls to return interesting status
     information back to userspace, such as currently
     configured MTU value, driver version number,
     and extended error status information (beta8).

(13) Added "tun" device emulation (beta8).

(14) Adapter media state is now controlled directly from
     userspace using the TAP_IOCTL_SET_MEDIA_STATUS ioctl.

(15) An option has been added to the TAP-Win32 driver
     advanced properties page that allows you to control
     whether the adapter appears to Windows as
     "Always Connected" or whether the connection status
     is dynamically brought up and down by OpenVPN
     ("Application Controlled").

(16) To a certain extent, backwards compatibility with NT 4 has
     been sacrificed in the interest of better usability and
     stability on Win2K/XP.

Notes -- Manual configuration of the TAP-Win32 adapter
------------------------------------------------------

On XP Go to Start -> Control Panel -> Network Connections.

On Win2K, go to Start -> Settings -> Control Panel ->
Network (and Dial-up) Connections.

You should see a "TAP-Win32 Adapter" with a name like
"Local Area Connection 3".  Right click and rename
this to something shorter and without embedded spaces
such as "my-tap".

Now right click again and select properties.

Select Internet Protocol (TCP/IP) from the list
and click on Properties.

Set the IP address and subnet mask of your
new TAP device.  For the example below we
will use an IP of 10.3.0.1 and a subnet mask
of 255.255.255.0.  Other fields can be left
as they are.

Note also that the command line tool
netsh can do many of these same functions.

For example, the following command will set the IP
and subnet for my-tap:

  netsh interface ip set address my-tap static 10.3.0.1 255.255.255.0

This setting is persistent across reboots.

Notes -- List available TAP-Win32 adapters
------------------------------------------

Type:

  openvpn --show-adapters

at a command prompt.

You should see a list that looks like this:

Available TAP-Win32 devices:
[1] 'my-tap'

You can list all network interfaces with the
Windows "ipconfig" command, and all TAP-Win32
interfaces should be included among them.

Notes -- Windows and TAP device naming
--------------------------------------

Basically what happens when you install the
TAP-Win32 driver is that you get a new network adapter
that shows up in your network control panel.  You right
click on the TAP adapter and set the TCP/IP properties,
i.e. IP address and netmask.  Then you rename the TAP
adapter icon to something like "my-tap" and reference
it using the --dev-node option in OpenVPN.

Windows also has command line utilities to accomplish
these same kinds of tasks such as devcon, netsh,
and ipconfig.

Notes -- Building from source
-----------------------------

This section is for developers only.

You will need the following:

(1) MinGW/MSYS environment
    http://mingw.sourceforge.net/

(2) OpenSSL library
    http://www.openssl.org/

(3) LZO library
    http://www.oberhumer.com/opensource/lzo/

(4) Windows DDK (available only from Microsoft)
    http://www.microsoft.com/whdc/ddk/winddk.mspx

(5) Nullsoft Install System (optional)
    http://www.nullsoft.com/free/nsis/

It should be noted that Visual C++ is NOT required.
The open-source MinGW compiler is used to build the
userspace component of OpenVPN, and the DDK is used
to build the driver component.

First build the usermode component of OpenVPN
from the top-level directory of the OpenVPN
source distribution:

Edit makefile.32 with the location of
your OpenSSL and LZO distributions.  Note that
it is only necessary to build these distributions,
not to install them.

Note that the makefile accepts a 'dynamic'
or 'static' target, depending on the way
you want to link with the OpenSSL library.

By default the makefile will attempt to
dynamically link with OpenSSL.

Type:
  make -f makefile.w32

This will build the user mode component of OpenVPN.

Now build the TAP-Win32 kernel driver:

Go to Start -> All Programs -> Development Kits -> Windows DDK
  -> Build Environments -> Win Free Build Environment

Use the Checked Build Environment if you want a debugging version.

A command prompt window will open.  Go to the tap-win32 directory
of the OpenVPN distribution.

Type:
  build -cef

This will build the kernel driver in the i386 directory.

At this point you will have built:

.\openvpn.exe -- openvpn daemon
.\tap-win32\i386\tapdrvr.sys -- TAP-Win32 kernel driver

Copy openvpn.exe to a directory in your path.
If you build dynamically with OpenSSL, copy the OpenSSL
DLLs to a directory in your path.

If you want to build a self-installing EXE, consult
the NSIS install script (openvpn.nsi) in the
install-win32 directory.  You will need to edit
openvpn.nsi to reflect the setup of your
development environment.

See instructions below for installing the kernel driver.

Notes -- Manual Install/Update/Uninstall of the TAP-Win32 kernel driver
-----------------------------------------------------------------------

This is best done using tapinstall.exe, which is distributed
with the self-installing form of OpenVPN on Windows.  Cd to the
directory which contains OemWin2k.inf and tapdrvr.sys.

To install:
  tapinstall install OemWin2k.inf TAP0801

To update:
  tapinstall update OemWin2k.inf TAP0801

To uninstall:
  tapinstall remove TAP0801

Note that the TAP0801 is the hardware ID of the
TAP-Win32 driver and may change with future
releases.

By installing multiple times, you will create
additional TAP-Win32 adapter instances, which can
be used for multiple concurrent VPN tunnels.

It is also possible to install using Control Panel ->
Add New Hardware, and it is possible to uninstall
using Control Panel -> System -> Hardware -> Device
Manager.

Notes -- OpenVPN Performance Benchmarks
---------------------------------------

All tests with OpenVPN 1.5-beta2 on systems
locally connected to a 100Mbps LAN using
UDP tunnel transport, TAP devices
with an MTU of 1500, and no compression.

[---------------------]
[     TEST #1         ]
[---------------------]

Linux 2.4.21 P2 266Mhz <-> Linux 2.4.21 P4 2.4Ghz

OpenVPN Blowfish tunnel
-----------------------

FTP get on 266Mhz

 33128460 bytes received in 23.1 secs (1.4e+03 Kbytes/sec)
 33128460 bytes received in 25.7 secs (1.3e+03 Kbytes/sec)

FTP send on 266MHz

 33128460 bytes sent in 16.9 secs (1.9e+03 Kbytes/sec)
 33128460 bytes sent in 15.8 secs (2e+03 Kbytes/sec)

OpenVPN plaintext tunnel
------------------------

FTP get on 266Mhz

 33128460 bytes received in 9.75 secs (3.3e+03 Kbytes/sec)
 33128460 bytes received in 9.65 secs (3.4e+03 Kbytes/sec)

FTP send on 266MHz

 33128460 bytes sent in 8.21 secs (3.9e+03 Kbytes/sec)
 33128460 bytes sent in 9.65 secs (3.4e+03 Kbytes/sec)

Direct FTP without OpenVPN
--------------------------

FTP get on 266Mhz

 33128460 bytes received in 4.73 secs (6.8e+03 Kbytes/sec)
 33128460 bytes received in 4.75 secs (6.8e+03 Kbytes/sec)

FTP send on 266MHz

 33128460 bytes sent in 4 secs (8.1e+03 Kbytes/sec)
 33128460 bytes sent in 3.93 secs (8.2e+03 Kbytes/sec)

[---------------------]
[     TEST #2         ]
[---------------------]

Linux 2.4.21 P2 266Mhz <-> Win XP SP1 P4 2.2 Ghz

OpenVPN Blowfish tunnel
-----------------------

FTP get on Win XP

 33128460 bytes received in 19.14Seconds 1731.03Kbytes/sec.
 33128460 bytes received in 19.11Seconds 1733.84Kbytes/sec.

FTP send on Win XP

 33128460 bytes sent in 23.46Seconds 1411.94Kbytes/sec.
 33128460 bytes sent in 23.44Seconds 1413.09Kbytes/sec.

OpenVPN plaintext tunnel
------------------------

FTP get on Win XP

 33128460 bytes received in 11.31Seconds 2930.17Kbytes/sec.
 33128460 bytes received in 11.89Seconds 2786.95Kbytes/sec.

FTP send on Win XP

 33128460 bytes sent in 11.72Seconds 2827.38Kbytes/sec.
 33128460 bytes sent in 10.71Seconds 3094.67Kbytes/sec.

Direct FTP without OpenVPN
--------------------------

FTP get on Win XP

 33128460 bytes received in 5.55Seconds 5971.24Kbytes/sec
 33128460 bytes received in 5.39Seconds 6148.56Kbytes/sec

FTP send on Win XP

 33128460 bytes sent in 4.90Seconds 6765.05Kbytes/sec
 33128460 bytes sent in 4.91Seconds 6751.27Kbytes/sec