OPNsense Firewall Rules and NAT: How They Work

OPNsense is a FreeBSD-based routing and firewall platform driven by a web interface. The interface writes configuration for the underlying packet filter and the services around it. Almost every early mistake comes from misreading three things: where rules live, which direction they apply in, and what NAT does independently of them.

Interfaces come first

Everything is anchored to an interface. There is a WAN side facing the upstream connection, a LAN side facing your network, and optionally VLANs, additional physical ports, and VPN interfaces. A VLAN is defined on a parent physical port, then assigned as an interface, then given an address. Skipping the assignment step is why a newly created VLAN often appears to do nothing.

Each assigned interface gets its own firewall rule tab. There is no single global list.

Rules are evaluated per interface, on the way in

A rule on an interface applies to traffic entering the firewall through that interface, not leaving it. To allow your LAN clients to reach the internet you write the rule on the LAN interface. To allow inbound access from the internet you write it on WAN. Thinking in terms of source and destination without also thinking about the entry point produces rules that never match.

Within an interface the list is processed top to bottom and the first matching rule decides the outcome. Order therefore carries meaning: a broad allow near the top makes everything below it unreachable.

The firewall is stateful. You permit the first packet of a connection and the return traffic is handled automatically, so there is no need for a mirrored rule in the opposite direction.

That state has a cost in memory. Every tracked connection occupies roughly a kilobyte, so a network holding hundreds of thousands of simultaneous connections needs RAM allocated for the table before anything else runs. The state table and bandwidth sizer on this site turns a target connection count into a memory figure, and OPNsense hardware requirements covers how that interacts with CPU and interface choice.

NAT is separate from filtering

Outbound NAT translates internal addresses to the WAN address. By default it is generated automatically from your interface layout. Switching it to manual gives you control and also freezes it, so newly added networks will not get translation until you add entries yourself.

Port forwarding is an inbound NAT entry that rewrites the destination, and it needs a matching filter rule to permit the traffic. The interface can create that rule for you. If a forward is not working, check whether both halves exist, and whether the upstream device is also doing NAT, because two layers of translation cannot be fixed from inside.

VPN interfaces follow the same rules

A VPN is not an exception to any of the above, which is the single most useful thing to know about setting one up. A tunnel needs a pass rule on WAN to let the connection in, a separate pass rule on the tunnel’s own interface to govern what the connected client may reach, and outbound NAT covering the tunnel subnet if that client should reach the internet through you. Three different places, three different jobs.

Which tunnel technology to run is a separate decision, covered in OPNsense VPN: WireGuard vs OpenVPN vs IPsec. When a tunnel establishes but carries nothing, the cause is almost always one of those three pieces missing, and OPNsense WireGuard not connecting works through them in order.

Aliases and readability

Aliases are named groups of addresses, networks or ports that can be referenced in rules. Using them turns a long unreadable ruleset into something you can audit later, and it means changing a server address updates every rule at once. Adopt them early, because retrofitting them across a grown ruleset is tedious.

Intrusion detection is a tuning project

An IDS engine can run in detection mode, where it observes and alerts, or inline, where it can drop traffic. Inline mode requires network interface support and turns every false positive into a user-visible outage.

Enabling large numbers of rule categories at once produces noise that nobody reads, which is functionally the same as having no IDS. Start in detection mode with a narrow, relevant set of categories, watch what actually fires on your traffic, and only then consider blocking. Also accept that most traffic is encrypted, so an inspection engine sees far less than its rule count suggests.

Common mistakes

Locking yourself out by disabling or overriding the anti-lockout protection before you have another way in. Writing rules on the wrong interface. Leaving an allow-any rule above the specific rules you carefully wrote. Running the firewall behind an ISP router that also performs NAT, without putting that device into bridge or passthrough mode. Treating a working configuration as safe without exporting a backup of it, which is a single file and takes seconds.