Network Bridge Kills Your Internet — Why and How to Fix

1. The Bridge Steals Your Main Adapter's Default Gateway

What's actually happening here is that creating a network bridge merges two or more network adapters into one virtual adapter. Windows then assigns this new bridge adapter a single IP, subnet mask, and default gateway. If your main connection (say, your Ethernet or Wi-Fi) was the one providing internet, the bridge can overwrite or drop that adapter's routing info.

I've seen this most when someone bridges their Wi-Fi adapter with a virtual machine adapter (like Hyper-V or VMware). The bridge adapter gets an IP from the wrong subnet or no gateway at all.

The Fix: Check and Force the Correct Gateway

Open a Command Prompt as administrator — right-click Start, select "Command Prompt (Admin)" or "Windows Terminal (Admin)". Run:

ipconfig /all

Look for the "Ethernet adapter Network Bridge" section. Under it, find "Default Gateway". If it's blank or shows 0.0.0.0, that's the problem. The bridge has no route to the internet.

To fix, first delete the bridge temporarily. Go to Network Connections (ncpa.cpl), right-click the bridge adapter, and select "Delete". Then re-create the bridge by holding Ctrl and clicking only the two adapters you want to bridge. Right-click one and select "Bridge Connections".

After that, run ipconfig /renew in the admin command prompt. This forces the bridge to request a new IP from your router. If your router's DHCP works right, the bridge should get a valid gateway.

If it still fails — and I've had this happen on older routers — set the IP manually. Right-click the bridge adapter, Properties, select "Internet Protocol Version 4 (TCP/IPv4)", click Properties, and enter:

IP address: 192.168.1.50 (or whatever your router's subnet is)
Subnet mask: 255.255.255.0
Default gateway: 192.168.1.1 (your router's IP)
Preferred DNS: 8.8.8.8

The reason step 3 works is that you're bypassing the bridge's messed-up DHCP negotiation and telling Windows exactly where to send traffic.

2. DNS Stops Resolving After Bridging

Sometimes the bridge keeps an IP and gateway, but DNS stops working. This happens when the bridge adapter doesn't inherit the DNS servers from your main adapter. It might try to use the router's DNS but the router's DHCP lease is tied to the original adapter, not the bridge.

Real-world trigger: You bridge your Ethernet and a USB tethering adapter from your phone. The phone's connection has different DNS settings, and Windows gets confused about which one to use.

The Fix: Flush DNS and Set DNS Explicitly

In the same admin command prompt, run:

ipconfig /flushdns
ipconfig /registerdns
netsh winsock reset

Then restart your computer. This clears all cached DNS and resets the network stack. If that doesn't do it, go back to the bridge adapter's IPv4 properties and set DNS manually (like 8.8.8.8 and 1.1.1.1). I've had the best luck with Google's DNS here because they're more tolerant of weird routing.

Why flushing DNS helps: The bridge adapter might have cached stale DNS records from before the bridge existed. Windows doesn't automatically clear those when you change the network configuration.

3. Windows Holds on to Old Route Entries from the Pre-Bridge Setup

The third common cause is that Windows keeps a routing table entry from your original single adapter. When you create the bridge, the old route stays, pointing to an interface that no longer exists. This causes "destination host unreachable" for some traffic, even if the bridge looks fine in ipconfig.

You see this most after removing a bridge and re-creating it — Windows doesn't clean up old routes.

The Fix: Reset the Routing Table

Open an admin command prompt and run:

route -f

This deletes all gateway entries from the routing table. Then run:

ipconfig /renew

Your computer will rebuild the routing table from scratch based on the new bridge adapter. I've fixed several stubborn "no internet" issues with just this command. It's aggressive — it wipes everything — but it's clean.

If you don't want to nuke all routes, you can check the table first with route print. Look for any entries with "On-link" and a gateway of 0.0.0.0 pointing to an old adapter's interface number. Delete those entries with route delete 0.0.0.0 mask 0.0.0.0 [old interface IP].

Quick-Reference Summary

If none of these work, take the bridge down and test each adapter alone. Sometimes one adapter has a bad driver or is flaky, and the bridge just inherits the problem. Update drivers, especially for Realtek and Intel network chips — I've seen Realtek PCIe GBE Family Controller drop packets under bridge load.