cscli allows decisions on CIDR ranges, but nftables sets are missing the `interval` flag

[exigentix-dev]

What happened?

TLDR: nftables sets created/managed by cs-firewall-bouncer are missing the interval flag, causing incorrect elements to be added for subnets when adding decisions via cscli.

---

Today I manually added a decision to ban an IPv6 subnet, which cscli reported as successful, but then I noticed that traffic from IPs in the subnet was still getting past the crowdsec6 table's chains. I dug deeper and realized that it's because the banned subnet wasn't added correctly to the crowdsec6-blacklists-cscli set; it appears to have been added as a single IP.

root@srv:~# cscli decisions add --range 2a06:4880::/32 --duration 90d --reason "[srv] manual ban"
INFO Decision successfully added                  

root@srv:~# nft list set ip6 crowdsec6 crowdsec6-blacklists-cscli
table ip6 crowdsec6 {
    set crowdsec6-blacklists-cscli {
        type ipv6_addr
        flags timeout
        elements = { 2a06:4880:: timeout 29d23h35m21s expires 29d22h28m56s800ms }
    }
}

2a06:4880:: is not equivalent to 2a06:4880::/32, as seen below:

root@srv:~# ipcalc 2a06:4880::
Full Address:    2a06:4880:0000:0000:0000:0000:0000:0000
Address:    2a06:4880::
Address space:    Global Unicast

root@srv:~# ipcalc 2a06:4880::/32
Full Network:    2a06:4880:0000:0000:0000:0000:0000:0000/32
Network:    2a06:4880::/32
Netmask:    ffff:ffff:: = 32

Address space:    Global Unicast
HostMin:    2a06:4880::
HostMax:    2a06:4880:ffff:ffff:ffff:ffff:ffff:ffff
Hosts/Net:    2^(96) = 79228162514264337593543950336

Yes, I know that's a lot of IPs... hopefully, if it did work, the CIDR wouldn't be expanded to its constituent addresses.

As a test I attempted to manually add the subnet as an element, and I believe the result confirms the root cause, which is that the interval flag is missing from the set definition:

root@srv:~# nft add element ip6 crowdsec6 crowdsec6-blacklists-cscli { 2a06:4880::/32 }
Error: You must add 'flags interval' to your set declaration if you want to add prefix elements
add element ip6 crowdsec6 crowdsec6-blacklists-cscli { 2a06:4880::/32 }
                                                       ^^^^^^^^^^^^^^

I already did some googling & AI-ing, but it seems that currently there is no way to override how these sets are created in cs-firewall-bouncer's configuration to add the interval flag to the sets (it's also missing from the IPv4 crowdsec-blacklists-cscli set).

I would love to be wrong here and find out that there is actually a way to configure cs-firewall-bouncer to create the sets with flags timeout,interval. Or that I'm overlooking some other simple solution. Ideally, I'd like to keep the tables fully managed and not have to resort to managing them myself; I'm not even sure if it would work if I configured cs-firewall-bouncer as set-only, since the sets would likely be recreated (incorrectly) on every restart.

What did you expect to happen?

The crowdsec6-blacklists-cscli & crowdsec6-blacklists-cscli sets are created with the interval flag so that CIDR elements are supported.

How can we reproduce it (as minimally and precisely as possible)?

1. cscli decisions add --range <CIDR_subnet> --duration <duration>
2. nft list set ip crowdsec crowdsec-blacklists-cscli -OR- nft list set ip6 crowdsec6 crowdsec6-blacklists-cscli
3. Note that the specified subnet has not been added, but instead a single address (same behavior for both IPv4 & IPv6)

Anything else we need to know?

I researched but wasn't able to find a way to override how the sets are created (to add the interval flag).

version

remediation component version:

$ crowdsec-firewall-bouncer --version
version: v0.0.33-debian-pragmatic-amd64-cb8b3e3c654499f745ff487eb1c327d7234a533f
BuildDate: 2025-05-22_13:39:17
GoVersion: 1.24.3
Platform: linux

crowdsec version

crowdsec version:

$ crowdsec --version
version: v1.6.10-debian-pragmatic-amd64-79870769
Codename: alphaga
BuildDate: 2025-07-10_13:15:34
GoVersion: 1.24.4
Platform: linux
libre2: C++
User-Agent: crowdsec/v1.6.10-debian-pragmatic-amd64-79870769-linux
Constraint_parser: >= 1.0, <= 3.0
Constraint_scenario: >= 1.0, <= 3.0
Constraint_api: v1
Constraint_acquis: >= 1.0, < 2.0
Built-in optional components: datasource_appsec, datasource_cloudwatch, datasource_docker, datasource_file, datasource_http, datasource_journalctl, datasource_k8s-audit, datasource_kafka, datasource_kinesis, datasource_loki, datasource_s3, datasource_syslog, datasource_victorialogs, datasource_wineventlog
Excluded components: cscli_setup

OS version

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ uname -a
Linux srv899372 6.1.0-37-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux

[github-actions]

@exigentix-dev: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Documentation to see if your issue can be self resolved.
2. You can also join our Discord

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[exigentix-dev]

Example for IPv4:

root@srv:/etc/crowdsec# cscli decisions add --range 39.70.174.0/24 --duration 30d
INFO Decision successfully added                  

root@srv:/etc/crowdsec# nft list set ip crowdsec crowdsec-blacklists-cscli
table ip crowdsec {
	set crowdsec-blacklists-cscli {
		type ipv4_addr
		flags timeout
		elements = { 39.70.174.0 timeout 29d23h59m57s expires 29d23h59m48s676ms }
	}
}

[LaurenceJJones]

Ranges should be ignored in nftables due to not being supported #396

We will most likely need to patch it to ignore them cause adding support for ranges is an involved task.

[EnzanNoMetsuke]

Thanks for responding, @LaurenceJJones . I reviewed the conversation on #85 and I can see how the complexity on this could get pretty intense... adding overlapping ranges causing nftables to throw errors, potential for race conditions when deleting decisions close to timeout expiry, etc.

That said, since cscli already supports decisions on ranges and nftables also supports CIDR ranges in sets as long as they have the interval flag, it really seems to me that it's bad UX to leave this undone for long.

As it stands now with the current (unexpected) behavior, an ineffective ban occurs despite both ends of the stack supporting ranges.

[CactiChameleon9]

Was trying to debug this exact issue, I thought my firewall was broken for a while! Do any of the other firewall protocols work? Why is this not documented as a broken feature?

[PurpleTape]

any updates? 🥺🥺🥺