How to Configure a Bridged Network (VMnet0) in VMware Workstation

If you use VMware Workstation, you probably want your virtual machine to act like a separate node on your LAN. At this point, Bridged Network comes into play. This mode lets your VM get its own IP address on the subnet. Also, it communicates directly with other hosts on the local L2 segment. In addition, other computers on the LAN can see the guest too.

Even so, issues may not always go as planned. Sometimes your guest cannot reach the internet, or the network link drops continuously. Other times, you get no IP address at all. In addition, new Windows 11 builds cause problems. Furthermore, Hyper-V conflicts and Wi-Fi driver issues complicate matters.

In this guide, I will explain how VMware bridged mode works. I will show how the VMnet0 virtual switch maps to your physical NIC. Also, I will walk you through how to fix every problem you may face, step by step. My goal is to give you solutions you can apply immediately, rather than struggling with theory.

For years, I have worked with VMware software in enterprise LANs and lab settings. The most important lesson I have learned is this: the cause of every problem is usually very simple. We just need to know where to look.

What is a Bridged Network? How VMware Bridged Mode Works

A bridged network is a mode that links your virtual machine directly to your physical LAN. In this mode, the guest acts like other physical nodes on the L2 segment. That means your router sees the VM as a separate L3 host on the subnet. As a result, it gives the machine its own IPv4 address.

Thanks to this setup, your VM reaches printers and file servers on the local segment immediately. In addition, it connects to other nodes directly.

In the same way, other computers on the LAN can reach the guest. For example, if you run a web server, anyone on your subnet can open it from their browser.

So how does this work at the packet level? The answer lies in the second layer of the OSI model, specifically in the bridging step performed at the data link layer (OSI layer 2). VMware uses your physical NIC as a bridge. This way, it forwards your VM’s Ethernet frames to the physical wire.

Bridged Network Defined: How OSI Layer 2 Bridging Works

The bridging step happens at the data link layer (OSI layer 2), not at the network layer (OSI layer 3). At layer 2, devices use MAC addresses, not IP addresses. That means when a guest sends a frame out, the frame goes to the virtual switch first. From there, it passes to the physical NIC.

The virtual switch reads the destination MAC inside the Ethernet frame header. Then it looks up its MAC table and makes a forwarding decision. If the target MAC sits on the physical wire, it forwards the frame to the physical card. If the target is a VM, it passes the frame directly to that system.

This setup provides a significant advantage. In addition, your guest sits in the same L3 subnet as other nodes on the physical wire. So if your VM is on 192.168.1.0/24 in CIDR notation and your physical computer is on the same subnet, the two communicate directly over IP.

However, note one important point: in this mode, your VM also sees all broadcast traffic on your LAN. This can affect performance. Also, security requires careful attention.

VMnet0 Virtual Switch and Physical NIC Mapping in VMware

VMware Workstation has a separate virtual switch for each mode. For bridged mode, this switch is named VMnet0. This virtual switch bridges your physical NIC and your VMs at layer 2.

In fact, VMnet0 is just one of VMware’s virtual switches. Custom virtual switches and VMnet logic clarifies the topic. You create separate switches for different modes.

VMnet0 runs in auto-bridging mode by default. So whichever NIC is active on your host, the virtual switch links to that card automatically. For example, if you use Wi-Fi, VMnet0 connects to your Wi-Fi card. If you use Ethernet, it connects to your Ethernet card.

However, this automatic selection may not always give you the result you want. If you have more than one NIC, VMnet0 may pick the wrong adapter. The same problem appears if you use virtualization platforms like Hyper-V. In this case, your guest cannot join the LAN. In addition, you experience continuous link drops.

To fix this problem, use Virtual Network Editor. With this tool, you can link VMnet0 to a specific physical adapter manually. This way, you control which NIC the virtual switch uses.

Bridged Network Adapter Settings for Virtual Machines

If bridged mode fails and you face internet link problems, the fix is straightforward. You can set up your VM’s link by following the steps below.

Step 1

When you install VMware Workstation, the Virtual Network Editor app has default settings. As proof, you can see these settings in the screenshot below.

In the Virtual Network Editor app, the VMnet0 section has a “Type” option. Here, you can see that bridge mode is active. VMnet0 acts as a transparent bridge between the physical computer and the virtual computer. In short, this adapter is the default setting for VMnet0.

