Installation Notes

The standard INSTALL file included in the source distribution

Installation instructions for OpenVPN, a Secure Tunneling Daemon

Copyright (C) 2002-2010 OpenVPN Technologies, Inc. This program is free software;
you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2
as published by the Free Software Foundation.

*************************************************************************

QUICK START:

Unix:
./configure && make && make-install

Cross-compile for Windows on Unix

See INSTALL-win32.txt

*************************************************************************

To download OpenVPN, go to:

http://openvpn.net/download.html

OpenVPN releases are also available as Debian/RPM packages:

https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos

To download easy-rsa go to:

https://github.com/OpenVPN/easy-rsa

To download tap-windows driver source code go to:

https://github.com/OpenVPN/tap-windows

To get the cross-compilation environment go to:

https://github.com/OpenVPN/openvpn-build

For step-by-step instructions with real-world examples see:

http://openvpn.net/howto.html
https://community.openvpn.net/openvpn/wiki

For examples see:

http://openvpn.net/examples.html

Also see the man page for more information, usage examples, and information on
firewall configuration.

*************************************************************************

SUPPORTED PLATFORMS:
(1) Linux (kernel 2.6+)
(2) Solaris
(3) OpenBSD 5.1+
(4) Mac OS X Darwin 10.5+
(5) FreeBSD 7.4+
(6) NetBSD 5.0+
(7) Windows (WinXP and higher)

SUPPORTED PROCESSOR ARCHITECTURES:
In general, OpenVPN is word size and endian independent, so
most processors should be supported. Architectures known to
work include Intel x86, Alpha, Sparc, Amd64, and ARM.

REQUIRES:
(1) TUN and/or TAP driver to allow user-space programs to control
a virtual point-to-point IP or Ethernet device. See
TUN/TAP Driver Configuration section below for more info.

OPTIONAL (but recommended):
(1) OpenSSL library, necessary for encryption, version 0.9.8 or higher
required, available from http://www.openssl.org/
(2) PolarSSL library, an alternative for encryption, version 1.1 or higher
required, available from https://polarssl.org/
(3) LZO real-time compression library, required for link compression,
available from http://www.oberhumer.com/opensource/lzo/
OpenBSD users can use ports or packages to install lzo, but remember
to add CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib"
directives to "configure", since gcc will not find them otherwise.

OPTIONAL (for developers only):
(1) Autoconf 2.59 or higher + Automake 1.9 or higher
-- available from http://www.gnu.org/software/software.html
(2) Dmalloc library
-- available from http://dmalloc.com/

*************************************************************************

CHECK OUT SOURCE FROM SOURCE REPOSITORY:

Clone the repository:

git clone https://github.com/OpenVPN/openvpn
git clone git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn

Check out stable version:

git checkout -b 2.2 remotes/origin/release/2.2

Check out master (unstable) branch:

git checkout master


*************************************************************************

BUILD COMMANDS FROM TARBALL:

./configure
make
make install

*************************************************************************

BUILD COMMANDS FROM SOURCE REPOSITORY CHECKOUT:

autoreconf -i -v -f
./configure
make
make install

*************************************************************************

BUILD A TARBALL FROM SOURCE REPOSITORY CHECKOUT:

autoreconf -i -v -f
./configure
make dist

*************************************************************************

TESTS (after BUILD):

make check (Run all tests below)

Test Crypto:

./openvpn --genkey --secret key
./openvpn --test-crypto --secret key

Test SSL/TLS negotiations (runs for 2 minutes):

./openvpn --config sample/sample-config-files/loopback-client (In one window)
./openvpn --config sample/sample-config-files/loopback-server (Simultaneously in another window)

For more thorough client-server tests you can configure your own, private test
environment. See tests/t_client.rc-sample for details.

*************************************************************************

OPTIONS for ./configure:

