The NIC that wouldn't bridge — Intel I350-T4V2 as the foundation for a segmented lab

In October 2025, my lab was outgrowing its hardware.

I was running CML on VMware Workstation with Proxmox coming up alongside it, FMC and FTD topologies that needed real internet reachability, pfSense as a virtual firewall, and a single desktop trying to act like a small data center. The build was a Ryzen 7 3800XT with 128 GB of RAM. The kind of single-box lab that works until it doesn’t.

It stopped working when I tried to license FMC.

The setup

Cisco Firepower Management Center needs internet to do most of what makes it useful: license activation, threat intel feeds, GUI features that hit cloud APIs. In a CML topology, the standard path is the External Connector. It’s a virtual node that bridges out of the simulation, through VMware Workstation’s bridged networking, onto the physical NIC, onto the LAN, out to the internet.

CML node → External Connector → vmnet0 (bridged) → host NIC → LAN → internet

That should just work. It didn’t.

The wall

The host’s onboard NIC couldn’t pull a DHCP lease in bridge mode. Static IPs didn’t reach the internet either. From the FMC GUI, every license request timed out. Bridged adapters inside CML behaved unpredictably. Sometimes traffic flowed, sometimes it didn’t.

The host itself had perfectly fine connectivity. Browse the web, pull packages, all normal. The problem was specifically what happened when VMware tried to bridge a VM’s traffic through that NIC. VMs got addresses but couldn’t get out.

I spent too long on driver swaps, vmnet config files, and forum threads from 2015 about Realtek bridging quirks. Eventually I stopped chasing the software and started looking at the hardware.

Why consumer NICs fail at this

VMware Workstation bridged networking works by putting the host NIC into promiscuous mode and registering additional MAC addresses for each VM. Every VM gets its own MAC, and the host NIC has to accept frames addressed to all of them.

Consumer-grade NICs often don’t fully support this. Realtek chips and certain onboard Intel I219 variants filter frames at the MAC level before the driver ever sees them, or limit how many MAC addresses can be registered on a single port, or quietly drop frames not addressed to the host’s primary MAC. The card is doing exactly what it was designed to do: filter aggressively, save power, and pretend frames not destined for it never existed.

That’s fine for a desktop. It’s fatal for hypervisor-style bridging.

Why the I350-T4V2 specifically

I evaluated a few options before buying:

Intel I210: single port, cheap, solid driver support. Works fine but no room to grow.
Intel I350-T1 / I350-T2: same chipset family, fewer ports. Same gold-standard igb driver.
Intel I350-T4V2: quad-port, same igb driver, headroom for the next year of design.

The decision came down to one factor. This NIC needed to last. Intel’s igb driver is the gold standard across Linux, Proxmox, VMware, and pfSense. It’s the kind of hardware where you stop thinking about driver compatibility and start thinking about what you want to do with the ports.

Quad-port wasn’t about needing four ports immediately. It was about not having to revisit this decision when the lab grew.

The install

The card went into PCI_E4 on an MSI X570 Gaming Edge WiFi. That’s an x4-lane slot, electrically appropriate for a quad-port gigabit card. Passive cooling, so I made sure airflow over the slot was clear. Drivers loaded clean on Windows and Linux on first boot.

I pointed vmnet0 at one of the I350’s ports and left the onboard NIC alone for host traffic. Bridging worked the first time. The External Connector pulled a DHCP lease. FMC’s license activated. The lab came up the way it was supposed to.

What it actually unlocked

Past me would have called this “the NIC swap.” Looking back, it was the moment the lab stopped being a collection of VMs and started being infrastructure.

With multiple physical ports and proper hypervisor support, traffic could finally move the way I wanted it to. CML’s External Connector became reliable. FMC and FTD stayed licensed and reachable. The Proxmox build that came later had a clean physical interface waiting for it.

Most of what came after, the cluster, the security stack, the observability layer, traces back to this card doing the boring job of moving frames the way a NIC is supposed to.

Sometimes the fix is hardware. Sometimes the fix is the right hardware.