VMware Workstation 3.2
Network address translation - or NAT - is a networking option that first appeared in VMware Workstation 3.0.
NAT provides a simple way for virtual machines to use most client applications over almost any type of network connection available to the host. The only requirement is that the network connection must support TCP/IP.
NAT is useful when you have a limited supply of IP addresses or are connected to the network through a non-Ethernet network adapter. NAT works by translating addresses of virtual machines in a private VMnet network to that of the host machine. When a virtual machine sends a request to access a network resource, it appears to the network resource as if the request came from the host machine.
NAT uses the host's own network resources to connect to the external network. Thus, any TCP/IP network resource to which the host has access should be available through the NAT connection.
The chief advantage of NAT is that it provides a transparent, easy to configure way for virtual machines to gain access to network resources.
The NAT device is connected to the VMnet8 virtual switch. Virtual machines connected to the NAT network also use the VMnet8 virtual switch.
The NAT device waits for packets coming from virtual machines on the VMnet8 virtual network. When a packet arrives, the NAT device translates the address of the virtual machine to that of the host before forwarding the packet to the external network. When data arrives from the external network for the virtual machine on the private network, the NAT device receives the data, replaces the network address with that of the virtual machine and forwards the data to the virtual machine on the virtual network. This translation occurs automatically and requires minimal configuration on the guest and the host.
The host computer has an adapter on the NAT network (identical to the host-only adapter on the host-only network). This adapter allows the host and the virtual machines to communicate with each other for such purposes as file sharing. The NAT never forwards traffic from the host adapter.
In order to make networking configuration easy, a DHCP server is automatically installed when you install VMware Workstation. Virtual machines running on the network with the NAT device can dynamically obtain their IP addresses by sending out a DHCP request. The DHCP server on the NAT network, which is also used in host-only networking configurations, dynamically allocates IP addresses in the range of <net>.128 through <net>.254, where <net> is the network number assigned to your NAT network. VMware Workstation always uses a Class C address for NAT networks. IP addresses <net>.3 through <net>.127 can be used for static IP addresses. IP address <net>.1 is reserved for the host adapter; <net>.2 is reserved for the NAT device.
In addition to the IP address, the DHCP server on the NAT network also sends out additional configuration information that enables the virtual machine to operate automatically. This information includes the default gateway and the DNS server. In the DHCP response, the NAT device instructs the virtual machine to use the IP address <net>.2 as the default gateway and DNS server. This causes all IP packets destined for the external network and DNS requests to be forwarded to the NAT device.
The NAT device acts as a DNS server for the virtual machines on the NAT network. Actually, the NAT device is a DNS proxy and merely forwards DNS requests from the virtual machines to a DNS server that is known by the host. Responses come back to the NAT device, which then forwards them to the virtual machines.
If they get their configuration information from DHCP, the virtual machines on the NAT network automatically uses the NAT device as the DNS server. However, the virtual machines can be statically configured to use another DNS server.
The virtual machines in the private NAT network are not, themselves, accessible via DNS. If you want the virtual machines running on the NAT network to access each other by DNS names, you must set up a private DNS server connected to the NAT network.
In general, any protocol using TCP or UDP can be used automatically by a virtual machine on the NAT network so long as the virtual machine initiates the network connection. This is true for most client applications such as Web browsing, Telnet, passive-mode FTP and downloading streaming video. Additional protocol support has been built into the NAT device to allow FTP and ICMP echo (ping) to work completely transparently through the NAT.
On the external network to which the host is connected, any virtual machine on the NAT network appears to be the host itself, because its network traffic uses the host's IP address. It is able to send and receive data using TCP/IP to any machine that is accessible from the host.
Before any such communication can occur, the NAT device must set up a mapping between the virtual machine's address on the private NAT network and the host's network address on the external network.
When a virtual machine initiates a network connection with another network resource, this mapping is created automatically. The operation is perfectly transparent to the user of the virtual machine on the NAT network. No additional work needs to be done to let the virtual machine access the external network.
The same cannot be said for network connections that are initiated from the external network to a virtual machine on the NAT network.
When a machine on the external network attempts to initiate a connection with a virtual machine on the NAT network, it cannot reach it because the NAT device does not forward the request. Network connections that are initiated from outside the NAT network are not transparent.
However, it is possible to manually configure port forwarding on the NAT device so network traffic destined for a certain port can still be automatically forwarded to a virtual machine on the NAT network. For details, see Advanced NAT Configuration below.
File sharing of the type used by Windows operating systems and Samba is possible among computers on the NAT network - including virtual machines and the host computer. If you are using WINS servers on your network, a virtual machine using NAT networking can access shares on the host known by the WINS server as long as they are in the same workgroup or domain.
Use the NAT configuration file on the host to configure the NAT device.
On Windows, this file is vmnetnat.conf. It is located in the host operating system's system folder (normally C:\WINNT\system32).
On Linux, this file is /etc/vmware/vmnet8/nat/nat.conf.
The configuration file is divided into sections. Each section configures a part of the NAT device. Text surrounded by square brackets - such as [host] - marks the beginning of a section. In each section is a configuration parameter that can be set. The configuration parameters take the form ip = 192.168.27.1/24.
For an example of a NAT configuration file, see Sample Windows vmnetnat.conf File. The configuration file variables are described below.
This section is for Windows hosts only. Linux does not use this section.
If autodetect is on and some name servers are specified, the DNS servers specified in nameserver1, nameserver2 and nameserver3 are added before the list of detected DNS servers.
This section applies to Windows hosts only. Linux does not use this section.
nbnsTimeout = 2
nbnsRetries = 3
nbdsTimeout = 3
This section is used to configure TCP port forwarding for NAT. In this section, you can assign a port number to an IP address and port number on a virtual machine.
The following line shows the format used in this section.
8887 = 192.168.27.128:21
This creates a mapping from port 8887 on the host to the IP address 192.168.27.128 and port 21. When this is set and an external machine connects to the host at port 8887, the network packets are automatically forwarded to port 21 (the standard port for FTP) on the virtual machine with IP address 192.168.27.128.
This section is used to configure UDP port forwarding for NAT. In this section, you can assign a port number to an IP address and port number on a virtual machine.
The following line shows the format used in this section. It illustrates a way to forward X server traffic from the host port 6000 to the virtual machine's port 6001.
6000 = 192.168.27.128:6001
This creates a mapping from port 6000 on the host to the IP address 192.168.27.128 and port 6001. When this is set and an external machine connects to the host at port 6000, the network packets are automatically forwarded to port 6001 on the virtual machine with IP address 192.168.27.128.
Because NAT requires that every packet sent and received from virtual machines is in the NAT network, there is an unavoidable performance penalty. Our experiments show that the penalty is minor for dial-up and DSL connections and performance is adequate for most VMware Workstation uses.
NAT is not perfectly transparent. It does not normally allow connections to be initiated from outside the network, although you can set up server connections by manually configuring the NAT device. The practical result is that some TCP and UDP protocols that require a connection be initiated from the server machine - some peer to peer applications, for example - do not work automatically, and some may not work at all.
A standard NAT configuration provides basic-level firewall protection because the NAT device can initiate connections from the private NAT network, but devices on the external network cannot normally initiate connections to the private NAT network.
When using NAT networking in a virtual machine with a Windows guest operating system running on a Windows host, you can utilize NetLogon to log on to a Windows domain from the virtual machine. This allows you to access file shares known by the WINS server in the domain.
To use NetLogon, you need to know how WINS servers and Windows domain controllers work. This section only explains how to set up the virtual machine to use NetLogon. The setup process is similar to the way you would set up a physical computer on one LAN that is using a domain controller on another LAN.
In order to log on to a Windows domain outside the virtual NAT network, the virtual machine needs access to a WINS server for that domain. There are two ways the virtual machine can connect to the WINS server. You can connect to the WINS server provided by the DHCP server used on the NAT network, provided that the WINS server is already set up on the host. If you want to connect from the virtual machine to a WINS server not set up on the host, you can manually enter the IP address of the WINS server.
In order to use this method, a WINS server in the same workgroup or domain must be set up on the host. These steps use Windows 2000, Windows XP or Windows .NET Server as a guide. The process is similar for Windows NT, Windows Me and Windows 9x guests.
Use this method to connect to a WINS server in the same workgroup or domain that is not already set up on the host.
Now that the virtual machine has an IP address for a WINS server, you use NetLogon in the virtual machine to log on to a domain and access shares in that domain.
For example, if the WINS server covers a domain with a domain controller it is possible to access that domain controller from the virtual machine and add the virtual machine to the domain. You need to know the Administrator's user ID and password of the domain controller.
Note: You can access shares of virtual machines that are only on the same NAT network or are bridged on the same domain.
# Windows NAT configuration file
# NAT gateway address
ip = 192.168.237.2/24
hostMAC = 00:50:56:C0:00:08
# enable configuration; disabled by default for security reasons
#configport = 33445
# VMnet device if not specified on command line
device = VMnet8
# Allow PORT/EPRT FTP commands (they need incoming TCP stream...)
activeFTP = 1
# Allows the source to have any OUI. Turn this one if you change the OUI
# in the MAC address of your virtual machines.
#allowAnyOUI = 1
# Timeout in seconds, 0 = no timeout, default = 60; real value might
# be up to 100% longer
timeout = 30
# This section applies only to Windows.
# Policy to use for DNS forwarding. Accepted values include order,
# rotate, burst.
# order: send one DNS request at a time in order of the name servers
# rotate: send one DNS request at a time, rotate through the DNS servers
# burst: send to three servers and wait for the first one to respond
policy = order;
# Timeout in seconds before retrying DNS request.
timeout = 2
# Retries before giving up on DNS request
retries = 3
# Automatically detect the DNS servers (not supported in Windows NT)
autodetect = 1
# List of DNS servers to use. Up to three may be specified
#nameserver1 = 22.214.171.124
#nameserver2 = 126.96.36.199
#nameserver3 = 188.8.131.52
# This section applies only to Windows.
# Timeout for NBNS queries.
nbnsTimeout = 2
# Number of retries for each NBNS query.
nbnsRetries = 3
# Timeout for NBDS queries.
nbdsTimeout = 3
# Use these with care - anyone can enter into your virtual machine through
# FTP (both active and passive FTP is always enabled)
# ftp localhost 8887
#8887 = 192.168.27.128:21
# WEB (make sure that if you are using named webhosting, names point to
# your host, not to guest... And if you are forwarding port other
# than 80 make sure that your server copes with mismatched port
# number in Host: header)
# lynx http://localhost:8888
#8888 = 192.168.27.128:80
# ssh -p 8889 root@localhost
#8889 = 192.168.27.128:22
# UDP port forwarding example
#6000 = 192.168.27.128:6001