Cybersecurity Lab Part 3: Advanced pfSense

Example rule tiers

1. Block RFC1918 on WAN (anti‑spoof)
2. Allow mgmt UI from mgmt VLAN only
3. Allow DNS/NTP from user VLANs
4. Explicit allow for lab flows (VLAN30 → DMZ)
5. Default deny for everything else

4) Policy-based routing (keep lab traffic contained)#

Route “attack” traffic via a separate gateway or VPN tunnel so the lab stays isolated.

• Create a Gateway Group and assign it to a VLAN30 rule.
• Keep other VLANs on the default WAN route.

5) Remote access with Tailscale (subnet router)#

Use Tailscale when you want private, authenticated access to lab VLANs without exposing pfSense to the public internet.

High-level steps

• Install the Tailscale package in pfSense (Package Manager).
• Authenticate with an auth key from the Tailscale admin console.
• Advertise routes for your lab subnets (VLAN10/20/30/40 CIDRs).
• In the Tailscale admin console, approve the subnet routes.
• On clients, enable Use tailnet routes (no exit node needed).

Firewall rules (important)

• Create a Tailscale interface and only allow what you need.
• Example: allow TAILSCALE_NET -> MGMT_VLAN (UI), allow TAILSCALE_NET -> LAB_VLAN, deny everything else.
• Keep pfSense UI restricted to mgmt + Tailscale only.

Quick test

• From a remote client, ping a lab VM and open the pfSense UI (mgmt IP).

6) Multi‑WAN failover (optional, but lab‑realistic)#

• Add WAN2, define gateway monitoring (DPinger).
• Create a Failover Gateway Group.
• Bind critical outbound rules to the group.

Common pitfall: DNS will “black hole” if it’s bound to a failed WAN. Either use Resolver in pfSense or set DNS to gateway‑aware upstreams.

7) DNS controls (Unbound + split‑horizon)#

• Use Unbound Resolver with local overrides:
  • target.lab → DMZ VM IP
  • siem.lab → Security Onion
• Enable DNS over TLS to upstream resolvers.
• Add DNS allow‑list per VLAN (block direct outbound DNS from clients; force to pfSense).

8) IDS/IPS: Suricata + pfBlockerNG#

Suricata

• Start in alert‑only mode.
• Then test inline IPS on the lab VLAN only.
• Keep rule sets minimal to avoid noise.

pfBlockerNG

• DNSBL for ad/malware domains (lab realism).
• GeoIP or ASN blocks for restricted use cases.

9) Traffic shaping (realistic congestion + stability)#

Use limiters with fq_codel:

• Apply to VLAN10 for user realism.
• Apply to VLAN30 to simulate constrained attack paths.

10) Logging and telemetry (feed your SIEM)#

• Send pfSense logs → Security Onion via syslog.
• Enable Firewall + DNS + DHCP logs.
• Tag logs with VLAN/interface so detections are contextual.

11) Operational hygiene#

• Snapshot before major changes.
• Export config after each phase.
• Keep a change log in Git (configs are XML).

Validation checklist#

• Management UI reachable only from VLAN20.
• Inter‑VLAN default deny verified.
• DNS traffic forced through pfSense.
• Suricata alerts visible in Security Onion.
• Lab VLAN policy routing works as expected.
• Tailscale subnet routes approved and reachable (optional).
• Syslog delivered with VLAN/interface fields.

Wrap‑up#

pfSense becomes the security boundary of your lab when you harden its UI, enforce segmentation, and push telemetry into your SIEM. This sets you up for controlled attack simulations and detection exercises.

Next up idea: Part 4 could focus on attack‑emulation workflows and detection tuning (Sigma/Suricata rules + dashboards).