Make an Oracle VM Virtual Box Ubuntu Server Network Accessible


If you've followed the previous article in this "from scratch" series, you will have installed Ubuntu server. If you've installed it into an Oracle VM Virtual Box virtual machine, then the next step is making it accessible to the rest of your network.

If you installed Ubuntu Server onto physical hardware, and you either:

Then the second part of this guide will still be relevant to you.

Oracle VM Virtual Box uses NAT by Default. Why not NAT?

Oracle VM Virtual box, by default, configures VMs to use NAT networking with the VirtualBox Networking engine running on your host computer acting as a gateway between the virtualised server and the rest of your home network. This would probably be ideal for a desktop or client operating system but for a server it's sub-optimal. If you were for instance, running a web server on your new virtualized server, you could try sending the host computer a HTTP request. Unless your computer is running IIS, Apache or Nginx, it won't know what to do with it. Ultimately, your computer will quietly drop the request, doing nothing with it.

This excerpt from the Virtual Box manual reinforces my point. You could of course configure port forwarding, so that when your computer recieves a HTTP request it forwards it to the VirtualBox Networking Enginge, and that in-turn forwards it to your virtualised server. Instead tho, it's worth taking some time to re-configure our Virtual Box hosted server to use bridged networking. Configured to use bridged networking, Virtual Box effectively creates a new network interface that can be seen on your home network. Your virtualised server will see any traffic received by that interface and in-turn, it will be able to emit traffic straight onto your home network from that interface. In reality, there is only one network interface - the one that your host computer is using to access the network. Virtual Box uses a mechanism to filter incoming traffic from that network interface that's destined for a given virtual machine, and then an additional mechanism to inject outgoing traffic.

It's worth taking time to understand why and for that you need an understanding of how NAT or Network Address Translation works.

If that explanation leaves you slightly baffled, then maybe Leo Notenboom's explanation might help. Be warned, if you're new to networking you might have to read it a few times and let it slowly sink in. On the other hand, if this is childs play to you, lets move on and show you how to re-configure your Oracle VM Virtual Box hosted Ubuntu Server.

Configure Oracle VM Virtual Box to use Bridged Networking

Oracle VM VirtualBox Manager

In the settings dialog, select Network in the left-hand pane. You should see the "NAT" default option selected.


From the 'Attatched to' drop down list, select 'Bridged Adapter'. Then in the 'Name' drop down list, make sure the network adapter you're currently using to access your home network is selected. Under Linux, these will usually be wlan0 for a Wi-Fi connection and eth0 for a cabled connection. Under Windows, these are often have longer names, but with 'Wi-Fi' or 'Wireless' somewhere in the description for a Wi-Fi connection and 'Ethernet' somewhere in the description for a cabled entwork connection.

bridged networking

Once you're happy with your select settings, click OK to save an apply the new network settings. That conludes the first part of this process, your virtualised server now has it's own virtual network interface and will appear on your home network just like any other device.

Host Only Networking

You might have noticed that I've been working on the assumption that you're working on your Virtualised Server from home, and that you've got your own private network. This might not always be the case. In some settings, you might not have the privilege of using your own network, for example at work, in student accommodation or in places where you're using public Wi-Fi.

In such circumstances, it's not very wise to do what we've just done. You will in effect be creating a honey pot for brute-force attempts at breaking into the virtualised server via SSH, because we haven't secured it yet. In this sort of situation, you could look at something called host-only networking.

host only networking

With the host only networking configuration, the VirtualBox Networking Engine runs a virtual switch on the host the computer. Each virtualised computer or device can then connect to that virtual switch. This means that they can communicate with each other, but not with the wider world. This is great for isolating your own network when running labs in say, a work setting. If you want to set-up your own DHCP server or Domain Controller with having an adverse effect on your physical computers real network, then host only networking is a great option.

Your host computer even get's a virtual network adapter which can be configured with a static IP address on your virtual network - or even acquire an IP address using DHCP if you choose to run a DHCP server on your virtual network.

If at this point you're wonding what a DHCP is, don't worry. I'll be writing a bit more about these things at a later date. A bit like NAT, DHCP is something you've been using extensively for quite some time without even realising it.

There is unfortunately a downside to using host only networking, and that's the extra work required to create an internet connection or set-up services such as DHCP and DNS that you will take for granted on a home or corporate network. For some people these extra challenges prove useful in having a discrete isolated network for testing purposes. Setting up a fully functional host only network goes beyond the scope of this article, but could be a topic for a future piece.