In the “Bridged to” option, when Auto-Bridging is active, you switch between NICs. So, in a sense, you allow the link to be established automatically.

Step 2

First, open your Workstation Pro app. Next, assume you want to set up the Windows 10 VM as bridged. In this case, click the Network Adapter option.

Step 3

Now, open the Virtual Machine Settings window. Then, click the Network Adapter option. Finally, check the Bridged: Connected directly to the physical network option.

Step 4

After you check the bridged setting, click OK.

Review the VM’s IP

Now restart the Windows VM (do this after every setting change). Then, check what IP address it got from DHCP. Use the ipconfig command in the CMD screen. At this point, you can see if the guest got a valid IPv4 lease on the physical subnet.

After we set up the bridge link, we open an internet browser. If the test passes, our virtual PC has taken an IP from the physical wire.

Also, run the “ping www.google.com” command in the CMD prompt. This way, you can check ICMP echo replies and DNS lookup without a browser.

To learn more about VMware bridged mode, you can check the Broadcom source.

No Internet in VMware Bridged Mode: 12 Proven Fixes

The most common problem in bridge mode is that the guest cannot reach the internet. This problem can have more than one cause. Below, you will find 12 proven steps to fix it.

Try each step in order. Also, test the internet link on your VM after each step. Do not move to the next step until the problem goes away. This method helps you identify the source quickly.

Steps 1-3: Fast Diagnosis — Find the Source in 3 Minutes

First, you must find where the problem comes from. For this, we will run three fast tests.

1. Test the host’s link: Open a browser on your physical computer. Go to a website. If the host cannot reach the internet either, the problem lies with your connection.
2. Check the VM’s IP address: Open a command prompt on the guest. Type ipconfig. If the IPv4 address starts with 169.254, the machine could not get a DHCP lease.
3. Ping the host: Run the ping 192.168.1.1 command from the VM. If the ICMP reply comes back, you have an L2/L3 link but no internet access.

These three tests tell you if the problem lies at the IP layer or in the virtual machine setup. If the host reaches the internet but the guest cannot, the problem most likely lies in the VMware setup.

Steps 4-6: Check and Restart VMware Services

Services that run in the background manage VMware’s network parts. If any of these services fails or gets stuck, the bridge will not work correctly.

1. Check the VMware Bridge Control service: Run the services.msc command. Find the “VMware Bridge Control” service in the list. Make sure its status is “Running”. If not, right-click it and select “Start”.
2. Check the VMware DHCP service: Find the “VMware DHCP Service” in the same list. Make sure it runs. This service hands out IP leases to your VM.
3. Restart both services: Right-click the services and select “Restart”. This step clears stuck processes.

After you restart the services, test the link on your VM again. Most of the time, this simple step fixes the problem.

If the services will not start or keep stopping, your VMware install may have a problem. In this case, you may need to repair VMware.

Steps 7-9: Repair and Reinstall the VMware Bridge Protocol Driver

VMware Bridge Protocol lets your physical NIC bridge with VMs at layer 2. If this driver is damaged or not loaded correctly, bridging will not work.

1. Check the driver: Open Device Manager. Find your physical NIC under “Network Adapters”. Right-click it and select “Properties”. Here, make sure “VMware Bridge Protocol” is checked on the “Install” tab.
2. Remove and reload the driver: If the option is not checked, check it and click “OK”. If the option is not in the list, click the “Install” button. Then select “Add Service”. After that, find “VMware Bridge Protocol” and load it.
3. Do a manual install: If the automatic install fails, select the “Have Disk…” option. Point to the C:\Program Files (x86)\VMware\VMware Workstation\netbridge.inf file. This file holds the info needed for the manual driver install.

After these steps, test the link on your guest again. These steps are vital on Windows 11 25H2. This is because driver signature enforcement is very strict on this build.

Steps 10-12: VMnet0 Adapter Selection and IP Renewal

In the last three steps, we will make sure the VMnet0 virtual switch selects the right adapter. Also, we will renew the IP setup.

