I use VirtualBox as a virtual machine host on many systems, usually so I can fire up a differently configured environment for testing software as I develop it. In December 2013 a new version, v4.3, was released, and among its few new features is a networking mode called "NAT Network."

VirtualBox has had a few networking modes that allow the virtual machines to have various levels of connectivity with the host, the wider network (including the Internet), and each other. Sadly, there are gaps in functionality or some loss of flexibility in each. I'll lay out what I mean by that.

Bridged Adapter

Sometimes the most flexible, but sometimes also problematic is the Bridged Adapter. In this case, the virtual guest participates directly in the same network the host is on. In this mode, the guest should receive the same kind of information as the host (either through DHCP or manual settings), and have the same kind of access to the rest of the network.

The Bridged Adapter can be problematic as sometimes the virtual network adapter isn't allowed to participate in the same network as the host. It can also be problematic because when the virtual machine is participating in the larger network, it needs to be "unique enough," in terms of things like its hostname and MAC address; this can lead to conflicts if many people are using clones of the same virtual machine on the same network, for example. Also, by virtue of participating in the larger network, the virtual machines are potentially accessible by all of the machines on the network (at least as much as the host is, too), which can lead to problems when clients connect to the wrong servers.

What the Bridged Adapter network doesn't allow you to do is to create a small private network, one with only the host and guest virtual machines. There are two kinds of VirtualBox networks that do allow you to create a small private network, the Host-only Adapter and Internal Network.

Host-only Adapter

The Host-only Adapter creates a virtual private network that the host and virtual machines share. This is the only mechanism that the virtual machine host directly participates in the network. This network acts as any other small network, but does not include any built-in mechanism for the guest virtual machines to get traffic through the host.

Since it's like any other small network, it would be possible to run NAT or proxy software on the host that the guests could use to participate in the larger network, but this then requires configuring the virtual machines to be aware of that software. For example, if the host were running NAT software, the guests could be configured to use the host's network address as the gateway; or by configuring the guest's software to use the host's proxy software if that were the route used.

If the virtual machines have no need to access the host's network (or the Internet beyond), this is the best network to chose to have a virtual private network with many hosts.

Internal Network

The Internal Network is similar to, but is a little more restrictive than the Host-only Adapter network, because only the virtual machines participate in the network. That is, unlike the Host-only Adapter network, the host does not participate in this network. All of the virtual machines need to have static addresses, or one of the virtual machines needs to act as a DHCP server, as the host doesn't provide these services. Since the host doesn't participate in the network, there are no port-forwarding tricks to use to connect to them, so the only access is through the virtual machine console interface (or by going through one virtual guest to get to others). Also, there's also no way for virtual machines on an Internal network to participate in the host's network.

This is really useful for operating in isolation, but without a mechanism for interacting with the host or other networks, this isolation is severe. Especially since the host can't participate with the guests, getting files and such to the guests requires mounting file systems such as CDs or shares, which can require the VirtualBox guest additions.

NAT

VirtualBox has also offered NAT networking as an option. In this mode a very small network is created in which the virtual machine is the only device; technically, from the virtual machine's perspective there's a whole network, and the host device will act as the virtual machine's gateway, but the host isn't able to interact with the network, at least not without tricks like port forwarding. In the case where many virtual machines are started with NAT networking, each starts its own small private network, even when the networks seem to be the same; that is, every virtual machine running will receive an address like 10.0.2.15 and a gateway of 10.0.2.2 for its first network interface configured to use NAT.

The NAT networking is handy becaue the virtual machine is able to access the host's network (and beyond), but the limitation is that the virtual machine's cannot participate with each other. There are tricks with port forwarding that can be done, but without the trickery, it isn't an easy task.

Dual NIC

Until VirtualBox v4.3 the most widely used mechanism for having multiple virtual machines participate in the same network and the host's network has been to give the virtual machines two network adapters. Usually one configured for Host Only networking, so the host can also participate, and one for NAT networking, so the virtual machines can see the host's network and other network resources.

For the most part this is an acceptable compromise, and the overhead and impact of having muliple adapters is pretty benign.

NAT Network

