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 revision Previous revision
Next revision
Previous revision
howtos:network_services:ethernet_bridging_with_openvpn [2018/03/04 00:56 (UTC)]
bifferos [tap0 device]
howtos:network_services:ethernet_bridging_with_openvpn [2018/03/13 00:56 (UTC)] (current)
bifferos [Bridging setup]
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 }}
  
-I could have stopped short of the '​Private ​Server' ​and '​Private Client' ​and you'd have your bridge, but what's the point in a bridgeif you've nothing to test it with?  The switch in the middle is just my home network ​setup, ​you could consider that to be 'the Internet'​+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. 
 + 
 +Many real setups will make the 'Server Gateway'​ and the '​Private Server'​ one and the same, there is no reason for them to be separate machines, however I felt it's easier to follow what's going on if they are distinct.
  
 ===== 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 =====
  
-Without further ado, let's get on with setting up our private server.  I'm going to call it '​hiddenserver'​.  I've given the virtual machine the following resources:+Without further ado, let's get on with setting up our private server. ​ I've given the virtual machine the following resources:
  
   * 1024 MB RAM   * 1024 MB RAM
Line 95: Line 97:
 OK, so now we are talking about [[https://​wiki.linuxfoundation.org/​networking/​bridge | kernel network bridging]], not the ethernet bridging that's the subject of this article. ​ It's a sad fact that even though we have a NIC purposely allocated to the task of talking to our private network, i.e. not shared with any other traffic, we still need to create a kernel bridge in order for OpenVPN to talk properly to the NIC, in other words we can't tell OpenVPN to just 'use eth1' (oh that it were so simple). ​ It wants a '​tap'​. ​ And a tap can only talk to a NIC via a bridge. ​ So let's have a look at the network config in Slackware. OK, so now we are talking about [[https://​wiki.linuxfoundation.org/​networking/​bridge | kernel network bridging]], not the ethernet bridging that's the subject of this article. ​ It's a sad fact that even though we have a NIC purposely allocated to the task of talking to our private network, i.e. not shared with any other traffic, we still need to create a kernel bridge in order for OpenVPN to talk properly to the NIC, in other words we can't tell OpenVPN to just 'use eth1' (oh that it were so simple). ​ It wants a '​tap'​. ​ And a tap can only talk to a NIC via a bridge. ​ So let's have a look at the network config in Slackware.
  
-For eth0 in /​etc/​rc.d/​rc.inet1.conf you are going to now have a setup something like this, curteously ​supplied by the slackware networkconfig ​script:+For eth0 in /​etc/​rc.d/​rc.inet1.conf you are going to now have a setup something like this, courteously ​supplied by the Slackware netconfig ​script:
  
 <​code>​ <​code>​
 IPADDR[0]=""​ IPADDR[0]=""​
 NETMASK[0]=""​ NETMASK[0]=""​
-USE_DHCP[0]=yes"​+USE_DHCP[0]="yes"
 ... ...
 </​code>​ </​code>​
Line 120: Line 122:
 IPADDR[1]="​0.0.0.0"​ IPADDR[1]="​0.0.0.0"​
 </​code>​ </​code>​
 +
 +Be careful with the numbers. ​ It's the the square brackets which are telling Slackware this is the 2nd device we're configuring as a bridge, and we want to add eth1 to the bridge along with the tap0 device. ​ Slackware doesn'​t configure the eth1 device, we don't even need to bring it up or otherwise refer to it in the config files as it's slave to the bridge.
 +
 +<​note>​
 +Some people might configure br0 as br1 here, to indicate it's connected to the second NIC and keep them the same.  You can do that.  And you can change the name of tap0 as well if you want, experience tells me it's best to always use the lowest numbers for everything regardless of what they do.  For me, at least, it reduces the confusion.
 +</​note>​
  
 You don't have to set the IP address to 0.0.0.0, but it's a handy way of making the bridge come '​up'​ without giving it an IP address, and something that is supposed to simply sit there forwarding ethernet frames has no business having an IP address of its own.  If you don't set any address at all you can do '​ifconfig br0 up' at some later point. You don't have to set the IP address to 0.0.0.0, but it's a handy way of making the bridge come '​up'​ without giving it an IP address, and something that is supposed to simply sit there forwarding ethernet frames has no business having an IP address of its own.  If you don't set any address at all you can do '​ifconfig br0 up' at some later point.
Line 147: Line 155:
 Ready? ​ Good. Ready? ​ Good.
  
-So my /​etc/​openvpn/​server.conf is a little simpler than the one in the OpenVPN howto. ​ We don't care about any of the routing stuff, and I've removed all the comments for brevity. ​ You can always check them in the manual page for OpenVPN if you want but most are self-explanatory.+So my /​etc/​openvpn/​server.conf is a little simpler than the one in the OpenVPN howto. ​ We don't care about any of the routing stuff, and I've removed all the comments for brevity. ​ You can always check options ​in the manual page for OpenVPN if you want but most are self-explanatory.
  
 <​code>​ <​code>​
Line 208: 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'​)
  
-====== ​Sources ​====== +===== End to End Testing ​=====
-<!-- * Originally written by [[wiki:​user:​bifferos | User bifferos]] -->+
  
 +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 =====
 +
 +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.
 +
 +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}}

In Other Languages
QR Code
QR Code howtos:network_services:ethernet_bridging_with_openvpn (generated for current page)