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.

Acerca de OpenVPN

OpenVPN es cubierto en este otro articulo, así que haré referencias a las secciones en lugar de copiar y pegar partes de esto aquí. Espero que esto cubra las brechas necesarias para obtener un puente ethernet que funcione.
OpenVPN is covered in another article, so I will reference sections in that rather than just copy-paste parts of it here. This will hopefully plug the gaps required to get a working ethernet bridge.

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

In the VirtualBox network settings, I've told the virtual machine to use 'Internal Network' and I've typed in the network name 'slacknet' for want of a better name. You could call it 'private' if you like. Nothing will reach this network unless we setup a machine as some kind of router to it.

I've told Slackware to install the A, AP, N and L disk sets because I don't need any GUI but want networking stuff, but it doesn't really matter, make it a full install if it pleases you. I've taken care to give this machine a static IP address, in this case 10.0.0.1. Otherwise the install is following all defaults.

After boot there is just one thing we need to do to make this test realistic. We need to enable Dnsmasq. You can follow that link for details, but we just need a small configuration file /etc/dnsmasq.conf containing only:

So now we have our private server running on our private network! Nothing can see it for the moment but if you were to install another virtual machine and connect it to that private (slacknet) network it would get an IP address. We have done this purely to demonstrate that non-IP (i.e. DHCP) traffic can get across our bridge and DHCP is just a convenient way of doing this.

Now all the questions Slackware asks you during network setup apply to the public interface which is connected directly (via VirtualBox's bridge) to the switch in the middle of the diagram above. Chances are it is your home broadband router which will dish out an IP address and maybe (if you're lucky) an appropriate DNS name. It matters not, so long as there is something you can use to identify this public interface on the network. From here on I'm going to refer to this machine's ethernet interface as 'vpn', or we can say 'vpn.localnet', however if you only have an IP address just use that.
The good news is that it doesn't matter if it 'clashes' with the IP address range we talked about in 'Private Server' dnsmasq configuration because… well… it's really private.
Neat huh? This would obviously be a big issue if we want to later add routing from 'Private Server' to the outside world, but that will be another howto.
Las buenas noticias es que no importa si esta 'choca' con el rango de direcciones IP de las que hablamos en la configuración de dnsmasque de el 'servidor privado' por que… bueno… esto es realmente privado.
Limpio eh? Obviamente, esto sería un gran problema si queremos agregar más adelante el enrutamiento del 'Servidor privado' al mundo exterior, pero ese será otro ejemplo.

This will (on boot) create a tap0 device with the correct permissions such that OpenVPN can access it and, more to the point,
it will create it before any of the bridging configuration stuff in the Slackware init scripts kicks in. rc.local would have it created way too late.

configuración del puente

OK, so now we are talking about kernel network bridging, not the ethernet bridging that's the subject of this article.
Este es un hecho triste que a pesar de que tenemos una NIC asignada a propósito a la tare de hablar con nuestra red privada, es decir, no se comparte con ningún otro tráfico, todavía necesitamos crear un puente del kernel para que OpenVPN pueda hablar correctamente con la NIC. En otras palabras, no podemos decirle a OpenVPN que simplemente 'usá eth1' (o que sea tan simple).
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).
Esto quiere un 'tap'. Y un tap puede solo hablar a un dispositivo NIC a través de un puente.
Así que echemos un vistazo a la configuración de red en Slackware.
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.

O puede tener una dirección IP estática. Debes tener *algo*. Ahora desplácese hacia abajo a la sección sobre puentes:
Or you may have a static IP address. You should have *something*. Now scroll down to the section on bridging:

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.

No necesitas configurar la dirección IP a 0.0.0.0, pero esto es una forma práctica de hacer que el puente sea levantado sin darle una dirección ip, y no es un problema.
Si usted no configura alguna dirección ip, usted puede hacer 'ifconfig br0 up' posteriormente.
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.

Cuando se arranca con esta configuración, usted debé chequear que br0 esta arrib con:
When you boot with this configuration, you should check that br0 is up with

# ifconfig br0

y usted puede también chequear el puente con 'brctl show br0' y se debería mostrar algo como esto:
And you can also check the bridge with 'brctl show br0' and it should show something like this:

So that's done the bridging config. Now OpenVPN (when it's eventually configured) will talk nicely to the private network aka 'slacknet' without any trouble, even if it only has 'nobody' as a username.

So this is the part where I can just rest easy 'on the shoulders of giants' so to speak. Please setup your the PKI stuff for an OpenVPN server by following the
guide in the OpenVPN howto. Follow all of section 5 so you have a set of public and private keys for the server. Don't worry about creating the config file to reference them from though as we'll do that back here.
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 options in the manual page for OpenVPN if you want but most are self-explanatory.

I have removed the passphrase from vpn.key (remember that's the equivalent of 'server1.key' in the OpenVPN howto). I've avoided giving up root as well. You would run a more secure setup if this was a production system by understanding the options in the OpenVPN manual page, this is just to get you working.

Now you can go back to the other article and look at Setting up the server. Skip forward to the stuff that talks about rc.openvpn, to ensure you have a script to start OpenVPN up. Once you have that you should be able to startup without seeing errors in /var/log/openvpn.log.

Client Gateway

Configuración de VirtualBox

Al igual que la máquina 'puerta de enlace privado', esta máquina puede tener dos NICs. 'Adaptador 1', sin embargo, puede ser NAT en lugar de puenteado, ya que nada tiene que ser capaz de encontrarlo.
Like the 'Private Gateway' machine, this machine will have two NICs. 'Adapter 1', however can be NAT instead of bridged, as nothing needs to be able to find it.
El 'Adaptador 2' puede estar conectado a la red privada 'slacknet'. Yo hice le asigne el mismo nombre que en la otra máquina del servidor, ya que se conectarán entre sí, pero no importa como se llame, siempre que el 'Cliente privado' use el mismo nombre.
'Adapter 2' will be connected to a private 'slacknet' network. I made the name the same as on the other server machine, as they will become connected together but it doesn't matter what you call it so long as 'Private Client' uses the same name.

Once again, I bring into play the other howto
for the PKI config on the client side. However you can skip the rc.openvpn creation as we won't be running as a daemon. The client configuration (/etc/openvpn/client.conf) is a little simpler:

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).
Si en el arranque va todo bien, obtendras una dirección IP como 10.0.0.50 (o al menos en el rango de direcciones proporcionadas por el servidor Dnsmasq que configuramos en el 'Servidor privado').
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')

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.