VyOS integration guide.

Confirm the installed version and commands

VyOS can fetch Data-Shield as a native remote firewall group. The supported commands depend on the installed image, not just the product name. Run show version in operational mode and use CLI completion before applying this guide.

References: 1.5 remote groups, rolling remote groups, T9076 implementation and 1.4 groups. The archived public Circinus branch does not establish the feature set of current vendor images; validate on the installed image. These are documentation and source checks, not appliance certification.

In configuration mode, use completion after set firewall group and set firewall group remote-group DS_STANDARD. Confirm the url option and, for a rule, source group remote-group. Stop if a required node is absent. See the VyOS CLI guide for completion and configuration modes.

Create a complete IPv4 remote group

Back up the configuration and keep a trusted management or console path. Ensure DNS, routing, accurate time, trusted CA certificates and outbound HTTPS work. Keep certificate validation enabled. Select one profile first and allow memory, storage and reload headroom for the complete list and existing groups.

Standard

109,308 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,382 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, 12:05 UTC. Check live counts and SHA-256.

The following opens a configuration session and creates only the Standard group. It does not yet add a blocking rule:

configure
set firewall group remote-group DS_STANDARD description 'Data-Shield Standard IPv4'
set firewall group remote-group DS_STANDARD url 'https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt'

For Critical, use DS_CRITICAL and the Critical URL above instead. Use separate names if you intentionally load both profiles. No credentials, API key, conversion or additional cron job is required.

Choose one automatic refresh method

Recent rolling: two hours for this group

If the installed CLI exposes the per-group interval, use this option. It leaves the global resolver cadence unchanged:

set firewall group remote-group DS_STANDARD interval '2h'

The reviewed rolling implementation accepts 60 seconds through four weeks. With no group override it uses the global resolver interval. Failed downloads are retried at the shorter of those two intervals. See the reviewed updater.

1.5 documented path or older rolling: shared interval

When remote groups exist but the per-group option does not, retain the existing shared schedule unless there is a reason to change it. The reviewed CLI schema allows 10 to 3,600 seconds, with a default of 300 seconds. If an hourly schedule is suitable for all affected groups and firewall FQDN resolution, this is an optional setting:

set firewall global-options resolver-interval '3600'

This global option also affects domain resolution used by the firewall. Do not use 7200 here or slow an existing resolver without reviewing its dependencies. The global option is defined in the published CLI schema; confirm its range on your release.

Review the pending changes, commit the group and selected schedule, then leave configuration mode:

compare
commit
save
exit

List publication and router retrieval are separate schedules. The website snapshot does not push entries into VyOS. An addition, expiry or whitelist correction takes effect only after a successful retrieval and reload. Persistent caching can keep an older list available when a fetch fails; a first download can still leave an empty group, and a cache is not proof of freshness or complete import.

Add a scoped incoming-source rule

Review the existing policy before adding a rule. In the example, eth0 must be your actual Internet ingress interface, and 100 must be an unused rule number placed before any applicable pass rule. Replace both as needed. This example filters forwarded IPv4 traffic; traffic to the router itself uses the input chain. Existing global state policies, earlier accepts and established sessions can affect the result. For a zone-based design, integrate the group in the existing zone policy instead.

configure
set firewall ipv4 forward filter rule 100 action 'drop'
set firewall ipv4 forward filter rule 100 inbound-interface name 'eth0'
set firewall ipv4 forward filter rule 100 source group remote-group 'DS_STANDARD'
set firewall ipv4 forward filter rule 100 description 'Data-Shield Standard incoming sources'
compare
commit-confirm 10

Keep existing default actions and management rules. Check the configured commit-confirm rollback action before use: an unconfirmed change may reboot the router. Verify connectivity and the test below before entering these commands in the same configuration session:

confirm
save
exit

See IPv4 firewall traffic paths and ordering and configuration and confirmed commits. This guide adds a dedicated rule; it does not replace your firewall policy.

Verify the loaded group and subsequent updates

In operational mode, inspect the group and the dedicated rule:

show firewall group DS_STANDARD
show firewall group DS_STANDARD detail
show firewall ipv4 forward filter rule 100

The summary may show the URL without listing members. Use the detail view where supported, or your release's supported table-inspection tools. The reviewed rolling operational implementation reads loaded entries from nftables. Large groups produce substantial output; an entry count alone is not a content checksum.

1. Compare the complete imported membership with the publication actually retrieved. Check specific additions and removals, not just the configured URL. Watch for parser errors, insufficient memory and empty or incomplete groups.
2. Check updater logs and successful reload status. Then repeat the membership check after a scheduled interval and a source publication change. An available cache or a recent file timestamp alone does not prove a successful fresh reload.
3. Use a controlled test source you own to verify the intended traffic path and rule counters. A zero counter or an existing connection does not by itself prove a failed or successful block.

No checksum gate is configured by these native commands. The reviewed downloader uses verified HTTPS, but transport verification does not replace full-import and freshness checks. See the official downloader.

Maintain and remove the integration safely

Monitor retrieval failures, retained old membership, resource use and the effect of legitimate exclusions. Do not assume the native importer rejects every incomplete response. Validate the installed version before upgrades, especially when moving between rolling and LTS.

For rollback, remove only the dedicated rule you created, review and commit the change, then verify connectivity. Remove the remote group only after clearing its references. If you changed the global resolver interval, restore its recorded previous value after reviewing other consumers. Leave unrelated groups, states, default actions and rules intact.