OPNsense
13 posts on OPNsense: design decisions and how-to guides from small infrastructure estates run on a very low budget.
- OPNsense: announce your own prefix with FRR BGP
The FRR plugin on an OPNsense pair is enough to announce a portable /24 to a transit provider. The settings that matter, the blackhole route without which nothing is advertised, strict filters both ways, and how to confirm the announcement from outside.
Announce your own /24 from an OPNsense pair: BGP without a router budgetProvider-assigned addresses lock you to a contract and turn every service IP into a migration project. A portable prefix, an ASN and FRR on OPNsense are enough. The decisions that made the first announcement boring.
- OPNsense: retire a public IP address without a blackhole
An alias nothing referenced was deleted during a cleanup and a routed /28 went dark for about 26 hours. The procedure that came out of it, from the inventory of references to the provider's written confirmation, dual-running the replacement, deleting on both nodes and probing from outside.
- OPNsense as the routing peer for a NetBird mesh
Install the NetBird agent on both firewalls of an HA pair, advertise one route per VLAN with the pair as routing peers, add the outbound NAT the agent's masquerade does not cover, filter on the overlay interface, and avoid the endpoint trap that drops large packets.
- OPNsense: keep ACME certificates valid on both HA nodes
The ACME client renews on the node it runs on. The backup keeps serving whatever it had, which after ninety days is an expired certificate at the worst possible moment. A daily copy, an import on the backup, and a fingerprint check that tells you when they differ.
- OPNsense: fix HA config sync that stopped syncing
The backup looks healthy and is a month behind. How to tell, what actually triggers the XMLRPC sync, what never syncs at all, and a drift check you can run from a laptop every fifteen minutes.
OPNsense HA that actually fails over: VHID 1 everywhere, and the sync that is not automaticTwo firewalls are only a pair if the backup holds the master's config. The VHID numbering that scales past VLAN 255, the config sync that only runs when asked, and the drift audit that caught rules living on one node.
- OPNsense: split-horizon DNS with Unbound forward zones
Internal zones forwarded to the per-site authoritative server, public names overridden to internal addresses for internal clients, and DNS over TLS to the upstream. Plus the test that proves the public answer is right, which is not the one you run from your laptop.
- OPNsense: manage aliases, rules and NAT from Python
The OPNsense API is good enough to run an estate's firewall policy from a script, as long as the script reads back every write, marks what it owns, and remembers that the HA sync will not run on its own. A working pattern with requests.
- OPNsense: VLANs on a trunk from a Catalyst, with Kea DHCP
Adding a tenant VLAN to an OPNsense pair fed by a Catalyst trunk, from the switch port to the CARP gateway, the firewall rule order that keeps tenants apart, and a Kea DHCP pool for provisioning. Done twice, because there are two nodes.
- Catalyst 3850: trunks with a native VLAN that does not exist
Set every trunk's native VLAN to one you never create, so untagged frames vanish instead of landing in VLAN 1. Then carry the provider's WAN handoff through the stack as a tagged VLAN to both firewalls.
- OPNsense: port forward to a VM behind a CARP pair
A port forward on an HA pair has to land on the shared WAN address, not a node's own, and it has to exist on both nodes. The forward, its filter rule, why NAT reflection is the wrong fix for the inside test, and how to test from outside properly.
A VLAN scheme you can derive in your headSegmentation fails when nobody can remember it. Encode site, VLAN and role into the address so a firewall rule, a DHCP reservation and a MAC can all be derived from a tenant number.