Automatic rules and default allow

OPNsense generates several firewall rules automatically. They are not visible in the GUI as separate rules — they appear in the compiled filter.conf as if they were regular rules. The operator must understand what these auto rules do, why they exist, and how to disable the ones that conflict with the production posture.

This lesson covers the auto-generated rules OPNsense produces by default, the anti-lockout rule in particular, the “let-out-anything-from-firewall-itself” rule, and the production pattern for keeping the auto rules that are needed and disabling the ones that are not.

The auto-generated rules

OPNsense generates four categories of automatic rules. They appear in the compiled filter.conf at specific positions.

1. Anti-lockout rule (LAN by default)

The anti-lockout rule allows TCP 80 and TCP 443 from the LAN subnet to the firewall’s own LAN IP. The rule 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.

The anti-lockout rule is generated by default on the LAN interface. It is not generated on other interfaces unless the operator explicitly enables it.

2. Let-out-any-from-firewall rule

The let-out-any rule allows the firewall itself to initiate outbound traffic to any destination. The rule is required because the firewall makes outbound connections for many purposes: DNS queries, NTP, plugin update checks, syslog delivery, API calls to cloud services, and more.

Without the let-out-any rule, the firewall could not perform any of these functions. Every service that needs outbound access would have to be explicitly allowed in a per-service rule, which is fragile and impractical.

3. Anti-spoofing rules

The anti-spoofing rules block traffic with source IPs that should not appear on a given interface. The classic example: block traffic arriving on the WAN with a source IP from an RFC 1918 range, because no host on the Internet has an RFC 1918 source. The block prevents an attacker from injecting packets with spoofed private source IPs.

OPNsense generates anti-spoofing rules automatically. The operator can configure which source ranges to block per interface under Firewall → Settings → Advanced.

4. Bogons rules

The bogons rules block traffic from IP ranges that are not allocated or are reserved. The list is maintained by OPNsense and updated periodically. The rules are typically enabled on the WAN to drop traffic from non-routable space.

$ pfctl -s rules | grep -E 'lockout|antispoof|let out'

@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
@4 block drop in quick on igb1 inet from 10.0.0.0/8 to any
@5 block drop in quick on igb1 inet from 172.16.0.0/12 to any
@6 block drop in quick on igb1 inet from 192.168.0.0/16 to any

The anti-lockout rule in depth

The anti-lockout rule exists to save you. It is also a liability if it is enabled on the wrong interface.

Why it exists

Consider the workflow of adding a strict “block all” rule on the LAN. The operator edits the LAN rules, clicks Apply, and suddenly cannot reach the GUI from the LAN because every packet to the firewall’s LAN IP is being blocked. Without the anti-lockout rule, the recovery requires console access.

The anti-lockout rule sits above any user-added rule and allows TCP 80/443 from the LAN to the firewall’s LAN IP. The operator can always reach the GUI from the LAN.

The risk

If the anti-lockout rule is enabled on a management VLAN that should not have unrestricted LAN-like access to the GUI, the operator may have inadvertently exposed the GUI to a broader range of sources than intended.

For example: the operator adds a new management VLAN, assigns it as an OPT interface, but the anti-lockout rule was generated for the LAN interface only (by default). The operator assumes the new VLAN can reach the GUI because the LAN can. It cannot — the anti-lockout rule does not apply. This is the most common “I added a management VLAN and cannot reach the GUI” scenario.

The other risk: an attacker on the LAN can reach the GUI because the anti-lockout rule permits it. If the LAN hosts are user workstations and not trusted operator hosts, the attacker has a path to the GUI that bypasses the source restrictions on a management VLAN.

How to disable

Under System → Settings → Administration, the operator can disable the anti-lockout rule. The setting is “Disable anti-lockout webgui lockdown” — when checked, the anti-lockout rule is not generated.

The recommendation: do not disable the anti-lockout rule on the LAN. The rule exists for a reason. The operator who disables it and then locks themselves out of the GUI has to go to the console, which is exactly the lockout the rule was designed to prevent.

If the operator adds a new management VLAN, the right approach is to add an explicit allow rule for the management VLAN to the firewall IP on 443 (and SSH on 22 if needed) — not to disable the anti-lockout rule.

The let-out-any rule

The let-out-any rule is the second auto rule that is critical for operation. Without it, the firewall cannot make outbound connections, which means:

• DNS resolution breaks (Unbound cannot reach upstream resolvers).
• NTP breaks (the firewall cannot reach NTP servers).
• Plugin updates break (the firewall cannot reach the OPNsense package server).
• Syslog breaks (the firewall cannot reach remote syslog destinations).
• API calls break (any feature that calls a cloud API cannot work).

The let-out-any rule is generated by default and applies to all interfaces. The operator can disable it under Firewall → Settings → Advanced → Disable let-out rules.

When to disable

The right pattern in a strict production estate is:

• Keep the let-out-any rule enabled by default.
• For specific services that should not be allowed outbound, add a more specific block rule that overrides the let-out.

For example, the operator might want to block the firewall from reaching specific destinations (e.g. a known malicious domain). The block rule goes above the let-out-any rule. The firewall can still reach other destinations but cannot reach the blocked one.

When to be concerned

The concern with the let-out-any rule is that it allows the firewall to make outbound connections to anything. If the firewall is compromised, the attacker has full outbound access. For a defence-in-depth posture, the operator might want to limit the firewall’s outbound to specific destinations (DNS, NTP, plugin update, syslog, monitoring).

This is a strict posture. It requires explicit allow rules for every destination the firewall needs to reach, plus a default block. The complexity is high; the security benefit is also high. Most production estates accept the let-out-any default and add specific blocks for known-bad destinations.

The production pattern

The pattern for a strict production estate:

1. Keep the anti-lockout rule enabled on the LAN. The rule is a safety net for GUI access from the LAN. Do not disable it.
2. Keep the let-out-any rule enabled. The firewall needs outbound access for DNS, NTP, updates, syslog, and monitoring. Disable only if you have a specific security requirement and you have explicit allow rules for every destination the firewall needs.
3. Keep anti-spoofing enabled. The rule blocks traffic with source IPs that should not appear on a given interface. This is a baseline defence.
4. Keep bogons enabled on the WAN. The rule blocks traffic from non-routable source ranges. The list is maintained by OPNsense; you benefit from the updates automatically.
5. Add explicit block rules for known-bad destinations. The block rules go above the let-out-any rule so they override.

The pattern works because the auto rules provide the safety net the operator needs (anti-lockout, outbound connectivity) while the explicit blocks provide the production posture (blocked destinations).

Verification

After every configuration change, the verification is:

1. pfctl -s rules | grep -E 'lockout|let out|antispoof|bogons' — confirm the auto rules are present at the expected positions.
2. pfctl -s rules | grep <unique-text> for each user rule — confirm the rule compiled at the expected position.
3. From a host on the LAN, attempt to reach the GUI on 443 — should succeed via the anti-lockout rule.
4. From the firewall itself, attempt outbound to a test destination (e.g. DNS to 1.1.1.1) — should succeed via the let-out-any rule.
5. If a block rule was added for a specific destination, from the firewall, attempt to reach that destination — should be refused.

Summary

• OPNsense generates four categories of auto rules: anti-lockout, let-out-any, anti-spoofing, bogons.
• The anti-lockout rule permits LAN-to-firewall on 80/443. Keep it enabled on the LAN.
• The let-out-any rule permits firewall-to-any. Required for DNS, NTP, updates, syslog, monitoring.
• Anti-spoofing and bogons are baseline perimeter defences.
• Add explicit block rules above the auto rules to override them for specific destinations.