OpenWrt integration guide.

Check OpenWrt and banIP separately

Use banIP to retrieve both Data-Shield feeds over HTTPS and load dedicated IPv4 sets into its own inet banIP nftables table. This guide uses the native OpenWrt package and scheduler. It does not install a second firewall engine or require a Linux controller.

References: OpenWrt stable release, 25.12.6 release and support notes, reviewed banIP package and version-pinned banIP manual. Check ubus call system board and, after installation, apk info -v banip. This is a source-reviewed integration, not certification on an OpenWrt appliance.

Budget memory before loading both profiles

The reviewed banIP release requires at least 256 MB of RAM. That is a package floor, not a guarantee that both Data-Shield profiles fit alongside your other services. Budget for the complete downloads, parsing, nftables replacement, backups and overlapping addresses retained in both sets. Check free memory and storage with free -m and df -h, then measure peak usage during a supervised reload.

On smaller devices, review banIP's sequential processing and external working-directory options. Splitting nftables loads reduces memory pressure but changes loading behavior; it is not permission to truncate a feed. Do not enable unattended updates if either complete profile fails to load. The source files have one IPv4 address per line, while nftables can merge adjacent addresses into intervals. A kernel element count can therefore be lower than the number of covered addresses.

Register both unchanged HTTPS feeds

Standard

109,123 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

119,122 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 24 Oct 2026, 14:05 UTC. Check live counts and SHA-256.

Download the custom-feed JSON example and review it. Merge its two named objects into /etc/banip/banip.custom.feeds through LuCI's Services > banIP > Custom Feed Editor. Preserve any other custom objects. On an empty installation the example is a complete JSON document. Do not replace the package-managed /etc/banip/banip.feeds, which package upgrades can overwrite.

{
  "datashieldstandard": {
    "url_4": "https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt",
    "rule": "feed 1",
    "chain": "in",
    "descr": "Data-Shield Standard IPv4"
  },
  "datashieldcritical": {
    "url_4": "https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_critical_data-shield_ipv4_blocklist.txt",
    "rule": "feed 1",
    "chain": "in",
    "descr": "Data-Shield Critical IPv4"
  }
}

url_4 limits these feeds to IPv4; no IPv6 feed is invented. feed 1 reads the first column of each plain-text row. in selects incoming-source filtering in both WAN-Input and WAN-Forward. It does not create an outbound destination policy. Selecting both feeds blocks their union, even though many addresses occur in both.

Prepare a supervised first import

Back up the existing OpenWrt and banIP configuration and keep a trusted LAN or console management path. Use the package repositories for the installed release. On OpenWrt 25.12:

apk update
apk add luci-app-banip curl ca-bundle
apk info -v banip

In LuCI, select datashieldstandard and datashieldcritical under the banIP feed settings. Keep any intentionally selected existing feeds. Enable IPv4 processing, verify the actual WAN interfaces and devices, and choose the appropriate WAN startup trigger. Tunnels and multi-WAN installations need an explicit interface review. Keep certificate verification enabled, configure correct system time and DNS, and use the installed curl downloader.

In the existing config banip 'global' section of /etc/config/banip, merge these settings once. They are a configuration fragment, not a replacement file or a shell script. Preserve unrelated options and list entries:

option ban_protov4 '1'
option ban_fetchcmd 'curl'
option ban_fetchinsecure '0'
list ban_feed 'datashieldstandard'
list ban_feed 'datashieldcritical'
list ban_feedcomplete 'datashieldstandard'
list ban_feedcomplete 'datashieldcritical'

ban_feedcomplete exempts these two feeds from cross-feed deduplication so each retains its complete membership. Otherwise the overlap may be assigned to just one set. Local allowlists and the auto-allowed uplink still affect enforcement; retaining every feed address does not override those exceptions. Review existing direction overrides, allowed ports and allowlist-only mode before enabling the policy.

banIP also provides log-triggered blocking and flood protections independently of Data-Shield. Review those defaults before first activation. Enabling the service applies live filtering, including traffic to the router itself. After that review, enable banIP in LuCI and under System > Startup, then perform the initial refresh:

/etc/init.d/banip reload
/etc/init.d/banip status
/etc/init.d/banip report
logread -e banIP

