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 10.0.0.128”, 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:

VERSION=1,0
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH F5FEE30FD06F6A58C7B1B1C2497C54BE04676E98
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 192.168.32.0
answer VNET_1_VIRTUAL_ADAPTER yes
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH 0AEB0A5DAC06201088354E25F52B115FF3F6609F
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
answer VNET_8_HOSTONLY_SUBNET 172.16.110.0
answer VNET_8_NAT yes
answer VNET_8_VIRTUAL_ADAPTER 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 10.0.0.1 and 10.0.0.253, in the 10/16 subnet):

answer VNET_2_HOSTONLY_NETMASK 255.255.0.0
answer VNET_2_HOSTONLY_SUBNET 10.0.0.0
answer VNET_2_VIRTUAL_ADAPTER yes
answer VNET_2_VIRTUAL_ADAPTER_ADDR 10.0.0.128

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.

VNET_n_DHCP

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!

VNET_n_DHCP_CFG_HASH

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.

VNET_n_HOSTONLY_NETMASK

The subnet mask for the interface.

VNET_n_HOSTONLY_SUBNET

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.

VNET_n_NAT

Set to “yes” to provide NAT for virtual machines on this network so they can access your Mac’s real network interfaces.

VNET_n_VIRTUAL_ADAPTER

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.

VNET_n_VIRTUAL_ADAPTER_ADDR

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.