Network Segmentation for Humans: VLANs and Zero-Trust Basics

Quickstart

If you only do the “80/20”, do this: create three zones, enable default-deny between zones, and then add the few explicit allows you truly need. You can implement this with VLANs on a managed switch/router, or with separate SSIDs and a router that supports multiple networks.

Overview

Network segmentation is the practice of splitting one flat network into multiple smaller networks (segments) and controlling the traffic between them. The goal is simple: reduce lateral movement. If something gets compromised, it should not automatically see everything else on your LAN.

Think of segmentation as a network seatbelt. It doesn’t prevent every accident, but it makes the outcome much better. When paired with basics like updates, strong authentication, and sensible logging, it’s one of the highest-leverage security moves you can make — even in a home lab or small office.

Core concepts

Segmentation in one sentence

Segmentation is making “who can talk to whom” explicit. VLANs create separation at Layer 2, subnets and routing create separation at Layer 3, and firewall rules decide what traffic is allowed.

VLANs vs subnets (the common confusion)

A VLAN is like a virtual switch: devices in different VLANs don’t share the same Layer-2 broadcast domain. A subnet is an IP network (Layer 3): it’s how devices get addresses and how routing decides where packets go. In practice, people often use one VLAN per subnet because it’s easy to reason about and easy to enforce with firewall rules.

The “rooms and doors” mental model

Imagine your network as a building:

• Rooms = VLANs/subnets (Admin, Users, IoT, Guests)
• Doors = firewall rules between rooms
• Keys = identity (accounts, device trust, VPN, MFA)
• Security cameras = logs/monitoring so you notice abuse

Segmentation is not about being fancy. It’s about having doors at all — and deciding which doors are locked.

Zero-trust basics (without the buzzwords)

“Zero trust” in small environments boils down to three behaviors:

Step-by-step

This guide is vendor-agnostic. Whether you use a prosumer stack (managed switch + APs) or a router firmware like OpenWrt, the workflow is the same: design zones → create VLANs/subnets → assign ports/SSIDs → apply firewall policy → test → document.

Step 1 — Inventory what you have (and what is “critical”)

Segmentation works best when it’s anchored in reality. List devices and decide what must be protected.

Step 2 — Design your zone map (start small)

A good default design is 4 VLANs: Mgmt (admin only), Users, IoT, Guest. If you want an even simpler start, merge IoT+Guest into one.

# vlan-plan.yaml — a human-friendly segmentation plan
vlans:
  10:
    name: mgmt
    subnet: 192.168.10.0/24
    dhcp: 192.168.10.100-192.168.10.199
    notes: "router/switch/AP mgmt; admin laptop only"
  20:
    name: users
    subnet: 192.168.20.0/24
    dhcp: 192.168.20.100-192.168.20.250
    notes: "laptops/phones/desktops"
  30:
    name: iot
    subnet: 192.168.30.0/24
    dhcp: 192.168.30.50-192.168.30.250
    notes: "TVs, speakers, cameras, smart devices"
  40:
    name: guest
    subnet: 192.168.40.0/24
    dhcp: 192.168.40.50-192.168.40.250
    notes: "visitors; internet only"

policy:
  inter_vlan_default: "deny"
  allow:
    - "users -> internet"
    - "iot -> internet (optional; prefer allow-list if possible)"
    - "users -> nas: 192.168.20.10 tcp/445, tcp/2049 (if needed)"
    - "users -> printer: 192.168.20.25 tcp/9100, tcp/631 (if needed)"
    - "mgmt -> router/switch/ap admin UIs"
  deny:
    - "iot -> users"
    - "guest -> users/mgmt/iot"

Step 3 — Make VLANs real: switch ports and Wi-Fi SSIDs

This is where confusion often appears, so keep it simple:

• Access ports for “normal devices” (one VLAN per port).
• Trunk ports only where needed (router↔switch, switch↔AP).
• Wi-Fi SSIDs map to VLANs (e.g., WiFi-Users on VLAN 20, WiFi-IoT on VLAN 30, WiFi-Guest on VLAN 40).

Step 4 — Configure VLAN interfaces (example pattern)

Every platform has different knobs, but the ingredients are consistent: define VLAN IDs, create interfaces, attach DHCP, and tag trunks. Below is a representative example for an OpenWrt-style setup (UCI), showing the shape of a multi-VLAN configuration. Adapt the port names and VLAN IDs to your hardware.

# Example: OpenWrt-style UCI snippets (conceptual)
# /etc/config/network — define a bridge and VLANs, then create L3 interfaces.

config device
  option name 'br-lan'
  option type 'bridge'
  list ports 'lan1'
  list ports 'lan2'
  list ports 'lan3'
  list ports 'lan4'

# VLAN 10 (mgmt): untagged on lan2, tagged on lan1 (trunk to router/AP)
config bridge-vlan
  option device 'br-lan'
  option vlan '10'
  list ports 'lan1:t'
  list ports 'lan2:u*'

# VLAN 20 (users): untagged on lan3, tagged on lan1 trunk
config bridge-vlan
  option device 'br-lan'
  option vlan '20'
  list ports 'lan1:t'
  list ports 'lan3:u*'

# VLAN 30 (iot): untagged on lan4, tagged on lan1 trunk
config bridge-vlan
  option device 'br-lan'
  option vlan '30'
  list ports 'lan1:t'
  list ports 'lan4:u*'

config interface 'mgmt'
  option proto 'static'
  option device 'br-lan.10'
  option ipaddr '192.168.10.1'
  option netmask '255.255.255.0'