Checking your Ubuntu Server's DHCP IP Address

This first step in configuring your virtualised Ubuntu Server with bridged networking, is checking whether it's been assigned an IP address. This can be achieved very easily using the console. First start the VM by selecting it in Oracle VM Virtual Box manager and clicking start.

start vm

Log into the VM using the username/password set during the installation process.


At the console, run the command "ifconfig"


The output above shows us that we have two configured network interfaces. The first one, eth0 has an IP address of, which has been assigned by my home network's DHCP server. If your virtual server does not return an IP address (other than the local loopback address of don't worry. This most likely means you don't have a DHCP server running. Just read onto to the next steps on configuring an IP address.

If your virtual server did get an IP address, as mine did in this example, you can now confirm that this virtual server is accessible from your network network by pinging that IP address and checking for a response. You can do this from the host operating system (not the virtualised server) by opening up a terminal (Linux) or a command window (Windows) and typing:

$ ping <IP address>

<IP address> is of course the inet addr that was shown up in the output from your ifconfig command.

If you are struggling to open a terminal window on Linux or a command window on Windows, then here's a brief how to:

How to Open a Linux Terminal Session

How to Open a Windows Command Shell (DOS Prompt)

ping ip address

You can see here that I've managed to send 4 single packets to the virtualised server and I've received responses for each of them. This is good news. In the next step, I want to see if I can ping the server using it's hostname rather than it's IP address. This test won't be successful for all of you, depending on how your network is configured. I know I have a DNS server set-up and that my DHCP server is integrated into it as to automatically create DNS records for DHCP clients. If I've just stopped making sense, don't worry - as I've already more than inferred I'll be discussing both these topics in the future - or you can in the meantime start doing your own research.

ping hostname

As you can see, I'm fortunate enough to get a response from each of my pings. Again, if this second step doesn't work for you, then don't worry. I'll be explaining DHCP and DNS in more detail soon.

So, that's all dandy and nearly concludes this lab. But, this is a server, and as such it might be important to me that it always has the same IP address. There's no guarantee a computer or device with a DHCP assigned IP address will get to keep the same address once it's lease expires. Once way around this is configuring the server with a static IP address.

It's actually not a good idea to hard code or rely on an IP address anywhere that is can be avoided - it's always better to refer to a machine by it's hostname as IP addresses can change when networking schemes are updated. That said, I always tend to follow certain conventions where by IP addresses have a meaning. For example, in a network that is defined as, I would have a starting IP address of and an ending IP address of I'd reserve the first 49 addresses for networking devices (routers/switches etc) and servers. I'd probably run my primary DNS/DHCP servers on, where x is any digit between 0 and 9. Then I'd run my storage servers on, And finally my development and testing servers on In practice, I actually run a much larger range than that, as most companies will. Thus I'd like to give my new virtual server an IP address of - all of my lab and test devices live in the - range. I could create a DHCP reservation, but that's going beyond the scope of this lab. So, instead, I'm going to show you how to statically assign this IP address - or another of your choosing.

Manually Assigning a Unique Static IP Address to your Ubuntu Server

Choosing a Static IP Address

If your server didn't get an IP address automatically via DHCP, or you'd like to use an IP address of your choosing then this next section is for you. How you select an IP Address is up to you - with just a few caveats:

Working out the your home network's IP address range or subnet is potentially quite tricky because it requires an explanation of how IP subnetting works. That, I'm afraid is going a bit beyond the scope of this article, so we're going to cheat a little for now, with the help of DuckDuckGo.

All you need to do is again open a command shell (Windows) or a terminal session (Linux) on any computer connected to your network and then type "ipconfig" for Windows or "ifconfig" for Linux followed by the [enter] key.


There are two values in the output from running that command in which we're interested. The first is the "IPv4 Address" or "inet addr". The second is the "Subnet Mask" or "Mask". We need to note them down something like: and then paste that information into DuckDuckGo

ddg instant answer

The result displayed above is from an Instant Answer incorporated into DuckDuckGo called "subnet calculator". In the results is a field called "Host Address Range". You can pick any address within that range for your virtual server, so long as it's not already used. So, how do we determine whether or not an IP address is already used? Without going into why and wherefore, there's another little trick we can use.

