Virtual Network Customization in VMware Fusion

When working on a project where we need to run software that typically runs on another operating system, virtualization can be a very useful tool. On macOS, VMware Fusion is an excellent choice for this; it has many time-saving features, and its compatibility is top-notch—especially if you need to run Windows or macOS itself in a VM.

By default, Fusion provides several basic virtual networking options that can satisfy most requirements. If you need a little more, customization is fairly easy, though undocumented—and information on how to customize is scattered. The Pro version has a network editor, but if you don’t need the rest of what that version offers, or you’re just curious how VMware Fusion networking works, this article can help you.

Out of the Box

A brand-new VMware Fusion installation (8.5.4 at the time of this writing) offers a handful of networking options:

  • NAT, a.k.a. “Internet Sharing: Share with my Mac,” hides your virtual machine behind your Mac’s network address, allowing it to access anything your Mac can, most notably the Internet if you’re connected. However, it doesn’t allow other computers that can access your Mac to access the virtual machine. Most virtual machines are connected this way—it’s the default. This network is available on your Mac as the “vmnet8” interface.
  • Bridged makes your virtual machine appear as if it were another computer on one of your Mac’s network interfaces. Your virtual machine can talk to everyone else on the network, and everyone else on the network can talk to your virtual machine.
  • Host-Only, a.k.a. “Custom: Private to my Mac,” is the one out-of-the-box custom network you get. You can use it to communicate between your Mac and your virtual machines, or between virtual machines if they’re all connected to it. This network is available on your Mac as the “vmnet1” interface.

In my case, the latter option was what I went for first—but it didn’t turn out to be quite what I’d hoped for. The virtual machines I was using were already configured to talk to each other using their own IP address scheme and could see each other just fine over vmnet1—virtual networks don’t care what protocols you use over them. However, my Mac could not talk to those machines, as it was using an IP address (issued by the DHCP server Fusion runs by default on that network) that was not in the same subnet.

I found I could make it work temporarily with a quick “sudo ifconfig vmnet1”, but the next time Fusion restarted, the Mac’s configuration had reverted. That didn’t stop the DHCP server, either, which could have caused problems if a virtual machine tried to use it!

Changing It Up

The key to customizing Fusion’s networking is the directory “/Library/Preferences/VMware Fusion”. In there, you’ll find a file called “networking”, which is the master configuration file for Fusion networking. You can edit this file with Sudo when Fusion is shut down (which also tears down any virtual networks); changes will be picked up and applied the next time you start Fusion.

A brand-new “networking” file looks similar to this:

answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH F5FEE30FD06F6A58C7B1B1C2497C54BE04676E98
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH 0AEB0A5DAC06201088354E25F52B115FF3F6609F
answer VNET_8_NAT yes

In this file, the “VNET_1” answers correspond to vmnet1, the included host-only network, and “VNET_8” is for vmnet8, the NAT network that all virtual machines that need Internet access use.

I recommend you don’t change either one of these networks’ configurations. Instead, you can add your own networks, supplying new “answer” directives by adding lines for VNET_2, VNET_3, and so on. You can make additional networks past VNET_8, too—just skip to VNET_9, VNET_10, and so on. (I don’t know how far these go, but I haven’t run out yet!)

In my example, I needed a new host-only network where I could attach my virtual machines. This network would not have DHCP, and I would want my Mac to have a fixed address on that network. I added these lines to “networking”, which—once the virtual machines were configured appropriately—allowed my Mac to talk to the other virtual machines (on and, in the 10/16 subnet):


Writing Your Own Configuration

Here’s what every setting in the configurations above means. I haven’t needed any more than these settings to establish the configurations I need.

Set to “yes” if you want Fusion to run a DHCP server on this interface. For most custom configurations, you won’t want this, but if you’re just trying to isolate virtual machines on their own network without any pre-existing configuration and would find DHCP handy, by all means turn it on!
Used by Fusion to track the DHCP configuration files it writes out. I am not entirely sure how this works, but I haven’t had to change it.
The subnet mask for the interface.
The subnet address for the interface. If you’re using DHCP, this and the mask will be used to figure out how to configure it.
Set to “yes” to provide NAT for virtual machines on this network so they can access your Mac’s real network interfaces.
Set to “yes” to put your Mac on the virtual network. If you want virtual machines to communicate with each other but not your Mac, then don’t use this.
Set to the fixed address you want your Mac to use on a virtual network. If you don’t use this, your Mac will use DHCP if available (Fusion will give it a fixed lease), or the first available address in the subnetwork.

If these aren’t enough for you, you can also peek into the vmnetn directories that are created and edit some of the network configuration files, like dhcpd.conf and nat.conf. The former may be particularly useful if you want Fusion to give DHCP configurations containing, say, custom name servers. Heed any warnings in the files carefully, though! Fusion’s autoconfiguration can create a confusing situation if you don’t.

Making Connections

Once you’ve got the network configuration the way you think you want it, start Fusion again. If your networks have “VNET_n_VIRTUAL_ADAPTER” on, you’ll be able to see them when you run “ifconfig -a”.

Connecting your virtual machines to your new virtual networks is done in the settings for each virtual machine. You can reconnect an existing virtual network adapter to a different network at any time (much like you can unplug a network cable from a network port and plug it into a new one on a real computer).

If you want to add additional virtual network adapters to your virtual machine, you’ll have to shut it down. You can then use the “Add Device…” button to add as many as you need—or at least eight, which is where I stopped trying.

Once your virtual machines are running, you should be able to ping them both ways, assuming no firewalls are in play. And if that works, you should be good to go.

  • This VNET_n_DHCP_CFG_HASH value is a SHA1 checksum of the “DO NOT MODIFY” section of the dhcpd.conf file, including the ‘beginning of’ and ‘end of’ comments. VMware Fusion generates this whenever it regenerated the dhcpd.conf file.

  • Mark Trumpold says:

    The inability to setting a static ip addr to a Fusion custom network has been a thorn in my side for a long time.

    This was a perfect solution for me. Now I don’t have to jump thru hoops with pre-defined addressing in my dev VMs.

    Thank you for this post !!!

  • Aero says:

    Great write-up, thanks. My question is, am I able to tag each new VMnet to a different VLAN? For example, I’ll have four VMnets in my example, each will be a unique L3 subnet, but, I need to map each to a different VLAN. Can this be done?

    • Mattie Behrens says:

      I don’t know anything about setting up VLAN tags with this file, unfortunately. Is that something that Fusion Pro can do? You could get a trial and see.

  • Comments are closed.