install-win32.txt

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

--------------------

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

* Bridging advantages

    Broadcasts traverse the VPN -- this allows software that depends
    on LAN broadcasts such as Windows NetBIOS file sharing and
    network neighborhood browsing to work.

    No route statements to configure.

    Works with any protocol that can function over
    ethernet, including IPv4, IPv6, Netware IPX,
    AppleTalk, etc.

    Relatively easy-to-configure solution for road warriors.

* Bridging disadvantages

    Less efficient than routing, and does not scale well.

* Routing advantages

    Efficiency and scalability.

    Allows better tuning of MTU (see notes below)
    for efficiency.

* Routing disadvantages

    Clients must use a WINS server (such as samba) to allow
    cross-VPN network browsing to work.

    Routes must be set up linking each subnet.

    Software that depends on broadcasts will not "see"
    machines on the other side of the VPN.

    Works only with IPv4 in general, and IPv6 in some
    special cases.

What is Bridging?

  Bridging is a technique of creating a virtual, wide-area
  ethernet LAN, running on a single subnet.

What are the fundamental differences between bridging
and routing in terms of configuration?

  When a client connects via bridging to a remote network,
  it is assigned an IP address that is part of the remote
  physical ethernet subnet and is then able to interact
  with other machines on the remote subnet as if it were
  connected locally. Bridging setups require a special
  OS-specific tool to bridge a physical ethernet adapter
  with a virtual TAP style device.  On Linux, for example,
  "brtcl" is this tool.  On Windows, select your TAP-Win32
  adapter and your ethernet adapter in Control Panel -> Network
  Connections, then right click and select Bridge Connections.

  When a client connects via routing, it uses
  its own separate subnet, and routes are set up on both
  the client machine and remote gateway so that data packets
  will seamlessly traverse the VPN.  The "client" is not
  necessarily a single machine.  It could be a subnet of
  several machines.

  Bridging and routing are functionally very similar, with
  the major difference being that a routed VPN will not
  pass IP broadcasts while a bridged VPN will. 

  When you are bridging, you must always use --dev tap
  on both ends of the connection.  If you are routing
  you can use either --dev tap or --dev tun, but you
  must use the same on either end of the connection.
  --dev tun tends to be slightly more efficient for
  the routing case.

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 5000.  It is a good idea to
  ping the "remote" address in the config
  file before actually starting OpenVPN
  to confirm that it is reachable.

Troubleshooting
---------------

For solutions to common troubleshooting problems,
consult the OpenVPN Troubleshooting guide

http://openvpn.sourceforge.net/trouble.html

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-Win32 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 (this is an OpenVPN config file option)

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