OPNsense integration guide.

Plan table capacity and access

Export a configuration backup and keep trusted management access. Review available memory and the combined size of existing aliases. Check Firewall → Settings → Advanced → Firewall Maximum Table Entries against the complete feed plus existing tables and growth headroom. Avoid choosing an arbitrary global limit without checking the appliance.

Use an up-to-date release with native URL table aliases. The appliance needs DNS, correct time and verified HTTPS access to the primary source. This workflow uses the native alias subsystem.

Create a regularly refreshed alias

Standard

94,998 unique IPv4 addresses in this published snapshot.

https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt

Critical

104,852 unique IPv4 addresses in this published snapshot.

https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_critical_data-shield_ipv4_blocklist.txt

Published 21 Oct 2026, 00:05 UTC. Check live counts and SHA-256.

1. Open Firewall → Aliases and add an enabled alias named DS_STANDARD.
2. Select URL Table (IPs), sometimes labeled URL Tables (IPs). Do not select URL (IPs), which fetches once.
3. Paste the Standard URL into Content. For Critical, use its URL and name the alias DS_CRITICAL.
4. Set the refresh frequency to two hours, using the time-unit fields shown by your version. Save and apply the changes.
5. Open Firewall → Diagnostics → Aliases. Select the table and check its contents, entry count and last update. Keep certificate verification enabled if the interface offers a verification option.

Block matching incoming sources

In Firewall → Rules → WAN, create a dedicated IPv4 Block rule. Use the actual Internet ingress interface, any protocol, source DS_STANDARD and the destinations you intend to protect. Add a clear description and enable logging. Place it before matching interface allow rules, then apply.

The OPNsense rules manual documents these precedence rules. Menu names differ between Rules and Rules [new]; inspect the effective ruleset when both implementations are present. Preserve management access while changing rule order.

Inspect the table and logs

The diagnostics view is the primary verification method. If shell access is already enabled for administration, the following FreeBSD PF inspection commands are read-only. Do not enable public SSH just to run them.

pfctl -t DS_STANDARD -T show | wc -l
pfctl -t DS_STANDARD -vT show

Compare the loaded set with the retrieved publication and investigate missing entries. The verbose output can be large. The first command counts displayed table records; it is not a checksum or proof of equal address coverage if entries have been aggregated.

In Firewall → Log Files → Live View, filter on the rule description and confirm a new controlled incoming connection hits the intended block rule. Existing states may continue under the earlier policy. Inspect only the relevant test state if needed rather than flushing all connections.

Keep the alias healthy

Check scheduled refreshes, table growth and log messages after the first update cycle. A shared whitelist correction appears in this alias only after a successful refresh. Confirm membership directly when validating a removal.

To roll back, disable the dedicated block rule, apply and confirm required connectivity. Remove the alias only after its references have been removed. Do not flush all PF tables or alter unrelated aliases.