FreeBSD and Persistent Network Interface Names in VMware

Why vmx0, vmx1, vmx2 interface names sometimes cause fear?

Anyone running FreeBSD as a router or firewall in a virtualized environment knows this situation well: network interfaces are named vmx0, vmx1, vmx2, and critical configuration (pf, routing, jails) depends on them. A small change can suddenly turn WAN into LAN and LAN into DMZ.

On physical hardware this is a common problem. Adding a PCI card can change device enumeration order. In VMware, the situation is much better, but it is still important to understand how to make interface naming stable and future-proof. 

How FreeBSD names network interfaces

FreeBSD:

• does not use persistent interface naming like Linux (udev)
• names interfaces based on the driver and detection order
• examples: vmx0, vmx1, vmx2

The number (0, 1, 2) is not bound to the interface role, but to the order in which the kernel initializes the devices.

Why VMware is different

In VMware, each virtual NIC is:

• explicitly defined in the VM configuration
• ordered as Network adapter 1, 2, 3
• consistently exposed to FreeBSD as vmx0, vmx1, vmx2

As long as you do not delete or reorder adapters manually, the order does not change.

This is why many FreeBSD VMs run for years on VMware without ever seeing interface renumbering issues.

The correct solution: renaming interfaces at boot

FreeBSD allows network interfaces to be renamed during system startup. This is the key feature.

Recommended and simple approach

ifconfig_vmx0_name="wan0"
ifconfig_vmx1_name="lan0"
ifconfig_vmx2_name="dmz0"

ifconfig_wan0="inet 1.2.3.4/30"
ifconfig_lan0="inet 192.168.1.1/24"
ifconfig_dmz0="inet 192.168.100.1/24"

From this point on:

• vmx0, vmx1, vmx2 no longer exist
• you only work with wan0, lan0, dmz0
• pf rules, routing, and scripts become stable

What if the vNIC order does change?

If the adapter that FreeBSD sees as vmx0 changes, then this line would need to be adjusted:

ifconfig_vmx0_name="wan0"

However:

• VMware will not change this order on its own
• it only happens due to administrative actions
• deleting, re-adding, or reordering virtual NICs

This is not random behavior, but a configuration change.

100% bulletproof solution: bind names to MAC addresses

For critical systems (firewalls, HA, DR), you can bind interface names directly to MAC addresses:

ifconfig_ether_00:50:56:aa:bb:cc_name="wan0"
ifconfig_ether_00:50:56:dd:ee:ff_name="lan0"
ifconfig_ether_00:50:56:11:22:33_name="dmz0"

Result:

• it does not matter whether the interface appears as vmx0 or vmx7
• as long as the MAC address stays the same, the name is stable
• ideal for cloning, disaster recovery, and HA setups

Recommended naming model from real-world practice

In real world, you typically have network gateways (routers, firewalls, etc.) with interfaces in various roles which should be mapped to interface names like in table below.

Role        Name   

WAN         wan0

LAN.        lan0

DMZ.        dmz0

MANAGEMENT  mgmt0

STORAGE     stor0

Never:

• configure vmx0 directly
• rely on interface numbering for semantics

Summary

• FreeBSD does not guarantee stable interface names
• VMware provides a very stable virtual hardware model
• renaming interfaces in rc.conf is the correct solution
• MAC-based naming is the enterprise-grade option

If you are building a FreeBSD router, firewall, or HA system on VMware, this is a fundamental best practice that will save you from painful outages later.