If you recall, I told you that I wanted to give my virtualised server an IP address of So the first thing I'm going to do in order to check whether that address is available, is try pinging it:

$ ping

destination host unreachable

This is a good sign. When I tried pinging my new IP address, there was no response. It's possible that there is a device with an IP address of, but it's configured not to respond to ICMP traffic (pings). Don't worry, there's one more check we can do. In the Command shell/terminal session, try the following command:

$ arp -a

If we've run this command from Windows, we should see our new IP address completely ommitted from the results. Under Linux, you should hopefully see some output like:

? ( at <incomplete> on wlan0

It just so happens I have a device on my network configured not to respond to pings. That has an entry in my ARP (Address Resolution Protocol) cache that looks like this:

? ( at bc:5f:f4:e7:a9:06 [ether] on wlan0

Do you see the difference?

Although I don't get any responses back when I issue the command "ping", I can see an ARP cache entry for that IP address that shows the network card's unique MAC (Media Access Control) address which tells me that there is definitely a network interface assigned to that IP address.

So, I've established from these quick tests that it's safe to use the IP Address of The next step is assigning that IP address to the virtual server.

Configuring the Statically Assigned IP Address

Finally we're ready to assign our virtualised Ubuntu server a static IP address. Switch back to the console window and type:

$ sudo nano /etc/network/interfaces

sudo means execute the following command as root. In linux, the root user is the all powerful administrator user. That's why, quite often, you hear of jail broken phones being rooted. If a hacker compromises a server or a device, they will seek to "root" it or in otherwords get full control over it. The sudo command will prompt for your user account's password, so you'll need to type that in followed by [Enter] to continue.

nano is a simple text editor that we will be using to edit the interfaces file which is inside the /etc/network folder.

sudo nano interfaces

Once you have the interfaces file open inside the text editor, you can use the cursor keys to move around the file. Be careful not to press any other keys - I have a habit of trying to "Alt + Tab" back to the host operating system, which of course just inserts tabs into the file. If you are trying to move focus back to your desktop or another window, hit up the right [ctrl] key first. This will return control of your keyboard back to the host operating system making it possible to switch back to another application using "Alt + Tab".

We need to edit our file to look something like this:

eth0 static ip address

There are a few settings added to the file. The first is address, which is the new IP address you've selected for your server. The remaining settings are netmask, gateway and dns-nameservers. You can quite legitimately use the same settings for these as every other device on your network. In a Windows Command shell, running "ipconfig /all" will give you the netmask, gateway and the dns-nameservers in the results. At any rate, the netmask will not have changed since your sought it out earlier when we typed it into DuckDuckGo. If you are running Linux, then there are two different places we need to check for the gateway and the dns servers.

Determine Network Gateway
In a terminal window, issue the following command:

$ route -n

That reveals your IP routing table. The first row should have a destination of "" with an associated gateway IP address. The gateway IP address is the value we're interested in.

Determine DNS Servers
In a terminal window, issue the following command:

$ cat /etc/resolv.conf

This command returns the output of a special file, and in it should be at least one nameserver record. Use the values from each nameserver record for the dns-nameservers entry in our Ubuntu server's interfaces file.

When you have finished editing the "/etc/network/interfaces" file, type [ctrl] + [o] and then [Enter] to save the changes and then [ctrl] + [x] to exit the nano editor.

Phew! We're nearly there. We've re-configured the networking service to use our new IP address, so all we need now do is restart the interface and then test the changes.

Using the console window, type:

$ sudo ifdown eth0 ; sudo ifup eth0

sudo ifdown sudo if up

So that's it. We've now hopefully selected an IP address, check that it's available, configured the virtualised Ubuntu server to use that IP address and restarted it's network interface to bring our changes into being. How do we now check whether our changes work? We can do this simply and easily using the ping command from another computer on the network:

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=6.17 ms
64 bytes from icmp_seq=2 ttl=64 time=0.309 ms
64 bytes from icmp_seq=3 ttl=64 time=0.325 ms
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.309/2.271/6.179/2.763 ms

As you can see, in my lab at least, this has been a complete success. I hope you've been successful too. We've encountered quite a few things in this, fairly simple, article, including DHCP, DNS, and ARP. In the near future I'll be examining these acronyms and also looking at how, in future, we can make it a bit easier and somewhate more secure remotely accessing our virtualised Ubuntu server using SSH.