Implementing Network Segmentation with pfSense VLANs and Inter-VLAN Routing

By /

Network segmentation is one of the most effective controls in a defense-in-depth security architecture. By dividing a flat network into isolated broadcast domains, organizations limit lateral movement, reduce the blast radius of a compromise, and gain granular visibility into east-west traffic. pfSense, the open-source firewall distribution built on FreeBSD, provides a mature, production-grade platform for VLAN-based segmentation with full inter-VLAN routing control.

Why VLANs Over Physical Segmentation

Physical segmentation — dedicated switches and cabling for each network zone — is the gold standard but rarely practical. VLANs (IEEE 802.1Q) deliver the same isolation at a fraction of the cost. A single trunk port carrying tagged frames for a dozen VLANs replaces a rack of individual switches. More importantly, VLANs integrate natively with pfSense’s firewall engine, so every inter-VLAN packet traverses a stateful inspection checkpoint.

The tradeoff is that a misconfigured trunk port or an unpatched VLAN-hopping vulnerability can undermine segmentation. The mitigations are straightforward: disable unused ports, enforce native VLAN tagging on trunks, and keep switch firmware current.

VLAN Design Principles

Before touching a single interface, map your logical zones to VLAN IDs and subnets:

  • Management (VLAN 10, 10.0.10.0/24) — BMC/IPMI interfaces, switches, hypervisors. Tightly restricted; no user workstations.
  • Servers (VLAN 20, 10.0.20.0/24) — Production application servers. Inbound from LAN/DMZ as needed; no outbound to user segments.
  • User Workstations (VLAN 30, 10.0.30.0/24) — Standard desktops. Internet access permitted; direct server access blocked except specific approved ports.
  • DMZ (VLAN 40, 10.0.40.0/24) — Public-facing services. Internet-reachable; no initiated connections to internal VLANs.
  • IoT/OT (VLAN 50, 10.0.50.0/24) — Cameras, printers, HVAC controllers. Isolated from all other segments; internet access denied.
  • Guest WiFi (VLAN 60, 10.0.60.0/24) — Visitor devices. Internet only; no LAN access.

Keep VLAN IDs and subnet third octets aligned — it eliminates mental mapping errors during incident response at 02:00.

Switch Configuration: Trunk and Access Ports

On a managed switch (Cisco IOS syntax shown; adapt for your platform), configure the uplink to pfSense as a trunk:

interface GigabitEthernet0/1
 description TRUNK-TO-PFSENSE
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,40,50,60
 switchport trunk native vlan 999
 spanning-tree portfast trunk
 no shutdown

VLAN 999 is an unused “black hole” native VLAN — never assign hosts to it. This prevents double-tagging attacks. Access ports for end devices:

interface GigabitEthernet0/10
 description WORKSTATION-PORT
 switchport mode access
 switchport access vlan 30
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
 no shutdown

BPDU guard prevents rogue switches from injecting spanning-tree topology changes. Enable it on every access port.

pfSense Interface Assignment

Log into pfSense, navigate to Interfaces > Assignments > VLANs, and create a VLAN interface for each segment. The parent interface is your physical trunk port (typically igb0 or em0). Assign the VLAN tag and an optional description.

After creating all VLAN sub-interfaces, navigate to Interfaces > Assignments and add each VLAN as a new interface. Assign logical names (OPT1 to MGMT, OPT2 to SERVERS, etc.) and configure each with a static IPv4 address matching the gateway for that subnet.

DHCP Per VLAN

Navigate to Services > DHCP Server and configure a pool for each interface:

MGMT:      Range 10.0.10.100-10.0.10.200, DNS 10.0.10.1
SERVERS:   Range 10.0.20.100-10.0.20.200, DNS 10.0.20.1
WORKSTAT:  Range 10.0.30.100-10.0.30.254, DNS 10.0.30.1
DMZ:       Range 10.0.40.100-10.0.40.200, DNS 10.0.40.1
IOT:       Range 10.0.50.100-10.0.50.200, DNS 10.0.50.1
GUEST:     Range 10.0.60.100-10.0.60.254, DNS 1.1.1.1

For IoT and Guest VLANs, avoid pointing DHCP at your internal recursive resolver — these segments should not learn internal hostnames.

Firewall Rules Between VLANs

pfSense’s default inter-VLAN posture: without rules on an interface, traffic is blocked. The recommended approach is default deny with explicit allow. Navigate to Firewall > Rules and configure per-interface policies. Example for the SERVERS interface:

Rule 1: Pass  | SERVERS net to any        | TCP | 443  | HTTPS egress for updates
Rule 2: Pass  | SERVERS net to MGMT net   | TCP | 514  | Syslog to SIEM
Rule 3: Block | SERVERS net to any        | *   | *    | Default deny (logged)

For WORKSTATIONS:

Rule 1: Pass  | WORKSTAT net to SERVERS net | TCP | 443,8443 | App access
Rule 2: Pass  | WORKSTAT net to any         | TCP | 80,443   | Internet browsing
Rule 3: Block | WORKSTAT net to MGMT net    | *   | *        | No mgmt access
Rule 4: Block | WORKSTAT net to any         | *   | *        | Default deny

The Management VLAN should have the most restrictive rules. Only specific administrative workstation IPs should reach MGMT, and only over SSH or HTTPS.

Floating Rules and Aliases

Duplicate firewall rules across VLANs become a maintenance burden. Use Firewall > Aliases to group hosts and ports, then reference the aliases in rules. Floating rules — evaluated before interface rules — enforce organization-wide policies in a single place. For example, a single floating rule can block all RFC 1918 traffic from the DMZ rather than replicating that rule on every interface.

Monitoring Inter-VLAN Traffic

pfSense exposes several built-in visibility tools:

  • Status > Traffic Graph: Real-time per-interface bandwidth
  • Diagnostics > Packet Capture: tcpdump on any interface, filterable by host and port
  • Firewall > Firewall Logs: Every blocked packet logged with full five-tuple
  • ntopng: Install via System > Package Manager for deep flow analysis and protocol breakdown

For production environments, export firewall logs to a SIEM via syslog. Create detection rules that alert on unexpected inter-VLAN flows — a workstation initiating connections to the management subnet is a high-fidelity lateral movement indicator.

Testing Segmentation

After deployment, validate rules from representative hosts on each VLAN. From a workstation on VLAN 30, the server HTTPS port should be reachable while SSH to the management VLAN should time out. From the IoT VLAN, all outbound connections except DHCP and permitted DNS should drop. Automate these checks with a simple connectivity matrix script and run it after every firewall change.

Common Pitfalls

  • Anti-lockout omission: Always keep an explicit allow for your admin workstation to reach pfSense’s management IP before applying any default-deny floating rule.
  • Asymmetric routing: If multiple uplinks or internal routers exist, ensure reply traffic returns via the same path — pfSense’s stateful engine drops out-of-state packets.
  • Native VLAN mismatch: If the trunk native VLAN on the switch differs from pfSense’s expectation, untagged frames land on the wrong interface. Explicitly tag everything.
  • Broadcast storms: A misconfigured loop between trunk ports saturates all VLANs simultaneously. Enable STP and BPDU guard on all access ports without exception.

Conclusion

A well-designed VLAN architecture with pfSense inter-VLAN routing transforms a flat, vulnerable network into a segmented environment where an attacker who compromises a single host faces real barriers to lateral movement. The investment is modest — primarily planning time and switch configuration — but the security return is substantial. Combine this with centralized log aggregation and you gain the visibility to detect when segmentation is being probed or bypassed.

Scroll to Top