= Introduction =

For a brief introduction on bridging and routing, look at these links:

 * [http://openvpn.net/index.php/open-source/documentation/howto.html#vpntype Determining whether to use a routed or bridged VPN] (in OpenVPN HOWTO)
 * [http://openvpn.net/index.php/open-source/faq/75-general/311-what-are-the-fundamental-differences-between-bridging-and-routing-in-terms-of-configuration.html What are the fundamental differences between bridging and routing in terms of configuration?] (in OpenVPN FAQ)
 * [http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing OpenVPN Routing] (in Secure-Computing Wiki)

'''NOTE:''' The remaining sections are mostly based on [http://thread.gmane.org/gmane.network.openvpn.user/32935/ this email for dazo].

= Bridging vs. routing =

Bridging looks easier at first glance, but it brings a completely different can of worms.  First of all, there are no shortcuts in making networking easier except learning how to do it properly. Basically you want TAP devices if:

 * You want to transport non-IP based traffic, or IPv6 traffic on OpenVPN 2.2 or older releases
 * You want to bridge

You want bridging if:

 * You want your LAN and VPN clients to be in the same broadcast domain
 * You want your LAN DHCP server to provide DHCP addresses to your VPN client
 * You have Windows server(s) you want to access and require network neighbourhood discovery to work via VPN '''and''' WINS is not an option to implement.  If you have WINS, you don't want bridging.  Really.

It might be a few more reasons, but these are the most typical ones.  And as you see, TAP is a requirement for bridging.  Now lets see benefits and drawbacks of TAP vs TUN.

TAP benefits:

 * behaves like a real network card
 * can transport any network protocols (IPv4, IPv6, Netalk, IPX, etc, etc)
 * ''Can'' be used in bridges

TAP drawbacks

 * causes much more broadcast overhead on the VPN tunnel
 * adds the overhead of Ethernet headers on all packets transported over the VPN tunnel
 * scales poorly

TUN benefits:
 * A lower traffic overhead, transports only traffic which is destined for the VPN client

TUN drawbacks:

 * Broadcast traffic is not normally transported
 * Can only support IPv4 (OpenVPN 2.3 will add IPv6)
 * '''Cannot''' be used in bridges

In both setups, basic network knowledge is a must.  You need to be able to understand basic routing and firewalling, no matter which one use setup.  And both TUN and TAP do traditional network routing.  But using bridges, you also need to know how bridges work and how this changes firewalling in addition.

For more information about TCP/IP networking, the [http://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf TCP/IP Tutorial and Technical Overview] (IBM Red Book) is recommended reading, especially chapter 3.1.

= Using routing =

{{{
<disclaimer>
  NONE OF THIS IS TESTED.  But this is the basic theory behind it.
  It might be syntax errors here, or other stupid mistakes.
</disclaimer>
}}}

To set up a TUN setup with routing and masquerading for the VPN subnet, one approach could be something like this.  This example is based on a pretty standard network with a single Linux based firewall with two Ethernet cards:

{{{
                         +--------------------------------+
                         |            FIREWALL            |
              (public IP)|                                |192.168.0.1
 {INTERNET}=============={eth1                        eth0}=============<internal network / 192.168.0.0/24>
                         |   \                        /   |
                         |    +----------------------+    |
                         |    | iptables and         |    |
                         |    | routing engine       |    |
                         |    +--+----------------+--+    |
                         |       |*1              |*2     |
                         |     (openvpn)-------{tun0}     |
                         |                    10.8.0.1    |
                         +--------------------------------+

   *1 Only encrypted traffic will pass here, over UDP or TCP and only to the remote OpenVPN client
   *2 The unencrypted traffic will pass here.  This is the exit/entry point for the VPN tunnel.
}}}

Here tun0 is configured as 10.8.0.1 as a VPN, with the whole VPN network configured as 10.8.0.0/24.  

What happens with OpenVPN is that it accepts OpenVPN clients from eth1, OpenVPN will decrypt the data and put it to the tun0 interface, and the iptables and routing engine will pick up that traffic again, filter/masquerade it and send it further to eth0 or eth1, depending on the routing table.  When the routing engine sends traffic destined for the tun0 network, OpenVPN will pick it up, encrypt it and send it out on eth1, towards the proper OpenVPN client.

First we need to be sure that IP forwarding is enabled.  Very often this is disabled by default.  This is done by running the following command line as root:

{{{
    [root@host ~] # sysctl -w net.ipv4.ip_forward=1
    net.ipv4.ip_forward = 1
    [root@host ~] #
}}}

This change is only temporary, so if you reboot your box this will be reset back to the default value.  To make this change persistent you need to modify ''/etc/sysctl.conf''.  In this file you should have a line stating:

{{{
    net.ipv4.ip_forward = 1
}}}

So, lets look at the iptables rules required for this to work.

{{{
    # Allow traffic initiated from VPN to access LAN
    iptables -I FORWARD -i tun0 -o eth0 \
         -s 10.8.0.0/24 -d 192.168.0.0/24 \
         -m conntrack --ctstate NEW -j ACCEPT

    # Allow traffic initiated from VPN to access "the world"
    iptables -I FORWARD -i tun0 -o eth1 \
         -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

    # Allow traffic initiated from LAN to access "the world"
    iptables -I FORWARD -i eth0 -o eth1 \
         -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

    # Allow established traffic to pass back and forth
    iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
         -j ACCEPT

    # Notice that -I is used, so when listing it (iptables -vxnL) it
    # will be reversed.  This is intentional in this demonstration.

    # Masquerade traffic from VPN to "the world" -- done in the nat table
    iptables -t nat -I POSTROUTING -o eth1 \
          -s 10.8.0.0/24 -j MASQUERADE

    # Masquerade traffic from LAN to "the world"
    iptables -t nat -I POSTROUTING -o eth1 \
          -s 192.168.0.0/24 -j MASQUERADE

}}}

In the openvpn server config you will need these lines:

{{{
    dev tun
    topology subnet
    server 10.8.0.0 255.255.255.0
    push "route 192.168.0.0 255.255.255.0"
}}}

''(this is not a complete configuration file, but it should cover the network part of the configuration)''

This will provide the needed route for all VPN clients to the internal LAN.  If you want to all your VPN clients to send all the internet traffic via the VPN as well (so it looks like they sit behind the LAN when surfing the net), you need this line in addition:

{{{
    push "redirect-gateway def1"
}}}

And that's basically it.  Not much more extra trickery.  Routing setups are often much easier than people generally believe.  The firewall is generally a bit more tricky, but bridging doesn't make that easier.

''(If others see obvious mistakes, typos, or there are important details which are missing, please correct my errors.)''