This post walks through the config as it currently runs. Not a tutorial. Not a clean-slate build guide. Just what’s actually on the box, what each piece is doing, and which of the “this looks clever” choices turned out to be worth it.

What OPNsense replaced

The previous edge was a consumer router running vendor firmware. It worked. It also had opinions about DNS, UPnP, and what “internal” meant that didn’t line up with mine. The moment I wanted per-VLAN firewall rules and per-host DNS overrides, I’d hit a wall.

OPNsense runs on a small x86 box with two NICs. One is WAN, one is a trunk into the switch carrying tagged VLANs. The whole thing idles under 15% CPU with everything I’ve thrown at it.

Interfaces

Three interfaces that matter, plus the ones that don’t.

• WAN — the public side. spoofmac is set, blockpriv and blockbogons are both on. Anything showing up from RFC1918 or reserved space on the WAN gets dropped before it hits a single rule. This is a default, but it’s a default I’ve seen disabled “temporarily” on other people’s firewalls more times than I’d like.
• LAN (192.168.1.0/24) — the trusted network. Hosts, servers, my workstation, the things I wouldn’t want on a segment with a cheap IP camera.
• VLAN20_IOT (192.168.20.0/24) — everything that speaks a protocol I didn’t write and can’t audit. Cameras, smart switches, the TP-Link stuff, a Ring doorbell, an Apple TV. Anything that phones home on a schedule.
• VLAN30_GUEST (192.168.30.0/24) — guest Wi-Fi. Scoped tight and deliberately boring.

The WireGuard interface exists as a stub. The actual WireGuard endpoint runs on Boreas (the Raspberry Pi I wrote about previously) and terminates on LAN. Port 51820/udp is port-forwarded through OPNsense to it. The virtual interface here is reserved for a future on-box tunnel I haven’t needed yet.

Inbound: what’s actually exposed

A small, deliberate list. If something isn’t on this list, the outside internet can’t see it.

• 32400/tcp → Alecto (Plex). Plex’s own account server handles connection brokering; this is the fallback direct path.
• 25/tcp, 993/tcp → Alecto (SMTP inbound, IMAP-over-TLS). Yes, a residential SMTP listener is a lightning rod. I accept the noise in exchange for owning my own mail flow.
• 9001/tcp+udp → the Tor middle relay host. Advertised to the Tor directory as the relay’s ORPort.
• 443/tcp, 51820/udp → Boreas. 443 is Nginx Proxy Manager fronting Overseerr for friends and family behind Cloudflare. 51820/udp is the WireGuard handshake port for remote access.

Port 80 exists as a disabled rule. I leave disabled-but-documented rules in the config on purpose; they’re a paper trail for “this used to be exposed, here’s why it isn’t anymore.” Deleting them loses that context.

Nothing else is forwarded. No UPnP. No NAT-PMP. If a device wants to be reachable from outside, I add the rule by hand.

VLAN policy

The LAN rule is broad: trusted hosts can reach anything. The two VLANs get narrower treatment.

IoT VLAN (VLAN20)

• Can reach the router for DNS (53) and NTP (123). Nothing else on LAN.
• Can reach WAN on 80/443. That’s it.
• Blocked from every other internal subnet.

Guest VLAN (VLAN30)

• Can reach WAN on 80/443. Nothing else.
• Blocked from LAN, IoT, and the router’s management ports.
• Uses its own DHCP scope (192.168.30.50–200) with the router itself as DNS.

Guest users regularly ask why their work VPN client doesn’t connect. That’s not a bug. Guest is guest; if somebody needs a real tunnel, they’re not on guest.

DNS is the interesting part

I run Dnsmasq (not Unbound) across all three interfaces. Domain is home.lan. Upstream is Cloudflare 1.1.1.1 and 1.0.0.1. DNSSEC is off, which I’ll come back to. Authoritative DHCP is on, so DHCP leases produce DNS records for every host automatically.

The interesting part isn’t the resolver. It’s the firewall rules around it.

Forcing IoT through the router

Most cheap smart devices ship hardcoded with Google DNS (8.8.8.8) or similar. They don’t care what DHCP tells them; they use whatever the vendor baked in.

So there’s a NAT redirect on the IoT VLAN that rewrites any outbound connection to *:53 and sends it back to 192.168.1.1:53. The device thinks it’s talking to Google. It’s actually talking to OPNsense. From the device’s point of view, nothing changes. From my point of view, every DNS lookup for every IoT device is now logged locally and subject to the same filters as everything else.

The alias that drives this (TP_LINK) started as one device and grew organically. It now covers the usual IoT suspects including the NVR.

Killing the DNS escape hatches

DNS hijacking works until a device decides it would rather use DNS-over-HTTPS or DNS-over-TLS to bypass your resolver entirely. Modern OSes will happily do this without asking.

Three rules cover the escape routes:

• block-dns-tls-853 — drops TCP/853 outbound (DoT).
• block-doq-quic-853 — drops UDP/853 outbound (DoQ).
• block-doh — drops outbound to an alias called doh_providers.

doh_providers is a dynamic URL table alias. It pulls from the awesome-dnscrypt DoH server list on a 30-minute refresh. The alias updates itself; I don’t maintain it.

This isn’t perfect. DoH hiding inside a general HTTPS flow on port 443 is indistinguishable from any other HTTPS traffic without deep inspection, and I’m not terminating TLS at the edge. What the blocklist catches is lazy implementations that connect directly to a known public DoH provider’s IP, which is most of them.

The goal isn’t to stop a determined adversary. It’s to stop my smart TV from quietly ignoring my DNS server because its firmware author thought that was a reasonable default.

