Bill Gernert
Networking & Edge

VLANs

Segmented networking so a foothold in one place is not a foothold everywhere - infrastructure, compute, and identity on separate segments, default-deny between them.

What it is & why I use it

The lab network is split into separate VLAN segments by role rather than run as one flat network. Broadly: an infrastructure segment, a compute/cluster segment, and an identity segment, each its own broadcast domain, with traffic between them passing through the firewall rather than flowing freely.

I segment because a flat network means that anything which compromises one host can reach every other host directly. Segmentation turns "own one box, reach the whole lab" into "own one box, and now face a firewall to get anywhere else" - it is the network expression of least privilege and blast-radius containment.

How I use it in the lab

  • Segments by role. Infrastructure services, the compute/cluster workloads, and identity systems live on distinct segments, so unrelated things are not sharing one flat broadcast domain.
  • Routing through the firewall. Cross-segment traffic is routed and filtered by the firewall, which is where inter-segment policy is actually enforced.
  • Default-deny between segments. The baseline is that segments cannot talk to each other; specific, necessary flows are opened explicitly rather than assumed.
  • Least-exposure placement. Where a system sits is a security decision - the more sensitive the role, the more constrained what may reach it across a segment boundary.

Architecture

Diagram coming Role-based segments (infrastructure / compute / identity), each its own domain, with the firewall as the default-deny chokepoint between them. Scrubbed of subnet ranges, VLAN numbers, and addresses.

In action

Screenshot coming The inter-segment rule set showing default-deny with a handful of explicit, justified allows. Captured per the publishing checklist - subnets, VLAN IDs, and addresses redacted.

Lessons learned & gotchas

Gotcha - one broad "allow" quietly undoes the whole segmentation Segmentation is only as strong as its narrowest rule, and it dies to convenience. The day something does not work across segments, the tempting fix is a broad any-to-any allow "just to get it running" - and the moment that rule exists, the two segments are effectively one flat network again, except now it looks segmented on the diagram. The whole lateral-movement protection is gone and nothing visibly broke, so no one notices. The discipline is to open the specific flow that is actually needed - source, destination, port - and never the shortcut. A permissive rule buried in a default-deny policy is worse than no policy, because it grants false confidence.
  • Segmentation has an ongoing cost, and that is the point. Every legitimate cross-segment flow has to be an explicit rule. That friction is not a bug - it is what forces you to know and justify what talks to what.
  • A forgotten allow is a real outage too. Default-deny means a new service that needs to cross a boundary will simply not work until its rule exists. "It is a firewall rule" belongs on the checklist when adding anything that spans segments.
  • Put the crown jewels behind the tightest boundary. Identity and secrets deserve the most constrained segment - the fewer things that can even reach them across a boundary, the smaller the attack surface for the things that matter most.

Impact

3
role-based segments
Deny
between segments by default
Explicit
cross-segment flows only

VLAN segmentation is what keeps a single compromised host from being a compromise of the whole lab. The lasting lesson is that the control lives in the discipline, not the diagram: default-deny with narrow, justified allows is real containment, while one broad shortcut rule silently collapses it back into a flat network that only looks segmented.

Code & further reading

Segmentation notes (link coming) Network segmentation

Any published network notes are scrubbed of subnet ranges, VLAN IDs, addresses, and hostnames before they go public.