Centrally Disable NAT in VMware Workstation

A fellow IT-professional, who works with the non-wired flavor of networking, contacted me with the following scenario:

A group of users, developers in this case, have VMware Workstation installed on their laptops. This makes it easy for them to manage, test and develop their applications in a closed environment without having to install a bunch of tools/services on their centrally managed laptop environment. An excellent use case for VMware Workstation if there ever was one.

So far, so good. The problem in this particular case was that due to security policies in the network infrastructure there was a need to disable the NAT networking possibilities in VMware Workstation.

Network address translation (NAT) configures your virtual machine to share the IP and MAC addresses of the host. The virtual machine and the host share a single network identity that is not visible outside the network. NAT can be useful when you are allowed a single IP address or MAC address by your network administrator. You might also use NAT to configure separate virtual machines for handling http and ftp requests, with both virtual machines running off the same IP address or domain. See Network Address Translation (NAT).

VMware Workstation NAT Configuration
VMware Workstation NAT Configuration

Since the VM shares the host MAC address and IP, blocking network access from the VM is not trivial in this scenario.

Thankfully, in VMware Workstation for Windows, NAT is provided through a Windows Service that we can manipulate. By disabling the “VMware NAT Service” we can ensure that NAT does not work, and that the only real alternative is to run the VM in “Bridged Mode”.

Bridged Mode makes it easier for network admins to manipulate access, since the virtual network adapter is exposed to the switches with their own MAC address, and thus possibly also their own IP address, and the VM is not “hidden” behind the hosts MAC. For instance, this makes it possible for the network gurus to limit the VMs physical network access to internet access only, and not exposing the internal network to the VM.

Running around disabling the “VMware NAT Service” on all clients that run VMware Workstation is no fun job, so naturally we need to find a way to automate this as well.

Enter Group Policy Preferences!

  1. On a computer that has VMware Workstation installed, run the Group Policy Management Console and create a new GPO.Group Policy Management Console
  2. In Computer Configuration > Preferences > Control Panel Settings select Services
  3. In the menu click on Action > New > Service and and click on  “…” next to the Service Name field
  4. Select the “VMware NAT Service”and click “Select”Services
  5. Set the Startup mode to “disabled”
  6. Assign this new Group Policy Preference to the OU that the clients that have VMware Workstation installed on resides in, and the next time the policies are refreshed, the “VMware NAT Service” should be set to disabled.Note: This might require a reboot of the client.
  7. Profit.

And there it is, a workaround on how to disable the possibility for VMs running in VMware Workstation utilizing NAT mode. A bit of a hack, but it works.


I really wish VMware would include the possibility to configure and manage multiple VMware Workstation for Windows installs, through Group Policy and Group Policy Preferences.

The ability to centrally manage configurations and settings would be a welcome addition to this already excellent piece of software, and I am sure that I am not alone in asking for this possibility. So how about it VMware, yay or nay?

vSphere Web or Desktop Client – Who´s Your Daddy?

At the moment, VMware vSphere offers two different management clients, the vSphere Web Client and the vSphere Desktop Client.

The feature comparison table looks like this:
(Copied from “Which vSphere client should I use and when?“)

vSphere Web Client Only vSphere Desktop Client Only
  • vCenter Single Sign-On
    • Authentication
    • Administration
  • Navigation with Inventory Lists
  • Inventory Tagging
  • Work In Progress (Pause)
  • Pre-emptive Searching
  • Save Searches
  • Enhanced read performance utilizing the Inventory Service
  • vSphere Replication (not SRM)
  • Virtual Infrastructure Navigator
  • Enhanced vMotion (no shared storage)
  • Integration with vCenter Orchestrator (vCO) Workflows (Extended Menus)
  • Virtual Distributed Switch (vDS)
    • Health Check
    • Export/Restore Configuration
    • Diagram filtering
  • Log Browser Plugin
  • vSphere Data Protection (VDP)
  • VMware Desktop Plug-ins (VUM, SRM, etc)
  • 3rd Party Desktop Plugins (various)
  • VXLAN Networking
  • Ability to change Guest OS on an existing virtual machine
  • vCenter Server Maps
  • Create and edit custom attributes
  • Connect direct to a vSphere host
  • Inflate thin disk option found in the Datastore Browser


In plain words, this means that all new features in vSphere 5.1 are Web Client only, and older “legacy” features and plugin integrations are Desktop Client only at this point.

This will change over time as both VMware products, like VUM and SRM, are moved into a new home in the Web Client and when 3rd party vendors integrate their plugins with the new client.

