Bill Gernert
Networking & Edge

OPNsense

The firewall and router between the lab's segments - where default-deny is enforced, and where a rule's position on the list matters as much as what the rule says.

What it is & why I use it

OPNsense is the firewall and routing brain of AutomationLab. It routes between the role-based network segments and enforces what may cross between them. If VLANs draw the boundaries, OPNsense is what actually decides whether a given packet is allowed over one - it is where inter-segment policy lives and is enforced.

I use it because it gives me a real, inspectable firewall with a full rule model rather than a black-box appliance. That matters for a lab whose whole point is understanding the system end to end: I can see exactly which rule permitted or dropped a flow, and why.

How I use it in the lab

  • Router between segments. It carries and filters traffic between the role-based network segments, so cross-segment flow is a firewall decision, not an open path.
  • Default-deny, explicit allows. The baseline between segments is deny; the specific flows that are actually needed are permitted by named, justified rules.
  • Enforces the crown-jewel boundary. The most sensitive segments get the tightest rule sets, so very little is even permitted to reach them across a boundary.
  • The management path is itself protected. Access to the firewall's own administration is constrained - the thing that controls the network is not casually reachable from everywhere on it.

Architecture

Diagram coming Role-based segments meeting at the firewall, default-deny between them with explicit allows, and a protected management path. Scrubbed of interfaces, VLAN IDs, subnet ranges, and addresses.

In action

Screenshot coming A rule set showing default-deny with ordered, specific allows, and a live log of a flow being matched. Captured per the publishing checklist - interfaces, VLAN IDs, subnets, and addresses redacted.

Lessons learned & gotchas

Gotcha - rule order decides the outcome, and a bad rule can lock you out Two things about firewall changes that punish carelessness. First, rules are first-match, top-down: a broad allow sitting above a specific deny wins, so two rule sets with the identical rules in a different order enforce different policy. "The deny is there" is meaningless if a permissive rule above it matches first - position is policy. Second, the firewall is the one device that can sever your own access to it: apply a management or cross-segment rule that blocks the very session you are working over, and you have locked yourself out of the box that controls the network. The discipline is to make firewall changes so a bad one reverts on its own if you do not confirm it - change, verify you still have access, then commit - rather than applying a rule that could strand you with no way back in.
  • Read rules in evaluation order, not as a set. When a flow behaves unexpectedly, walk the rules top-down as the firewall does - the first match wins, and the rule you assumed applied may be sitting below one that caught the packet first.
  • Never blind-apply a change to the path you are on. A rule touching management or the segment you are connected over gets applied with a rollback safety net, so a mistake reverts instead of locking you out. This is the network cousin of ensuring SSH stays permitted before a default-deny lands.
  • Log the denies you care about. A silent drop looks identical to a misconfiguration. Logging the important denies turns "why is this not working?" into a visible, matched rule you can actually reason about.

Impact

Deny
by default between segments
Order
is policy, first match wins
Rollback
on risky rule changes

OPNsense is where the lab's segmentation stops being a diagram and becomes enforced policy. The lasting lessons are that a firewall rule's position is as load-bearing as its content, and that the device controlling the network is the one most able to lock you out of itself - so you change it in a way that fails safe, verifying access before you commit.

Code & further reading

Firewall notes (link coming) OPNsense docs

Any published firewall notes are scrubbed of interfaces, VLAN IDs, subnet ranges, addresses, and rule detail before they go public.