pfSense Firewall Secure Architecture

This started as a school project and turned into something I kept building long after the course ended. I wanted to understand what a real perimeter actually looks like — not just read about it. So I built one in VirtualBox: pfSense as the firewall, three isolated VLANs, a working VPN, and Suricata running in a mode where it can actually drop packets, not just complain about them.

The three-segment design (LAN for trusted clients, OPT1 as a DMZ-style server network, OPT2 as the isolated attacker network) wasn't chosen randomly — it mirrors what you'd see in an actual enterprise: a trusted zone, a service zone that needs limited access to production, and a segment you assume might be compromised. Everything between them is default-deny unless I explicitly wrote a rule for it.

Once the segmentation was solid, I layered in VPN (OpenVPN with certificate auth, not shared keys — more setup, but stolen credentials alone can't get you in) and then ran attack traffic from OPT2 to see what Suricata would catch. The alerts forwarded into my Splunk instance. That's when it clicked: a firewall log and an IDS alert on the same event tell a much more complete story than either one alone.

The interface assignments table below reflects the actual VirtualBox setup: four virtual NICs, each bound to a separate internal network adapter. Getting pfSense to recognize all four adapters on first boot took more troubleshooting than expected — the adapter ordering in VirtualBox doesn't always match what pfSense presents during interface assignment. The Suricata alerts at the bottom are from a live exercise, not synthetic data.

The decision to use three segments instead of two came from thinking about what I actually wanted to test. LAN is where you'd put workstations in a real environment. OPT1 is where servers live — things that need limited, specific access to LAN services (like a Splunk indexer) but shouldn't be able to roam freely. OPT2 is the attacker box. The whole point is that OPT2 has no legitimate reason to ever talk to LAN directly. If traffic is crossing that boundary, something is wrong.

pfSense processes rules top-down and stops at the first match. That ordering is everything. I learned this the wrong way — I had a broad PASS rule on OPT1 that came before my specific BLOCK rules, so OPT1 could reach LAN freely. Flipping the order immediately fixed it. The rule table below reflects the final working state. The OPT1 BLOCK to LAN rule sits above the general PASS rule deliberately — if it were below, it would never fire.

Screenshots from the pfSense rule editor — individual block rules and the consolidated view:

Test results — what blocked traffic actually looks like from the client side. Each attempt produces a clean timeout or connection refused, confirming the rules are firing:

The goal wasn't to "pass" a test — it was to understand what my own perimeter looks like to an attacker. OPT2 is the attacker machine. Everything it tries has to go through pfSense. I ran exercises in three stages, deliberately starting simple to confirm the fundamentals held before moving to more complex scenarios.

PHASE 02 — TESTING SURICATA SPECIFICALLY

Temporarily opening a rule to see if IDS catches what firewall blocks

To test Suricata's detection independently of the firewall, I temporarily added a rule allowing OPT2 → LAN TCP (scoped to a specific test port) and ran a payload exercise. Suricata caught the reverse shell signature immediately — the alert showed up in the Suricata web UI and forwarded to Splunk within a few seconds. I closed the test rule right after. What this confirmed: the firewall and IDS are independent layers. A misconfigured rule that opens too much doesn't mean the intrusion is invisible — Suricata still fires on the traffic pattern regardless of whether the firewall permitted it.

PHASE 03 — LATERAL MOVEMENT FROM DMZ

SSH brute-force from OPT1 — this is why all-interface IDS matters

I launched an SSH brute-force from OPT1 toward a LAN host. The firewall blocked the connection (OPT1 doesn't have a rule permitting SSH to LAN), and Suricata fired on the OPT1 interface — not WAN. That's the important part. If Suricata were only on WAN, this event would be completely invisible. A compromised DMZ server pivoting toward production would generate no WAN traffic at all. It took this exercise to make me fully appreciate why binding Suricata to internal interfaces isn't optional — it's what separates network monitoring from perimeter-only monitoring.

• Rule ordering in pfSense bit me before I understood it. A broad PASS rule that sits above specific BLOCK rules makes those block rules unreachable. I had OPT1 talking to LAN freely for a while before I caught it. Always verify isolation is actually working — log a test connection attempt and watch for it explicitly, don't assume.
• Alert tuning was the most time-consuming part of the whole project by far. The ET Open ruleset out of the box fires on Windows Update traffic, ARP broadcasts, and legitimate DNS. I suppressed by source IP for known-benign internal hosts rather than disabling entire categories — more work upfront, but the rules still catch the same behavior from anything unexpected.
• Binding Suricata to all interfaces changed how I think about IDS placement. WAN-only coverage leaves a blind spot for anything that stays east-west. In a real SOC, half the interesting traffic never touches the perimeter.
• The "block without reply" behavior of pfSense is useful from a security standpoint but confusing to verify. A silent timeout from the attacker's side could mean the firewall rule fired, or the host is down, or the route is broken. Building the habit of checking pfSense logs to confirm a rule actually fired — not just assuming — is something I now do automatically.
• Certificate-based VPN is more setup than shared keys, but the tradeoff is real: someone who phishes your VPN password still can't connect without your certificate file. Worth the extra steps.

Official Netgate documentation and community resources used during this lab build.