Connecting VMware Workstation guest virtual machines to the Internet

Learn how to configure VMware Workstation virtual networks, including connecting guest virtual machines to the Internet, use the Virtual Network Editor and more.

VMware Workstation is the ideal desktop application for a self-contained lab testing environment on your desktop

or laptop. With Workstation, you can create multiple private networks, connect virtual machines (VMs) to a host, bridge networks to a local area network (LAN) or use Network Address Translation protocol (NAT) to connect networks to a LAN.

Really, the configurability of VMware Workstation's virtual networks is what makes Workstation so powerful. But this same virtual networking flexibility is what can make Workstation a challenge to configure. So while creating a new VM in Workstation isn't difficult, configuring the virtual network can be. In this article, we cover various scenarios for VMware Workstation lab networking and address the most common question I am asked: How do you connect VM guests to the Internet?

VMware Workstation's Virtual Network Editor
One of the features that makes Workstation's virtual networking so configurable -- and complex -- is the Virtual Network Editor. This tool allows you to configure each of the different types of Workstation networking and work with the Dynamic Host Configuration Protocol (DHCP) and NAT Workstation services. We will use the tool to connect VM guests to the Internet and create various lab scenarios. There is a lot that you can do with the Virtual Network Editor. And fortunately, I don't have to go into detail on how to use it, because you can refer to my SearchVMware.com article "Managing virtual networks with VMware's Workstation and the Virtual Network Editor" covers this territory.

Now let's examine our four different virtual networking scenarios with VMware Workstation.

Scenario 1: Connecting virtual machines to the Internet with bridging
One of the more common questions I get about VMware Workstation is how to connect a guest VM to the Internet. What is required to connect the VM to the Web varies based on your network and Internet configuration. So let's just assume that your LAN offers a DHCP server (with default gateway and Domain Name System, or DNS to anyone, that there are no MAC restrictions and that your firewall allows any computer from the LAN to connect to the Internet.

In that case, you shouldn't have to do anything, and the configuration should just work if you chose NAT or bridged connections for your virtual network adapter. What I recommend and use myself is Bridged Networking, or VMnet0.

In the image below, the VM host has one IP address (10.0.0.100) and each VM guest has its own IP address (10.0.0.101, 102, and 103, respectively) that it received from the DHCP server. This way, each VM guest acts as its own IP node on the network. Usually I like this system, because each VM guest is identifiable. I can connect to each using Remote Desktop Protocol (RDP) or connect to the Web interface on a VM guest (if they run a Web server), for example.

The downside is that if your network has IP restrictions then each guest must be configured separately on the network. Say, for example, that your firewall allows only specific devices to communicate with the Internet. With bridging, each VM guest would have to have its own authorization on the firewall because it has its own IP address. There may also be Windows networking restrictions. Perhaps your Cisco switch has MAC address restrictions. In this case, each of these VM guests has its own MAC address. The VM host's Ethernet port may be locked down on the Cisco switch due to too many MAC addresses requesting network access. If a sticky MAC address with port security and a limitation of one MAC address is configured on the switch, bringing up even one VM guest with bridging is a very quick way to get your host PC orserver disconnected from the network for violation of port security.

To map a VM guest to a particular virtual network, just configure the virtual network interface card (NIC) to be bridged, 'NATed', etc. (as with the figure below).

Scenario 2: Connecting Virtual Machines to the Internet with NAT
As I talked about in the first scenario, as an alternative to bridging you can use NAT or VMnet8. With NAT, the host's IP address is used by all the VM guests. In other words, when the VM guest communicates with the LAN, it appears that the VM host is actually making the request.

But how do the guest VMs get their IP address? Every VM needs its own IP address. In the case of NAT with Workstation, VMware Workstation actually has its own internal DHCP server that hands out internal and private IP addresses to any VM guest on the NAT network.

If you go to the NAT tab in the VMware Workstation Virtual Network Editor, you can see the NAT Service. It is required to be running to translate the special Workstation NAT network – 192.168.220.0 to 192.168.220.254 – to the IP address of the VM host. As you see in the next image, the default gateway for the NAT'ed VMs is 192.168.220.2.

Still, the NAT service doesn't hand out IP addresses; the VMware Workstation DHCP Service does. If we look at the DHCP tab, you can see the DHCP range for VMnet8, in the next image.

Thus, with NAT, each VM will have its own IP address provided by the VMware Workstation DHCP service. That IP will be NAT'ed to the IP of the VM host to access the LAN (and then the Internet).

Scenario 3: Testing machines with IP address conflicts, malware or duplicate names (private)
What if you have some VMs that have IP address conflicts, malware, or DNS names that conflict with production server DNS names? You want these servers to run in a secure and private network to prevent any possible risk to the production network. With VMware Workstation, this is easy.

VMware Workstation has, by default, a private virtual network called VMnet7, as you see below.

Keep in mind that you will have to configure a static IP address on the VM guest in the private network as, by default, there will be no DHCP server on that subnet. If you do want DHCP, you could configure Workstation to provide IP addresses with the Workstation DHCP service or you could run, say, a Windows DHCP server as a VM, in the private subnet.

Scenario 4: Testing a VM that is safe but needs access to the host (host only)
And finally, what if you have a VM guest that you don't want on the local LAN but you do need to share files and access the VM, over a virtual network? While it isn't as secure as the private network option (VMnet7), the Host Only virtual network (VMnet1) was designed for this. With Host Only, the VM host and the VM guests on that virtual network will be able to communicate via TCP/IP networking on a private network that only they share.

VMware Workstation will provide DHCP services to this private network using the default IP address range of 192.168.234.0 - 192.168.234.254, as you see in the figure below.

To configure a VM guest to use this private network, connect it to the Host Only Virtual network (VMnet1), as you see in the figures below.

In summary, VMware Workstation offers many possibilities for configuring virtual networking – bridged, NAT'ed, private, and host-only. Each of these has its own particular use, depending on your scenario. If you just want to connect a VM guest to the local LAN and to the Internet, I recommend using the bridged or NAT'ed option, depending on your network's security configuration.

 

David Davis is the director of infrastructure at TrainSignal.com. He has a number of certifications including CCIE #9369, MCSE, CISSP, and VCP. Davis has also authored hundreds of articles and six different video training courses at Train Signal with his most popular course being VMware ESX Server. His personal website is VMwareVideos.com. You can follow Davis on Twitter or connect with Davis on LinkedIn.


 

This was first published in June 2009

Dig deeper on VMware Workstation, Fusion and Player

2 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close