Aliases that earn their keep

Most aliases are boring host groups. A few are worth calling out.

• doh_providers — the dynamic DoH blocklist described above.
• crowdsec_blocklists / crowdsec6_blocklists — external aliases driven by CrowdSec. These hold the IPs that CrowdSec has decided are hostile. Any firewall rule referencing these aliases gets the current set of bad actors without me maintaining a blocklist manually.
• CLOUDFLARE_IPS — Cloudflare’s edge ranges. Used to scope inbound rules so that services meant to sit behind Cloudflare only accept connections from Cloudflare’s IP space. Anything hitting those services directly at my IP gets dropped.
• TP_LINK — the IoT forcing-function alias. Named after what started it. Now overloaded with everything in the “must be hijacked for DNS” bucket.
• TOR_RELAY — single-host alias pointing at the Tor machine. Useful for bundling rules even when the alias has one entry, because when the hostname inevitably moves, I change it in one place.

CrowdSec is doing the heavy lifting

The earlier home lab post mentioned Suricata. That’s no longer what’s on the box.

OPNsense now runs CrowdSec as the main threat-intel layer:

• Agent enabled — parses local logs and identifies scanning, brute-force, and common exploit patterns.
• LAPI enabled — the local API that the bouncer talks to.
• Firewall bouncer enabled — actively drops traffic from IPs flagged by the agent or by the CrowdSec community feeds.
• Rules enabled — the community scenarios load and run automatically.

CrowdSec is cheaper on CPU than Suricata was, and its blocklist model fits the home lab better than a full IDS pipeline. Suricata gave me floods of alerts I wasn’t going to investigate. CrowdSec gives me “this IP has been a problem elsewhere, dropped at the firewall.” Less signal, but the signal it produces is directly actionable because the action already happened.

I lost some visibility moving away from Suricata — notably per-flow inspection rules for specific CVEs. That trade-off has been fine for this environment. If this were an enterprise edge I’d run both.

Observability

A firewall with no telemetry is a box with opinions you can’t verify.

• NetFlow v9 is enabled on LAN and WAN, with WAN set to egress-only. Export target is a local collector at 127.0.0.1:2056 that ships flow records into the metrics stack on Alecto. Active timeout 30 min, inactive 15 sec.
• vnstat runs against the WAN interface for long-term bandwidth counters. It’s the “how much did I actually use this month” graph, not a security tool.
• Zabbix agent is enabled, reporting to Alecto. CPU, memory, interface counters, states table, per-rule hits. The Zabbix server decides what to alert on; the firewall just emits data.

The alerting philosophy is the same as the one in the honeypot post. The firewall is not the thing that should decide what’s worth waking me up over. Its job is to produce honest signal. Somebody else’s job is to filter it.

Hardening that isn’t glamorous

None of this is interesting to read. All of it matters more than the DoH blocklists.

• Web GUI is HTTPS-only. HSTS is on. The cert is self-signed because the GUI is only reachable from LAN and I’d rather pin the cert than introduce an ACME dependency for a single internal endpoint.
• Console menu is disabled. Physical access to the box doesn’t immediately give you the OPNsense menu. It gives you a login prompt.
• NAT reflection is off — fewer surprises with internal traffic taking unexpected paths.
• SSH is bound to LAN only, group-restricted to admins. It’s one of the few places I’m still running password auth with root allowed. Not because I think it’s fine, but because the exposure surface (LAN-only) makes it low-risk and a key-only migration is on the list below.
• Bogon updates run monthly. Reserved/unallocated prefixes change less often than people think, but they do change.
• Backups go to Google Drive via os-gdrive-backup on a schedule. The XML config is small enough that a month of daily snapshots costs nothing and saves hours if I ever have to rebuild.

Gateway monitoring

Single WAN, no failover. The gateway monitor pings 1.1.1.1 continuously with alert thresholds at 30% packet loss (low) and 35% (high), and 300ms latency (low). If the line is bad enough to notice, OPNsense will flag the gateway before I do.

No multi-WAN yet. The second ISP option in my area isn’t worth the monthly cost for the uptime I actually need. If that changes, gateway groups are already half-configured.

What I’d change

A few things are genuinely outstanding, not just aspirational.

• Turn on DNSSEC. Dnsmasq supports it; I disabled it years ago when a misbehaving internal service was breaking on stale signatures. That reason is long gone.
• Move SSH to key-only, disable root login. The exposure is LAN-only today but the migration is trivial and overdue.
• Ship syslog off-box. Right now logs live on OPNsense and get rolled locally. A remote syslog destination (somewhere on LAN, not off-site) would survive a firewall rebuild and give me history during incident response.
• Terminate TLS on a reverse proxy for the services that sit behind Cloudflare. Right now the tunnel ends on Boreas with NPM, which is fine. Moving cert management to an ACME plugin on OPNsense for the few public services would remove a moving part.
• Split LAN. The LAN rule is still “trusted hosts can reach everything.” That worked when LAN was five devices. It’s less defensible now. A management VLAN separate from a workstation VLAN is the next logical step.

Closing

The interesting parts of this config aren’t the exotic features. They’re the boring ones: a DNS policy that assumes devices will lie, per-VLAN egress rules that default to deny, inbound exposure that fits on a single screen, and telemetry that lets somebody else decide what’s worth acting on.

OPNsense makes all of that reachable from a UI without punishing you for running CLI alongside it. That’s a rarer combination than it sounds.

If you’re standing one up from scratch and wondering where to start: segment the network, hijack DNS on the untrusted segments, block the DNS escape hatches, and wire up telemetry before you wire up rules. Everything else is refinement on top of that.