OPNsense: A Serious Firewall for a Serious Home

The router your ISP gave you is a compromise built to a price point, and it shows the moment you ask it to do anything beyond NAT a single flat network. No VLANs, no real firewall rules beyond “allow everything out, block everything in”, a web interface that reboots the whole box to change a DNS entry, and firmware that stops receiving updates the day the model falls out of the current catalogue. It works fine for a household that just wants Netflix and email. It falls over the instant you want a guest network that can’t see your NAS, a camera VLAN that can’t phone home to the internet, or logging that tells you what actually crossed the WAN link last Tuesday.

OPNsense is what you put in its place: a full BSD-based router and firewall distribution, forked from pfSense in 2015, with a genuinely usable web UI, a plugin system, and the packet-filtering pedigree of OpenBSD’s pf underneath it. It runs on anything from a fanless mini-PC to a repurposed office desktop, and it turns your internet edge into something you actually control instead of something you merely tolerate.

Why bother with a dedicated firewall box

The real appeal of OPNsense is that your router stops being a black box. Every interface, every rule, every DHCP lease and DNS query becomes visible and configurable. That matters for three concrete reasons that show up the first week you run it.

First, segmentation. A consumer router gives you one LAN and maybe a bolted-on “guest” SSID that still shares a subnet with everything else half the time. OPNsense treats VLANs as first-class citizens, so a smart plug, a set-top box, and your file server live on genuinely separate broadcast domains with a real firewall enforcing that separation between them.

Second, visibility. The stock firewall log on an ISP router, if it has one, is usually a rolling buffer of a few hundred lines. OPNsense keeps proper logs per rule, exposes live states, and — with the Zenarmor or Suricata plugins — gives you actual traffic classification instead of guesswork.

Third, longevity. OPNsense ships a new release roughly twice a year with security patches in between, and it runs on hardware you choose and can replace on your own schedule. Your ISP’s box gets EOL’d whenever the manufacturer decides the model is old enough.

Sizing the hardware

Before touching software, get the hardware right, because an underpowered box is the single most common reason people give up on OPNsense and go back to the ISP router.

For a gigabit internet connection with light IDS/IPS use, two CPU cores and 4 GB of RAM is comfortable. Once you turn on Suricata in inline IPS mode, or you’re doing more than basic NAT at line rate, budget four cores and 8 GB. The network interface cards matter more than the CPU in most home setups — cheap Realtek NICs are notorious for driver quirks under BSD; Intel i210/i350-based cards are the safe, boring choice and what most of the fanless “firewall appliance” boxes on the market use for exactly that reason. A pair of NVMe or even a decent SATA SSD for the OS drive keeps logging snappy; OPNsense writes a fair amount to disk once you enable NetFlow or IDS logging, and consumer USB sticks die under that write pattern within months.

Three physical (or VLAN-tagged) interfaces is the minimum sensible layout for a home network: WAN, a trunk LAN port carrying your VLANs, and — if you want it — a dedicated port for a separate management network so you can still reach the firewall UI if you fat-finger a LAN rule.

Interfaces and VLANs

OPNsense treats each VLAN as its own logical interface with its own firewall rule set, which is the whole point. A typical home layout looks like this:

• WAN — the physical uplink to your ISP’s modem/ONT.
• LAN (untagged, VLAN 1 or native) — trusted admin devices, the firewall’s own management access.
• VLAN 10 — Servers — NAS, hypervisor hosts, anything you’d be upset to lose.
• VLAN 20 — IoT — smart plugs, cameras, the robot vacuum, anything with a firmware update cadence of “never”.
• VLAN 30 — Guest — visitor Wi-Fi, internet-only, no access to anything else.

Creating the VLANs themselves is a few clicks under Interfaces → Other Types → VLAN: pick the parent interface (your LAN NIC), give it a tag, assign it a name. Each VLAN then gets promoted to a real interface under Interfaces → Assignments, where you give it an address, a subnet, and turn it on.

The important part happens next, in the firewall rules, because an interface with no rules on OPNsense defaults to deny everything — unlike a lot of consumer gear, there’s no implicit “LAN can reach anything” rule waiting for you. You write every permission explicitly.

Rules and aliases

Rules in OPNsense are evaluated top-to-bottom, first match wins, per interface, on traffic entering that interface. That trips up people coming from iptables, where a single global chain is normal — here you reason about each VLAN’s inbound rules separately.

Aliases are what keep a rule set maintainable instead of turning into three hundred near-identical lines. An alias is a named group — of hosts, networks, or ports — that you reference in rules and update in one place. Define RFC1918 once as a network alias covering your private ranges, and every “block IoT devices from talking to other private networks” rule can reference it instead of hardcoding three CIDR blocks per rule.

A representative slice of the IoT VLAN’s ruleset, described in the order OPNsense would show it:

1
2
3
4
5
6

# Interfaces > VLAN20_IoT > Firewall Rules

1. Pass   proto UDP   src VLAN20 net   dst this firewall   port 53      (allow DNS to the firewall)
2. Pass   proto UDP   src VLAN20 net   dst this firewall   port 67:68   (allow DHCP)
3. Block  proto any   src VLAN20 net   dst RFC1918 (alias)              (no lateral movement to other VLANs)
4. Pass   proto any   src VLAN20 net   dst any                          (everything else out to the internet)

That ordering matters: the block-private-networks rule has to come before the final permissive “allow to internet” rule, or it never gets evaluated. It’s a common first mistake — writing the broad allow rule first and wondering why the block never takes effect.