1. Open Virtual Network Editor as admin: Type “Virtual Network Editor” in the Start menu. Right-click it and select “Run as administrator”. Select VMnet0. From the “Bridged to” menu, select your active physical adapter.
2. Turn off auto-bridging: Click the “Automatic Settings” button. Uncheck the adapters you do not use. This way, VMnet0 links only to the adapter you select.
3. Renew the IP address: Open a command prompt on the guest. Run ipconfig /release, ipconfig /renew, and ipconfig /flushdns in that order. Also, you can use the netsh winsock reset and netsh int ip reset commands.

After you complete these steps, the internet link on your VM will most likely work. If you still have trouble, you may need to investigate causes like enterprise policies or AP isolation.

VMware Bridged Not Working on Windows 11: 25H2 and Wi-Fi 6 AX201 Fixes

Windows 11 25H2 brought key changes to the network stack. These changes affect VMware’s bridge mode immediately. In particular, people who use the Intel Wi-Fi 6 AX201 adapter report continuous drops. In addition, they face link problems.

Now, we will address the problems in the Windows 11 25H2 and Intel Wi-Fi 6 AX201 combination. Also, we will provide the fixes. In addition, we will examine driver signature errors caused by Secure Boot.

Bridged Network Drops Immediately with Intel Wi-Fi 6 AX201: Fix Steps

Intel Wi-Fi 6 AX201 is a wireless adapter used in many laptops. However, this card can cause serious problems in VMware’s bridged mode. In particular, with Windows 11 25H2, we often see instant link drops at layer 2.

According to a fix shared in the Superuser group, the problem is often that the driver stays in a “zombie” state. Windows knows it must delete the driver. But registry keys and hooks keep the driver alive. In this case, you get the “The specified service has been marked for deletion” error.

Follow these steps to fix this problem:

1. Remove the adapter: Open Device Manager. Right-click the “Intel(R) Wi-Fi 6 AX201” adapter. Select “Uninstall device”. Do NOT check the “Try to remove the driver software for this device” option.
2. Scan for hardware changes: From the top menu, select “Action” > “Scan for hardware changes”. Windows finds the adapter again.
3. Check VMware Bridge Protocol: Run the ncpa.cpl command. Right-click the Wi-Fi adapter and select “Properties”. If “VMware Bridge Protocol” is in the list, remove it. If not, follow the path “Install” > “Service” > “Have Disk…”. Then point to the netbridge.inf file.
4. Lock the adapter speed: Right-click the adapter in Device Manager. Go to the “Properties” > “Advanced” tab. Lock the “Wireless Mode” or “802.11n Mode” setting to “802.11ac”. This significantly reduces link drops.
5. Update the driver: Download the latest Wi-Fi 6 AX201 driver from Intel’s official site. The drivers Windows Update offers may not always be the newest.

After you apply these steps, restart your VM. Then test the link. Per user reports, this method fixes the drop problem on the Intel Wi-Fi 6 AX201 adapter permanently.

Additional Experience and Power Settings

Secure Boot and vmnetbridge.sys Driver Signature Error Fix

Windows 11 tightens its security features more with each build. Secure Boot and Memory Integrity block the loading of unsigned drivers. They also block old signed drivers. This fact affects VMware’s vmnetbridge.sys driver immediately.

As of 2026, this problem became clearer on Windows 11 25H2. Users report that the VM adapter shows up in Device Manager with a “Code 48” error. Some get a “Code 56” error instead.

Three different approaches exist to fix this problem:

The most lasting fix is to upgrade VMware Workstation to 17.5 or higher. Broadcom added the driver signatures needed for Windows 11 25H2 in these builds. In addition, it added compatibility updates.

If you cannot upgrade, you can turn off Secure Boot temporarily. For this, go into BIOS/UEFI settings. Turn off the Secure Boot option. However, this lowers system security. Also, it is not a lasting fix.

For personal use, the most practical fix is to turn off “Core Isolation” > “Memory Integrity” in Windows Security Center. This step lets VMware drivers load.

# Turn off Memory Integrity from the command line (as admin)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

After you run this command, restart your computer. VMware bridged mode will now work. But keep in mind that this setting carries some security risks.

Hyper-V, WSL2, and VMware Bridge Conflict: Lasting Fix with bcdedit

