VMware Bridged Guest Lost Its Network After OpenVPN

A guest that was bridged and reachable an hour ago now times out on everything, and nobody edited its settings. On the host, the internet still works through the tunnel. The two facts together point away from the VPN and toward the hypervisor, because the host and the guest are no longer using the same path. One new virtual adapter is enough to cause it.

The Guest Did Not Change, the Bridge Did

Installing the OpenVPN client on Windows adds a virtual network adapter that the service binds to when a tunnel comes up. To the operating system it looks like an ordinary interface with a link state and, often, its own addresses. That is enough for VMware to treat it as a bridge candidate.

VMnet0 is set to Automatic by default, which means the hypervisor selects a host adapter each time it bridges. A freshly installed virtual adapter joins that pool, and if it is selected, every frame the guest emits goes to a tunnel device rather than to the physical switch port.

Pin the Bridge or Route the Guest

The first branch is the right one when the guest is meant to be a peer on the physical LAN: stop letting the bridge choose, and name the adapter explicitly. The second branch applies when the guest is supposed to use the corporate tunnel, in which case a bridge was never the correct design, because a bridged guest does not inherit the host's VPN route.

Decide that first, since the two answers lead to different work. Getting the order backwards produces a correctly pinned bridge attached to a guest that should never have been bridged.

For the first branch, open the Virtual Network Editor on the host, select VMnet0 and replace Automatic with the physical adapter. If several adapters exist, use the automatic settings list and clear the checkboxes for anything that must never carry guest traffic: the OpenVPN TAP or Wintun device, plus Hyper-V, WSL, Docker and loopback adapters. Keep both the wired and the wireless physical adapter checked on a laptop, or the guest loses its bridge the next time the user docks.

Three Conditions That Settle the Choice

Whether a bridge is even appropriate depends on what the guest is for. If the guest must appear as its own host on the LAN, with its own address and its own inbound reachability, bridging is the correct model and pinning is the whole fix. If the guest only needs outbound access, a host-only or NAT network is simpler and immune to adapter churn.

If the guest must use the same tunnel as the host, neither bridged mode nor a pinned adapter helps, because the guest's traffic never enters the host's routing decision. That case needs a routed or translated path on the host, and the choice of adapter becomes irrelevant.

VMware Player has no network editor in its interface, so a host running only Player needs the standalone editor or a Workstation install to reach these settings. That constraint sometimes decides the approach on its own.

Read the Result From Inside the Guest

Bounce the virtual NIC, or restart the guest, so that it requests a lease again. Then read what it actually received rather than what the host believes it configured.

ipconfig /all
ip addr
ip route

Read two fields in that output and ignore the rest for now. The gateway should be the LAN router, and the adapter description should name the VMware Ethernet device rather than a tunnel. A self-assigned address in 169.254.0.0/16 means no DHCP server answered, which is what a bridge onto a tunnel adapter looks like from the guest side.

One more distinction is worth making before changing anything else. A guest that reaches the router but not the internet has a working bridge and an upstream problem. A guest that receives an address in the tunnel range is still attached to the wrong device. Disabling the TAP adapter is not a fix for either case, because the OpenVPN service needs it.