If you’ve spent any time with Linux firewalling, it’s worth being explicit about what’s different here. OPNsense sits on pf, OpenBSD’s packet filter, evaluated per-interface on ingress — a genuinely different mental model from nftables, where a single ruleset commonly governs input, output, and forward chains together and you reason about the whole host’s traffic in one file. Neither model is objectively better; pf’s per-interface approach maps unusually well onto a router with several VLANs because you naturally think in terms of “what can this segment do”, while nftables’ unified ruleset suits a single Linux box running its own services more directly. If you’re running OPNsense at the edge and nftables on individual Linux hosts behind it — a very common homelab pairing — knowing that the two enforce policy at genuinely different layers, rather than assuming rules on one somehow inform or duplicate rules on the other, saves a lot of confused debugging when traffic behaves unexpectedly.

Aliases also make outbound NAT sane. Under Firewall → NAT → Outbound, switch from automatic to hybrid mode once you have VLANs, so you can be explicit that VLAN 20 and VLAN 30 both NAT out through WAN but never get a rule that accidentally lets them reach VLAN 10 through some NAT quirk.

DNS and DHCP

OPNsense bundles both Unbound (DNS resolver) and ISC/Kea DHCP, and running them on the firewall itself rather than a separate box is a genuine convenience: DHCP reservations and DNS host overrides live in the same place, and a device’s hostname resolves correctly the moment it gets a lease.

Per-VLAN DHCP scopes are configured under Services → DHCPv4 → [interface]. Each VLAN gets its own range, its own gateway (the firewall’s interface IP on that VLAN), and — usefully — its own DNS server setting, so IoT devices can be pointed at Unbound without picking up any DNS-based ad-blocking overrides you might have set only for the trusted LAN.

Unbound’s host overrides give you internal-only DNS records without running a separate authoritative server:

1
2
3

# Services > Unbound DNS > Overrides > Host Overrides
Host: nas          Domain: mylab.local     IP: 10.10.10.5
Host: proxmox      Domain: mylab.local     IP: 10.10.10.10

If you also run Pi-hole for ad-blocking, the clean pattern is Pi-hole as the first DNS hop for trusted VLANs, with Unbound on OPNsense as its upstream resolver — the two aren’t competing for the same job.

Running your resolver and your firewall on the same box has a knock-on benefit worth calling out: split-horizon behaviour comes almost for free. Because Unbound sees which interface a query arrived on, it’s straightforward to hand internal clients the LAN address for a service while anyone asking from outside gets nothing, or a different answer entirely, without running a second authoritative DNS server anywhere. That’s the same underlying problem the split-horizon DNS piece covers in more depth for people running a dedicated resolver — the mechanics translate directly if Unbound-on-OPNsense is your only DNS box, you’re just configuring it through the firewall’s own UI instead of a standalone BIND or Unbound install.

Intrusion detection

Suricata ships as a plugin (os-suricata), running either in IDS mode (log and alert) or inline IPS mode (log, alert, and drop). Start in IDS-only mode on the WAN interface with the ET Open ruleset for a couple of weeks before flipping on blocking — inline mode with an aggressive ruleset will occasionally flag legitimate traffic, and you want to have tuned out the false positives before it starts silently dropping your own packets. A misconfigured IPS is a self-inflicted outage that looks exactly like an ISP fault, and you’ll waste an evening on the phone with your provider before you think to check the IDS log.

Troubleshooting

A VLAN can’t reach the internet after you assign it. Check that outbound NAT is actually covering the new subnet — if you’re in manual or hybrid NAT mode, a new interface doesn’t automatically get a NAT rule, and traffic will route out but never get translated, so replies never find their way back.

Devices on a VLAN can’t resolve DNS at all. Almost always rule 1 above missing or in the wrong order — the interface’s default-deny is blocking UDP/53 to the firewall itself before the client ever reaches Unbound. Check Firewall → Log Files → Live View filtered to that interface; a blocked DNS packet shows up immediately.

The web UI becomes unreachable after a rule change. This is why the separate management interface earns its keep. If you’ve locked yourself out of the LAN admin access, console access to the box (or the OPNsense recovery shell) lets you run pfctl -d to briefly disable the packet filter and fix the rule from the UI, or edit config.xml directly if things are dire.

Suricata pegs a CPU core and inline mode starts dropping packets under load. Reduce the ruleset to categories you actually care about rather than running every ET Open category, and confirm you’re not accidentally running IDS and IPS instances on the same interface simultaneously — a known way to double the workload for no benefit.

High latency spikes under load with the stock kernel scheduler. Confirm hardware checksum offloading and TSO/LRO are disabled on the WAN NIC if you’re seeing packet corruption in the logs — some Realtek and even some Intel chipsets misbehave with these enabled under BSD, and it’s a five-minute fix that ends a week of head-scratching.

Is it worth it

If your network is one flat subnet and a phone, laptop and a smart bulb are the extent of your ambitions, OPNsense is overkill — the ISP router is fine, and you should spend the weekend on something else. But the moment you’re running a proper VLAN-segmented home network, self-hosting services you’d be annoyed to see compromised, or you just want to know what’s actually crossing your WAN link, OPNsense earns the extra hour of setup. It’s free, it’s actively maintained, it runs on hardware as modest as a decade-old office PC, and unlike the box your ISP rents you, every setting in it exists because you put it there.