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. In VirtualBox this router is placed between each virtual machine and the host. This separation maximizes security since by default virtual machines cannot talk to each other.
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 Section 9.11, “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.
To configure Port Forwarding you can use the graphical Port Forwarding editor which can be found in the Network Settings dialog for Network Adaptors configured to use NAT. Here you can map host ports to guest ports to allow network traffic to be routed to a specific port in the guest.
Alternatively command line tool VBoxManage could be used;
for details, please refer to Section 8.8, “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 possible to configure incoming NAT connections while the VM is running, see Section 8.13, “VBoxManage controlvm”.
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:
- ICMP protocol limitations:
-
Some frequently used network debugging tools (e.g.
pingor tracerouting) rely on the ICMP protocol for sending/receiving messages. While ICMP support has been improved with VirtualBox 2.1 (pingshould now work), some other tools may not work reliably. - Receiving of UDP broadcasts is not reliable:
-
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\sharenotation. - Protocols such as GRE are unsupported:
-
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.
- Forwarding host ports < 1024 impossible:
-
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).