config interface 'users'
  option proto 'static'
  option device 'br-lan.20'
  option ipaddr '192.168.20.1'
  option netmask '255.255.255.0'

config interface 'iot'
  option proto 'static'
  option device 'br-lan.30'
  option ipaddr '192.168.30.1'
  option netmask '255.255.255.0'

Step 5 — Apply the policy: default deny, then add allows

This is where segmentation becomes security. A safe baseline for small networks:

Below is an example of a simple inter-VLAN firewall idea using an nftables-style approach (conceptual). The syntax will vary by distro/router, but the logic is what matters: allow-list flows, everything else denied.

# nftables-style conceptual policy (shape of rules, not vendor-specific)
# Goal: default deny inter-VLAN; allow only deliberate flows.

table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    # keep existing connections working
    ct state established,related accept

    # Users VLAN (192.168.20.0/24) to internet (WAN)
    iifname "vlan20-users" oifname "wan" accept

    # IoT VLAN to internet (optional; consider allow-listing destinations if supported)
    iifname "vlan30-iot" oifname "wan" accept

    # Guest VLAN to internet only
    iifname "vlan40-guest" oifname "wan" accept

    # Users to NAS (example: SMB and NFS)
    iifname "vlan20-users" ip daddr 192.168.20.10 tcp dport { 445, 2049 } accept

    # Users to Printer (example: RAW printing + IPP)
    iifname "vlan20-users" ip daddr 192.168.20.25 tcp dport { 9100, 631 } accept

    # Block IoT/Guest to Users/Mgmt (implicit by policy drop; explicit rules are OK too)
  }

  chain input {
    type filter hook input priority 0; policy drop;

    # allow router management only from mgmt VLAN
    iifname "vlan10-mgmt" tcp dport { 22, 80, 443 } accept

    # allow DHCP/DNS to the router from LAN VLANs (if the router provides these services)
    iifname { "vlan20-users", "vlan30-iot", "vlan40-guest" } udp dport { 53, 67 } accept

    # allow ICMP for debugging (optional)
    ip protocol icmp accept

    ct state established,related accept
  }
}

Step 6 — Test and iterate (don’t skip this)

Segmentation changes connectivity. The difference between “secure and usable” vs “everyone disables it” is how you test and tune.

Step 7 — Zero-trust “light” upgrades you can add later

Once the baseline is stable, you can improve without turning your network into a science project.

Common mistakes

Segmentation is conceptually simple, but a few recurring mistakes make it either ineffective or frustrating. Here are the ones that show up most often — plus how to fix them.

FAQ

Do I need VLANs for network segmentation on a small network?

Not strictly, but VLANs are the cleanest way to create multiple isolated zones on the same hardware. If your router/AP supports multiple SSIDs with separate networks and firewall rules, you can still segment effectively. The key requirement is policy control: the ability to restrict traffic between segments.

Is “Guest Wi-Fi” the same as segmentation?

No. Guest Wi-Fi is one segment for one purpose (visitors, untrusted devices). Segmentation is broader: separating management, users, and risky devices with explicit inter-zone rules. Guest Wi-Fi is a good component, not the whole design.

What’s the simplest “zero-trust” move I can make at home?

Put management interfaces (router/switch/AP/NAS admin) behind an Admin/Mgmt zone. Then require your admin device (or a VPN) to reach them. This prevents “any device on Wi-Fi can manage the network” outcomes.

Why doesn’t my phone see my TV/Chromecast after I segment IoT?

Because many devices use local discovery (mDNS/Bonjour/SSDP) that doesn’t cross VLAN boundaries. The secure fix is adding a controlled discovery mechanism (when your router supports it) or a targeted allow rule for the specific service, not flattening the network again.

Should IoT devices be allowed to access the internet?

It depends on the device and your risk tolerance. Many IoT devices require internet for updates and cloud control; others work locally. A strong baseline is: allow IoT internet access if needed, but block IoT access to Users/Mgmt, and consider restricting IoT to known destinations if your platform supports it.

Can I segment with an unmanaged switch?

You can do limited segmentation, but VLANs generally require a managed switch and a router that supports VLAN interfaces. Without that, your best options are separate physical networks (multiple routers) or a single router that provides multiple SSIDs/networks via Wi-Fi. If you want wired segmentation with VLANs, managed switching is usually necessary.

How many VLANs should I have?

Start with 3–4 and stop. A solid baseline is Mgmt + Users + IoT + Guest. Add more only when you have a clear reason (e.g., a separate lab environment, a server DMZ, or compliance needs).

Cheatsheet

Use this as a quick “am I segmented?” audit. If you can check most boxes, you’ve implemented practical network segmentation for humans.

Wrap-up

Network segmentation for humans isn’t about building an enterprise network at home. It’s about making your network safer by design: separate “risky stuff” from “important stuff”, and put a few sensible rules on the doors between them. VLANs are a practical way to do that, and zero-trust thinking helps you keep the rules minimal, explicit, and maintainable.

If you want to go further after the baseline is stable, the best upgrades are: VPN-based admin access, tighter allow-lists for IoT, better logging/monitoring, and endpoint hygiene (patching + MFA + passkeys). Segmentation is a foundation — not a replacement — for the rest of your security stack.

Related posts

• OWASP Top 10 in Real Life: How Apps Actually Get Hacked
• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• API Security Checklist: Auth, Rate Limits, and Abuse Cases
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can Burn Your App