8. OOB management¶
Do this on both nodes — OOB addressing is per-node and the rules protect each box.
A dedicated USB NIC (OOB) gives SSH (22) and the web GUI/API (443) for managing the
firewall, and nothing else — no routing, no transit.
You already addressed OOB in page 2 §2.4
(static, no gateway, no VIP). This page locks it down.
8.1 Why there's no gateway and no route¶
DESIGN §7.3's OOB gateway gw-oob-1 source-NATs all VPN clients into <OOB_NET>.
So OPNsense only ever sees management traffic from an on-link source, and replies
go straight back out OOB — no gateway, no static route, no policy routing needed.
This is what structurally prevents OOB from becoming a transit/backdoor path.
It also avoids a real bug
With no gateway on OOB, replies to a remote client would otherwise follow the
default route out the WAN and die on asymmetry. The upstream source-NAT is what
makes that impossible — so gw-oob-1's source-NAT is a hard precondition, not
a nicety. If OOB management "hangs", check that NAT first, not the OPNsense rules.
8.2 The honest limit — forwarding is global¶
net.inet.ip.forwarding is global on a router; you cannot disable forwarding per
interface. "No routing on OOB" is therefore enforced by absence of routes + firewall
rules, not a kernel property. So the rules below are load-bearing.
8.3 OOB firewall rules¶
Firewall ▸ Rules ▸ OOB, in order:
| # | Action | Source | Destination | Port | Notes |
|---|---|---|---|---|---|
| 1 | pass | <OOB_NET> |
This Firewall | 22 (SSH) | management |
| 2 | pass | <OOB_NET> |
This Firewall | 443 (GUI/API) | management |
| 3 | pass | <OOB_NET> |
This Firewall | ICMP echo | reachability |
| 4 | block | <OOB_NET> |
RFC1918 (10/8,172.16/12,192.168/16) |
any | anti-pivot |
| 5 | block | any | any | any | default drop |
No OOB pass rule may target another network
Rules 1–3 all destination This Firewall. No pass rule on OOB may have a
destination that is another network — that single discipline is the no-transit
guarantee, since the kernel won't enforce it for you. Rule 4 is belt-and-braces so
OOB can't become a pivot even if someone later fat-fingers a permissive rule.
8.4 Keep OOB out of routing¶
- No
networkstatement, no redistribution, no BGP neighbour onOOB(it isn't in the FRR config — confirm on page 5). - No CARP VIP on
OOB— a VIP would follow the master and leave the backup unreachable, defeating the point. Each node is reached at its own<OOB_FW01>/<OOB_FW02>.
8.5 What this unlocks¶
- Manage each node independently over OOB regardless of who holds CARP master — which is exactly what monitoring needs ("monitor both nodes over OOB, never the data path", §14).
- Break-glass remains the BMC/KVM on the OOB switch if the USB NIC itself drops
(its
ue0/ue1re-enumeration risk — page 1). OOB-over-USB is a convenience path; the BMC is the last line.
Monitor the rescue path itself
The OOB interface must be explicitly included in Zabbix and alerted on
link-down — the one interface you most need to know about. This is the deliberate
exception to the "filter out interface noise" advice on page 9.