Changes between Initial Version and Version 1 of BridgingAndRouting

Timestamp:

02/08/12 12:49:16 (12 years ago)

Author:

Samuli Seppänen

Comment:

Wikified ​http://thread.gmane.org/gmane.network.openvpn.user/32935

BridgingAndRouting

@@ +1 @@
+= 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)
+
+'''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 than 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
+
+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)
+
+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
+ * Can be used in bridges
+
+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. But using bridges, you also need to know how bridges work and how this changes firewalling in addition.
+
+= 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>
+}}}
+
+Say you have a pretty standard network with a single firewall:
+
+{{{
+{INTERNET}-----[FIREWALL/OpenVPN server]-----<Internal network>
+}}}
+
+To set up a TUN setup with routing and masquerading for the VPN subnet, one approach could be something like this.  Say your VPN is 10.8.0.0/24, your "Internet interface" is configured as eth1 and your internal LAN (say, 192.168.0.0/24) is eth0 ... then the firewall rules would be something like:
+
+{{{
+    # Allow 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 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 LAN to "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
+
+    # Masquerade traffic from VPN to "the world"
+    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
+
+}}}
+
+You need in the openvpn server config 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.