He we are writing in this brand new blog category called Plumbing. Welcome to the misterious world of the systems/servers/networking :-S
I started working as a sysadmin some years ago. It is something I don’t love exactly but here in the Canaries you have to do everything yourself; you design, you develop, you patch, and you manage the servers and networks. Now I am a Plumbing Power Ranger again! 🙂 It is nice sometimes though.

The idea of having a Virtual Private Network to which connect a Virtual Machine that is using your local machine resources but accesing the internet through the other peer of the VPN is very useful. This is another idea of my friend Alberto Morales, a.k.a Master Alberto ;-). By doing so you can see how the network is behaving on the other side of the tunnel so that you get an idea on how the PCs in the office are working. If the system installed in those PCs is the same that you are running in your virtual machine, the conditions are pretty much the same.

This time we are using OpenVPN and VirtualBox which allow us testing Windows or Linux machines as both tools run on Windows and Linux. However we are using Linux right now. OpenVPN uses a static key in the server side for simplicity sake.

Server side, OpenVPN config:

  • /etc/openvpn/server.conf
    proto tcp-server
    dev tap
    up ./server.up
    secret secret.key
  • /etc/openvpn/server.up
    /sbin/ifconfig $1 0.0.0.0 promisc up
    /usr/sbin/brctl addif br0 $1

In order for that to work a bridge br0 has to be configured and up. An ethernet bridge is like a networking switch. When openvpn starts the network interface /dev/tapX (X will be a number) is configured. A tap interface is like the rj45 socket of the switch (ethernet bridge).

What we do to connect the server above using VirtualBox (the client):

  • brctl addbr br1 # create a bridge called bridge 1
  • openvpn –dev tap –remote serverIPorName 1194 –proto tcp-client –secret /etc/openvpn/secret.key
  • # The previous line will create a /dev/tapX device, let’s call it /dev/tap2
  • ifconfig tap1 0.0.0.0 promisc up # create tap1 making sure it didn’t exist already
  • ifconfig tap2 0.0.0.0 promisc up # set tap2 promisc, considering that tap2 was created by openvpn
  • ifconfig br1 0.0.0.0 promisc up # let the bridge be promisc
  • brctl addif br1 tap1 # give the bridge a socket
  • brctl addif br1 tap2 # give the bridge another socket
  • chmod 0666 /dev/net/tun # set the permissions for the user to access the tap sockets
  • Start virtualbox, select the virtual machine to run, go to settings and configure the network: Use “Host Interface” for the network adapter. Interface name will be tap1, the one that is in the bridge but not used by OpenVPN.

The reason we need 2 tap interfaces is that OpenVPN uses one so it gets busy and the virtual machine needs another. If we just wanted to establish a tunnel with OpenVPN and access the other peer of the virtual LAN, we don’t need the bridge in the client side. Just launch OpenVPN with the command above and give an ip address to the tap device:

  • ifconfig tap2 192.168.3.34 netmask 255.255.255.0

Now you should be able to ping the LAN ip of the server. You are in the virtual LAN. If rather than setting the ip manually you request dhcp, the dhcp server will change the default gateway in your local machine so you loose the internet connection and openvpn falls down. Always check the routing table (route -n)
In case you make the same mistake I did and set the ip of the tap device having a bridge with 2 tap devices, you get to weird situations. In that case the packages were sent through tap2 but they were trying to come back through tap1. It ends up in lost packages, tap1 drops packages because it didn’t send them. That is: having the bridge with more than one tap device, never give an ip address to any of the tap devices.