OPNsense Firewall Rules Explained for Beginners

OPNsense firewall rules are badly served by most tutorials, which either stop at “click the plus button” or assume you already know what a stateful packet filter does. This guide bridges that gap: it covers the logic OPNsense uses to evaluate rules, what every field in a rule actually controls, the difference between block and reject, and how to confirm your rules are doing what you think they are — all without glossing over the mechanics that determine whether traffic flows or dies silently.

How OPNsense Processes Firewall Rules

OPNsense’s firewall engine is built on FreeBSD’s PF (Packet Filter). Rules are not evaluated as a flat list — they are evaluated in a strict three-tier hierarchy, in this order:

1. Floating rules — applied across all interfaces simultaneously, useful for global policies.
2. Interface group rules — applied to any interface that belongs to a named group.
3. Interface rules — applied only to the specific interface you configure them on (WAN, LAN, VLAN10, etc.).

Within each tier, rules are read top to bottom. By default every rule carries the “quick” flag, which means first match wins and the rest of the list is skipped for that packet. This is critical: a broadly written allow rule near the top will shadow all the specific deny rules below it.

OPNsense uses stateful filtering by default. When a connection is permitted, the firewall records the session state in a table. Return traffic for an already-established connection is matched against the state table and passed without re-running the full rule list. The practical result: you write rules for the direction traffic originates, and OPNsense handles the reply path automatically. The official docs note that stateful tracking also validates TCP sequence numbers, making traffic spoofing materially harder than with a simple ACL.

Anatomy of a Rule: What Every Field Controls

Navigate to Firewall → Rules, pick an interface, and click the + button. Here is what each field does:

Action is the outcome if this rule matches: Pass (allow the traffic), Block (drop silently — the sender gets no response), or Reject (drop and notify — TCP gets an RST, UDP gets ICMP unreachable). On a WAN interface facing the internet, use Block; on internal interfaces where you want a faster failure signal for users, Reject is acceptable.

Direction defaults to In, which means traffic arriving at the interface from outside the firewall’s perspective. For a LAN interface, In covers traffic originating from your LAN clients heading toward the firewall. The OPNsense documentation describes this as filtering “the interface originally receiving the traffic” — filter inbound on every interface and you cover all traffic without needing outbound mirror rules.

Protocol narrows the match: TCP, UDP, ICMP, or TCP/UDP for rules covering both. Leaving it at any matches everything.

Source and Destination accept a single IP, a CIDR range (192.168.20.0/24), or an alias. Aliases are the most important habit to build early: define them at Firewall → Aliases before you write rules. A host alias named IoT_Devices that contains five IPs lets you update all five in one place instead of hunting through every rule. Aliases also accept port lists, which keeps protocol-specific rules readable.

Description is not optional in practice. A rule with no description becomes undebuggable six months later. Write one sentence: what traffic this allows, from where, to where, and why.

The Defaults OPNsense Ships With

A fresh OPNsense install, of the kind the initial setup guide produces, has three implicit policies you need to know before writing a single rule:

Anti-lockout rule. OPNsense automatically creates a rule allowing the LAN host (the IP your browser is at) to reach the firewall’s web GUI on port 443 and SSH on port 22. This rule cannot be accidentally deleted through the GUI. It is a safety net, not a permanent policy — once you have explicit management rules in place, you can disable it under Firewall → Settings → Advanced.

LAN implicit allow-all. The LAN interface ships with an allow-all rule (* source, * destination). This is intentional for first-boot accessibility, but it means your LAN has no effective restrictions until you either replace or supplement it. Many deployments leave this in place and add specific block rules above it; others delete it and build an explicit allowlist from scratch. The explicit allowlist approach is harder to set up but leaves less to chance.

WAN implicit block-all. The WAN interface has no allow rules by default. Unsolicited inbound traffic from the internet is dropped. Port forwarding rules (under Firewall → NAT → Port Forward) punch specific holes through this; everything else stays closed. NAT is evaluated before the filter, so the pass rule that accompanies a forward has to match the internal address the NAT rule just translated to — the single most common reason a forward silently fails. OPNsense port forwarding and NAT rules walks through that pairing, the filter-rule association options, and hairpin access from inside your own LAN.

A Practical Example: Isolating an IoT VLAN

The pattern that illustrates rule order most clearly is IoT segmentation. Suppose you have an IoT VLAN on 192.168.20.0/24 (VLAN 20) and a trusted LAN on 192.168.10.0/24 (VLAN 10) already built out per the OPNsense VLAN configuration guide. You want IoT devices to reach the internet but not talk to trusted hosts, a common requirement given how rarely consumer IoT firmware gets patched.

On the VLAN 20 interface, rules in top-to-bottom order:

Order	Action	Source	Destination	Port	Purpose
1	Block	VLAN20 net	VLAN10 net	any	Block IoT → trusted LAN
2	Block	VLAN20 net	192.168.20.1	443, 22	Block IoT → firewall GUI/SSH
3	Pass	VLAN20 net	any	any	Allow IoT → internet

Rule 1 must sit above Rule 3. If you put the broad allow first, traffic from VLAN 20 to VLAN 10 matches Rule 3 and passes before Rule 1 is ever evaluated. The block at Rule 2 protects the firewall’s management interface from IoT devices — without it, a compromised smart bulb could attempt to reach the web GUI.

If you would rather see an ordered plan than assemble one from scratch, the site’s OPNsense rule and alias recipe generator turns a goal — isolate an IoT VLAN, guest Wi-Fi internet-only, a safe inbound port forward — into the aliases to create first and the rules in the order to create them, with the reason attached to every line.

For larger networks with many VLANs, the OPNsense security zones model provides a policy abstraction that reduces rule count dramatically — one zone policy covers all interfaces in that trust tier rather than duplicating rules per-interface.

Verifying Rules with the Live Log

Rules that appear correct in the GUI are not necessarily working. The only way to know is to generate traffic and watch it. In OPNsense, navigate to Firewall → Log Files → Live View. Before testing, enable logging on the specific rule you want to observe: edit the rule, expand the advanced section, and check the log checkbox, then click Apply.

Run a ping or curl from a client on the source network. If the rule is matching, you will see entries in the live view showing the action (pass or block), source IP, destination IP, port, and which interface the traffic arrived on. If nothing appears, the traffic is either not reaching OPNsense (check routing) or being matched by a higher rule before yours (check rule order). The live log is the ground truth — do not call a ruleset done until traffic appears there matching your expectations.

One limit worth stating plainly: a pass rule decides only whether a packet is permitted, never whether its contents are hostile. Inspecting what you have chosen to allow is a separate control, and on OPNsense that means running Suricata as an IDS or inline IPS on the interface that carries the traffic you care about.