Network Segmentation Done Right: VLANs, Firewalls and Zero-Trust Inside the LAN

A flat network is a breached network. Once an attacker — or a misbehaving IoT device — is on the LAN, the only thing standing between them and the file server is hope. This article is the comprehensive segmentation playbook: VLAN design, firewall policy, identity-aware access, and the Zero-Trust patterns that make troubleshooting tractable instead of a PhD thesis.

Companion to our budget Zero-Trust piece (which is "how to get 80% of the value for €5k") and the multi-tenant office VLAN piece (which is shared-office-specific). This article is the canonical office segmentation playbook for the 100-500 seat single-tenant company.

The flat-network failure mode

In a flat network, every device can reach every other device. The actual list:

• The receptionist's laptop can ssh to the production database
• The smart TV in the conference room can mDNS-discover every printer + NAS
• The contractor's laptop authenticates to the network and can map the entire LAN with nmap in 90 seconds
• The badge reader at the entrance can talk to your hypervisor management interface
• A ransomware infection on a single laptop has lateral movement to every endpoint, every share, every server

The fix is segmentation. The principle is least-privilege at the network layer: by default, segments cannot reach each other. Specific allow rules enable the business. The radius of impact from any single compromise shrinks dramatically.

The segmentation hierarchy

Four levels of segmentation, increasing in granularity:

1. Zone segmentation. Broad categories of network purpose (User, Server, Voice, IoT, Guest). Implemented via VLANs + L3 firewall.
2. Microsegmentation. Workload-level isolation within a zone. Implemented via host firewalls + identity-aware policy.
3. Identity-aware segmentation. Access decisions based on who the user is + what device they have. Implemented via ZTNA + Conditional Access.
4. Application-aware segmentation. Allow/deny based on the specific application being used. Implemented via NGFW + per-app policy.

Most SMBs benefit most from levels 1 + 3. Level 2 matters for high-value workloads. Level 4 matters in regulated environments. Build in order.

Layer 01: VLAN zone design

The numbering convention that scales:

Default policy on inter-VLAN routing: deny all. Specific allow rules enable the business. The allow list is small, named, and reviewed quarterly.

The allow-list rules

Layer 02: The firewall policy, as code

The policy lives in version control. Changes go through PR review. The firewall config is generated, not hand-written. The pattern that works for OPNsense / pfSense / Sophos:

# segmentation/policy.yaml
policies:
  - name: user-to-app
    source: vlan-20-user
    destinations:
      - host: app-server-1
        ports: [443]
      - host: app-server-2
        ports: [443]
      - host: gitlab.internal
        ports: [443, 22]
    log: true
    review_date: 2026-08-15

  - name: voice
    source: vlan-30-voice
    destinations:
      - host: voice-gateway
        ports: [5060, 5061]   # SIP
        protocols: [udp, tcp]
      - cidr: 0.0.0.0/0
        ports: [10000-20000]   # RTP media
        protocols: [udp]
    log: false
    review_date: 2026-07-30

  - name: iot-vendor-cloud
    source: vlan-60-iot
    destinations:
      - host: vendor-cloud.example.com
        ports: [443]
    log: true
    review_date: 2026-06-15

# Default policy: deny + log
default:
  action: deny
  log: true

Each rule has a name, a review date, and explicit logging. The review date is enforced by tooling: rules expire from the active policy if not reviewed. The default-deny + log is the floor.

Layer 03: Identity-aware access (ZTNA)

VLAN segmentation handles network-layer trust. ZTNA handles application-layer trust. The combination is what produces real Zero-Trust outcomes.

The pattern: even users on the User VLAN do not directly reach internal applications. Internal applications are reachable only via the ZTNA layer, which evaluates:

• User identity (verified via SSO with MFA)
• Device identity (compliant device per Intune / Jamf)
• Device posture (encryption, EDR healthy, OS patched)
• Context (location, time-of-day, sign-in risk)

A user can be sitting at their desk on the User VLAN and still be denied access to a specific internal app because their device is non-compliant or their sign-in is from an unfamiliar location.

The ZTNA stack we deploy

