Before deploymentchange-management

Pre-Change Checklist

16 items ·10 critical ·5 warn ·1 info

The OPNsense firewall is on the critical path of nearly every service, so a planned change without a tested rollback is not a change — it is a hopeful experiment. The pre-change checklist captures the discipline that lets a change window be short, the rollback predictable, and the stakeholders confident.

When to use

Use this checklist before any planned change to an OPNsense firewall: rule set changes, NAT changes, firmware upgrades, plugin installs, interface changes, VPN changes, and HA configuration. Use it for both service-affecting and non-service-affecting changes; the latter still need a change record and a backup.

How to use

Open the change record, walk the list, capture artefacts (configuration export, baseline metrics, rollback plan) against the record, and close the pre-change review with the change authority. Anything with severity critical must be satisfied before the change window opens.

Critical10 items

A change record exists with a clear description, the affected firewall, the affected services, and the change window.
Rollback plan is documented step by step, including the configuration snapshot used as the rollback point.
```
System > Configuration > Backups; export a copy to the change record.
```
Affected systems are listed (downstream hosts, services, partners) with explicit owners and contact paths.
Maintenance window is scheduled (if service-affecting) and posted on the operator calendar with the change record link.
Stakeholders have been notified at least one business day in advance for non-emergency changes; emergencies are escalated first.
A configuration backup / XML export has been taken and stored against the change record.
```
System > Configuration > Backups > "Download configuration".
```
Validation criteria are explicit: which tests will be run after the change, with expected pass conditions.
Approval from the change authority is recorded (per the operator change policy).
A communication channel is open (war room, on-call bridge) and the operator can reach the change author during the window.
A rollback time budget is set: if the change is not validated within X minutes, rollback is initiated.

Warning5 items

Affected users are listed (which subnets, which services, what user-visible behaviour will change).
A test plan in staging or a lab instance has been executed for non-trivial changes (rule set rewrites, NAT changes, plugin changes).
Maintenance mode flag is set on HA pairs so the firewall does not fail over during the change.
```
System > High Availability > Settings; "Persistent maintenance" mode.
```
Backup paths for the change (e.g. revert via XML restore) have been dry-run-tested before the window opens.
For HA pairs, the change is sequenced: primary node first, validation, then secondary.

Info1 item

Pre-change baseline metrics are captured: state table size, CPU, memory, interface counters, log volume.
```
pfctl -ss | wc -l; top -b -n 1; netstat -I.
```