Home network segmentation means splitting one flat network into isolated zones using VLANs, so a single compromised device can't reach everything else. I run five purpose-based VLANs — personal, wireless, kids, guest, and server/lab — behind a Cisco ASA firewall that denies all inter-VLAN traffic by default and logs every allowed exception.
The problem with a flat network
Most home networks are flat. The TV, the kids' tablets, the work laptop and the server all sit on the same subnet and can all talk to each other. It's convenient and it works, right up until one of those devices gets compromised. A vulnerable IoT gadget, a phished laptop, a smart plug running firmware nobody has touched since 2019. Once an attacker lands on that device, they're already on the same network as everything else, and nothing stops them moving sideways, because the network was never built to.
When I started building my lab I treated it like a small production network. The first rule I set for myself was to assume any single device could be compromised, and design so that it wouldn't matter much when it happened. That's what segmentation is for. Not a tidy diagram. Shrinking how far a problem can travel before it hits a wall.
VLANs draw the lines. The firewall enforces them.
There's a misconception I had early on: put devices on different VLANs and they're isolated. They're not, not on their own. VLANs separate broadcast domains at Layer 2, but something still has to route between subnets, and that router is where the real policy lives.
In my setup a MikroTik handles the edge: dual-WAN, NAT, the perimeter firewall. Behind it, a Cisco ASA is the Layer 3 gateway for every internal VLAN, one sub-interface per segment. Every packet going from one VLAN to another passes through the ASA, and the default answer there is no. Inter-VLAN traffic is denied unless there's an explicit, logged rule allowing it. The Aruba switch carries the VLANs as an 802.1Q trunk and handles port security and spanning-tree at the edge. Wi-Fi is mapped to the right VLAN by SSID, so a phone joining the guest network ends up in the guest segment without me doing anything.
A few lines carry the whole intent of the segment: permit only the management flows that have to exist — SSH and SNMP to the switch — then deny the rest.
The VLANs draw the lines. The ASA is what actually enforces them.
The five zones — and why each one exists
| VLAN | Zone | What lives here | Why it's separate |
|---|---|---|---|
| 20 | Personal / Home | Personal computers, trusted devices | The data I'm protecting, kept away from everything else |
| 30 | Wireless | Everyday phones, tablets, laptops over Wi-Fi | Roaming devices that install apps and join other networks |
| 40 | Kids | The kids' devices | Different rules, and no path into personal or server |
| 50 | Guest | Visitors' devices | Internet only, untrusted by definition |
| 60 | Server / Lab | Proxmox host, lab services, monitoring | Where I break things on purpose; the busiest segment |
Personal (VLAN 20) is the trusted zone. The machines I actually work on and keep data on. This is what everything else is being kept away from, so it gets the fewest ways in.
Wireless (VLAN 30) holds the everyday phones and tablets. I trust them more than a random IoT device, but they roam, install apps and hop onto other networks all the time, so they don't belong on the same segment as the wired personal machines.
Kids (VLAN 40) exists for two reasons. It lets me put content filtering and time-based access in one place. And if one of the kids' tablets picks up something off a game or a sketchy app, there's no road from there into the personal or server zones. The isolation protects them, and everyone else.
Guest (VLAN 50) is the segment most people skip and the easiest one to justify. Guests get internet and nothing else. No view of the personal network or the server. I have no idea what's running on a visitor's phone, so I treat it as untrusted and move on.
Server / Lab (VLAN 60) is where the Proxmox host, the lab services and the monitoring stack live. It's the busiest segment and the one where I'm most likely to break something on purpose, so keeping it contained matters. If an experiment misbehaves, it stays in the lab.
What this actually buys you
The payoff is concrete, not theoretical. With default-deny between zones:
- ›a compromised IoT device can't reach my personal machines or data;
- ›a guest's phone, and whatever it brought along, never touches anything internal;
- ›an experiment that goes sideways in the lab stays in the lab;
- ›and every cross-segment attempt that isn't on the allow-list shows up in the logs.
That last one is where segmentation and monitoring meet. Traffic trying to cross a boundary it has no business crossing is exactly the kind of thing worth alerting on, so the lines I enforce are also the lines I watch.
What building it taught me
A few things I didn't expect going in.
The hard part isn't making VLANs. It's writing the inter-VLAN policy. Every allow rule is a decision you have to defend to yourself, and the temptation is to just open things up to make something work. Holding that line is the actual job.
Default-deny breaks things loudly, and right away. The first few weeks, half of my "the network is broken" moments were the firewall doing exactly its job, denying a flow I hadn't written a rule for yet. It's annoying, and it's also the point. It forces you to know precisely what each device needs to talk to, instead of guessing and hoping.
Logging the denies turned out to be as useful as the denies themselves. It's a quiet window into what's actually trying to move around in there.
This is a home lab, not an enterprise, and I'm not going to pretend otherwise. But the principles are the same ones that scale up, and building it by hand, deciding each boundary, breaking it, fixing it, taught me more about how networks really behave than any amount of reading did. The full topology and the sanitized configs are on my GitHub.