• Identity provider: Entra ID or Okta. Source of truth for user identity + group membership.
• ZTNA layer: Tailscale (mesh, free under 100 users), Cloudflare Zero Trust (managed), or Twingate (managed). Pick by ops fit.
• Device compliance: Intune (Microsoft estates), Jamf (Apple-heavy), Kandji (Apple SMB).
• Conditional Access policies: Entra Conditional Access or equivalent. The decision engine.

Layer 04: Host-level microsegmentation

For high-value workloads, the host firewall is the last line. The Linux nftables / Windows Defender Firewall / macOS pf rules that produce real isolation:

# /etc/nftables/db-server.nft
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    ct state invalid drop

    # SSH only from bastion
    ip saddr 10.10.0.5/32 tcp dport 22 accept

    # Postgres only from the application VLAN's specific servers
    ip saddr { 10.40.0.10, 10.40.0.11, 10.40.0.12 } tcp dport 5432 accept

    # Prometheus scrape
    ip saddr 10.10.0.20/32 tcp dport 9100 accept

    # Block everything else, log first 10/min for forensics
    limit rate 10/minute counter log prefix "fw-drop: "
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }
}

Even if an attacker compromises the application server and tries to scan the database server, the host firewall on the database refuses connections from any IP except the explicit allow-list. Network-layer compromise does not translate to host-layer access.

The routing topology that scales

Three patterns for inter-VLAN routing, ranked by isolation strength:

Pattern A: Firewall-routed

All inter-VLAN traffic routes through the firewall. The firewall enforces policy on every hop. The bottleneck: firewall throughput on internal traffic.

Works for: most SMB scales. Modern firewalls handle 1-10 Gbps inspected throughput.

Pattern B: L3 switch with ACLs

Inter-VLAN routing on the core switch with stateless ACLs. Faster than firewall-routed but stateless (cannot track sessions, harder to manage).

Works for: very high-throughput deployments where the firewall would bottleneck.

Pattern C: L3 switch + VRF-per-zone

Each zone in its own VRF on the core switch. Inter-VRF routing is impossible without explicit policy. The strongest isolation; requires VRF-capable switching.

Works for: regulated environments + multi-tenant scenarios where hard isolation matters.

Our default for 100-500 seat single-tenant SMB: Pattern A (firewall-routed). Pattern C for regulated environments.

The DHCP + DNS plane (where leakage actually happens)

VLAN isolation is necessary but not sufficient. The DHCP and DNS planes need explicit design.

DHCP scoping

• One DHCP scope per VLAN. No spanning.
• DHCP snooping enabled on every access switch with trusted-port list explicit (uplink trunks only)
• ARP inspection enabled to prevent ARP spoofing
• IP source guard enforced (devices cannot use IPs they were not assigned)

DNS isolation

• Internal DNS resolver per zone where regulation requires isolation
• Conditional forwarders for cross-zone resolution where business requires it (always logged)
• mDNS / SSDP / UPnP blocked at VLAN boundaries by default
• External DNS queries (where allowed) go to a controlled resolver (Cloudflare 1.1.1.1, Quad9, or internal recursive)

The cross-VLAN service discovery question

"How does the conference room TV cast from a laptop on a different VLAN?" Cross-VLAN multicast / SSDP / mDNS is the recurring frustration. The patterns:

• mDNS reflector / Bonjour Gateway on the firewall — relays specific multicast groups across selected VLANs
• Dedicated cast SSID bridged into the conference-room VLAN where the TV lives
• Application-layer cast services (Airtame, ScreenBeam Enterprise) that work over normal IP and do not require cross-VLAN multicast

The troubleshooting that does not become a PhD thesis

Segmentation done badly produces network problems that take hours to diagnose. Segmentation done well includes diagnostic affordances:

Logging discipline

• Every firewall rule logs denied flows (sampled to avoid log volume explosion)
• Logs ship to Loki / Grafana for searchable history
• "Why is host X unable to reach host Y" becomes a Grafana query, not a tcpdump session

Documentation discipline

• The allow-list is in human-readable form (the YAML above), not just rule numbers
• Every rule has a "why" comment
• The deny-by-default policy has examples of what each VLAN can / cannot reach in plain English

Test-the-policy discipline

