Alias anti-patterns — overly broad tables, slow refresh, and silent failures

Aliases and floating rules are powerful — and misused, they become operational liabilities. A URL Table that was meant to be a curated threat-intel blocklist grows to half a million entries because someone added “every bad IP we’ve ever seen”. A static alias that should hold ten DMZ servers grows to two hundred as the DMZ expanded over three years. A floating rule that should permit SSH from three management subnets now permits SSH from anywhere because someone added 0.0.0.0/0 “to test something” and forgot to remove it.

This lesson covers the anti-patterns — what they look like, why they are dangerous, and how to recover from each.

Anti-pattern 1: the overly broad table

A URL Table with hundreds of thousands of entries is almost always wrong. The most common cause is feeding a low-quality list that aggregates dozens of sources, each of which has its own biases and false-positive rate. The aggregated list looks comprehensive; in practice, it blocks legitimate traffic.

Symptoms:

• Legitimate users report intermittent connectivity to services that have no obvious relation to the firewall.
• The firewall log shows blocked connections from CDN IP ranges, cloud provider ranges, or customer ranges that have never been abusive.
• The aliased table size grows steadily month over month, with no corresponding change in the threat landscape.

The fix is curation. Replace the aggregated list with two or three high-quality lists (Spamhaus DROP is the standard reference; AbuseIPDB is community-curated but high-quality for specific abuse types). Cap the entry count with the Maximum Entries field. Review the alias contents quarterly.

Anti-pattern 2: the slow refresh cycle

A URL Table with a refresh interval of 168 hours (weekly) or longer is almost always wrong for a threat-intel feed. A weekly refresh means the firewall operates on threat-intel data that is up to seven days old.

Symptoms:

• The firewall log shows attacks from IPs that were added to the feed days earlier.
• The alias’s Last updated timestamp is consistently a week or more old.

The fix is a shorter refresh interval. Most threat-intel feeds update at most once a day, so a 6- or 12-hour refresh is appropriate.

The exception: feeds that genuinely update rarely (RFC 1918 is RFC 1918; it does not change). For these, a long refresh is fine — but the alias should be a static network alias, not a URL Table.

Anti-pattern 3: the static alias that became unmaintainable

A static alias that started with three entries and grew to two hundred entries is a maintenance liability. The alias is referenced in many rules, but no one knows who owns it, when entries were added, or whether all the entries are still correct.

Symptoms:

• The alias edit page lists dozens of addresses with no description.
• Changes to the alias require cross-team coordination because no one knows which addresses are safe to remove.

The fix is governance. Adopt a naming convention that encodes ownership. Require every alias entry to have a comment describing what it is. Review aliases quarterly and remove entries that are no longer relevant.

Anti-pattern 4: the floating rule that became any → any

A floating rule that started as “permit SSH from management IPs on LAN” was edited over time to add 0.0.0.0/0 “to test connectivity”. The test was not reverted. The rule now permits SSH from anywhere on every interface.

Symptoms:

• The firewall log shows successful SSH connections from IP ranges that should not have management access.
• A security audit flags the floating rule as overly permissive.

The fix is review and a stricter source/destination discipline. Floating rules that permit management access should have explicit sources.

Anti-pattern 5: the FQDN alias that resolved to the wrong IP

A Host alias that holds an FQDN depends on DNS resolution. If the FQDN is wrong, the alias resolves to the wrong IP. If the FQDN is correct but DNS resolution is stale, the alias contains the old IP. Either way, the rule matches the wrong traffic.

Symptoms:

• The firewall log shows traffic to/from an IP that does not match what the operator intended.
• The alias’s resolved-IP list is different from what the operator expects.

The fix is verification. Always verify FQDN resolution independently with drill or host from the firewall console.

Anti-pattern 6: the alias that conflicts with another alias

Two aliases that overlap in coverage. For example, dmz_servers and dmz_servers_old both contain some of the same addresses. A rule that references dmz_servers and a rule that references dmz_servers_old produces confusing behaviour when the overlap matters.

The fix is consolidation. Pick one alias per logical set.

How to audit aliases and floating rules

The verification pattern for any alias or floating rule change:

1. Inspect the alias contents. pfctl -t <alias> -T show lists the entries.
2. Inspect the generated ruleset. pfctl -s rules | grep <alias> shows every rule that references the alias.
3. Test traffic. Send a test packet that should match the alias and verify the firewall’s decision.
4. Check the log. OPNsense’s firewall log shows which rule matched and what the action was.
5. Inspect the state. pfctl -s state | grep <source> shows the live state entries.

The discipline: never trust the GUI’s representation of an alias or rule without verifying the runtime state.

$ pfctl -t spamhaus_drop -T show | wc -l && pfctl -t spamhaus_drop -T stats

    1421
8 addresses added.
 1421 addresses deleted.
     0 addresses changed.
     0 addresses expired.
     0 addresses looked up.
     0 new addresses added.

Recovery patterns

When an anti-pattern is detected, the recovery is rarely “fix the rule”. It is “fix the rule, fix the documentation, fix the monitoring that should have detected this, and verify the fix did not introduce a new issue”.

Three patterns:

• The blanket fix. When an alias is wrong, fix it once and verify with a representative test. Document the fix in the change record.
• The migration. When an alias is structurally wrong, plan a migration: identify all rules that reference the alias, create the new alias, update the rules, verify the behaviour, then remove the old alias.
• The rollback. When a change introduces an anti-pattern, revert the change.

Summary

• The most common anti-patterns are overly broad tables, slow refresh cycles, unmaintained static aliases, any → any floating rules, FQDN aliases that resolved wrong, and overlapping aliases.
• Each anti-pattern has specific symptoms and a specific fix.
• Verification uses three views: GUI configuration, runtime state, and behaviour.
• Recovery is rarely “fix the rule”. It is fix + document + monitor.
• Aliases and floating rules need descriptions, owners, and quarterly review.