If you use Hyper-V and WSL2 on Windows 11, VMware’s bridged mode will most likely fail. The cause is that Windows’ virtualization layer (hypervisor) conflicts with VMware drivers.

This conflict blocks your VM from getting an IP address. Also, it cuts internet access off permanently. Luckily, this problem has a lasting fix.

VMnet0 Selects the Wrong Hyper-V Virtual Adapter

When you turn on Hyper-V, Windows creates virtual adapters automatically. These adapters show up with the “vEthernet” prefix. In auto-bridging mode, VMnet0 may select them by mistake.

While VMnet0 runs in auto mode, it scans all active adapters on the host. The virtual adapters Hyper-V makes are part of this scan too. If VMnet0 selects this virtual adapter, your guest cannot join the physical wire. Instead, it links to Hyper-V’s isolated segment.

The signs of this case are:

• The VM gets an IP address but cannot reach the internet.
• You cannot ping the host.
• You see the link as “Limited” or “Unauthenticated”.
• You see the adapter VMnet0 links to as “vEthernet (Default Switch)”.

To fix this problem, link VMnet0 to your physical adapter manually in Virtual Network Editor. Also, turn off auto-bridging mode. This way, you stop VMnet0 from selecting virtual adapters.

Still, the mere presence of Hyper-V not only leads to adapter selection problems. At the same time, Windows’ virtualization layer conflicts with VMware’s low-level drivers. This clash makes the bridge fail to work at all.

Temporary Fix with the bcdedit hypervisorlaunchtype off Command

The most effective way to fix the Hyper-V conflict is to turn off Windows’ hypervisor temporarily. For this step, we will use the bcdedit command.

1. Open the command prompt as admin: Type “cmd” in the Start menu. Right-click it and select “Run as administrator”.
2. Turn off the hypervisor: Run the command below:

   bcdedit /set hypervisorlaunchtype off

3. Restart the computer: After the command completes with no errors, restart the system. Windows will no longer load the hypervisor.
4. Test VMware bridged mode: Start your VM. Test the link. It should now get an IP address and reach the internet.

This fix resolves the Hyper-V conflict. However, it also turns off WSL2. Since WSL2 uses the Hyper-V framework, it will not run while the hypervisor is off. If you need WSL2, consider the other approach below.

If you want to use Hyper-V and VMware at the same time, change WSL2’s mode. Add these lines to the .wslconfig file:

[wsl2]
networkingMode=bridged
vmSwitch=WSLBridge

This setup lets WSL2 use bridge mode immediately instead of the Hyper-V virtual switch. But this setting may not work smoothly on all systems. So you must test it.

If you do not want to remove Hyper-V permanently, turn off the “Hyper-V” and “Virtual Machine Platform” options in Windows Features. This step turns off the hypervisor. But it affects WSL2 too.

In short, if you want to use Hyper-V and VMware bridged mode at the same time, try WSL2’s bridge mode. Otherwise, choose based on which virtualization platform you use more.

VMware Bridged in Enterprise LANs: 802.1X and AP Isolation Blocks

Using VMware bridge mode in enterprise LANs is much more complex than in home setups. 802.1X authentication, AP isolation, and MAC address filtering are common safeguards. In addition, these safeguards can block your VM from joining the LAN.

In this section, we will address the blocks in enterprise setups. Also, we will provide the methods you can use to get past them.

AP Client Isolation and 802.1X Blocking Bridged Mode

The most common block in enterprise Wi-Fi is AP (Access Point) client isolation. When you turn on this feature, clients linked to the same AP cannot communicate with each other directly.

Your VM shows up with a separate MAC address in bridge mode. The AP sees the guest as a different L2 client. Then it blocks traffic between it and your host at the switch port level. In this case, your virtual machine cannot join the LAN. In addition, it can only reach the host.

802.1X authentication leads to a similar problem. Enterprise setups require each device to authenticate on its own. Your VM shows up with its own MAC address in bridge mode. So it cannot use your host’s authentication certificate.

The Cisco group shared a fix. Per this fix, the host sees the guest’s EAPOL frames. Also, EAPOL stands for Extensible Authentication Protocol over LAN. Then it answers them by mistake. This makes the 802.1X handshake fail.

Remediation Steps and Enterprise Configuration

Several different approaches exist to get past these problems:

