The default rules already protect you. Your first handmade rules should be few, ordered correctly, and tested - rules are read top down and the first match wins.
Rule lists scare beginners because a wrong line can cut the office internet or lock the admin out. The safe way in is small: understand the defaults, learn the reading order, add one useful block, and log it. This page builds exactly that first rule set and names the one trap - locking yourself out - before it happens to you.
An example of a minimal first policy - defaults doing the heavy lifting, one deliberate block added. Your addresses will differ.
A fresh pfSense is not an open door. By default, everything unsolicited from the WAN side is blocked, and devices on the LAN are allowed out to the internet. Most small offices run safely on these defaults for a while. Your first rules should be small, deliberate additions - not a rewrite of the whole policy on day one.
Rules are checked from the top of the list downward, and the first rule that matches decides - the rest are never read. Rules live per interface and apply to traffic arriving on that interface. This one idea explains most beginner surprises: a perfect block rule placed below a broad pass rule does nothing at all. Order is not decoration; order is the policy.
A genuinely useful first project: stop cheap IoT gadgets and the guest network from reaching office PCs, while still letting them use the internet.
Every beginner eventually writes a rule that blocks their own access to the web console. pfSense has an anti-lockout rule protecting console access on LAN - do not disable it casually, and never add a broad LAN block rule without first checking what it does to your own management access. If you do lock yourself out, the physical console can restore access - another reason the firewall machine should stay reachable, not buried.
For a new block rule, tick Log and watch Status - System Logs - Firewall. You will see exactly what the rule catches. This is how you learn what is actually on your network - the smart TV phoning home, the forgotten printer scanning ports. Log new rules for a few days, then decide whether the log is still earning its disk space.
Rules decide by address, port and protocol. They cannot read inside encrypted HTTPS traffic - a rule can block a bad website's address, but it cannot read the page, scan the download or filter the video inside it. Content-level jobs need packages (DNS filtering, intrusion detection) or endpoint protection on the PCs themselves. Believing a basic rule set inspects everything is the most dangerous misunderstanding a new firewall owner can have.
Watch the base setup first so the interfaces and dashboard in this guide match what you see on screen.
Watch Full VideoOn the WAN side, unsolicited incoming traffic is blocked by default. On the LAN side, a default allow rule lets your devices reach the internet. These two defaults are the reason a fresh pfSense is safe to plug in before you write a single rule of your own.
Almost always its position. pfSense reads rules top down and stops at the first match, so a block rule sitting below a broad pass rule is never reached. Move the block above the pass rule, apply, and test again - then check the firewall log to confirm the rule is the one catching the traffic.
Rules work on addresses and ports, not names or page content. To block websites you would normally use DNS-based filtering such as the pfBlockerNG package, which blocks by domain. Even that cannot see inside encrypted traffic - it stops the lookup, not the content.