OPNsense's defaults already protect you: the internet cannot come in, your devices can go out. First rules are not about building a fortress — they are about the three or four specific things you actually want: one device that must never reach the internet, a guest network that must never see your NAS, and logs you can actually read.
A firewall rule answers one question: traffic from here, going there, on this port — allow it or block it? OPNsense reads rules from the top down and stops at the first match, so order is meaning. This guide explains the default rules you inherit, then builds the small set of first rules most homes and small offices genuinely need — and shows you how to test each one instead of hoping.
Rules live per interface and apply to traffic arriving on that interface. LAN rules judge traffic from your devices; WAN rules judge traffic arriving from the internet. Every packet walks the list from the top; the first rule that matches decides, and anything matched by no rule is blocked by the invisible default-deny at the end. That is why a broad allow placed above your careful block silently defeats it — the block is never reached. When a rule seems ignored, the answer is almost always order.
Camera_net so rules stay readableA fresh OPNsense is not an open door: unsolicited traffic from the internet is blocked by default, LAN devices can reach out freely, replies to their connections are allowed back in by the stateful firewall, and an automatic anti-lockout rule guarantees your path to the web GUI and SSH on LAN. You do not need to create any of that. Your first rules should be deliberate exceptions to the LAN-can-do-anything part — restrictions you choose, on purpose, for specific devices.
Three rules cover most real homes and small offices. One: block cheap IP cameras and recorders from reaching the internet entirely — they still work locally with your recorder, but their cloud-calling habit dies. Two: if you run a guest network or VLAN, block it from reaching your LAN, then allow it to the internet below that block. Three: for a work-from-home corner, allow one PC to reach a specific server or printer and nothing sideways. Build them one at a time, test from the affected device, and write a real description on each rule.
Logging everything feels safe and produces an unreadable flood within a day. The practical approach: log blocks that represent decisions you made (guest trying to reach LAN, camera trying to phone home), do not log the constant background noise of the internet knocking on your WAN — that is the default-deny doing its job silently. A rising count on a decision rule tells a story; ten thousand random WAN probes tell you only that the internet is the internet.
Watch rules being built and tested in the video, including the log view that proves each rule is doing its job.
▶️ Watch Full VideoAlmost always rule order or existing connections. Check that your block sits above the general LAN allow rule, and remember the stateful firewall keeps already-open connections alive — restart the device or clear its states (Firewall → States → Reset States) after changing rules, then test again.
For a home network that is usually misery without much gain — apps use countless ports and CDNs, and you will spend weekends whitelisting. Restrict specific devices that have no business online (cameras, recorders, old smart TVs) instead. Businesses with a compliance need do full egress filtering, but they staff it.
An alias is a named list — of addresses, networks or ports — that rules can refer to. Instead of twelve rules for twelve cameras, you keep one Camera_net alias and one rule. When a device changes, you edit the list in one place and every rule using it stays correct.