Real-World Firewall Lab Scenarios

“The guest Wi-Fi has no Internet.” “The VPN connects but nothing answers.” “We have two Internet lines and still went offline.” This book starts at the ticket and works back to the cause.

Every chapter from 4 to 14 begins with a build: the feature set up correctly and proven with real evidence. Then come two to five incidents, each with the same shape: the ticket, reproducing it, the investigation step by step, the root cause, the fix, and the proof. The scripts ran against real pfSense CE 2.9.0 firewalls, and the book was built from what they recorded.

Some of what you have read elsewhere is not true on 2.9.0. The lab found that pfSense 2.9.0 loads no automatic “negate” rules for policy routing (section 8.2), that running calls survive a failover with the default settings and die with the settings forums recommend (7.3), and that a new VLAN on a VMware vmxnet3 card cuts off the untagged LAN (4.1). Each is shown, not claimed.

Who it’s for

• Administrators who run pfSense in an office, a school or a branch and want a faster way from ticket to cause.
• Home-lab builders who want multi-WAN, VPNs, IDS and HA done properly, with proof that they work.
• Engineers who know another firewall (FortiGate, Cisco, Sophos) and need to get productive on pfSense. An appendix maps FortiGate terms to pfSense.

What’s inside

Foundations

• How pfSense handles a packet, and the four consequences that explain most tickets
• Building the automated lab on a Windows PC with VMware Workstation (pfSense CE needs no licence)
• The toolkit: firewall log, pfctl, packet capture, services and routing

Firewall rules and segments. Build a DMZ, guest VLAN and IoT VLAN, then: a new phone VLAN takes the whole office offline; a WAN block that doesn’t stop camera uploads; guests reaching the office after a rule tidy-up; a block that misses the upload already running; blocking a cloud by name.

NAT and port forwarding. A port forward that doesn’t answer; the shop showing the firewall’s login page from inside the office; a printer subnet with no Internet; a second ISP address whose forward never answers.

DNS and DHCP. “DNS Rebind attack” on the login page; a printer ignoring its reservation; a reserved host that doesn’t resolve; guest Wi-Fi losing Internet after DNS hardening.

Multi-WAN failover. ISP 1 down for an hour and no switch to ISP 2; a failover group that still went offline; phone calls that never come back after failover; drops every few minutes; the one website that breaks after failover.

Load balancing and policy routing. The bank logging you out since the second ISP; the office losing the DMZ server; half of all page loads failing; a WAN2 shop that only works when WAN2 is default.

Site-to-site IPsec. IKEv2 between HQ and a branch, then: re-entered keys, a rebuilt branch, “up but nothing gets through”, a new branch subnet, and branch Internet through HQ.

OpenVPN and WireGuard remote access. Connected but nothing answers; broken after a client update; full tunnel without Internet; a WireGuard tunnel with no handshake; handshakes but no traffic.

Suricata IDS/IPS. The honest state of IDS on pfSense CE in 2026, then: a month without a single alert; blocking that kills the cloud app; alert floods; inline IPS that still lets the download through.

High availability with CARP. Both firewalls saying MASTER; failover that drops every download and call; config sync that stops.

Lockouts, undo and updates. Locked out of the firewall; restoring deleted rules; “Unable to check for updates”.

Appendices: a symptom index, lab reference, command cheat sheet, firewall log fields, pfSense CE 2.9.0 vs pfSense Plus, and a FortiGate ↔ pfSense mapping.

From the book

Chapter 1 explains the order pfSense applies to every packet, and four consequences of that order that explain more tickets than any feature list:

• Rules belong to the interface where traffic enters. Guest-to-Internet traffic is filtered on the GUEST tab; a rule on the WAN tab won’t touch it.
• First match wins on each tab. Every rule pfSense writes is a quick rule, so a broad pass above a specific block makes the block useless.
• Port forwards happen before the rules. The rule for a forwarded port must name the inside server, because the destination has already been rewritten.
• Rules decide the first packet; states carry the rest. A new block rule doesn’t stop a connection that’s already established.

Tested on

All command output was recorded on pfSense CE 2.9.0-RELEASE (amd64) with the REST API, Suricata and WireGuard packages, on VMware Workstation 17.5. The lab scripts are free at github.com/vashy-labs/pfsense-lab, and one command replays any section of the book.