• A test harness validates: "VLAN 20 can reach app-server-1 on 443" → should pass
• "VLAN 20 can reach database directly on 5432" → should fail
• "VLAN 60 (IoT) can reach VLAN 40 (Server)" → should fail
• Test harness runs in CI before any policy change deploys

The rollout sequence for an existing flat network

Weeks 1-3: Discovery + design

• Map the existing traffic flows (passive monitoring via NetFlow / sFlow)
• Identify what talks to what (the inventory work that drives the allow-list)
• Design VLAN scheme + initial allow-list
• Procure / provision new firewall + switches if needed

Weeks 4-6: Foundation

• Deploy new firewall + core switch (or reconfigure existing)
• Create VLANs in "monitor" mode (allow all, log everything)
• Migrate devices into VLANs progressively without enforcement
• Capture lessons from the monitor-mode flow data

Weeks 7-9: Enforcement

• Flip policy from "allow + log" to "deny + log" on the inter-VLAN paths
• Watch for legitimate flows the inventory missed; add allow rules
• Roll out by zone: IoT → Guest → Voice → Server → User
• The User zone is last because user disruption is the most visible

Weeks 10+: Operate

• Quarterly policy review with named owners
• Monthly drift check: any new flow allowed in audit mode that has not been formalised as a rule?
• Annual external review (penetration test or red-team exercise) validates the segmentation under adversarial conditions

The compliance evidence mapping

The segmentation maps directly to:

The auditor expects: documented design + evidence of implementation + evidence of operation (logs showing policy in effect) + evidence of review (quarterly policy reviews with documented outputs). The stack above produces all four as a side effect of operation.

The patterns that go wrong

1. The "we'll add segmentation later" trap. Adding segmentation to a running flat network is harder than building it from day one. Cost is real but smaller than the breach it prevents.
2. The "one big VLAN per floor" anti-pattern. Floor-based segmentation does not match the threat model. Purpose-based segmentation does.
3. The "we have a firewall so we're segmented" misconception. Edge firewall ≠ internal segmentation. The threat model is post-compromise lateral movement; the edge firewall does not help.
4. The "every server gets its own VLAN" overcorrection. Hundreds of VLANs become unmaintainable. Group servers by trust level + purpose into a handful of zones; use host firewalls for finer-grained policy within a zone.
5. The "allow-rule sprawl over 18 months" entropy. Without quarterly review, the allow-list grows monotonically. The review cadence is mandatory operational discipline.

Real outcomes from a recent rollout

A 260-seat consultancy with a flat 10.0.0.0/16 network. Six-week rollout. Post-deployment metrics:

• Active VLANs: 9 (was: 1)
• Inter-VLAN allow rules: 47 (most are minor variations of "User → specific app on 443")
• Connection-attempt drops per day: 8,000-15,000 (mostly legitimate broadcasts + scans)
• Real lateral-movement attempts caught in first 6 months: 2 (both contained at VLAN boundary)
• Engineer hours spent on segmentation troubleshooting per month: 4-7 hours (down from "ad-hoc unscheduled" pre-segmentation)
• ISO 27001 audit: zero segmentation-related findings on the subsequent audit

The one paragraph version

A flat network is one ransomware infection away from the file server. Segmentation done right uses purpose-based zones (User / Voice / Server / Printer / IoT / Guest + Management + Quarantine), firewall-routed inter-VLAN traffic with default-deny + explicit named allow rules, host-level firewalls on high-value workloads, ZTNA overlay for application-layer trust, and the DHCP / DNS plane explicitly designed alongside the L3 layer. The allow-list lives in version control with named owners + review dates. Quarterly policy review is mandatory operational discipline. Compliance evidence (ISO 27001 / NIS2 / DORA / PCI-DSS) is a side effect of operation, not a separate project. 6-10 weeks to roll out for a 200-seat company; pays for itself on the first contained incident.

If you want the segmentation designed + rolled out + handed over with the operational cadence in place, that is the engagement shape. We deliver this as part of Microsoft 365 Defender + Azure Cloud Infrastructure engagements. The lighter-touch budget variant is in our budget Zero-Trust article; the shared-office variant is in our multi-tenant VLAN article.