Design

• Hypervisor bridge with no physical NIC attached — the segment only exists behind the router
• Dedicated /24 with the router as the only way out
• Firewall ruleset: internet egress allowed, all routes to the home LAN dropped
• VPN egress (WireGuard) for external lab work, toggled manually — not always-on

Prove the isolation

The rule that matters isn't the one you wrote — it's the one the packets hit. Verification was empirical: from the lab box, internet reachable; every host on the home LAN, 100% packet loss; firewall counters incrementing on the drop rule while the tests ran. Screenshots and counters, not assumptions.

Operational discipline

• Credentials for lab systems stored outside the lab, rotated when exposed
• Scheduled patching for the attack box — offensive tooling is still software with CVEs
• Storage watchdogs, because a full thin-pool takes down the lab exactly when you're mid-exercise

Practice targets are authorized-only: TryHackMe rooms (SSRF, IDOR, security fundamentals), intentionally vulnerable apps like DVWA and Juice Shop, and my own infrastructure. The habit that transfers to real network security work isn't the exploit — it's the segmentation, the verification, and the discipline.

The failure

An ASRock Rack X470D4U came up with the console frozen on "System Initializing" while POST codes showed the host itself was fine. That's the signature of a wedged BMC: the host works, but the management controller that owns video and USB never finished booting.

Triage order

1. Confirm it's the BMC, not the host — POST codes advancing to a healthy state while video/USB stay dead
2. Try in-band and LAN recovery first: IPMI web flash if the interface still answers
3. If the BMC is fully unresponsive, the SPI flash chip is the last resort

The bench fix

On this board the BMC firmware lives on a socketed SPI flash chip — which means a CH341A programmer and a firmware image turn a dead board into a bench-recoverable one. Pull the chip, flash the image, reseat, then update BMC firmware first and BIOS second (that order matters — the BMC mediates the flash process on these boards).

Takeaways

• Old BMC firmware wedges more; keep management controllers patched like any other attack surface
• Management-plane failures mimic hardware death — knowing the boot sequence saves you from replacing working boards
• Vendor firmware downloads are their own adventure: verify checksums, stage recovery USBs before you need them

The layout

• Two Arista switches, LACP port-channel trunk between them for redundancy and bandwidth
• VyOS router VM handling inter-VLAN routing, NAT, and firewall policy
• Separate VLANs for lab hosts, servers, storage, and out-of-band IPMI management
• DHCP relay (ip helper-address) from switch SVIs back to a central Kea DHCP server

Why segmentation first

Management interfaces don't belong next to workloads. IPMI/BMC interfaces live on their own VLAN with no route to anything that doesn't need them — the same principle that separates a defensible network from a flat one. When I later added an isolated pentest segment, the pattern was already there: new VLAN, explicit firewall ruleset, default deny toward everything else.

What broke and what it taught me

The interesting parts were the failures. A backup route advertised over a VPN overlay blackholed the entire LAN because a peer accepted a route to its own subnet — every host was healthy, and nothing could talk. Diagnosing that meant reading policy routing tables, not pinging harder. Lesson: a route you didn't mean to advertise is an outage you didn't plan for.

DHCP relay across VLANs is another one people get wrong: directly-attached segments need the DHCP server listening explicitly, relayed segments don't — mixing those two models silently serves no leases.

Verification over vibes

Every change gets proven: LACP state checked on both ends, firewall rules tested by actually generating the traffic they should block, failover exercised by pulling the primary path. If it isn't tested, it's a guess.