6.3. Network Address Translation (NAT)

6.3. Network Address Translation (NAT)

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
Oracle VM 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 Oracle VM VirtualBox networking engine, which maps
traffic from and to the virtual machine transparently. In
Oracle VM 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. See Section 6.3.1, “Configuring Port Forwarding with NAT”.

The network frames sent out by the guest operating system are
received by Oracle VM 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
Oracle VM VirtualBox application on the host, using an IP address
belonging to the host. Oracle VM 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
Oracle VM 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, see
Fine Tuning the Oracle VM VirtualBox NAT Engine.

6.3.1. Configuring Port Forwarding with NAT

As the virtual machine is connected to a private network
internal to Oracle VM 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, Oracle VM VirtualBox can make selected services available to
the world outside the guest through port
forwarding. This means that Oracle VM 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, the command line tool
VBoxManage can be used. See
Section 7.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. You may 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"

In 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, as with other
VBoxManage commands.

To remove this forwarding rule, 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, as
follows:

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 as follows:

VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,127.0.0.1,2222,,22"

This example forwards all TCP traffic arriving on the localhost
interface at 127.0.0.1 through port 2222 to port 22 in the
guest.

It is possible to configure incoming NAT connections while the
VM is running, see Section 7.13, “VBoxManage controlvm”.

6.3.2. PXE Booting with NAT

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.

6.3.3. NAT Limitations

There are some limitations of NAT mode which users should be
aware of, as follows:

  • ICMP protocol limitations.
    Some frequently used network debugging tools, such as
    ping or traceroute,
    rely on the ICMP protocol for sending and receiving
    messages. Oracle VM VirtualBox ICMP support has some limitations,
    meaning ping should work but some other
    tools may not work reliably.

  • Receiving of UDP
    broadcasts.
    The guest does not reliably receive
    UDP broadcasts. 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.

  • Some protocols are not
    supported.
    Protocols other than TCP and UDP are
    not supported. GRE is not supported. This means some VPN
    products, such as PPTP from Microsoft, cannot be used. There
    are other VPN products which use only TCP and UDP.

  • Forwarding host ports below
    1024.
    On UNIX-based hosts, such as Linux, Oracle
    Solaris, and 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 do not 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, which are those ports not
below 1024.