Lockout risks and prevention — every way an operator can lock themselves out

Lockout is the failure mode unique to a firewall: the device you depend on for access is the device that just locked you out. Unlike a server that loses its SSH key, the operator cannot “just reboot and fix it” — the firewall is also the path between the operator and the rest of the network. A lockout that requires console access in a remote data centre is a multi-hour recovery; a lockout that requires console access during a weekend with no on-site staff is a service-affecting incident.

This lesson covers the lockout modes OPNsense operators encounter, the warning signs of an imminent lockout, and the prevention patterns that keep recovery paths available.

The lockout modes

Six lockout modes account for most production incidents:

1. GUI lockout by rule change. The operator adds a rule that blocks the GUI source (LAN, management VLAN, or operator host) from reaching the firewall IP on 443. The next time the operator opens the GUI, the connection is refused or times out.
2. GUI lockout by source restriction. The operator enables source restrictions on the GUI bind, scoping the GUI to specific source IPs. The operator’s source IP is not in the list (typo, wrong VLAN, wrong subnet). The GUI is unreachable from the operator’s workstation.
3. SSH lockout by disabling password auth. The operator disables password authentication while the only authentication method available is a password (no SSH key deployed). SSH refuses the password login and the operator cannot SSH in.
4. 2FA lockout. The operator enables two-factor authentication and then loses the authenticator (broken phone, lost device, factory-reset). TOTP cannot be provided; the GUI and SSH refuse the login.
5. Certificate lockout. The operator installs a new TLS certificate for the GUI and HSTS is enabled with a long max-age. The browser refuses to connect because the certificate is invalid or because HSTS prevents downgrade. Recovery requires an out-of-band path.
6. Boot environment lockout. The operator reboots into a previous boot environment that has different configuration. The current credentials do not work; the rules are different; the interfaces are different.

Each lockout mode has a different recovery path. The prevention pattern is the same: maintain a tested out-of-band path that does not depend on the thing being configured.

Warning signs of an imminent lockout

A configuration change has warning signs. The operator who recognises them pauses and verifies before continuing.

GUI lockout warning signs:

• The rule being added affects the operator’s source IP or subnet.
• The rule is on the interface the operator uses to reach the GUI.
• The rule has quick and a block or reject action.
• The anti-lockout rule is being disabled or modified.

SSH lockout warning signs:

• The SSH configuration disables password auth and no key is deployed for the operator’s account.
• The SSH configuration restricts to a source IP the operator does not have.
• The SSH configuration changes the listen port without confirming the operator’s tooling uses the new port.

2FA lockout warning signs:

• The 2FA is being enabled for the only administrator account.
• The 2FA recovery codes are not stored in a password manager.
• The 2FA is being enforced without a “verification window” (a grace period where 2FA is enabled but not required).

Certificate lockout warning signs:

• A new certificate is being installed and HSTS is enabled with a long max-age.
• The certificate does not include the SANs the GUI uses.
• The CA chain is not deployed to the operator’s workstation.

The discipline is to enumerate the warning signs before applying the change. If any warning sign is present, the operator must verify a tested recovery path before applying.

Prevention patterns

Five prevention patterns reduce lockout risk:

1. Keep the anti-lockout rule enabled on the LAN. The anti-lockout rule allows TCP 80/443 from the LAN subnet to the firewall’s LAN IP. With it in place, the operator can reach the GUI from any LAN host even if every other rule is wrong. Disable only with a tested alternative.
2. Maintain a separate management interface. A dedicated management VLAN or interface, with its own ruleset, gives the operator a path that is independent of the LAN/WAN rulesets being changed.
3. Tested break-glass account. A local account with a known password, an SSH key, and no 2FA requirement. The break-glass account is the path that does not depend on the external identity store, the SSH key rotation, or the 2FA enrolment. Test it quarterly.
4. Console access verified during installation. The serial console, BMC SOL, or KVM over IP must work during install. Test during provisioning, not during the incident.
5. Configuration backup before every change. A recent, tested backup means a misapplied rule change can be reverted without console access. Backups are taken via the GUI, the API, or configctl config backup.

Soft vs hard lockouts

A soft lockout is recoverable through the GUI, SSH, or another network path. A hard lockout requires console access.

The hard lockouts all share one thing: the recovery path requires physical access (or its virtual equivalent — BMC SOL, KVM over IP, serial console). The prevention is to verify the console path during provisioning and re-verify it after any hardware change.

$ ssh operator@198.51.100.1 'pfctl -s rules | grep -E lockout | head -5'

@1 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to 192.0.2.1 port = https
@2 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to 192.0.2.1 port = http

The minimum lockout-resilient configuration

A production OPNsense firewall should have, at minimum:

1. Anti-lockout rule enabled. System → Settings → Administration → “Disable anti-lockout webgui lockdown” unchecked.
2. Local break-glass account. A local user with a strong password, an SSH key, and no 2FA requirement.
3. Tested console path. Serial console, BMC SOL, or KVM over IP tested during provisioning.
4. Recent configuration backup. Stored off the firewall, with a tested restore procedure.
5. Source-restricted management access. If source restrictions are used on the GUI, the operator’s source IP must be in the list before the restriction is enabled.
6. Documented escalation path. A runbook that names the console location, the BMC URL, the break-glass credentials, and the steps to recover from each lockout mode.

The lockout-resilient configuration is verified at provisioning and re-verified after any change to the firewall’s authentication, source restrictions, or interface assignments.

Summary

• Six lockout modes: GUI by rule change, GUI by source restriction, SSH by disabling password auth, 2FA, certificate, boot environment.
• Warning signs of an imminent lockout should pause the change and trigger verification of a tested recovery path.
• Five prevention patterns: anti-lockout rule, separate management interface, tested break-glass account, verified console access, configuration backup before every change.
• Soft lockouts are recoverable from the network; hard lockouts require console access. Verify the console path during provisioning.
• A break-glass account that has not been tested may not work when needed. Quarterly test.