--disable-lzo disable LZO compression support [default=yes]
--enable-lzo-stub don't compile LZO compression support but still
allow limited interoperability with LZO-enabled
peers [default=no]
--disable-crypto disable crypto support [default=yes]
--disable-ssl disable SSL support for TLS-based key exchange
[default=yes]
--enable-x509-alt-username
enable the --x509-username-field feature
[default=no]
--disable-multi disable client/server support (--mode server +
client mode) [default=yes]
--disable-server disable server support only (but retain client
support) [default=yes]
--disable-plugins disable plug-in support [default=yes]
--disable-eurephia disable support for the eurephia plug-in
[default=yes]
--disable-management disable management server support [default=yes]
--enable-pkcs11 enable pkcs11 support [default=no]
--disable-socks disable Socks support [default=yes]
--disable-http-proxy disable HTTP proxy support [default=yes]
--disable-fragment disable internal fragmentation support (--fragment)
[default=yes]
--disable-multihome disable multi-homed UDP server support (--multihome)
[default=yes]
--disable-port-share disable TCP server port-share support (--port-share)
[default=yes]
--disable-debug disable debugging support (disable gremlin and verb
7+ messages) [default=yes]
--enable-small enable smaller executable size (disable OCC, usage
message, and verb 4 parm list) [default=yes]
--enable-password-save allow --askpass and --auth-user-pass passwords to be
read from a file [default=yes]
--enable-iproute2 enable support for iproute2 [default=no]
--disable-def-auth disable deferred authentication [default=yes]
--disable-pf disable internal packet filter [default=yes]
--enable-strict enable strict compiler warnings (debugging option)
[default=no]
--enable-pedantic enable pedantic compiler warnings, will not generate
a working executable (debugging option) [default=no]
--enable-strict-options enable strict options check between peers (debugging
option) [default=no]
--enable-selinux enable SELinux support [default=no]
--enable-systemd enable systemd suppport [default=no]

ENVIRONMENT for ./configure:

IFCONFIG full path to ipconfig utility
ROUTE full path to route utility
IPROUTE full path to ip utility
NETSTAT path to netstat utility
MAN2HTML path to man2html utility
GIT path to git utility
TAP_CFLAGS C compiler flags for tap
OPENSSL_CRYPTO_CFLAGS
C compiler flags for OPENSSL_CRYPTO, overriding pkg-config
OPENSSL_CRYPTO_LIBS
linker flags for OPENSSL_CRYPTO, overriding pkg-config
OPENSSL_SSL_CFLAGS
C compiler flags for OPENSSL_SSL, overriding pkg-config
OPENSSL_SSL_LIBS
linker flags for OPENSSL_SSL, overriding pkg-config
POLARSSL_CFLAGS
C compiler flags for polarssl
POLARSSL_LIBS
linker flags for polarssl
LZO_CFLAGS C compiler flags for lzo
LZO_LIBS linker flags for lzo
PKCS11_HELPER_CFLAGS
C compiler flags for PKCS11_HELPER, overriding pkg-config
PKCS11_HELPER_LIBS
linker flags for PKCS11_HELPER, overriding pkg-config

*************************************************************************

BUILDING ON LINUX 2.6+ FROM RPM

You can build a binary RPM directly from the OpenVPN tarball file:

rpmbuild -tb [tarball]

This command will build a binary RPM file and place it in the system
RPM directory. You can then install the RPM with the standard RPM
install command:

rpm -ivh [binary-rpm]

When you install the binary RPM, it will install
sample-scripts/openvpn.init, which can be used to
automatically start or stop one or more OpenVPN tunnels on system
startup or shutdown, based on OpenVPN .conf files in /etc/openvpn.
See the comments in openvpn.init for more information.

Installing the RPM will also configure the TUN/TAP device node
for linux 2.6.

Note that the current openvpn.spec file, which instructs the rpm tool
how to build a package, will build OpenVPN with all options enabled,
including OpenSSL, LZO, and pthread linkage. Therefore all of
these packages will need to be present prior to the RPM build, unless
you edit the openvpn.spec file.

*************************************************************************

TUN/TAP Driver Configuration:

* Linux 2.6 or higher (with integrated TUN/TAP driver):

(1) load driver: modprobe tun
(2) enable routing: echo 1 > /proc/sys/net/ipv4/ip_forward

Note that (1) needs to be done once per reboot. If you install from RPM (see
above) and use the openvpn.init script, these steps are taken care of for you.

* FreeBSD:

FreeBSD ships with the TUN/TAP driver, and the device nodes for tap0,
tap1, tap2, tap3, tun0, tun1, tun2 and tun3 are made by default.
However, only the TUN driver is linked into the GENERIC kernel.

To load the TAP driver, enter:

kldload if_tap

See man rc(8) to find out how you can do this at boot time.

The easiest way is to install OpenVPN from the FreeBSD ports system,
the port includes a sample script to automatically load the TAP driver
at boot-up time.

* OpenBSD:

OpenBSD has dynamically created tun* devices so you only need
to create an empty /etc/hostname.tun0 (tun1, tun2 and so on) for each tun
you plan to use to create the device(s) at boot.

* Solaris:

You need a TUN/TAP kernel driver for OpenVPN to work:

