Connecting the dots…

I have been guilty of not reporting my findings at work on this blog as regularly as I had intend to. This can be attributed to various reasons more notably due to the change in place of work (more on that to come in the next weeks, need some time to put my thoughts together on that one).

This week, since I no longer have access to VMWare Fusion (where things just worked out of the box), i had to consider setting up my vms on the one of the popular open source alternatives VirtualBox.

Its pretty neat and easy to setup and getting a vm installed and running on it, however the first thing that struck me was that the VM are setup to use NAT which means that the VM can ping the host and the internet, but cannot be contacted by the outside world, not even the host. This being a great idea in case you need it just to check your emails or surf the internet in a safe manner, turns out to be a limitation is you are like me, interested in hosting your servers on the vm to be used as a dev box.

It turns out that virtual machine receives its network address and configuration on the private network from a DHCP server integrated into VirtualBox. The IP address thus assigned to the virtual machine is usually on a completely different network than the host. As more than one card of a virtual machine can be set up to use NAT, the first card is connected to the private network 10.0.2.0, the second card to the network 10.0.3.0 and so on. If you need to change the guest-assigned IP range for some reason, please refer to the section called “Configuring the address of a NAT network interface”.

Pinging this ip adress from the host doesnt work as its on a different subnet than the host (as its usually the case). The documentation for virtualbox states if you need to access a server on the guest on the host, you would need to setup Port Forwarding on the host so that the traffic on the host is directed to a port on the vm.

This turns out to be a pretty handy feature, especially since it can be used to protected your server from OS specific exploitable vulnerabilities, as the actual OS hosting the service can not be contacted. Obviously its assumed that in this case the host/guest OS are not the same .

So here’s my sample setup. I am running a LAMP server on my guest os an image of JeOS and for now i am only concerned about accessing the webserver on my host machine and also from other machines on the network (something that you cant do out of the box on VMWare Fusion, though i am sure it can be done on it by one means or the other).

I run the following commands:

  # VBoxManage setextradata "JeOS" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/Protocol" TCP
  # VBoxManage setextradata "JeOS" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/GuestPort" 80
  # VBoxManage setextradata "JeOS" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/HostPort" 8080

The above example assumes a PCNet virtual network card; if you have configured the guest to use the Intel PRO/1000, replace “pcnet” with “e1000″ in the above commands. Similarly, if you want to configure a different interface instance replace the /0/ with the appropriate index. pcnet and e1000 are counted separately in this respect, and counting starts at 0 for both types.

The name guesthttp is an arbitrary one chosen for this particular forwarding configuration. With that configuration in place, all TCP connections to port 8080 on the host will be forwarded to port 80 on the guest. Protocol can be either of TCP or UDP (these are case insensitive). To remove a mapping again, use the same commands, but leaving out the values (in this case TCP, 80 and 8080).

It is not possible to configure incoming NAT connections while the VM is running. However you can change the settings for a VM which is currently saved (or powered off at a snapshot).