Using a local file with remote-group

Apologies if this has already been talked about, but I’m looking to use the remote-group feature ideally with the SpamHaus DROP file to block the IPs in that list. Natively that file is in a JSON format that I can tweak into the format for a remote-group, but I would need to bring the file down to the firewall first, and the remote-group command appears to only support a remote URL accessed via a HTTP/HTTPS call?

I’m using the 2026.03 Stream version, and was wondering if anybody is doing something like this? I tried ‘file:///dir/file.txt’ but it doesn’t seem to like this.

Thanks in advance for any ideas folks may have!

After a bit of tinkering, this approach seems to be working to be implemented via script: use python3 to spin up a web server for the remote-group command using http://127.0.0.1 to access the text file. Here’s a quick flow:

  • download DROP file from SpamHaus -
    curl -s -O https://www.spamhaus.org/drop/drop_v4.json | jq -r ‘select(.type == null) | (.cidr)’ drop_v4.json > /root/scripts/sh_drop.txt

  • start web server -
    python3 -m http.server 8888 --bind 127.0.0.1 --directory /root/scripts &

  • create firewall rulesets -
    configure
    set firewall group remote-group test url http://127.0.0.1:8888/sh_drop.txt
    set firewall ipv4 forward filter rule 1 source group remote-group test
    set firewall ipv4 forward filter rule 1 action drop
    commit
    save
    exit

  • confirm nft tables are populated -
    sudo nft list table ip vyos_filter

  • stop web server as I really don’t want it running all the time -
    kill -9 $(lsof -t -i:8888)

Some feedback from other folks would be helpful on a couple of things:

  1. The resolver-interval Firewall option is available to “refresh” the remote-group periodically, but since I’d be stopping the web server, I’m assuming this would fail. However, I think this is OK as I’ll control the “refresh” of the group by running the script.

  2. What does a “diff” look like with this approach? i.e. the source DROP file changes, so does the entire remote-group need to be re-created, or will it incorporate the diff from the DROP file?

Again, any thoughts/suggestions are greatly appreciated.

Sounds like a good feature request. Being able to use file:// would save the hassle of having to fire up a webserver simply to load a file…

The Python webserver workaround is solid. To make it survive reboots, save the script to /config/scripts/ — VyOS includes that directory in config backups and runs scripts from /config/scripts/vyos-postconfig-bootup.script after each boot/commit. Drop your curl download and python3 http.server startup there and it persists automatically. For keeping the SpamHaus list fresh you can use VyOS task-scheduler which is commit-persistent: set system task-scheduler task update-spamhaus crontab-spec ‘0 4 * * *’ then set system task-scheduler task update-spamhaus executable path /config/scripts/update-spamhaus.sh — that runs the download daily at 04:00 and the remote-group picks up the refreshed file on its next update interval. Agree with WanWizard that native file:// support would clean this up — worth opening on Phabricator.The Python webserver workaround is solid. To make it survive reboots, save the script to /config/scripts/ — VyOS includes that directory in config backups and runs scripts from /config/scripts/vyos-postconfig-bootup.script after each boot/commit. Drop your curl download and python3 http.server startup there and it persists automatically. For keeping the SpamHaus list fresh you can use VyOS task-scheduler which is commit-persistent: set system task-scheduler task update-spamhaus crontab-spec ‘0 4 * * *’ then set system task-scheduler task update-spamhaus executable path /config/scripts/update-spamhaus.sh — that runs the download daily at 04:00 and the remote-group picks up the refreshed file on its next update interval. Agree with WanWizard that native file:// support would clean this up — worth opening on Phabricator.

I have 2 different scripts running now that create files for 2 different remote-group’s, and all is working very well! I ended up having the HTTP Server running at boot, and just leaving it up until things are enhanced to be able to use a local file with remote-groups:

#cat /config/scripts/vyos-postconfig-bootup.script

/usr/bin/python3 -m http.server 8080 --bind 127.0.0.1 --directory /config/scripts

Next step is to figure out how to create the Feature Request as I’ve never done that in all the years I’ve been involved with Vyatta and VyOS!

Thanks for the feedback!!

You can open a feature request here https://vyos.dev/

I had to register for an account on vyos.dev yesterday, and it said an Administrator will need to approve it. Do you know how long this process takes?