• MAC address cloning: Set the VM’s MAC address to match the host’s. This makes the AP see the virtual machine as part of the host.
• Static IP use: Set up a static IP instead of DHCP. This stops the DHCP server from seeing the guest as a separate L3 host.
• Switch to NAT mode: If bridged mode fails completely, switch to NAT mode. In NAT mode, the VM uses the host’s IP address. Also, it does not show up as a separate device.
• Wired link use: Connect with an Ethernet cable instead of Wi-Fi. Also, we usually do not apply AP isolation on wired setups.

Consult your enterprise admin. Ask them to set the switch port to multi-auth or MDA (Multi-Domain Authentication) mode. This mode lets the host and VMs authenticate on their own.

Fix in Enterprise LANs with MAC Cloning and Static IP

The most effective way to make bridged mode work in an enterprise LAN is to use MAC address cloning and a static IP together.

MAC address cloning makes the VM use the same L2 address as the host. This way, the AP sees the two devices as one. A static IP setup, on the other hand, stops the DHCP server from giving the guest a separate L3 address.

Follow these steps to apply this method:

1. Find the host’s MAC address: Open a command prompt. Run the ipconfig /all command. At this point, write down your physical adapter’s MAC address.
2. Change the VM’s MAC address: Go to the virtual machine settings in VMware. Select the adapter. Click the “Advanced” button. Then enter the host’s MAC address in the MAC address field.
3. Set up a static IP: Set the static IP settings in the guest’s operating system. Also set the subnet mask, default gateway, and DNS resolver. But make sure the IP address does not clash with the host’s.
4. Test the link: Run the ping 8.8.8.8 and ping google.com commands on the VM. If both work, bridged mode works in the enterprise LAN.

Authentication, Risks, and Comparison Methods

This method works on setups that need 802.1X authentication. When your host authenticates to the LAN, your VM uses the same session.

That said, this method has some risks. Your admin can detect MAC address cloning. Also, they may treat it as a security breach. For this reason, do not use this method without checking your enterprise policy.

In short, if you want to use VMware bridged mode in an enterprise LAN, consult your admin first. Do not use methods like MAC cloning without their approval. If the bridge fails completely, NAT mode is the safest option.

Bridged Network Performance and Security Tuning: iperf3, Promiscuous Mode, and VLAN

VMware bridge mode gives top performance when you configure it correctly. Even so, in some cases, you may see unexpected drops. Also, if you skip security settings, you can put your LAN at risk.

Now, let’s address performance measurement in bridged mode. Also, we will provide security tuning and VLAN setup.

Measure Bandwidth and Jitter in Bridged Mode with iperf3

iperf3 is an open-source tool used to measure network performance. It is ideal for measuring TCP throughput in bridge mode. Also, you can use it to measure latency and jitter on UDP.

Per a 2026 study, TCP throughput in bridged mode on VMware Workstation 17.3 fell below what was expected. Researchers measured 4.9 Gbps instead of 9.2 Gbps. The cause of this 47% drop was the ebtables (Ethernet Bridge Tables) rules that VMware turns on by default.

ebtables filters Ethernet frames at layer 2. By default, one rule accepts all TCP traffic. But the system checks this rule for each packet individually. This puts a heavy load on the CPU.

You can tune the ebtables rules to fix this problem:

# List the current ebtables rules
sudo ebtables -t filter -L FORWARD --Lc

# Clear the FORWARD chain
sudo ebtables -t filter -F FORWARD

# Open only the needed ports
sudo ebtables -t filter -A FORWARD -p IPv4 --ip-protocol tcp --ip-destination-port 22 -j ACCEPT
sudo ebtables -t filter -A FORWARD -p IPv4 --ip-protocol tcp --ip-destination-port 80 -j ACCEPT
sudo ebtables -t filter -A FORWARD -p IPv4 --ip-protocol tcp --ip-destination-port 443 -j ACCEPT

# Deny all other traffic
sudo ebtables -t filter -P FORWARD DROP

After this tune-up, throughput rose to 9.1 Gbps. In other words, the 47% performance loss went away permanently.

Follow these steps to test TCP and UDP on your own setup with iperf3:

