Zero Trust Network Segmentation with VLANs and Firewall Policies

By /

Zero Trust Network Segmentation with VLANs and Firewall Policies

The perimeter-based security model — the idea that everything inside your network is trusted — has been dead for years. Breaches increasingly originate from lateral movement after an initial foothold: a compromised endpoint, a phished credential, a misconfigured service. Zero Trust flips the assumption: no host, user, or service is implicitly trusted based on network location. Trust is earned continuously, scoped narrowly, and verified at every hop.

This article covers the practical mechanics of implementing Zero Trust network segmentation using VLANs, stateful firewall policies, identity-aware proxies, and monitoring integration. All examples use sanitized addressing (10.0.x.x, example-corp.com) and generic hostnames.

The Foundation: Why VLANs Alone Are Not Enough

VLANs provide Layer 2 isolation — they prevent broadcast domain overlap and stop ARP-based attacks between segments. But VLAN segmentation without firewall policy enforcement is theater. A misconfigured trunk port, an 802.1Q-tagged packet, or a dual-homed host can bridge segments silently.

True segmentation requires both:

  • Layer 2 isolation via VLANs with properly configured trunk and access ports
  • Layer 3-7 enforcement via stateful firewall rules that implement default-deny between zones

The firewall is not an add-on — it is the primary control plane. VLANs are the scaffolding.

VLAN Topology Design

A production Zero Trust topology separates hosts by function, sensitivity, and trust level. A reasonable baseline for a mid-size organization:

  • VLAN 10 — Management (10.0.10.0/24): Network devices, bastion hosts, out-of-band access. Strictly controlled inbound, no general user access.
  • VLAN 20 — Servers / DMZ (10.0.20.0/24): Web-facing services, API endpoints, load balancers. Internet-reachable services live here.
  • VLAN 30 — Internal Services (10.0.30.0/24): Databases, message queues, internal APIs. Reachable only from specific sources — never from the internet.
  • VLAN 40 — Workstations (10.0.40.0/24): End-user devices. Can initiate outbound connections to Internal Services only through defined proxies or identity-aware gateways.
  • VLAN 50 — IoT / OT (10.0.50.0/24): Cameras, sensors, embedded systems. Highly restricted — no outbound internet, no lateral reach.
  • VLAN 60 — Guest / Untrusted (10.0.60.0/24): Isolated internet-only access. No visibility into internal RFC1918 space.

Switch port assignment enforces physical placement. A host cannot change its VLAN assignment by reconfiguring its NIC — the switch access port locks it. Trunk ports between switches carry all VLANs but require 802.1Q tagging, limiting which VLANs pass through each uplink.

Firewall Policy: Default Deny as the Starting Point

The firewall ruleset between VLANs should begin with a terminal deny-all rule and build upward with explicit permits. This is the inverse of the historically common “permit everything, deny specific bad things” approach.

A pfSense inter-VLAN policy skeleton using the floating rules or interface-specific rulesets:

# Interface: VLAN40_WORKSTATIONS (10.0.40.0/24)

# Rule 1: Allow DNS to internal resolver only
pass in on VLAN40 proto udp from VLAN40:network to 10.0.10.5 port 53

# Rule 2: Allow HTTPS to Internal Services via identity proxy
pass in on VLAN40 proto tcp from VLAN40:network to 10.0.20.100 port 443

# Rule 3: Allow outbound internet (HTTP/HTTPS) through proxy
pass in on VLAN40 proto tcp from VLAN40:network to any port { 80 443 }

# Rule 4: Block all lateral movement — workstations cannot reach other workstations
block in on VLAN40 from VLAN40:network to VLAN40:network

# Rule 5: Block all access to Management VLAN
block in on VLAN40 from VLAN40:network to 10.0.10.0/24

# Default: implicit deny (pfSense behavior — explicit block logs it)
block in log on VLAN40 all

Key principles for every zone policy:

  • Workstations never initiate connections to other workstations (no lateral reach)
  • No zone has unrestricted access to the Management VLAN
  • Database servers (VLAN 30) accept connections only from application servers (VLAN 20) on specific ports
  • Guest VLAN has no RFC1918 routing — it is internet-only

Identity-Aware Proxies and Microsegmentation

VLANs and firewall rules segment by IP address. Identity-aware access adds a second dimension: who is making the request, not just where it comes from. This is the core of Zero Trust: network location is a weak signal; authenticated identity is a strong one.

An identity-aware proxy sits in the data path and enforces policy based on:

  • Authenticated user identity (from an OIDC provider or internal CA-signed mTLS cert)
  • Device posture (is the device managed, patched, running EDR?)
  • Request context (time of day, geolocation, sensitivity of the target resource)

A practical open-source stack for this pattern:

  • Authentik or Keycloak as the OIDC identity provider
  • Traefik with ForwardAuth middleware or Envoy with ext_authz as the proxy enforcing identity checks
  • mTLS for service-to-service authentication (each service holds a client certificate issued by the internal CA)

Example Traefik ForwardAuth middleware pointing to Authentik:

# traefik/dynamic/middlewares.yml
http:
  middlewares:
    authentik-auth:
      forwardAuth:
        address: "https://login.example-corp.com/outpost.goauthentik.io/auth/traefik"
        trustForwardHeader: true
        authResponseHeaders:
          - X-authentik-username
          - X-authentik-groups
          - X-authentik-email
          - X-authentik-uid

Any route tagged with this middleware requires a valid Authentik session. Unauthenticated requests are redirected to the IdP login flow. The application backend receives the identity headers and can make fine-grained authorization decisions without reimplementing authentication.

Service-to-Service: mTLS and Short-Lived Credentials

For internal service communication, password-based authentication or static API keys are inadequate. Mutual TLS (mTLS) provides cryptographic identity: both the client and server present certificates, and the connection is rejected if either fails validation.

Setting up an internal CA with step-ca for service certificates:

# Bootstrap the CA on ca.example-corp.com
step ca init \
  --name "Example Corp Internal CA" \
  --dns "ca.example-corp.com" \
  --address ":9000" \
  --provisioner "acme"

# Issue a certificate for a service
step ca certificate \
  "svc-api.internal.example-corp.com" \
  svc-api.crt svc-api.key \
  --ca-url https://ca.example-corp.com \
  --root /etc/step/ca/root_ca.crt \
  --not-after 24h

Short-lived certificates (24h or less) eliminate the revocation problem. A compromised certificate expires quickly without requiring CRL distribution or OCSP infrastructure. Automate renewal with a systemd timer or the step-ca ACME client.

Firewall Logging and IDS Integration

Segmentation without visibility is incomplete. Every deny action at the firewall boundary is a signal. Aggregated, these signals reveal reconnaissance patterns, lateral movement attempts, and misconfigured applications before they escalate.

pfSense firewall log export to a SIEM via syslog:

# pfSense: Status > System Logs > Settings
# Remote log server: siem01.management.example-corp.com:514
# Log format: RFC 5424
# Events to log: Firewall events, DHCP events

# On the SIEM (Wazuh/rsyslog receiving end):
# /etc/rsyslog.d/pfsense.conf
module(load="imudp")
input(type="imudp" port="514")
if $fromhost-ip == '10.0.10.1' then {
    action(type="omfile" file="/var/log/pfsense/firewall.log")
    stop
}

Useful detection rules to build from firewall logs:

  • Any host in VLAN 40 (workstations) attempting to reach VLAN 30 (databases) directly — should never happen under correct policy
  • Port scans: a single source IP generating deny events on 10+ distinct destination ports within 60 seconds
  • New outbound connections from server VLANs to internet IPs on non-standard ports — possible C2 beaconing
  • DHCP exhaustion on any VLAN — potential rogue device flood

Common Pitfalls and How to Avoid Them

Forgetting the Return Path

Stateful firewalls automatically permit return traffic for established sessions. However, if you have asymmetric routing — where the outbound and return paths traverse different firewalls — state tables get confused and connections silently drop. Always design symmetric routing at the start, and test with tcpdump on both sides of the firewall when connections fail unexpectedly.

VoIP and Real-Time Applications

SIP and RTP use dynamic port ranges negotiated in the signaling layer. Standard stateful firewall rules that inspect only headers will block RTP media streams. Use a SIP ALG (Application Layer Gateway) or a dedicated SIP proxy in your DMZ to handle the port negotiation properly.

Over-Relying on VLANs for Multi-Tenant Isolation

VLANs offer up to 4094 segments (12-bit VLAN ID space). For cloud-native or multi-tenant deployments with thousands of tenants, use VXLAN (24-bit VNI space, ~16 million segments) or overlay networks managed by SDN controllers. Do not attempt to use VLANs for tenant isolation at scale.

Leaving Management Interfaces Reachable from Production

Switch management interfaces, IPMI/iDRAC, and hypervisor management consoles should exist exclusively on the Management VLAN with no reachability from production server or workstation VLANs. Compromise of a single server should never provide a path to the management plane.

Validation: Testing Your Segmentation

Configuration is not correctness. Validate your segmentation with systematic testing:

# From a workstation (VLAN 40) — confirm database port is blocked
nc -zv 10.0.30.10 5432
# Expected: Connection refused or timeout

# From an application server (VLAN 20) — confirm database port is reachable
nc -zv 10.0.30.10 5432
# Expected: Connection succeeded

# Verify no workstation-to-workstation lateral reach
# From 10.0.40.50, attempt to reach 10.0.40.51:
ping -c 3 10.0.40.51
# Expected: 100% packet loss (blocked at firewall)

Automate this as a periodic audit script run from a dedicated test host in each VLAN. Failures in the expected-blocked direction are security incidents. Failures in the expected-allowed direction are availability incidents. Both matter.

Conclusion

Zero Trust network segmentation is not a product you buy — it is an architecture you build and continuously validate. VLANs establish the boundaries. Firewall policy enforces them with default-deny semantics. Identity-aware proxies elevate trust decisions from “where is this request coming from” to “who is making this request and are they authorized right now.” Logging and IDS integration turn the boundary controls into an early warning system.

The payoff is resilience against lateral movement. When an attacker compromises a workstation, they should find themselves in a carefully bounded segment with no path to databases, management interfaces, or other workstations. That containment buys time for detection and response — and often stops an incident from becoming a breach.

Scroll to Top