[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
howtos:network_services:securely_bridging_ethernet [2018/03/04 01:40 (UTC)] – [Introduction] bifferoshowtos:network_services:ethernet_bridging_with_openvpn [2018/03/13 00:56 (UTC)] (current) – [Bridging setup] bifferos
Line 1: Line 1:
 <!-- Add your text below. We strongly advise to start with a Headline (see button bar above). --> <!-- Add your text below. We strongly advise to start with a Headline (see button bar above). -->
-====== Securely Bridging Ethernet ======+====== Ethernet Bridging With OpenVPN ======
  
 Other guides detail setting up of OpenVPN for 'tun' bridging, where IP traffic is efficiently routed between a couple of geographically separated sites, but this guide is about so-called 'tap' bridging.  In effect, it describes how to join a couple of sites forwarding all ethernet traffic between, regardless of protocol.  This is useful for development, test networks and if you need to forward non-IP protocols.  It is also conceptually simpler than tun bridging because you don't have to care about routing, and you only need run a single DHCP server on one or other side of the bridge. Other guides detail setting up of OpenVPN for 'tun' bridging, where IP traffic is efficiently routed between a couple of geographically separated sites, but this guide is about so-called 'tap' bridging.  In effect, it describes how to join a couple of sites forwarding all ethernet traffic between, regardless of protocol.  This is useful for development, test networks and if you need to forward non-IP protocols.  It is also conceptually simpler than tun bridging because you don't have to care about routing, and you only need run a single DHCP server on one or other side of the bridge.
Line 12: Line 12:
 Just so we are clear what we're talking about, here is a diagram: Just so we are clear what we're talking about, here is a diagram:
  
-{{ howtos:network_services:ethernet_bridging:overview.png }}+{{ howtos:network_services:ethernet_bridging_with_openvpn:overview.png }}
  
 There are two physical machines (Client PM and Server PM) and four virtual machines.  The aim is that the 'Private Client' talks directly to the 'Private Server', as though they are on the same ethernet segment.  The switch in the middle is just my home network but you could consider that to be the Internet if you like. There are two physical machines (Client PM and Server PM) and four virtual machines.  The aim is that the 'Private Client' talks directly to the 'Private Server', as though they are on the same ethernet segment.  The switch in the middle is just my home network but you could consider that to be the Internet if you like.
Line 20: Line 20:
 ===== VirtualBox ===== ===== VirtualBox =====
  
-[[https://www.virtualbox.org/ | VirtualBox]] is my preferred virtualisation solution because it installs cleanly under Slackware 14.2 and -current and is pretty easy to use.  If you happen to have four physical machines on which you can install Slackware you can of course do all of this without virtualisation!  In my case I have two physical machines (I call them 'Client PM' and 'Server PM' to represent each 'site' that you want to bridge together, and the plan is to create two virtual machines on each of these physical machines.  All virtual machines run un-patched Slackware64 14.2 +[[https://www.virtualbox.org/ | VirtualBox]] is my preferred virtualisation solution because it installs cleanly under Slackware 14.2 and -current and is pretty easy to use.  If you happen to have four physical machines on which you can install Slackware you can of course do all of this without virtualisation!  In my case I have two physical machines to represent each 'site' that you want to bridge together.  All virtual machines run un-patched Slackware64 14.2 
  
 ===== Private Server ===== ===== Private Server =====
Line 102: Line 102:
 IPADDR[0]="" IPADDR[0]=""
 NETMASK[0]="" NETMASK[0]=""
-USE_DHCP[0]=yes"+USE_DHCP[0]="yes"
 ... ...
 </code> </code>
Line 216: Line 216:
 I was going to use Slackware for this, but I decided to cheat and use Slax (Bootable CD distro) to save time on the install.  Slax requests a DHCP address on boot, so it really has all you need to test the bridge out (DHCP request sent, DHCP response received).  If all goes well when you boot you'll get an IP address something like 10.0.0.50 ( or at least in the range of addresses provided by the Dnsmasq server we setup on 'Private Server') I was going to use Slackware for this, but I decided to cheat and use Slax (Bootable CD distro) to save time on the install.  Slax requests a DHCP address on boot, so it really has all you need to test the bridge out (DHCP request sent, DHCP response received).  If all goes well when you boot you'll get an IP address something like 10.0.0.50 ( or at least in the range of addresses provided by the Dnsmasq server we setup on 'Private Server')
  
-===== Putting it all together =====+===== End to End Testing =====
  
 So once all four (yes!) virtual machines are up and running, it should be possible (if all is working) to boot the Private Client and get an IP address in the right range, i.e. between 10.0.0.50 and 10.0.0.70.  Pay close attention to /var/logs/openvpn.log on 'Server Gateway' and of course the messages displayed when running openvpn on 'Client Gateway' as they should tell you what's wrong.  OpenVPN is pretty good like that.  The paranoid will also want to check /var/state/dnsmasq/dnsmasq.leases on 'Private Server' to reassure themselves that all's well and we are actually talking across the bridge. So once all four (yes!) virtual machines are up and running, it should be possible (if all is working) to boot the Private Client and get an IP address in the right range, i.e. between 10.0.0.50 and 10.0.0.70.  Pay close attention to /var/logs/openvpn.log on 'Server Gateway' and of course the messages displayed when running openvpn on 'Client Gateway' as they should tell you what's wrong.  OpenVPN is pretty good like that.  The paranoid will also want to check /var/state/dnsmasq/dnsmasq.leases on 'Private Server' to reassure themselves that all's well and we are actually talking across the bridge.
  
 +===== Consolidation =====
  
-====== Sources ====== +As I explained in the introduction, it's possible to test all this out without the 'Private server', and combine the function of 'Private Server' and 'Server gateway' in a single machine.  Read on to discover how.
-<!-- * Originally written by [[wiki:user:bifferos | User bifferos]] -->+
  
 +First thing to do is switch off (power down) the 'Private Server'.
 +
 +Next, we need to assign an ip address to our ethernet bridge on the 'Server Gateway'.
 +
 +<code>
 +# ifconfig br0 10.0.0.1 netmask 255.255.255.0
 +</code>
 +
 +<note>we assign an address to the bridge, not eth1!</note>
 +Now we just need to run a dnsmasq instance on this br0 interface, to serve requests up to the VPN.  Much like the 'Private Server' config, /etc/dnsmasq.conf should look like this:
 +
 +<code>
 +interface=br0
 +dhcp-range=10.0.0.50,10.0.0.70,12h
 +</code>
 +
 +Then it's just a matter of running up dnsmasq:
 +
 +<code>
 +# chmod 755 /etc/rc.d/rc.dnsmasq
 +# /etc/rc.d/rc.dnsmasq start
 +</code>
 +
 +At this point, rebooting the 'Private Client' should now get an IP address from the consolidated server, and that's really it.  However, I also changed the **old** 'Private Server' to dhcp to confirm it could also get an IP address from 'Server Gateway'
 +
 +
 +====== Sources ======
 +  * Originally written by [[wiki:user:bifferos | User bifferos]]
  
-{{tag>howtos ethernet bridging}}+{{tag>howtos ethernet bridging author_bifferos}}
 howtos:network_services:ethernet_bridging_with_openvpn ()