Network Topology — Enterprise Infrastructure Lab

Goal

Five-VLAN segmented lab network built around pfSense, Suricata, and Cisco switching to practice enterprise segmentation, firewall-policy, and IDS/IPS patterns.

1. Overview

The lab network is a segmented, five-VLAN topology built around a single perimeter firewall, a managed access/trunk switch, and a virtualization host. It exists to practice the same segmentation, firewall-policy, and IDS/IPS patterns used in enterprise networks — trust-tiered VLANs, default-deny inter-VLAN routing, and centralized detection — at a scale a single rack can support.

Core components:

2. Topology Diagram

pfSense is the sole Layer 3 gateway (router-on-a-stick): it holds one sub-interface per VLAN over a single trunked link to the 3750X, and every inter-VLAN packet — including VLAN-to-VLAN traffic that never leaves the switch physically — is routed through and inspected by the firewall by disabling local inter-VLAN switching at Layer 2 and forcing routing decisions to pfSense. The 3750X trunks the same VLAN set to the Proxmox host, where a VLAN-aware bridge (vmbr0 with VLAN awareness enabled) tags traffic per VM NIC so a single physical trunk can back all five segments without one vNIC per VLAN per VM.

3. VLAN / IP Address Table

4. Traffic-Flow Matrix

Default policy on every pfSense interface is deny all; the rules below are the explicit allows layered on top. Because pfSense is a stateful firewall, only the rule permitting the initiating direction is listed — return traffic for an established connection is permitted automatically and does not need a mirrored rule.

5. Security Rationale

• Default-deny, explicit-allow. Every VLAN pair is closed by default; the matrix above is the complete allow-list. This keeps the effective attack surface equal to documented, intentional traffic rather than "whatever wasn't explicitly blocked."
• Trust-tiered segmentation. VLANs map to trust level, not just function: Management (highest trust, broadest reach) → Servers/Workloads (mutual, protocol-scoped trust for AD operations) → Security (read/monitor-only, minimal egress) → DMZ (lowest trust, fully isolated from internal segments in both directions).
• DMZ isolation is bidirectional. The DMZ can reach the internet but nothing internal, and nothing internal can reach into the DMZ except a narrow Management path. A compromised DMZ host has no path back into Servers, Workloads, or Security — containing blast radius is the point of a DMZ, not just its outbound restriction.
• Router-on-a-stick keeps all inter-VLAN traffic firewall-visible. Because the 3750X does not route between VLANs itself, there is no path between segments that bypasses pfSense's rule evaluation and Suricata's inspection.
• Suricata deployment is asymmetric by design. WAN- and DMZ-facing interfaces run Suricata inline (IPS mode, actively blocking matched signatures) since that boundary faces the least-trusted traffic. Internal interfaces (Management, Servers, Workloads, Security) run Suricata in IDS/alert-only mode. This is a deliberate availability trade-off for a lab: inline IPS on internal segments risks false-positive-driven outages of legitimate AD/admin traffic, which isn't an acceptable risk to accept without a longer signature-tuning period than this lab has had.
• Explicit logged deny (cleanup) rule. Rather than relying solely on pfSense's implicit default-deny, an explicit, logged deny rule sits at the bottom of each interface ruleset so blocked attempts are visible in the firewall log for troubleshooting and detection, not just silently dropped.

6. Validation

• Confirmed 802.1Q tagging end-to-end: verified the 3750X trunk's allowed-VLAN list (show interfaces trunk), confirmed the Proxmox VLAN-aware bridge presents the correct tag per VM NIC, and confirmed each pfSense VLAN sub-interface (parent.<VLAN ID>) received its expected gateway address.
• Verified inter-VLAN isolation empirically: from a Workloads test host, confirmed ping/nmap against Security and DMZ address ranges failed by default, then confirmed the specific AD-service ports (DNS/Kerberos/LDAP/SMB) to Servers succeeded only after the corresponding allow rules were added — with the intermediate denies visible in the pfSense firewall log.
• Verified statefulness: confirmed a single allow rule (e.g., Management → Servers RDP) permits the full two-way session by inspecting the pfSense state table, with no separate reverse-direction rule required.
• Verified Suricata alerting using known, benign test signatures (ET "test" rule category and a controlled port scan against a monitored interface) and confirmed matching alerts appeared in the Suricata alert log.
• Verified the DMZ's inbound isolation by attempting connections from Servers and Workloads test hosts toward the DMZ subnet and confirming all were blocked.

7. Limitations

• Single points of failure. One pfSense instance (no CARP/HA pair) and one Cisco 3750X (no redundant switch or uplink) — a hardware or software fault on either takes the whole lab network down. This is an accepted lab trade-off, not a production-viable design.
• Suricata is lab-scale, not production-tuned. The ruleset (a subset of ET Open) has not been tuned against sustained production-level traffic volume or a real threat feed; false-positive/false-negative rates have not been formally measured.
• DMZ has no real external exposure. The DMZ segment is not reachable from the public internet in this lab, so validation demonstrates internal segmentation and containment, not perimeter defense against live external attackers.
• No periodic rule audit process. The traffic-flow matrix reflects the intended design at time of writing; there is no recurring review process to catch rule drift the way a change-management process would in a managed environment.
• No formal capacity/throughput testing. VLAN and firewall behavior has been validated functionally (does traffic pass or get blocked as designed), not load-tested under realistic bandwidth or connection-count pressure.