Wait for processing to finish and inspect both feeds in Set Reporting. Do not treat the init command returning as proof that both lists loaded successfully. Existing and related connections can be accepted before feed checks, and software or hardware flow offloading can bypass later packet processing. Validate new connections through the intended WAN path and retain the main firewall policy.

Refresh both lists every two hours

After the supervised import and traffic test, add one line in System > Scheduled Tasks, preserving existing jobs. OpenWrt uses the root crontab format, without a username column:

23 */2 * * * /etc/init.d/banip reload

Save and apply, ensure the cron service is enabled and running, and verify the router's timezone and clock. The example checks both selected profiles every two hours at minute 23. It reloads all selected banIP feeds, not just Data-Shield. Do not add a second identical schedule.

Use reload for refreshes. In the reviewed release, start, restart and boot restoration can reuse existing backups instead of retrieving changed data. A reload checks for updates; with curl, an unchanged ETag can avoid a redundant body download. Monitor the last successful retrieval for each profile, not just the scheduler timestamp.

Successful processing replaces feed membership, so additions and removals from publication reach the corresponding set. Standard and Critical are fetched independently and can temporarily span two publications. Native banIP does not compare Data-Shield snapshot SHA-256 values or provide a transaction covering the pair. HTTPS validation and an ETag check do not prove snapshot byte equality. The website's two-hour generation and hourly snapshot refresh are separate from this router schedule.

Verify membership, freshness and enforcement

Check the Processing Log for errors, the service state, and both datashieldstandard.v4 and datashieldcritical.v4 sets. The following commands read configuration and loaded data without changing firewall rules:

/etc/init.d/banip status
/etc/init.d/banip report
nft list set inet banIP datashieldstandard.v4
nft list set inet banIP datashieldcritical.v4
nft list chain inet banIP wan-input
nft list chain inet banIP wan-forward
nft list chain inet banIP _inbound

Use banIP's Set Search with an address from the current published feed. Compare the complete loaded address coverage with the complete downloaded list before unattended use, accounting for interval merging. If split loading is configured, include all generated set parts shown in the report. A few successful lookups or an equal count alone do not prove complete membership.

The reviewed implementation keeps gzip copies of retrieved feed bodies in its configured backup directory. With the default directory and a completed reload, inspect their full-body checksums:

gzip -t /tmp/banIP-backup/banIP.datashieldstandard.v4.gz && zcat /tmp/banIP-backup/banIP.datashieldstandard.v4.gz | sha256sum
gzip -t /tmp/banIP-backup/banIP.datashieldcritical.v4.gz && zcat /tmp/banIP-backup/banIP.datashieldcritical.v4.gz | sha256sum

Use the actual backup path if customized. Compare with the same publication on Data-Shield downloads; recheck publication timestamps if an update raced the comparison. A backup hash proves only which downloaded bytes were saved. It does not prove that nftables loaded them or that a connection was blocked. Do not accept a hash from an empty or corrupt stream.

Finally, test a new connection from a source you control through the intended incoming path. Check the applicable local allowlist, feed rules and a temporary, rate-limited logging configuration. Counters may be disabled for memory efficiency and zero counters alone do not prove that filtering failed. This procedure covers IPv4; it does not add equivalent IPv6 protection.

Handle unavailable feeds and roll back

banIP can fall back to a saved feed after download errors. A restored backup can keep old entries, including addresses since removed upstream. It is not a fresh retrieval. Its default backup directory is under /tmp, so it does not survive a reboot. If recovery across reboots is required, configure persistent storage with appropriate capacity and write endurance, and test offline startup before relying on it.

Native parsing and loading failures do not provide a blanket guarantee that both old sets remain intact. Inspect processing errors, backup age and the actual loaded sets after any failure or memory exhaustion. A syntactically valid truncated response is not detected by a snapshot checksum gate in this integration. Keep full-feed validation and freshness monitoring part of operations.

For rollback, remove this schedule first, deselect only the two Data-Shield feeds, remove their corresponding ban_feedcomplete entries and custom objects, and reload banIP. Confirm their sets and references are gone while other feeds and the main firewall remain active. Restore the saved banIP configuration when needed. Do not flush the whole nftables ruleset. Recheck behavior on your exact firmware and hardware before unattended use.