http://www.whiteboard.ne.jp/~admin2/tuntap/

* Windows XP/2003/Vista/7:

OpenVPN on Windows needs a TUN/TAP kernel driver to work. OpenVPN installers
include this driver, so installing it separately is not usually required.
The driver source code is available here:

https://github.com/OpenVPN/tap-windows

*************************************************************************

CAVEATS & BUGS:

* I have noticed cases where TCP sessions tunneled over the Linux
TAP driver (kernel 2.4.21 and 2.4.22) stall when lower --mssfix
values are used. The TCP sessions appear to unstall and resume
normally when the remote VPN endpoint is pinged.

* If run through a firewall using OpenBSDs packet filter PF and the
filter rules include a "scrub" directive, you may get problems talking
to Linux hosts over the tunnel, since the scrubbing will kill packets
sent from Linux hosts if they are fragmented. This is usually seen as
tunnels where small packets and pings get through but large packets
and "regular traffic" don't. To circumvent this, add "no-df" to
the scrub directive so that the packet filter will let fragments with
the "dont fragment"-flag set through anyway.

* Mixing OFB or CFB cipher modes with static key mode is not recommended,
and is flagged as an error on OpenVPN versions 1.2.1 and greater.
If you use the --cipher option to explicitly select an OFB or CFB
cipher AND you are using static key mode, it is possible that there
could be an IV collision if the OpenVPN daemons on both sides
of the connection are started at exactly the same time, since
OpenVPN uses a timestamp combined with a sequence number as the cipher
IV for OFB and CFB modes. This is not an issue if you are
using CBC cipher mode (the default), or if you are using OFB or CFB
cipher mode with SSL/TLS authentication.

The openvpn.spec files

The OpenVPN 2.3 source tree contains an example RPM spec file under the distro subdirectory. For OpenVPN releases we use other spec files tailored for each supported operating system.

OpenVPN on Windows notes


These notes are intended to highlight the Windows-specific characteristics of OpenVPN. For a general introduction to OpenVPN configuration, see the FAQ.

Please report any bugs to the openvpn-devel list ( This email address is being protected from spambots. You need JavaScript enabled to view it. ).

