This is part 1 of a 4-part series on running OPNsense at home. Part 2: Securing the Network covers DNS, ad blocking, IDS, and hardening. Part 3: Connectivity covers dual WAN, WireGuard, and bufferbloat. Part 4: Observability covers the logging and monitoring stack.

For a while, a GL.iNet Flint 2 (running GL.iNet's firmware, which is based on OpenWrt) handled everything at home: dual WAN failover via mwan3, a WireGuard server, basic DNS filtering. It worked. Then I wanted to run Suricata at wire speed, and the Flint 2 hardware is not remotely equipped for that. Once you start pulling on that thread the rest unravels quickly.

This is the writeup of what I replaced it with, how I set it up, and the things that tripped me up that I did not find documented anywhere useful.

The hardware

I looked at a few options. The Protectli Vault FW4B comes up in every forum thread: four Intel NICs, fanless, purpose-built for firewall appliances, starting around $200 barebones. The VP series (VP2430 and up) covers higher-end configurations. There is also a whole category of cheap N100 mini-PCs (HUNSN, CWWK, MOGINSOK and similar) that are popular because they are inexpensive, but they are less proven in long-running configurations and often ship with Realtek NICs, which have a bad reputation in BSD networking stacks.

I ended up with a Protectli VP6650: six Intel NICs (four 2.5GbE, two 10G SFP+), an Intel i5-1235U, 32GB RAM, 1TB NVMe. Overkill for a home network by any reasonable measure.

The Intel NIC point is not incidental. OPNsense is FreeBSD-based, and FreeBSD's driver support for Realtek and MediaTek NICs is spottier than Linux's. If you are buying hardware for OPNsense specifically, Intel NICs are the safe choice.

Why OPNsense, and why BSD

OPNsense is built on FreeBSD, which matters for a few reasons. The BSD networking stack has a long track record in routing and firewall applications. The packet filter (pf) originated on OpenBSD and is deeply integrated into the BSD kernel rather than bolted on. BSD releases are slower and more deliberate than Linux distributions, which is the right tradeoff for something running 24/7 as your network perimeter.

OPNsense forked from pfSense in 2015. Both are BSD-based. The practical difference today is that OPNsense has a cleaner plugin architecture, more frequent security updates, and a UI that does not feel like it was designed in 2009.

The main tradeoff is hardware support, which is narrower than Linux. That is why the NIC choice matters.

Network layout

My setup has several physical zones connected to the VP6650:

• Two WAN interfaces: fiber (primary) and a 5G home internet gateway (failover), each on its own port
• WiFi access point on a dedicated port, isolated subnet
• Raspberry Pi on its own port, isolated, running only a Cloudflare tunnel daemon
• Wired segments for different parts of the house, each on their own subnet

The Raspberry Pi isolation is deliberate. The tunnel daemon is the only thing on that port. If the tunnel is ever compromised, it does not touch the firewall.

First boot: what to expect

OPNsense ships with a working default config for basic WAN and LAN. After install, it assigns a LAN IP (192.168.1.1), runs DHCP, enables automatic outbound NAT, and has a default pass rule on LAN. If you plug a laptop into the LAN port, it will get an IP and reach the internet. In that sense it works like any home router.

Where OPNsense diverges from a consumer router is everything after that first port. Every additional interface, VLAN, or tunnel you add starts with nothing: no IP, no DHCP, no firewall rules. You have to configure each one explicitly, and you have to write a firewall rule to allow traffic through it. That is by design, and it catches you the first time you add a second subnet and wonder why it has no connectivity.

If something is not working on any interface, check these three things in order:

1. Interfaces > [interface name]: does it have an IP assigned and is it enabled?
2. Firewall > NAT > Outbound: is automatic outbound NAT enabled? Without this, traffic from that subnet has no way to get translated to your WAN IP.
3. Firewall > Rules > [interface name]: is there a pass rule? No rule means no traffic.

You can test connectivity from OPNsense itself before involving any clients: Interfaces > Diagnostics > Ping, ping 8.8.8.8 from the WAN interface. If that works, the problem is in your rules or NAT config, not the upstream connection.

Was it worth it

The GL.iNet Flint 2 was a good device for what it is. If you want a travel router with OpenWrt-based flexibility and do not need wire-speed IDS or clean multi-WAN failover, it is still a reasonable choice. I outgrew it in a specific direction: I wanted to know what was on my network, I wanted active threat blocking, and I wanted failover I could trust. OPNsense on purpose-built hardware delivered all three.

The setup took longer than it should have, mostly because the multi-WAN gateway group step is easy to miss. The firewall rule change that connects the gateway group to actual traffic is not mentioned in most guides I found. Hopefully this saves someone an afternoon.

Next: Part 2: Securing the Network covers DNS security, ad blocking, Suricata IDS, and hardening.