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 and whyHow I use it inArchitectureLessons learned and gotchasImpactFurther reading

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

OPNsense architecture: Default-deny routing boundary Role-based segments meet at OPNsense, default-deny evaluates first, specific rules permit justified flows, and the management path remains separately constrained. ARCHITECTURE FLOW DEFAULT-DENY ROUTING BOUNDARY Role-based segments: Infrastructure, compute, identity ROLE-BASED SEGMENTS Infrastructure, compute, identity Firewall boundary: All cross-segment traffic meets here FIREWALL BOUNDARY All cross-segment traffic meets here Default deny: Unjustified traffic stops DEFAULT DENY Unjustified traffic stops Ordered rules: The first matching rule decides ORDERED RULES The first matching rule decides Explicit allow: Permit one justified flow EXPLICIT ALLOW Permit one justified flow Protected destination: Service and management stay scoped PROTECTED DESTINATION Service and management stay scoped Cyan. Automated step or path. Amber. Operator or policy gate. Green. Recorded or healthy outcome. Rounded box. Actor or process. Arrow. Direction of work or data.
Role-based segments meet at the firewall, which applies default-deny, ordered explicit allows, and a protected management path. Interfaces, VLAN IDs, subnet ranges, and addresses are omitted.

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.

Further reading

OPNsense docs