Table of Contents
As briefly mentioned in the section called “Network settings”, VirtualBox provides up to eight virtual PCI Ethernet cards for each virtual machine. For each such card, you can individually select
the hardware that will be virtualized as well as
the virtualization mode that the virtual card will be operating in with respect to your physical networking hardware on the host.
Four of the network cards can be configured in the "Network" section of the settings dialog in the graphical user interface of VirtualBox. You can configure all eight network cards on the command line via VBoxManage modifyvm; see the section called “VBoxManage modifyvm”.
This chapter explains the various networking settings in more detail.
For each card, you can individually select what kind of hardware will be presented to the virtual machine. VirtualBox can virtualize the following six types of networking hardware:
AMD PCNet PCI II (Am79C970A);
AMD PCNet FAST III (Am79C973, the default);
Intel PRO/1000 MT Desktop (82540OEM);
Intel PRO/1000 T Server (82543GC);
Intel PRO/1000 MT Server (82545EM);
Paravirtualized network adapter (virtio-net).
The PCNet FAST III is the default because it is supported by nearly all operating systems out of the box, as well as the GNU GRUB boot manager. As an exception, the Intel PRO/1000 family adapters are chosen for some guest operating system types that no longer ship with drivers for the PCNet card, such as Windows Vista; see the section called “Windows Vista networking” for details.[27]
The "Paravirtualized network adapter (virtio-net)" is special. If you select this, then VirtualBox does not virtualize common networking hardware (that is supported by common guest operating systems out of the box). Instead, VirtualBox then expects a special software interface for virtualized environments to be provided by the guest, thus avoiding the complexity of emulating networking hardware and improving network performance. Starting with version 3.1, VirtualBox provides support for the industry-standard "virtio" networking drivers, which are part of the open-source KVM project.
The "virtio" networking drivers are available for the following guest operating systems:
Linux kernels version 2.6.25 or later can be configured to provide virtio support; some distributions also back-ported virtio to older kernels.
For Windows 2000, XP and Vista, virtio drivers can be downloaded and installed from the KVM project web page.[28]
VirtualBox also has limited support for so-called jumbo frames, i.e. networking packets with more than 1500 bytes of data, provided that you use the Intel card virtualization and bridged networking. In other words, jumbo frames are not supported with the AMD networking devices; in those cases, jumbo packets will silently be dropped for both the transmit and the receive direction. Guest operating systems trying to use this feature will observe this as a packet loss, which may lead to unexpected application behavior in the guest. This does not cause problems with guest operating systems in their default configuration, as jumbo frames need to be explicitly enabled.
Each of the eight networking adapters can be separately configured to operate in one of the following five modes:
In this mode, VirtualBox reports to the guest that a network card is present, but that there is no connection -- as if no Ethernet cable was plugged into the card. This way it is possible to "pull" the virtual Ethernet cable and disrupt the connection, which can be useful to inform a guest operating system that no network connection is available and enforce a reconfiguration.
If all you want is to browse the Web, download files and view e-mail inside the guest, then this default mode should be sufficient for you, and you can safely skip the rest of this section. Please note that there are certain limitations when using Windows file sharing (see the section called “NAT limitations” for details).
This is for more advanced networking needs such as network simulations and running servers in a guest. When enabled, VirtualBox connects to one of your installed network cards and exchanges network packets directly, circumventing your host operating system's network stack.
This can be used to create a different kind of software-based network which is visible to selected virtual machines, but not to applications running on the host or to the outside world.
This can be used to create a network containing the host and a set of virtual machines, without the need for the host's physical network interface. Instead, a virtual network interface (similar to a loopback interface) is created on the host, providing connectivity among virtual machines and the host.
This option can be used to connect to a Virtual Distributed Ethernet switch on a Linux or a FreeBSD host. It is only available if the VDE software and the VDE plugin library from the VirtualSquare project are installed on the host system. For more information on setting up VDE networks, please see the documentation accompanying the software.
The following sections describe the available network modes in more detail.
Network Address Translation (NAT) is the simplest way of accessing an external network from a virtual machine. Usually, it does not require any configuration on the host network and guest system. For this reason, it is the default networking mode in VirtualBox.
A virtual machine with NAT enabled acts much like a real computer that connects to the Internet through a router. The "router", in this case, is the VirtualBox networking engine, which maps traffic from and to the virtual machine transparently. The disadvantage of NAT mode is that, much like a private network behind a router, the virtual machine is invisible and unreachable from the outside internet; you cannot run a server this way unless you set up port forwarding (described below).
The network frames sent out by the guest operating system are received by VirtualBox's NAT engine, which extracts the TCP/IP data and resends it using the host operating system. To an application on the host, or to another computer on the same network as the host, it looks like the data was sent by the VirtualBox application on the host, using an IP address belonging to the host. VirtualBox listens for replies to the packages sent, and repacks and resends them to the guest machine on its private network.
The 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 “Fine-tuning the VirtualBox NAT engine”.
As the virtual machine is connected to a private network internal to VirtualBox and invisible to the host, network services on the guest are not accessible to the host machine or to other computers on the same network. However, like a physical router, VirtualBox can make selected services available to the world outside the guest through port forwarding. This means that VirtualBox listens to certain ports on the host and resends all packets which arrive there to the guest, on the same or a different port.
To an application on the host or other physical (or virtual) machines on the network, it looks as though the service being proxied is actually running on the host. This also means that you cannot run the same service on the same ports on the host. However, you still gain the advantages of running the service in a virtual machine -- for example, services on the host machine or on other virtual machines cannot be compromised or crashed by a vulnerability or a bug in the service, and the service can run in a different operating system than the host system.
You can set up a guest service which you wish to proxy using the
command line tool VBoxManage; for
details, please refer to the section called “VBoxManage modifyvm”.
You will need to know which ports on the guest the service uses
and to decide which ports to use on the host (often but not always you
will want to use the same ports on the guest and on the host). You can
use any ports on the host which are not already in use by a service. For
example, to set up incoming NAT connections to an
ssh server in the guest, use the
following command:
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,,22"
With
the above example, all TCP traffic arriving on port 2222 on any host
interface will be forwarded to port 22 in the guest. The protocol name
tcp is a mandatory attribute defining
which protocol should be used for forwarding
(udp could also be used). The name
guestssh is purely descriptive and will
be auto-generated if omitted. The number after
--natpf denotes the network card, like
in other parts of VBoxManage.
To remove this forwarding rule again, use the following command:
VBoxManage modifyvm "VM name" --natpf1 delete "guestssh"
If for some reason the guest uses a static assigned IP address not leased from the built-in DHCP server, it is required to specify the guest IP when registering the forwarding rule:
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,10.0.2.19,22"
This example is identical to the previous one, except that the NAT engine is being told that the guest can be found at the 10.0.2.19 address.
To forward all incoming traffic from a specific host interface to the guest, specify the IP of that host interface like this:
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,127.0.0.1,2222,,22"
This forwards all TCP traffic arriving on the localhost interface (127.0.0.1) via port 2222 to port 22 in the guest.
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).
PXE booting is now supported in NAT mode. The NAT DHCP server
provides a boot file name of the form
vmname.pxe if the directory
TFTP exists in the directory where the
user's VirtualBox.xml file is kept. It
is the responsibility of the user to provide
vmname.pxe.
There are four limitations of NAT mode which users should be aware of:
Some frequently used network debugging tools (e.g.
ping or tracerouting) rely on the
ICMP protocol for sending/receiving messages. While ICMP support
has been improved with VirtualBox 2.1
(ping should now work), some
other tools may not work reliably.
The guest does not reliably receive broadcasts, since, in
order to save resources, it only listens for a certain amount of
time after the guest has sent UDP data on a particular port. As a
consequence, NetBios name resolution based on broadcasts does not
always work (but WINS always works). As a workaround, you can use
the numeric IP of the desired server in the
\\server\share notation.
Protocols other than TCP and UDP are not supported. This means some VPN products (e.g. PPTP from Microsoft) cannot be used. There are other VPN products which use simply TCP and UDP.
On Unix-based hosts (e.g. Linux, Solaris, Mac OS X) it is
not possible to bind to ports below 1024 from applications that
are not run by root. As a result,
if you try to configure such a port forwarding, the VM will refuse
to start.
These limitations normally don't affect standard network use. But the presence of NAT has also subtle effects that may interfere with protocols that are normally working. One example is NFS, where the server is often configured to refuse connections from non-privileged ports (i.e. ports not below 1024).
With bridged networking, VirtualBox uses a device driver on your host system that filters data from your physical network adapter. This driver is therefore called a "net filter" driver. This allows VirtualBox to intercept data from the physical network and inject data into it, effectively creating a new network interface in software. When a guest is using such a new software interface, it looks to the host system as though the guest were physically connected to the interface using a network cable: the host can send data to the guest through that interface and receive data from it. This means that you can set up routing or bridging between the guest and the rest of your network.
For this to work, VirtualBox needs a device driver on your host system. The way bridged networking works has been completely rewritten with VirtualBox 2.0 and 2.1, depending on the host operating system. From the user perspective, the main difference is that complex configuration is no longer necessary on any of the supported host operating systems.[29]
Even though TAP is no longer necessary on Linux with bridged networking, you can still use TAP interfaces for certain advanced setups, since you can connect a VM to any host interface -- which could also be a TAP interface.
To enable bridged networking, all you need to do is to open the Settings dialog of a virtual machine, go to the "Network" page and select "Bridged network" in the drop down list for the "Attached to" field. Finally, select desired host interface from the list at the bottom of the page, which contains the physical network interfaces of your systems. On a typical MacBook, for example, this will allow you to select between "en1: AirPort" (which is the wireless interface) and "en0: Ethernet", which represents the interface with a network cable.
Depending on your host operating system, the following limitations should be kept in mind:
On Macintosh hosts, functionality is limited when using AirPort (the Mac's wireless networking) for bridged networking. Currently, VirtualBox supports only IPv4 over AirPort. For other protocols such as IPv6 and IPX, you must choose a wired interface.
On Linux hosts, functionality is limited when using wireless interfaces for bridged networking. Currently, VirtualBox supports only IPv4 over wireless. For other protocols such as IPv6 and IPX, you must choose a wired interface.
Also, setting the MTU to less than 1500 bytes on wired interfaces provided by the sky2 driver on the Marvell Yukon II EC Ultra Ethernet NIC is known to cause packet losses under certain conditions.
On Solaris hosts, there is no support for using wireless interfaces. Filtering guest traffic using IPFilter is also not completely supported due to technical restrictions of the Solaris networking subsystem. These issues would be addressed in a future release of Solaris 11.
With VirtualBox 2.0.4 and above, it is possible to use Crossbow Virtual Network Interfaces (VNICs) with bridged networking, but with the following caveats:
A VNIC cannot be shared between multiple guest network interfaces, i.e. each guest network interface must have its own, exclusive VNIC.
The VNIC and the guest network interface that uses the VNIC must be assigned identical MAC addresses.
When using VLAN interfaces with VirtualBox, they must be named according to the PPA-hack naming scheme (e.g. "e1000g513001"), as otherwise the guest may receive packets in an unexpected format.
Internal Networking is similar to bridged networking in that the VM can directly communicate with the outside world. However, the "outside world" is limited to other VMs on the same host which connect to the same internal network.
Even though technically, everything that can be done using internal networking can also be done using bridged networking, there are security advantages with internal networking. In bridged networking mode, all traffic goes through a physical interface of the host system. It is therefore possible to attach a packet sniffer (such as Wireshark) to the host interface and log all traffic that goes over it. If, for any reason, you prefer two or more VMs on the same machine to communicate privately, hiding their data from both the host system and the user, bridged networking therefore is not an option.
Internal networks are created automatically as needed, i.e. there is no central configuration. Every internal network is identified simply by its name. Once there is more than one active virtual network card with the same internal network ID, the VirtualBox support driver will automatically "wire" the cards and act as a network switch. The VirtualBox support driver implements a complete Ethernet switch and supports both broadcast/multicast frames and promiscuous mode.
In order to attach a VM's network card to an internal network, set its networking mode to "internal networking". There are two ways to accomplish this:
You can use a VM's "Settings" dialog in the VirtualBox graphical user interface. In the "Networking" category of the settings dialog, select "Internal Networking" from the drop-down list of networking modes. Now select the name of an existing internal network from the drop-down below or enter a new name into the entry field.
You can use
VBoxManage modifyvm "VM name" --nic<x> intnet
Optionally, you can specify a network name with the command
VBoxManage modifyvm "VM name" --intnet<x> "network name"
If you do not specify a network name, the network card will be
attached to the network intnet by
default.
Unless you configure the (virtual) network cards in the guest operating systems that are participating in the internal network to use static IP addresses, you may want to use the DHCP server that is built into VirtualBox to manage IP addresses for the internal network. Please see the section called “VBoxManage dhcpserver” for details.
As a security measure, the Linux implementation of internal networking only allows VMs running under the same user ID to establish an internal network.
Host-only networking is another networking mode that was added with version 2.2 of VirtualBox. It can be thought of as a hybrid between the bridged and internal networking modes: as with bridged networking, the virtual machines can talk to each other and the host as if they were connected through a physical ethernet switch. Similarly, as with internal networking however, a physical networking interface need not be present, and the virtual machines cannot talk to the world outside the host since they are not connected to a physical networking interface.
Instead, when host-only networking is used, VirtualBox creates a new software interface on the host which then appears next to your existing network interfaces. In other words, whereas with bridged networking an existing physical interface is used to attach virtual machines to, with host-only networking a new "loopback" interface is created on the host. And whereas with internal networking, the traffic between the virtual machines cannot be seen, the traffic on the "loopback" interface on the host can be intercepted.
Host-only networking is particularly useful for preconfigured virtual appliances, where multiple virtual machines are shipped together and designed to cooperate. For example, one virtual machine may contain a web server and a second one a database, and since they are intended to talk to each other, the appliance can instruct VirtualBox to set up a host-only network for the two. A second (bridged) network would then connect the web server to the outside world to serve data to, but the outside world cannot connect to the database.
To change a virtual machine's virtual network interface to "host only" mode:
either go to the "Network" page in the virtual machine's settings notebook in the graphical user interface and select "Host-only networking", or
on the command line, type VBoxManage modifyvm
"VM name" --nic<x> hostonly; see the section called “VBoxManage modifyvm” for details.
For host-only networking, like with internal networking, you may find the DHCP server useful that is built into VirtualBox. This can be enabled to then manage the IP addresses in the host-only network since otherwise you would need to configure all IP addresses statically.
In the VirtualBox graphical user interface, you can configure all these items in the global settings via "File" -> "Settings" -> "Network", which lists all host-only networks which are presently in use. Click on the network name and then on the "Edit" button to the right, and you can modify the adapter and DHCP settings.
Alternatively, you can use VBoxManage
dhcpserver on the command line; please see the section called “VBoxManage dhcpserver” for details.
[27] Support for the Intel PRO/1000 MT Desktop type was added with VirtualBox 1.6. The T Server variant of the Intel PRO/1000 card was added with VirtualBox 1.6.2 because this one is recognized by Windows XP guests without additional driver installation. The MT Server variant was added with VirtualBox 2.2 to facilitate OVF imports from other platforms.
[29] For Mac OS X and Solaris hosts, net filter drivers were already added in VirtualBox 2.0 (as initial support for Host Interface Networking on these platforms). With VirtualBox 2.1, net filter drivers were also added for the Windows and Linux hosts, replacing the mechanisms previously present in VirtualBox for those platforms; especially on Linux, the earlier method required creating TAP interfaces and bridges, which was complex and varied from one distribution to the next. None of this is necessary anymore. Bridged network was formerly called "Host Interface Networking" and has been renamed with version 2.2 without any change in functionality.