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

* [Determining whether to use a routed or bridged VPN](http://openvpn.net/index.php/open-source/documentation/howto.html#vpntype) (in OpenVPN HOWTO)

* [What are the fundamental differences between bridging and routing in terms of configuration?](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) (in OpenVPN FAQ)

* [OpenVPN Routing](http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing) (in Secure-Computing Wiki)

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

This discussion needs to start with TAP vs TUN devices. You want TAP if:

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

* You want to bridge

And you want to bridge 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. TUN devices cannot be used for bridges and non-IP traffic.

Bridging looks easier at first glance, but it brings a completely different can of worms. Make no mistake: **There are no shortcuts in making networking easier** - except learning how to do it properly.

Now lets see benefits and drawbacks of TAP vs TUN.

TAP benefits:

* behaves like a real network adapter (except it is a virtual network adapter)

* can transport any network protocols (IPv4, IPv6, Netalk, IPX, etc, etc)

* Works in layer 2, meaning Ethernet frames are passed over the VPN tunnel

* *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

* can not be used with Android or iOS devices

TUN benefits:

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

* Transports only layer 3 IP packets

TUN drawbacks:

* Broadcast traffic is not normally transported

* Can only transport IPv4 (OpenVPN 2.3 adds IPv6)

* **Cannot** be used in bridges

Please understand that in both setups, **basic networking knowledge is a must**. You do need to understand basic network *routing* and *firewalling*, no matter if you use routing, bridging, TUN or TAP. Both TUN and TAP devices supports traditional network routing, so you are not required to use bridging with TAP. But using bridges, you need in addition to know how bridges work and how this changes your firewalling. To say it simple: Bridging will complicate your setup further. Of course, there are scenarios where bridging really is the right solution. But in most cases you will most likely solve your VPN setup with basic routing.

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:

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:

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:

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

Again, these changes are only temporary. If you reboot your box, these rules will be cleared out. Please read the documentation to your distribution on how to save the iptables configuration. In worst case you can also use *iptables-save* and *iptables-restore* to dump and restore the iptables configuration to/from a file.

In the openvpn server config you will need these lines:

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:

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.

This setup have much of the same requirements as the previous example. But there are a few minor modifications you need to make.

The Router needs to have a port forwarding for the port you want to use for OpenVPN and forward that port to 192.168.0.10, which is the IP address of the OpenVPN on the internal network.

The next thing you need to do on the router is to add a route for your VPN subnet. In the routing table on your router, add 10.8.0.0/24 to be sent via 192.168.0.10. This is needed for the traffic from your LAN clients to be able to find their way back to the VPN clients. If this is not possible, you need add such routes explicitly on all the LAN clients you want to access via the VPN.

The firewall rules will also need to be different, and less extensive. Here you just need to add rules which opens up traffic from the VPN subnet and into your local LAN.

If you also want your VPN clients to access the complete Internet, just remove the *-d 192.168.0.0/24* part from the first iptables example above.

In some situations it is not possible to modify the routing table on the main router or on each client. Then the alternative is to masquerade all VPN clients as coming from 192.168.0.10. The drawback of this approach is that all VPN clients looks like coming from the VPN server itself - you will **not** see the IP address of the VPN client at all. This approach is generally considered as a last option if proper routing is not feasible.

The rest of the configuration will be as the very first routing example. You need to set net.ipv4.ip_forward=1 and you need the extracts for the OpenVPN configuration as indicated.