Before you post, check out the FAQ (http://openvpn.net/index.php/open-source/faq.html) for more info.

Currently, OpenVPN runs on Windows XP (or later), Linux, Mac OS X, Solaris, FreeBSD, NetBSD, and OpenBSD, making it one of the most portable VPN packages today.

Note however that OpenVPN does NOT run on Win9x/Me or Windows 2000.


OpenVPN GUI for Windows

Please look here for details on OpenVPN GUIs


Installing OpenVPN on Windows

See the HOWTO.


Running OpenVPN from a console window

First, create a config file. A sample is provided in \Program Files\OpenVPN\config\sample.ovpn.txt

Edit this file and save to a .ovpn extension. Now, run OpenVPN by right clicking on the .ovpn filename and selecting "Start OpenVPN on this config file".

You can also run from a command prompt window:

    openvpn --config sample.ovpn

Running OpenVPN as a Windows Service

When OpenVPN runs as a service it will start a separate OpenVPN process for each configuration file it finds in the \Program Files\OpenVPN\config directory and will output a logfile of the same name to the \Program Files\OpenVPN\log directory.

When installed as a service, OpenVPN will default to manual start mode. You can go to the "Services" control panel in Control Panel -> Administrative Tools to start the service or to set it to Automatic Start mode.

A sample config file has been provided in \Program Files\OpenVPN\config\sample.ovpn.txt which can be adapted to your needs.

Service Notes:

  • When you install OpenVPN as a service, you are actually installing openvpnserv.exe which is a service wrapper for OpenVPN, i.e. it reads the config file directory and starts up a separate OpenVPN process for each config file. openvpnserv.exe performs the same function under windows as the /etc/init.d/openvpn startup script does under linux.
  • When you stop the OpenVPN service, it will send a terminate signal to all OpenVPN processes which were started by it.
  • If the OpenVPN service wrapper (openvpnserv.exe) encounters fatal errors, it will write them to the windows event log, which can be viewed in Control Panel -> Administrative Tools -> Event Viewer -> Application Log.
  • If the OpenVPN processes themselves encounter errors, they will write them to their respective log files in the log file directory.
  • There is a one-to-one correspondence between an OpenVPN process, an OpenVPN config file, an OpenVPN log file, and a TAP-Win32 adapter which represents an endpoint of a VPN tunnel.
  • OpenVPN tunnels are point-to-point in their simplest form, but can be made point-to-multi-point through the use of bridging or routing (see below).
  • Multiple OpenVPN processes can run concurrently, each on a different TAP-Windows adapter.
  • openvpn.exe gets all configuration information from its config file, not from the registry.
  • The openvpnserv.exe program (the service wrapper) gets several string parameters from the registry which can be modified by the user. If you change any of these parameters, you should be able to upgrade OpenVPN to a new version without the installer overwriting your changes:

    HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN

    config_dir
    configuration file directory to scan, defaults to "\Program Files\OpenVPN\config"
    config_ext
    file extension on configuration files, defaults to "ovpn"
    exe_path
    path to openvpn.exe, defaults to "\Program Files\OpenVPN\bin\openvpn.exe"
    log_dir
    log file directory, defaults to "\Program Files\OpenVPN\log"
    log_append
    if set to "1", multiple instantiations of an OpenVPN process will append onto the same log file, if set to "0" (default), each new instantiation will truncate the previous log file
    priority
    the windows priority class for each instantiated OpenVPN process, can be one of:
    • "IDLE_PRIORITY_CLASS"
    • "BELOW_NORMAL_PRIORITY_CLASS"
    • "NORMAL_PRIORITY_CLASS" (default)
    • "ABOVE_NORMAL_PRIORITY_CLASS"
    • "HIGH_PRIORITY_CLASS"

Bridging vs. Routing

Bridging and routing are two methods of linking systems via a VPN.

See FAQ for more info.

Example running a point-to-point VPN

This example will work between Windows and Windows, Windows and Linux, or Windows and FreeBSD.

For purposes of this example, we will refer to our two Windows machines as "A" and "B".

The Windows OpenVPN installer should have already installed a TAP-Win32 adapter on each machine which you should see in the Network Connections control panel.

We will choose the network 10.3.0.0 subnet 255.255.255.0 as our virtual VPN subnet.

We are assuming that the network 10.3.0.0 subnet 255.255.255.0 is a new and distinct subnet from any that you are currently using. If it is not, choose a different subnet by substituting something else for the "10.3.0" component of the subnet.

It is very important that the virtual VPN subnet you use is private and unique from any other physical or virtual subnets in use. If your virtual subnet clashes with your physical subnet, the VPN will not work and there will likely be no error messages to tell you why.

Now generate a static key on Machine A:

    openvpn --genkey --secret key

(Or use the shortcut in the start menu)

Copy this key to Machine B over a secure medium.

Now edit the config files for both ends of the connection.

On Machine A create a file config.ovpn:

    remote [IP address of B]
dev tap
ifconfig 10.3.0.1 255.255.255.0
secret key
ping 10
verb 3
mute 10

On Machine B create a file config.ovpn:

    remote [IP address of A]
dev tap
ifconfig 10.3.0.2 255.255.255.0
secret key
ping 10
verb 3
mute 10

Another important point to remember is that the addresses used in the "remote" option are real addresses, not virtual addresses. Before OpenVPN is started you must be able to ping the address given after the "remote" option. OpenVPN will try to connect to that address and if you can't ping it beforehand, OpenVPN will not be able to connect to it either.

The rule of thumb to remember is that "remote" specifies real, non-VPN addresses while "ifconfig" specifies virtual VPN addresses. The address used in "remote" should NEVER be a part of the subnet defined by the "ifconfig" option.

Now the moment of truth... Type:

    openvpn --config config.ovpn

On both A and B.

Alternatively, bring up the folder that contains the .ovpn file, right click on the .ovpn file, and select "Start OpenVPN on this config file".

If everything worked correctly you will now have a point-to-point VPN connecting the two boxes.

On Machine A you can ping B with the following command:

    ping 10.3.0.2

On Machine B you can ping A with the following command:

    ping 10.3.0.1

A few notes to be aware of:

  • If you are using different versions of OpenVPN on either side of the connection, then add the following lines to both configs:
        tun-mtu 1500
tun-mtu-extra 32
  • If one side of the connection is running on Linux, make sure you tell your linux firewall to allow incoming connections on virtual tap interfaces. The command for iptables would be:
        iptables -A INPUT -i tap+ -j ACCEPT
  • Make sure that both boxes can talk to each other over UDP port 1194. It is a good idea to ping the "remote" address in the config file before actually starting OpenVPN to confirm that it is reachable.

Setting up routing

If you set up a routed VPN, i.e. one where local and remote subnets differ, you need to set up routing between the subnets so that packets will transit the VPN.

Here is a possible road warrior network configuration:

Road Warrior (Windows)

    TAP-Windows Adapter
10.3.0.2 subnet 255.255.255.0

ifconfig option in OpenVPN config:

    ifconfig 10.3.0.2 255.255.255.0

Main Office, server (any OS)

    tap adapter
10.3.0.1 subnet 255.255.255.0

ifconfig option in OpenVPN config:

    ifconfig 10.3.0.1 255.255.255.0
    private ethernet
10.0.0.1 subnet 255.255.255.0

The road warrior needs this route in order to reach machines on the main office subnet:

    route add 10.0.0.0 mask 255.255.255.0 10.3.0.1 (this is a shell command)

Routes can be conveniently specified in the OpenVPN config file itself using the --route option:

    route 10.0.0.0 255.255.255.0 10.3.0.1

If the OpenVPN server in the main office is also the gateway for machines on the remote subnet, no special route is required on the main office side.

On the other hand, if the main office OpenVPN server is NOT also the gateway, then whatever machine or router which IS the gateway must know to route 10.3.0.0 subnet 255.255.255.0 to the machine which is running OpenVPN.


Notes -- Ethernet bridging, Windows client, Linux Server

Ethernet bridging is a powerful networking capability that allows remote systems (such as "Road Warriors") to connect over a VPN to an ethernet LAN in such a way that their system appears to be directly connected to the LAN, i.e. they have an IP address taken right from the LAN's subnet and they are able to interact with other hosts on the LAN including sending and receiving broadcasts and being able to conveniently browse and access the Windows network neighborhood.

I have tested ethernet bridging with Windows clients connecting to a Linux server. On the linux side, basically follow the instructions in the Ethernet bridging Mini-Howto on the OpenVPN web site.

On the Linux side you must first set up ethernet bridging. Here is a configuration which I use:

    #!/bin/bash

modprobe tun
modprobe bridge

openvpn --mktun --dev tap0
openvpn --mktun --dev tap1

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0
brctl addif br0 tap1

ifconfig tap0 0.0.0.0 promisc up
ifconfig tap1 0.0.0.0 promisc up
ifconfig eth1 0.0.0.0 promisc up

ifconfig br0 10.5.0.1 netmask 255.255.255.0 broadcast 10.5.0.255

# end of script

This script will set up ethernet bridging between eth1, tap0, and tap1. Change the br0 ifconfig to match the ifconfig that would be used for eth1 under normal, non-bridged configuration. Use as many tapX virtual adapters as you will have remote clients connecting.

In the firewall, add these entries to allow TAP devices and ethernet bridges to operate:

    iptables -A INPUT -i tap+ -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

Now make an OpenVPN configuration on the server side to receive incoming connections such as:

    ###################################
# OpenVPN bridge config, Linux side

local [public IP address or hostname]

# IP settings
port 8888
dev tap0

# crypto config
secret key.txt

# restart control
persist-key
persist-tun
ping-timer-rem
ping-restart 60
ping 10

# compression
comp-lzo

# UID
user nobody
group nobody

# verbosity
verb 3

# end of config
###################################

For additional clients, copy the configuration above, but use a different port number, tapX unit number, and secret key.

Now on the windows client side:

    ############################################
# OpenVPN bridge config, windows client side

remote [public IP address or hostname of server]
port 8888
dev tap

# This is the address the client will
# "appear as" when it connects to the
# bridged LAN.
ifconfig 10.5.0.5 255.255.255.0
ifconfig-nowarn

secret key.txt
ping 10
comp-lzo
verb 3

# end of config
###################################

Now run OpenVPN on both sides with the appropriate configuration file, using the --config option.

On the Linux side, you probably want to run as a daemon, so include --daemon and --cd [dir], where dir is the directory that contains the key file.

If everything worked correctly, the Linux server or any host on its subnet should be able to ping 10.5.0.5 and see the remote VPN connected client.

The Windows client should be able to ping any address on the 10.5.0.x subnet, including addresses of other remote, OpenVPN-bridged clients.

If Windows machines or Samba servers exist on the LAN bridged by the Linux server (including Samba running on the Linux server itself), the Windows client should see them in its network neighborhood, and vice versa.

Furthermore, ethernet bridging allows for the transport of all protocols which are compatible with Ethernet, including IPv6 and IPX.

Ethernet bridging is a great way to work when on the road, and I personally use it for securely connecting to home or office from WiFi Internet cafes.


Notes -- Ethernet bridging, with the bridge occurring on the Windows side.

This configuration requires Windows XP or higher on the bridge side. First make a TAP-Windows adapter ("tap-bridge") without setting any TCP/IP properties.

Select "tap-bridge" and your ethernet adapter in Control Panel -> Network Connections, then right click and select "Bridge Connections". I am assuming that the bridged network address is 10.0.0.0 subnet 255.255.255.0. The connecting client will use an address of 10.0.0.7.

Note that if your ethernet adapter is a DHCP client, the act of bridging the connection may cause it to get a new IP address lease.

Use this config on the Windows side (the side doing the bridging):

    remote [myremote]
dev tap
dev-node tap-bridge
ping 5
secret key

Use this config on the remote (which in this case is a linux box but could also be a windows box):

    remote [myremote]
dev tap
ifconfig 10.0.0.7 255.255.255.0
ping 5
secret key

Notes -- Setting TAP-Windows address/subnet automatically via DHCP

Setting the TAP-Windows address/subnet automatically via DHCP is a convenient method of managing IP addresses in a bridge situation, though there are some caveats that must be handled.

The problem with getting addresses for VPN clients via DHCP is that you only want to get the IP address and subnet mask, not the gateway. Therefore in a bridge situation, a DHCP server must be able to differentiate between local clients and remote VPN clients.

Dave Lau contributed a config file for ISC's dhcp3 server that does just this. I reproduce Dave's email describing his setup in full below, including the DHCP server config file.

[Editors note: The 00:FF MAC prefix is not my original idea -- I got it from the Linux TAP driver.]

I've been using openVPN since you ported it to windows, and I must say it is fantastic. In just 2 short weeks of testing, I have decided to scrap my IPSec VPN that I have been using for my small business in place of openVPN. One thing that I have found to be immensely useful is the ethernet bridging. I would rather bridge than route for my particular situation, because I want my remote vpn clients to be on the same subnet as the office-bound clients for myriad reasons. I did not like having to manually configure IP addresses for each client, so I elected to use a dhcp server to serve my remote clients an IP address through the openVPN tunnel.

Rather than relying on client hostnames to distinguish between openVPN and non-openVPN connections, I took advantage of your clever idea to create MAC addresses for the Tap adapters as 00:FF:xx:xx:xx:xx, and I wrote my dhcpd.conf file accordingly. The reason this is necessary for me is that I do not want to hand out a default gateway or DNS server to my openVPN clients, I only want local traffic going through the tunnel. I'm sure there are many other possible instances in which the dhcp server would like to handle openVPN clients differently from standard clients, so I though I would share my dhcp server config with you on the off chance that it might be useful to others. This particular config is for ISC's dhcp3 server, but I'm sure it would work with just about anything. There is nothing particularly clever or tricky about this config file, I just did not happen to see any examples of it anywhere, so if this could save someone some time and effort, that would be great:

Thank you, Jim, for writing this fantastic piece of software.

Sincerely,
Dave Lau


beefcake:~# cat /etc/dhcp3/dhcpd.conf
## If hardware address begins with 00:FF, the client is an
## openvpn tap adapter, and we do not want to assign a
## default gateway or dns server. Assign then to a special
## subclass and configure a pool which does not hand out
## these parameters.

class "openvpn" {
match if substring (hardware, 1, 2) = 00:FF;
}
## end class declaration

## subnet for br0

authoritative;
subnet 172.16.0.0 netmask 255.255.255.0 {
always-broadcast on;
max-lease-time 3600;
default-lease-time 1800;
option domain-name "ezone.net";
option subnet-mask 255.255.255.0;

pool {
deny members of "openvpn";
range 172.16.0.150 172.16.0.254;
option routers 172.16.0.1;
option domain-name-servers 172.16.0.1;
option tftp-server-name "172.16.0.209";
}

pool {
allow members of "openvpn";
range 172.16.0.100 172.16.0.125;
}

}

Notes -- Driver Stability

The stability of the TAP-Windows driver is obviously of great concern since any crash by a driver will also crash the entire system, producing the infamous blue screen of death (BSOD).

Between 1.5-beta1 and 1.5-beta2, significant stability improvements have been made in the driver, and it now passes the Windows Driver Verifier when running in its most rigourous verification mode. The 1.5-beta1 driver had problems crashing on sleep/resume and I believe these bugs have been fixed in 1.5-beta2 and higher.

Versions of the TAP-Windows driver prior to 1.5-beta8 are NOT safe for usage on SMP (i.e. multiprocessor) systems.

1.5-Beta8 has been redesigned to be SMP-safe but more real world testing will be required before its stability can be assured.


Notes -- TUN devices

Tun device support (via the --dev tun option) was first included in OpenVPN 1.5-beta8.

A "tun" device is a virtual point-to-point IP link.

Using --dev tun also requires that you use --ifconfig to tell OpenVPN the local and remote IP endpoints for the point-to-point tunnel.

The --ifconfig option also calls the Windows "netsh" command, and some problems have been reported with this command on Win2K at lower service packet levels.

If you would like to use --dev tun but would rather set the TCP/IP properties manually rather than having OpenVPN try to do it automatically with netsh, follow these steps:

  • Specify --ifconfig with endpoint addresses.
  • Specify the --ifconfig-noexec option.
  • Manually set the network/subnet in the TCP/IP properties. You should use a "/30" subnet that encloses the addresses that were specified in the --ifconfig option. The netmask, therefore, will be 255.255.255.252.

Notes -- TAP vs. TUN devices

A "tap" device is a virtual ethernet adapter, while a "tun" device is a virtual point-to-point IP link.

As of OpenVPN 1.5-beta8, the TAP-Windows driver supports both "tun or "tap" style devices.

You cannot mix --dev tun and --dev tap on different ends of the connection. Use one or the other consistently.

There are some caveats to be aware of when using "tun" style devices on Windows: the --ifconfig endpoints chosen must be the two "middle" addresses in a 255.255.255.252 subnet.

The command

    openvpn --show-valid-subnets

will show more information about how to choose VPN endpoints when --dev tun is used.

The other caveat concerns MTU. On most platforms, OpenVPN programatically sets the MTU of the "tun" or "tap" interface. Currently on Windows, the only way to change the TAP-Windows MTU is to go to the adapter advanced properties and do it manually.

Because of this, the easiest choice is to leave the TAP-Windows MTU setting at "1500" and tell OpenVPN on both sides of the connection to use an MTU of "1500" with the config option:

    tun-mtu 1500

If you then need to lower the MTU because of fragmentation or router problems, use something like

    fragment 1400
mssfix

to lower OpenVPN's tunnel carrier UDP packet size to "1400".


Notes -- MTU

Setting the MTU is an important but sometimes problematic aspect of VPN configuration. The MTU (maximum transmission units) is the maximum packet size in bytes that can be sent or received by a real or virtual network adapter.

The common symptom of MTU problems is a VPN connection which appears to start up fine, but then locks up under real usage.

The easiest way to solve MTU problems is by using the --mssfix and/or --fragment options which were added in beta8. Typical usage would be:

    fragment 1400
mssfix

Some notes:

  • The TAP-Windows adapter MTU defaults to "1500" which is the required setting for ethernet bridging.
  • For some time before the Windows port of OpenVPN was completed, a default --link-mtu of "1300" has been in place for "tun" interfaces. Because the Windows TAP-Windows interface prefers an MTU of "1500", it is essential to not rely on the default MTU value in this case, but to explicitly include "tun-mtu 1500" on both sides of the connection.
  • The MTU on both sides of an OpenVPN connection must exactly match. On non-windows systems, the MTU of a tap device is usually set by the ifconfig command.
  • The MTU of a TAP-Windows adapter can be changed by going to Control Panel -> Network Connections -> [TAP-Windows adapter name] -> Configure -> Advanced.

Notes -- Firewall on the Windows client

In general, it's a good idea to always protect a VPN client or server with a firewall.

The important points for setting up firewalling on a Windows system running OpenVPN are:

  1. Make sure that your connection to the internet is always firewalled, especially when you are running a VPN. VPNs create trusted relationships between geographically disparate networks, and if any network on the VPN is compromised by a virus or worm, the exploit has the potential of jumping across the VPN and infecting other machines.
  2. You can enable firewalling on a given network adapter by going to Control Panel -> Network Connections, right-click on the icon that represents your link to the internet, select "Properties", go the the "Advanced" tab, and enable "Internet Connection Firewall".
  3. If you are running OpenVPN as a server on a Windows machine, you will need to configure your firewall to allow incoming clients to connect to OpenVPN's port number which is "UDP 1194" by default.
  4. In general, running OpenVPN as a client doesn't require any special firewall configuration, provided you use the --ping option to preserve the state of the OpenVPN connection in the firewall.
  5. In general, you don't need to enable firewalling on the TAP-Windows adapter. Once an IP packet appears to be "coming in" on the TAP-Windows adapter, it has already been decrypted and authenticated by OpenVPN, even though the connection between OpenVPN peers might transit an untrusted network such as the internet.
  6. One case where you might want to firewall the TAP-Windows adapter is if you are connecting to an untrusted machine, or a machine which will route or bridge your connection with an untrusted network.

Notes -- Media Status

1.5-beta2 of the driver has the Media Status patch. This patch shows the TAP-Win32 adapter as being "unplugged" whenever OpenVPN is not running.


Notes -- Error message from OpenVPN

OpenVPN can be on the chatty side when it comes to error messages, and sleep-resume activity often produces a flurry of non-fatal messages. Most of these messages can be safely ignored and are provided for informational and debugging purposes only.

To suppress repeating messages, the --mute option can be used. For example --mute 10 will print no more than 10 consecutive messages in the same error class. To suppress all error messages except those that are fatal, use --verb 0.


Notes -- ARP/MAC Issues with the TAP-Windows driver

Most TAP drivers allocate a random MAC to their virtual NIC. If OpenVPN running on Windows disconnects and reconnects to a remote peer, it is possible that that peer will reinitialize its TAP device and generate a new random MAC, causing Windows to temporarily lose access to the IP addresses exported by that remote peer. This is because Windows doesn't know that a given IP address on the virtual TAP network now is associated with a new MAC, so it tries to send packets to the old MAC, causing them to be dropped.

Luckily, there is an easy solution to this problem. Create a batch file with one or more of the following commands:

    arp -d [ip-address]

Where ip-address is a remote IP address at the other end of the virtual TAP network whose access was lost due to an OpenVPN restart. The "arp -d" command will cause Windows to "forget" the MAC address which it previously associated with the given IP address. Next time that IP address is used, Windows will actively query the remote peer (with an "arp who-has" message) to get the new MAC address.

You can also use

    arp -d *

to purge all MAC addresses from the cache.

You can use the --up option in OpenVPN to automatically run a given batch file immediately after TAP device initialization -- such a batch file can contain "arp" commands as described above.

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-Windows driver and CIPE driver

The TAP-Windows 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-Windows" 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-Windows 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-Windows adapter

This section has been moved here.


Notes -- List available TAP-Windows adapters

This section has been moved here.


Notes -- Windows and TAP device naming

This section has been moved here.


Notes -- Building from source

This documentation has been moved to the Wiki.


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

This section has been moved here.


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

Transfer of 33,128,460 bytes -- Linux 2.4.21 P2 266Mhz Linux 2.4.21 P4 2.4Ghz


FTP get on 266MhzFTP send on 266MHz
OpenVPN Blowfish tunnel 23.1 sec (1.4e+03 Kbytes/sec)
25.7 sec (1.3e+03 Kbytes/sec)
16.9 sec (1.9e+03 Kbytes/sec)
15.8 sec (2e+03 Kbytes/sec)
OpenVPN plaintext tunnel 9.75 sec (3.3e+03 Kbytes/sec)
9.65 sec (3.4e+03 Kbytes/sec)
8.21 secs (3.9e+03 Kbytes/sec)
9.65 secs (3.4e+03 Kbytes/sec)
Direct FTP without OpenVPN 4.73 sec (6.8e+03 Kbytes/sec)
4.75 sec (6.8e+03 Kbytes/sec)
4 secs (8.1e+03 Kbytes/sec)
3.93 secs (8.2e+03 Kbytes/sec)

TEST #2

Transfer of 33,128,460 bytes -- Linux 2.4.21 P2 266Mhz Win XP SP1 P4 2.2 Ghz


FTP get on WinXPFTP send on WinXP
OpenVPN Blowfish tunnel 19.14 sec (1731.03 Kbytes/sec)
19.11 sec (1733.84 Kbytes/sec)
23.46 sec.(1411.94 Kbytes/sec)
23.44 sec (1413.09 Kbytes/sec)
OpenVPN plaintext tunnel 11.31 sec (2930.17 Kbytes/sec)
11.89 sec (2786.95 Kbytes/sec)
11.72 sec (2827.38 Kbytes/sec)
10.71 sec (3094.67 Kbytes/sec)
Direct FTP without OpenVPN 5.55 sec (5971.24 Kbytes/sec)
5.39 sec (6148.56 Kbytes/sec)
4.90 sec (6765.05 Kbytes/sec)
4.91 sec (6751.27 Kbytes/sec)

 


Copyright © OpenVPN Technologies, Inc. ( This email address is being protected from spambots. You need JavaScript enabled to view it. ), 2003-2010