With VirtualBox v4.3 a new mechanism has arrived. The (unfortunately named) NAT Network networking extends the NAT networking (see why that's unfortunate?) to allow multiple virtual machines to participate; no longer is each virtual machine solo on an otherwise identical private network. Each virtual machine guest configured for the same NAT Networking network can see the other guests configured to be on that network. They can also pass through the host and access resources on the host's network. Unfortuantely, the host isn't directly participating in the network, so the same restrictions as NAT networking exist on the new NAT Network.

Shortfalls

There are a couple of irksome shortfals to using the NAT Network, which I accept as part of its early (and noted in the documentation, "experimental") nature.

The first is in the GUI configuration. When viewing the VirtualBox library (and not a VM), the preferences dialog offers the chance to create an maintain the NAT Network, in the same way one can create and maintain Host-only Adapter networks. Unlike the otherwise similarly managed Host-only Adapter network options, the DHCP server is not (yet) configurable in the GUI. When creating a new NAT Network, the DHCP is configured by default to use nearly the entire address range; really leaving just the few addresses needed by the virtual network such as the DHCP server and gateway. For a lot of uses this may not be troublesome, but in the case where there may be a need or desire to assign some static hosts on the private network, the chance of DHCP offering a static address is real. The VirtualBox DHCP server configuration leaves a lot of normal DHCP options off the table, like reservations, which would alleviate this. Still, for its general purpose, it's sufficient. Creating or modifying the DHCP server on the command line offers opportunity to free some addresses--this is discussed later.

Also, when creating a new NAT Network using the GUI, the network is given the name NatNetwork (and later NatNetwork1 and so on). While the name seems to be able to be changed in the GUI, the original name remains the one used througout the system. This means that scripting or command-line use will always use the original name. This suggests the better way to create these networks is to use the command line (or accept the NatNetwork as the name).

The following two commands will create a NAT Network, with a desired name, and related DHCP server, with the desired DHCP address range. (Note the \ are to show command-line continuation, to make up for the slim width of the post.)

VBoxManage natnetwork add \
--netname 10.20.14-NAT \
--network "10.20.14.0/24" \
--enable

VBoxManage dhcpserver add \
--netname 10.20.14-NAT \
--ip 10.20.14.3 \
--netmask 255.255.255.0 \
--lowerip 10.20.14.200 \
--upperip 10.20.14.250 \
--enable

 Of course, whatever "netname" is desired can be used (this will be displayed in the GUI and used on the command line), and the "network" and related information can be configured to match specific cases. Here I chose to use this year as the middle of the private network definition and created a related name. I nabbed just 50 addresses for the DHCP; of course, there's no reasonable way my workstation will be running 50 virtual hosts at a time, but this allows switching virtual machines off and on without risking address collision.

Once the NAT Network is created, configuration is done in the individual virtual machine settings; select NAT Networking and the 10.20.14-NAT in its network configuration. Start the virtual machines, and the virtual machines can see each other and can access resources on the host network (including the Internet)!

Of course, there's still no direct access from the host to the guests without using port forwarding. Using port forwarding is helpful for the statically-addressed devices, but is not as helpful for the dynamically-addressed devices.

Troubles

I've done this same configuration in tests on a few VirtualBox hosts, and have had a couple of weird quirks. Not the same quirk, and one I blame on something weird in the host configuration and not VirtualBox.

On one of my Ubuntu hosts, everything seemed to work well, but the virtual machines didn't receive a nameserver. This didn't matter which guest I used; an Ubuntu server or desktop, a Fedora desktop, and a Windows guest. It took a few attempts and digging around on the Internet to recognize nothing was added to the /etc/resolv.conf of the guests, which led me to discover a weird configuration on my host. For some reason the /etc/resolv.conf on my host had 127.0.0.1 as its nameserver; the NAT Network documentation says this won't be passed to the client. Even though the host is not running any name resolver, and even though its static configuration had a different DNS named, somehow this configuration worked and my workstation could still resolve addresses. It took a few tries, but I changed the static configuration to another DNS, and that corrected the problem for the guests.

On my Mac host, everything else seems to work well, but for some reason the NAT gateway is on the wrong IP address. On my Ubuntu host it was using the 10.20.14.1 address as the host address and gateway successfully; successfully in that the documentation suggests this would be the case. On the Mac host, the guests were likewise configured to use 10.20.14.1 as their gateway, but through trial and error I discovered that indeed the gateway needed to be configured to be 10.20.14.2 instead. I was able to verify this by changing the default gateway in the virtual machine, as this Linux example shows:

sudo route del default

sudo route add default gw 10.20.14.2

I've created several other NAT Networks to test this, and it happens to every one--the second, not the first address is used--for every network created using the command line. However, when I use one of the GUI-created NAT Networks, it works without this complication.

As a compromise, instead of monkeying within each virtual machine, it is possible to change the DHCP server related to the GUI-created NatNetwork. This command will edit the DHCP range, in this example only providing 10 addresses, allowing the weird goof to not be an issue (although the name is not indicative of its network):

VBoxManage dhcpserver modify \
--netname NatNetwork \
--ip 10.0.2.3 \
--netmask 255.255.255.0 \
--lowerip=10.0.2.220 \
--upperip=10.0.2.229

Of course, one could change the name in the GUI, which does change it for the purposes of selecting in the virtual machine configurations, if one wasn't concerned that the actual under-the-hood name of the network didn't match what the GUI showed.

Conclusion

It's handy to have some flexibility to run a few virtual machines on the same network, still with access to the host's network and Internet, and with the ease of (simple) DHCP, and without the tedium of configuring multiple network adapters on each machine. Now a "server" can be set up and have software deployed in an environment from scratch or more appropriately configured (and with less cruft than the development workstation), and a "client" can be configured on the same network for testing. Or many "servers" to test a distributed configuration. All of this on a shared private network, and still with (one-way) access to other network resources (like the Internet).

While all of this is nice, what I would really like to see in the future is a combination of the NAT and Host-only Adapter networking, so that the virtual host can directly participate in the network as well. I can understand that it may be difficult to offer a single address that could do both work as a NAT router and offer direct access from the host, but perhaps a compromise would be to add another virtual network adapter for the host to participate in the network. It's already the case that the DHCP server and NAT can have different IPs on the network, so why not one more where the host can directly access the network?

Or maybe a solution would be to offer a NAT virtual device that could be added to a Host-only Adapter network. That might require some additional DHCP options to be configured, though, and that might be asking too much.