Action: built an isolated Kali segment behind a dedicated VyOS zone with default-deny firewall policy, no-uplink bridge, and jump-host-only access.

Result: containment verified empirically - internet egress works, 100% of lateral traffic to the home network is dropped and logged.

Skills: network segmentation, firewall policy design, VyOS, threat containment, verification testing.

If you're practicing offensive security at home, the lab must be provably isolated — not "probably fine." Mine runs a dedicated Kali VM on a bridge with no physical uplink, behind a VyOS firewall segment built default-deny.

Design

• Hypervisor bridge with no physical NIC attached, so 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 instead of 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 because 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.

Action: pulled the socketed SPI flash chip, sourced correct vendor firmware, and reflashed it chip-level with a CH341A programmer.

Result: restored IPMI/out-of-band management without board replacement, returning the server to service.

Skills: hardware-level troubleshooting, firmware analysis, IPMI/BMC internals, vendor firmware sourcing.

A server's BMC (baseboard management controller) is the thing that saves you a drive to the datacenter, until it wedges. Then it can hold the whole board hostage: VGA stuck on a placeholder screen, USB dead, POST completing behind a console you can't see.

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 advance 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. That 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 because 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

Action: designed a multi-VLAN lab on Arista EOS with VyOS routing - SVIs, LACP trunks, DHCP relay, OOB management VLAN, and inter-VLAN firewall policy.

Result: a production-like segmented environment used daily for security testing, monitoring, and infrastructure automation.

Skills: L2/L3 network engineering, Arista EOS, VLAN design, DHCP relay, LACP, access control.

I built my home lab the way I'd build a small production network: real switches, a real router, and real VLAN segmentation, not a flat /24 with everything trusted.

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. That same principle 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, while 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.