Repository / Network and Security /Architecture Pattern /Pre-Zero-Trust: VPN and Zone-Based Enterprise Architecture

Pre-Zero-Trust: VPN and Zone-Based Enterprise Architecture

What This Architecture Represents

This is the architecture most enterprises are still running. It's not broken -- it's well-designed, compliant, and defensible. But it predates zero trust, and understanding its structure is the first step toward understanding what zero trust actually changes.

The model is built on three principles: network segmentation defines trust, the firewall is the primary enforcement point, and VPN extends the perimeter to remote users.

Security Zone Model

The architecture segments the network into eight security zones, each with a defined purpose and explicit communication rules enforced at the firewall.

Core Infrastructure

VLANs 1, 11, 15. Infrastructure management and administrative access. This is the highest trust zone -- switches, management interfaces, admin workstations. Internet access is restricted to admin-initiated updates only. No inbound access from any endpoint zone.

Virtualization Layer

VLANs 21, 22, 23. Hypervisor management, live migration, and storage replication traffic. Completely isolated from the internet. Only the core infrastructure zone has management access. This traffic never touches the firewall's external interfaces.

Identity and Access Management

VLANs 31, 32, 33, 34. Domain controllers, PKI, NAC, and SSO services. Internet access is routed through a security proxy for certificate revocation checks and directory sync. Every other zone depends on this one for authentication, which makes it both critical and a high-value target.

Security Services

VLANs 41, 42, 43, 44. SIEM, vulnerability scanning, monitoring, and surveillance. Direct internet access for threat intelligence feeds and signature updates. This zone has monitoring-level access to every other zone -- it can observe but not modify.

Server Infrastructure

VLAN 51. Application servers and business services. Internet access via proxy. Accepts service requests from endpoint devices and provides application-to-application communication within the zone.

Endpoint Devices

VLANs 111, 121, 131, 141. User workstations, printers, phones, and IoT devices -- each on a separate VLAN. Content-filtered internet access. Can reach servers for business applications and identity services for authentication. Cannot reach core infrastructure, virtualization, or security services directly.

Guest Networks

VLAN 161. Isolated guest access with direct internet but zero internal access. This zone cannot communicate with any other zone. Full isolation enforced at the firewall.

WAN / Internet

External gateway. The boundary between the enterprise and everything else. Inbound traffic is tightly controlled -- admin VPN only to core infrastructure, reverse proxy for published services, direct inbound only for security services pulling external feeds.

Communication Rules

Every inter-zone flow is explicitly defined. There is no implicit trust. If a rule doesn't exist, the traffic is dropped.

What Core Infrastructure Can Reach

| Target Zone | Access Level | |---|---| | Virtualization | Management only | | Identity | Management only | | Security | Management only | | Servers | Management only | | Endpoints | Administrative access | | Guests | None | | WAN | Restricted outbound |

What Endpoints Can Reach

| Target Zone | Access Level | |---|---| | Core Infrastructure | None | | Virtualization | None | | Identity | Authentication requests only | | Security | None | | Servers | Service requests only | | Other Endpoints | Limited | | Guests | None | | WAN | Content-filtered outbound |

What Guests Can Reach

| Target Zone | Access Level | |---|---| | Everything Internal | None | | WAN | Direct outbound |

This is the simplest rule in the architecture and the most important one to get right. Guests get internet. Nothing else.

Remote Access Model

Remote users connect via VPN. The VPN terminates on the firewall and places the user into a zone based on their authentication level and device posture. Once inside, they're subject to the same inter-zone rules as local devices.

This works. It's auditable, it's compliant, and assessors understand it. But it has a fundamental limitation: VPN grants zone-level access, not resource-level access. A user who authenticates to the VPN gets access to everything their zone permits, whether they need it or not.

Where This Model Works

This architecture meets compliance requirements across multiple frameworks:

  • NIST 800-171 -- Network segmentation satisfies boundary protection (SC-7), controlled communication (SC-7(5)), and access enforcement (AC-3)
  • CMMC Level 2 -- Zone isolation and explicit firewall rules demonstrate system and communications protection controls
  • PCI DSS -- Cardholder data environment can be isolated in its own VLAN with explicit rules
  • SOC 2 -- Segmentation and logging provide evidence for the security and availability trust principles

The architecture is defensible, documented, and assessors know how to evaluate it. For many organizations, this is sufficient.

Where This Model Breaks Down

Lateral Movement Within Zones

The firewall enforces rules between zones. Within a zone, devices can communicate freely. If an attacker compromises one server in VLAN 51, they can reach every other server in VLAN 51 without crossing the firewall. The firewall never sees it.

VPN Over-Entitlement

VPN places users into a zone. A finance analyst and a system administrator in the same zone get the same network access. The firewall can't distinguish between them at the application level without User-ID integration, and even then, policies are coarse.

Network Location as Identity

Trust decisions are based on which VLAN you're on, not who you are. A compromised device on a trusted VLAN is trusted. A legitimate user on the wrong VLAN is blocked. The model assumes network location correlates with trustworthiness, and that assumption is increasingly wrong.

Static Policies

Firewall rules are written by humans, reviewed periodically, and changed through a formal process. They don't adapt to behavior, risk signals, or real-time threat intelligence. A device that was clean this morning and is compromised this afternoon is still trusted until someone updates a rule.

Visibility Gaps

The firewall sees inter-zone traffic. It doesn't see intra-zone traffic, encrypted east-west flows (without SSL inspection), or host-level activity like process execution, memory manipulation, or credential theft. The architecture is blind to threats that don't cross a zone boundary.

What Comes Next

This architecture is the starting point, not the destination. Zero trust doesn't replace it wholesale -- it layers identity, continuous verification, and workload-level enforcement on top of the segmentation foundation that's already here.

The zones stay. The firewall stays. What changes is how trust decisions are made -- shifting from "what VLAN are you on" to "who are you, what's your device posture, and do you need this specific resource right now."

That transition is covered in the companion articles in this series.