Table aliases and URL feeds

A Network alias with ten entries is a configuration item. A Network alias with ten thousand entries is a maintenance liability — and a security update cycle. Threat-intelligence feeds, abuse databases, and geolocation blocklists are all expressed as large lists of addresses that change daily. Manually maintaining them in the GUI is impossible. OPNsense’s answer is the URL Table alias: an alias whose contents are fetched from a URL on a schedule and applied atomically to the underlying PF table.

This lesson covers how URL Tables work, the feeds that are useful in production, and the failure modes that turn a threat-intel blocklist into an operational incident.

What a URL Table is

A URL Table alias is a Host or Network alias whose contents are fetched from a URL. The URL is polled on a configurable interval; OPNsense fetches the content, parses out the addresses, and replaces the underlying PF table in one atomic operation. The rule that references the alias does not change when the table contents change.

$ pfctl -t spamhaus_drop -T show | head -5

   1.10.16.0/20
  1.18.0.0/15
  1.24.0.0/13
  1.32.0.0/14
  1.36.0.0/16

What URL Tables are good for

Three production patterns dominate:

• Threat-intel feeds. Spamhaus DROP, Spamhaus EDROP, AbuseIPDB, FireHOL, Emerging Threats. These feeds list IP ranges observed in malicious activity.
• Geolocation blocklists. Country-level blocklists expressed as aggregated CIDR blocks. Useful when you need to restrict traffic from specific regions.
• Abuse and scan lists. Lists of IPs observed scanning, brute-forcing, or otherwise behaving badly.

The key property: the list is maintained externally, fetched automatically, and applied atomically. The operator never edits the table contents directly; the feed provider does.

The common feeds

Four feeds cover most production needs:

• Spamhaus DROP. Spamhaus Don’t Route Or Peer list — IP ranges that should not be routed on the public Internet.
• Spamhaus EDROP. Extended DROP list — additions to DROP for very large allocations.
• FireHOL level 1 to 4. Aggregated lists from multiple sources, ranked by quality.
• AbuseIPDB. A community-reported abuse database.

A production firewall typically references two or three feeds, not all of them.

The URL Table configuration

A URL Table has six configuration fields that matter:

• URL. Where to fetch the content. HTTPS is strongly preferred.
• Refresh interval. How often to fetch. Typical values are 1, 6, 12, or 24 hours.
• SSL verification. Whether to verify the server certificate. Default is yes.
• Parser. Which parser to use. Common options are auto, pfctl, csv, and plain.
• Maximum entries. A safety limit. Prevents a misconfigured feed from overloading the firewall.
• Verify against DNSBL. For FQDN-style feeds, optionally verify each hostname against a DNS-based blocklist.

Refresh cadence and timing

The refresh interval is how often the firewall fetches the URL. The interval is a balance:

• Too short. Wastes firewall CPU and network.
• Too long. Stale data.

The default for most feeds is 24 hours. For high-value blocklists (DROP), 6-12 hours is reasonable.

The refresh happens at the configured interval plus a small random offset to avoid hammering the feed provider when many OPNsense firewalls refresh simultaneously.

Failure modes

URL Tables have specific failure modes that are different from static aliases.

The unreachable URL

The most common failure: the URL becomes unreachable because the feed provider’s site moves, the URL changes, the certificate expires, or the provider goes offline. The fetch fails. The previous table contents are retained.

The format change

A feed provider changes the format of their list. The parser fails or misinterprets the content. The table either empties (allowing previously-blocked traffic) or fills with garbage (blocking legitimate traffic).

The huge feed

A feed that quietly grows from 10,000 to 500,000 entries. The Maximum Entries limit kicks in and truncates.

The unreachable certificate chain

The URL is HTTPS, the certificate is valid, but the certificate chain is incomplete. The firewall’s TLS verification fails.

How to monitor URL Table health

Three signals tell the operator that a URL Table is healthy:

• Last successful refresh timestamp. Alert if it is more than 2 × refresh interval in the past.
• Entry count. A sudden drop indicates a parser failure; a sudden spike indicates a feed format change or growth.
• Refresh log entries. Alert on log entries containing “fetch failed” or “parser error”.

The operational practice is to script these checks. A small cron job on a monitoring host runs pfctl -t <alias> -T show | wc -l every hour and compares to the expected count.

Summary

• URL Table aliases fetch their contents from a URL on a schedule and replace the underlying PF table atomically.
• Common feeds: Spamhaus DROP and EDROP, FireHOL, AbuseIPDB. Quality varies; false positives exist.
• Refresh cadence is a balance between freshness and load. Default 24 hours is fine for most feeds.
• URL Tables have specific failure modes: unreachable URL, format change, huge feed, TLS failure.
• Monitor last refresh, entry count, and log entries to detect failure.
• Disabling SSL verification is an anti-pattern.