install-win32.txt

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

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.  To my knowledge, Windows 2000 does not
support bridging, however a Windows 2000 machine can
be a client on a bridged network, where the other
end of the OpenVPN connection where the bridging is
occurring is a Linux or Windows XP machine.

* First make a TAP-Win32 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-Win32 address/subnet automatically via DHCP
----------------------------------------------------------------

Setting the TAP-Win32 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-Win32 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-Win32 driver prior to beta8 are
NOT safe for usage on SMP (i.e. multiprocessor) systems.

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-Win32 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-Win32
MTU is to go to the adapter advanced properties and do it
manually.

Because of this, the easiest choice is to leave the
TAP-Win32 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-Win32 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-Win32 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-Win32 adapter can be changed by
  going to Control Panel -> Network Connections ->
  [TAP-Win32 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 5000 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-Win32 adapter.  Once an IP
    packet appears to be "coming in" on the TAP-Win32
    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-Win32 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-Win32 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.