There is no doubt that the vSphere Web Client is where the future lives, but in the interim vAdmins are forced to utilize both to be able to use all the available functionality and obviously this is far from ideal.

I´m sure VMware will get where they want with the vSphere Web Client in the end, and changing platform like this is a big task, especially when you consider that third parties need to be on their toes and upgrade their integrations as well.

Having two clients for management is not fun, but it does beat having no management at all.

So in short, your daddy? They both are. While they might be separated, the divorce has not been finalized just yet.

Multi-Hypervisor Management and the Future

In a previous post, vCenter Integration Mantra, I made the point that vSphere vAdmins wants the 3rd party modules to integrate into the vCenter client and show their delicious addon-value there, and not in their own management interface. Give the vAdmins the info they need, where they do most, if not all their work. Open up the admin client and let us get all that juicy and fruity information we need. Sounds good, right?

Yes, it does. It sounds really good, but there is this one small curve-ball that can change everything. The 500 pound gorilla in the room that no-one wants to talk about, but we all know is there. As a day-to-day VMware vSphere admin it’s really easy to get our blinders on and not see the forest for all the trees.

During Embotics presentation at Tech Field Day #6 in Boston, it dawned on me:

We might just be approaching this entirely the wrong way around.

This epiphany was caused by one single statement from Embotics: “Our plan is to be hypervisor agnostic, and support other architectures in future versions”.

Multi-hypervisor support? Provisioning VMs regardless of hypervisor, just create what the business or application owner needs, on the performance and storage tier that suits that particular usage pattern best. Of course, this very much ties into the whole cloud mindset, and as a concept of management it is really interesting.

Consider the following scenario:

Your enterprise has a high-performance VMware vSphere environment where mission-critical applications run. All the bells and whistles are available in this environment; HA/DRS, High Performance SAN, 10GigE networking and loads of CPU and RAM.
For a given set of workloads available in the service catalog, the default would be to create new mission-critical workloads in this environment. Of course, chargeback mechanisms would also come into play, and price workloads in this environment at a premium level.
For the sake of simplicity we’ll call this tier “Tier 1”

“Tier 2” would be your test/development and QA environment where you probably won’t need the performance and high availability you get in “Tier 1”, and the chargeback mechanisms would reflect this in the cost model. This environment runs Hyper-V, has cheaper storage and simpler networking.

“Tier 3” is your hosted environment, available outside of your own datacenters. Some workloads belong here too, and of course, chargeback would come into play here as well. To further complicate things, the provider uses Xen for their environment.

If 3rd party applications where to tie into the administration tools for those three separate hypervisors, administrators would have to use three different tools to manage their environment.

What if we turn everything on its head, and look at it from the exact opposite direction. Why should 3rd party vendors have to tie into the hypervisors management tools? They wouldn’t have to if the hypervisor vendors made their admin tools available in a manner that let 3rd party vendors integrate their management tool into theirs instead?

Solarwinds does something really interesting in their Virtualization Manager product, the statistics and status reports you get in your Solarwinds Virtualization Manager dashboard are all available as web “widgets” that you can include in other web pages. In other words, you can integrate Solarwinds Virtualization Manager data into your existing dashboards.

What if you could do the same with output from future VMware vSphere, Hyper-V and Citrix XenServer management products? VKernel could do the same for their data, and you could easily create your own dashboard that contained information from a wealth of sources.

Of course, there are a number of issues with doing something like this, like “what happens if you want to move something from Tier 2 to Tier 1, and the VMs run on different hypervisors?”, “How do you enforce security between hypervisors with different management systems?” and so on.

This is not something that can be very easily done today, and it might even be a pipe-dream, but it’s an intriguing thought. I do think we will see more and more multi-hypervisor environments in the years to come, and getting into the market for management of such environments seems like a good business opportunity (Note: IANAA = I Am Not An Analyst).

Of course, this is an overly simplified scenario, but it does show that the need for management tools to be hypervisor agnostic is very much present, and will be even more so in the future.

We as vAdmins need to apply pressure on our hypervisor vendors to try and make them open up their management tools in such a way that this could be possible someday, the multi-hypervisor world is already here and it’s growing.

I wrote this post while on the plane returning from Tech Field Day #6 in Boston. Greg Ferro has replied to my original post with a post of his own vCenter Integration Mantra – vEverything Is Not Wise where he pretty much says the same as I do in this post.

Tom Howarth also commented on the original post. In fact, I even voiced this opinion in the session we had with Embotics, when the Tech Field Day delegates had a roundtable discussion after the presentations.

It all goes to show that you can in fact get blinded by the light.