1. Start the server side: Run the iperf3 -s command on the VM.
2. Start the client side: Run the iperf3 -c <vm_ip> -t 30 -P 8 command on the host.
3. Check the results: Look at the “Bitrate” value in the output. This value shows the amount of data you send per second.
4. Measure jitter: Use the iperf3 -c <ip> -u -b 1G command to test in UDP mode. Check the “Jitter” value in the output.

Promiscuous Mode and VLAN Tagging: Security and Setup

Promiscuous mode lets the virtual switch listen to all frames on the L2 segment. This mode helps with traffic analysis and packet capture. Even so, it also carries serious security risks.

Per Broadcom security docs, when you turn on promiscuous mode, the VM can see traffic in the same port group. Also, this traffic belongs to other VMs. This case can lead to the theft of sensitive data. For example, passwords, tokens, and private info are at risk.

Turn on promiscuous mode only in these cases:

• You run traffic analysis (Wireshark, tcpdump).
• You run an IDS/IPS (Intrusion Detection/Prevention System).
• You run a port scan or security audit.
• You use VMware’s own monitoring tools.

Keep promiscuous mode off for normal use. In VMware, you can change this setting from Virtual Network Editor. Also, you can edit it from the .vmx file.

VLAN tagging (802.1Q) is a more complex topic in bridge mode. VMware Workstation does not support 802.1Q VLAN tags natively. Even so, you can set up VLAN through your VM’s operating system.

For VLAN setup on Linux VMs, you can use these commands:

# Create a VLAN interface
sudo ip link add link eth0 name eth0.100 type vlan id 100

# Turn on the interface
sudo ip link set eth0.100 up

# Assign an IP address
sudo ip addr add 192.168.100.10/24 dev eth0.100

On Windows VMs, load the “Intel VLAN” or “Realtek VLAN” driver from Device Manager. Then set the VLAN ID in the adapter properties.

In enterprise setups, we usually do VLAN tagging at the switch port level. If your switch port is in trunk mode, your VM can send 802.1Q tags. But if it is in access mode, you can only reach one specific VLAN.

Bridged Network Setup on Linux Virtual Machines: netplan, NetworkManager, and nmcli

Setting up a bridge on Linux VMs is more flexible than on Windows. However, it varies from distro to distro. Now, we will address bridge setup on the most common Linux distros.

Ubuntu and Debian based systems use netplan. RHEL and CentOS based systems use NetworkManager and nmcli.

Static IP in Bridged Mode with Ubuntu/Debian netplan

On Ubuntu 20.04 and later builds, netplan is the default setup tool. Follow these steps to set up a static IP in bridge mode:

1. Find the netplan config file: List the YAML files in the /etc/netplan/ folder. You will usually find a file like 01-network-manager-all.yaml or 50-cloud-init.yaml.
2. Edit the config file: Define the bridge interface with the structure below:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces: [eth0]
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]
      parameters:
        stp: false
        forward-delay: 0

1. Apply the setup: Run the sudo netplan apply command. If you get an error, you can see the details with the sudo netplan --debug apply command.
2. Test the link: Check the bridge interface’s IP address with the ip addr show br0 command. Then ping the gateway with the ping -c 3 192.168.1.1 command.

This setup links the physical interface (eth0) to the bridge. Then it gives the bridge interface (br0) a static IP. The physical interface no longer has an IP address. It only communicates through the bridge.

If you want to use DHCP, remove the addresses and routes sections. Then add dhcp4: true.

RHEL/CentOS ifcfg-eth0 and NetworkManager nmcli Setup

On Red Hat based distros like RHEL, CentOS, and Fedora, you set up the connection in two ways. You can use classic ifcfg files or NetworkManager’s nmcli tool.

Method 1: Bridge setup with ifcfg files

This method is common on old RHEL/CentOS builds. First, make a config file for the bridge interface:

# /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
IPADDR=192.168.1.100
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=8.8.8.8
ONBOOT=yes
DELAY=0

Then link the physical interface to the bridge:

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
BRIDGE=br0

Restart the service to apply the changes:

sudo systemctl restart network

Method 2: Bridge setup with nmcli

On modern systems that use NetworkManager, nmcli is much more convenient. In addition, you can create a bridge with one command:

sudo nmcli connection add type bridge con-name br0 ifname br0 \
  ipv4.method manual \
  ipv4.addresses "192.168.1.100/24" \
  ipv4.gateway "192.168.1.1" \
  ipv4.dns "8.8.8.8" \
  connection.autoconnect-ports 1

Then add the physical interface to the bridge:

sudo nmcli connection add type ethernet port-type bridge \
  con-name br0-port-eth0 ifname eth0 controller br0

Turn on the bridge:

sudo nmcli connection up br0

Check the link:

nmcli connection show
ip addr show br0
ping -c 3 192.168.1.1

This method is much faster and less prone to errors than ifcfg files. In particular, select nmcli on new RHEL 8+ and CentOS Stream builds.

The most common mistake in Linux bridge setup is to forget to clear the IP address when you add the physical interface to the bridge. If an IP address stays on the physical interface, the bridge will not work correctly. Netplan and nmcli do this step automatically. But in manual setups, do not forget to run the ip addr flush dev eth0 command.

Further Reading Sources for VMware Bridged Network

If you want deeper network tech knowledge about VMware bridged mode, the sources below will guide you. These sources come from official docs and academic work.

• Broadcom Official Docs — Configuring Networking: The official bridged guide for VMware Workstation Pro 25H2. The most current info on VMnet0 settings, adapter selection, and auto-bridging mode resides here.
• Microsoft Learn — Hyper-V NAT Network Setup: The official Microsoft source for learning Hyper-V and WSL2 setup. It helps you understand the root of conflict problems with VMware.
• RFC 826 — An Ethernet Address Resolution Protocol: The original spec of the ARP protocol. An academic source for those who want to understand the foundation of OSI Layer 2 bridging and MAC address resolution.

FAQ About Virtual Machine Bridged Mode and VMnet0

Conclusion: Key Points in Bridged Network Setup and Next Steps

VMware bridge mode is the most powerful tool to make your VM a real member of the physical wire. However, using this power requires the right setup and troubleshooting skill.

In this guide, we started with the basic logic of bridged mode. Then we covered every problem you may face and its fix. Now let’s wrap up with a final checklist.

7 Key Checkpoints in Bridged Network Setup

When you check the seven points below, you can be sure your bridge works without issues:

1. VMnet0 adapter selection: Make sure VMnet0 links to the right physical adapter in Virtual Network Editor. In particular, select manually instead of auto mode.
2. VMware Bridge Protocol: Check that the “VMware Bridge Protocol” option is loaded and on in your physical NIC’s properties.
3. VMware services: Make sure the “VMware Bridge Control” and “VMware DHCP Service” services run.
4. Windows firewall: Make sure Windows Firewall does not block VM traffic on TCP ports 22, 80, and 443. Add an exception if you need to.
5. Hyper-V state: If Hyper-V is on, bridged mode will not work. Turn it off temporarily with the bcdedit /set hypervisorlaunchtype off command.
6. IP setup: Check that the VM can get an IP from DHCP or that the static IP, subnet mask, and default gateway are configured correctly.
7. Secure Boot and Memory Integrity: These features can block VMware drivers. Turn them off if you need to, or update VMware.

Switch to Other VMware Modes: NAT, Host-Only, and LAN Segment

Bridged mode is not right for every case. In some cases, it makes more sense to switch to other modes.

NAT mode lets the VM share the host’s IP address through a NAT table. If bridge mode fails in enterprise LANs or Wi-Fi with AP isolation, NAT is the safest option. The guest can reach the internet, but other devices cannot see it. In addition, you can provide access from outside by doing port forwarding.

Host-Only mode makes an isolated L2 segment between the virtual machine and the host. In this case, the VM cannot reach the internet. This mode is ideal for security tests and isolated lab setups.

To link more than one virtual machine to each other, you use LAN Segment. The host is not part of this setup. It is well suited for multi-layer cases and micro segmentation tests.

For more detailed info on VMware’s other modes, check our NAT link guide and our Host-Only setup article.

In short, bridged mode is a strong tool, but it may not work in every setting. In enterprise LANs, usually select NAT mode. But, in personal lab setups, bridged mode is the most flexible choice. No matter which mode you use, always keep security first.

Test the methods I covered in this guide in your own setting. Keep in mind that every LAN is different. A fix that works in one setting may not work in another. Be patient and try the steps in order.