pfSense Network Segmentation & Firewall Lab

Lab Overview

This lab documents building and testing an enterprise-style segmented network topology inside a virtualized hypervisor using pfSense Community Edition. The purpose is to study how stateful firewall inspection operates, configure isolated virtual LANs (VLANs), and observe traffic flow across zones.

Status Note: This lab is currently in progress. The network segmentation and basic routing rules are configured and operational; intrusion detection (Suricata package) and VPN configurations are planned for upcoming phases.

Network Architecture & Topography

               +--------------------------------------+
               |             WAN Uplink               |
               |       (Bridged to Home Router)       |
               +------------------+-------------------+
                                  |
                                  v
               +--------------------------------------+
               |          pfSense Router/FW           |
               |     WAN IP: 192.168.1.150 (DHCP)     |
               +-------+----------------------+-------+
                       |                      |
      VLAN 10 (LAN)    |                      | VLAN 20 (DMZ / Lab)
   192.168.10.1/24     |                      | 192.168.20.1/24
                       v                      v
        +----------------------+      +----------------------+
        | Internal Management  |      | Exposed Lab Services |
        | - Admin Workstation  |      | - Web Server (Nginx) |
        | - Analysis VM        |      | - Vulnerable Test VM |
        +----------------------+      +----------------------+

Subnet Allocation

Core Configuration Steps

1. VLAN Tagging & Virtual Switch Setup

• Configured 802.1Q VLAN trunking on the pfSense internal network interface within the hypervisor.
• Assigned vlan0.10 to the LAN interface and vlan0.20 to the DMZ_LAB interface.
• Enabled separate DHCP pools with static MAC reservations for known lab virtual machines.

2. Firewall Rule Matrix

To enforce strict boundary security, I followed the principle of least privilege:

• Rule 1 (Anti-Lockout): Allow TCP port 443 only from 192.168.10.10 (Admin Workstation) to pfSense WebGUI.
• Rule 2 (DMZ to LAN Block): Explicitly block and log all traffic originating from VLAN 20 (DMZ) destined for VLAN 10 (LAN):

  Action: Block & Log
  Interface: DMZ_LAB
  Protocol: IPv4 *
  Source: DMZ_LAB net
  Destination: LAN net
  

• Rule 3 (DMZ Outbound Internet): Allow HTTP/HTTPS out to the WAN from DMZ servers for software updates:

  Action: Pass
  Interface: DMZ_LAB
  Protocol: IPv4 TCP
  Source: DMZ_LAB net
  Port: 80, 443
  Destination: *
  

• Rule 4 (Default Deny): Implicit drop on all unmatched ingress packets.

3. Outbound NAT

Configured Hybrid Outbound NAT so traffic leaving the 192.168.20.0/24 subnet is translated to the pfSense WAN IP (192.168.1.150), while maintaining port address translation (PAT) tables.

Verification & Traffic Testing

To confirm the firewall rules worked as expected, I ran tests from both network zones:

$ ping -c 3 192.168.10.10
$ PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
$ ^C
$ --- 192.168.10.10 ping statistics ---
$ 3 packets transmitted, 0 received, 100% packet loss

Next, I checked the pfSense system log via CLI filter to verify the drop action:

$ clog /var/log/filter.log | grep 'block' | tail -n 2
$ filterlog: 4,,,1000000103,em1_vlan20,match,block,in,4,0x0,,64,0,0,DF,1,icmp,84,192.168.20.5,192.168.10.10

The packet was blocked by the boundary rule on em1_vlan20 before it could route into VLAN 10.

Real Challenges Encountered

1. Hypervisor Promiscuous Mode on Trunk Interfaces

• Problem: When configuring 802.1Q tags inside VirtualBox internal networks, tagged packets were initially dropped silently by the hypervisor's virtual switch.
• Fix: Enabled Promiscuous Mode (Allow All) on the internal virtual adapter settings for both pfSense and VM endpoints, allowing tagged Ethernet frames to reach the pfSense sub-interfaces.

2. State Table Persistence After Rule Updates

• Problem: When changing a rule from Pass to Block, existing active connections from the test web server continued to transmit packets for several seconds.
• Fix: Realized pfSense is a stateful firewall; modifying a rule does not instantly kill existing state entries. Learned to clear states manually in Diagnostics > States > Reset States during testing to verify immediate rule behavior.

Next Steps for This Lab

1. Install and tune the Suricata IDS/IPS package on the DMZ interface to inspect signature-based attacks.
2. Configure OpenVPN / WireGuard with certificate authentication to practice secure remote access into the management subnet.