Anti-lockout rule and defaults — the safety net that lets you change other rules

The anti-lockout rule is the most important auto-generated rule on OPNsense. It exists to prevent the operator from locking themselves out when they change other firewall rules. With the anti-lockout rule in place, even if every other rule on the LAN is wrong, the operator can still reach the GUI from the LAN.

This lesson covers the anti-lockout rule in detail — what it allows, where it sits in the ruleset, when it is generated, and the production patterns for source-restricted management that replace it without disabling it.

What the anti-lockout rule allows

The anti-lockout rule permits:

• TCP port 80 (HTTP) from the LAN subnet to the firewall’s LAN IP.
• TCP port 443 (HTTPS) from the LAN subnet to the firewall’s LAN IP.

The rule does not permit SSH (port 22) or any other service. It is specifically scoped to GUI access. With the rule in place, the operator can open a browser on any LAN host and reach the GUI; even if every other rule on the LAN is wrong, the GUI is reachable.

$ pfctl -s rules | grep -B 1 -A 1 lockout | head -10

@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

Where the anti-lockout rule sits

The anti-lockout rule is auto-generated by the OPNsense filter generator. It is inserted at the very top of the LAN interface ruleset (or whichever interface is configured as the LAN). Because PF is first-match-wins with quick, the rule matches before any user rule can shadow it.

The rule’s position in the compiled ruleset is fixed:

@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
@3 pass out all                                          ← let-out-any
@4 block drop in quick on igb1 inet from 10.0.0.0/8 ...   ← anti-spoofing
...
@45 pass in quick on igb0 ...                              ← user rules start here

The rule sits above the let-out-any rule, the anti-spoofing rules, and all user rules. There is no user rule that can shadow it.

When the anti-lockout rule is generated

The anti-lockout rule is generated when:

• The interface configured as the LAN exists.
• The setting System → Settings → Administration → "Disable anti-lockout webgui lockdown" is unchecked.

The rule is not generated on other interfaces unless the operator explicitly enables it. A management VLAN configured as an OPT interface does not get an anti-lockout rule by default. The operator who expects the management VLAN to have an anti-lockout rule will be surprised.

Verifying the anti-lockout rule

The verification is one command. Run it after every firewall restart, every interface reassignment, and every major rule change:

pfctl -s rules | head -5

The output should show the anti-lockout rule at the top:

@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

If the rule is missing, the operator must restore it before any other change. The setting System → Settings → Administration → "Disable anti-lockout webgui lockdown" controls whether the rule is generated. Re-enable it if necessary, apply, and re-verify.

When to disable the anti-lockout rule

The anti-lockout rule should almost never be disabled. The reasons an operator might consider disabling it:

1. Strict source restrictions. The operator wants to scope GUI access to specific source IPs (an operator_hosts alias). The anti-lockout rule permits any LAN source; the operator wants to override this.
2. DMZ-like posture. The LAN is not trusted; an attacker on the LAN should not reach the GUI. The anti-lockout rule permits any LAN source.
3. Strict compliance. A compliance framework requires that all rules be explicitly enumerated; auto-generated rules are not allowed.

In each case, the answer is not “disable the anti-lockout rule”. The answer is:

• For source restrictions: keep the anti-lockout rule as a fallback. Add a more specific rule above it that restricts GUI access to the operator_hosts alias. First-match-wins means the more specific rule matches first; the anti-lockout rule is the fallback for other LAN sources.
• For DMZ-like posture: do not put user workstations on the LAN. Use a management VLAN with its own ruleset; do not disable the LAN anti-lockout rule.
• For compliance: the anti-lockout rule is a safety net that the compliance auditor can be shown as a baseline; explicit rules are layered above it.

Source-restricted management: the production pattern

The production pattern for source-restricted management:

1. Define an alias operator_hosts containing the IPs of operator workstations.

2. On the LAN interface, add a rule above any other rule:

   pass in quick on igb0 inet proto tcp from <operator_hosts> to 192.0.2.1 port = https

3. Below that rule, keep the anti-lockout rule (the auto-generated rule at the top):

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

The order is important. The source-restricted rule matches first for operator hosts; the anti-lockout rule is the fallback for other LAN sources. If the operator’s source IP is in the alias, the more specific rule matches. If the operator’s source IP is not in the alias (typo, wrong subnet, wrong VLAN), the anti-lockout rule still matches.

For a management VLAN:

1. Create a VLAN interface as an OPT interface.

2. Assign a subnet.

3. Add an explicit allow rule on the VLAN interface:

   pass in quick on igb0_vlan10 inet proto tcp from <operator_hosts> to 10.0.10.1 port = https
   pass in quick on igb0_vlan10 inet proto tcp from <operator_hosts> to 10.0.10.1 port = ssh

4. Do not rely on the anti-lockout rule — it does not apply to OPT interfaces by default.

The explicit allow rule on the management VLAN is the safety net for that VLAN. If the operator changes the rule and locks themselves out of the management VLAN, they must reach the GUI via the LAN (which has the anti-lockout rule) or via the console.

Verification

After any change to the anti-lockout rule setting, the LAN interface assignment, or the management ruleset, verify:

1. pfctl -s rules | grep lockout — confirms the anti-lockout rule is present.
2. From a host on the LAN (or the management VLAN), attempt to reach the GUI on 443 — confirms the rule matches.
3. From a host on the LAN (or the management VLAN), attempt to reach the GUI on 80 — confirms the HTTP rule matches.
4. From the firewall itself, run pfctl -s rules | head -10 — confirms the rule sits at the top of the compiled ruleset.

A fix that passes 1-3 but fails 4 is a configuration drift between the GUI and the kernel. Reboot or pfctl -f to reload the ruleset.

Summary

• The anti-lockout rule permits TCP 80/443 from the LAN subnet to the firewall’s LAN IP, sitting at the top of the LAN ruleset.
• It is generated by default on the LAN interface and not on OPT interfaces.
• Verify the rule is present at every change window with pfctl -s rules | grep lockout.
• The production pattern for source-restricted management is to add a more specific rule above the anti-lockout rule, not to disable the anti-lockout rule.
• Disabling the anti-lockout rule requires a tested alternative path: console access, break-glass SSH, and an explicit SSH allow rule.