Crowdsec bans don't appear to be blocked

[svheel]

Hi everybody,

I have a fairly simple setup with OPNsense in my home, which works very well (WAN interface based on PPPoE, LAN interface with several VLANs) running on an N100 mini PC with 2.5 GB ports.

I have the Crowdsec plugin installed and configured mostly with default settings and it appears to function well, the overview shows green checkmarks everywhere, I see alerts and decisions appearing.
I have an SSH server behind the OPNsense box in the LAN segment and I have created a port-forward rule from WAN to that SSH server, which works without a problem (I can login to the SSH server from outside my network). On the SSH server I have installed Crowdsec in a Docker container, which connects to the OPNsense firewall and parses the SSH logs. This also works without a problem, the SSH server is shown in the 'Machines' page of the Crowdsec overview page in OPNsense and I see alerts with reason 'crowdsecurity/ssh-slow-bf' and 'crowdsecurity/ssh-bf' in the 'Alerts' page, with corresponding decision in the 'Decisions' page.

All this appears to work fine, but the problem is that the firewall doesn't block the IP's banned by Crowdsec (which are on the decisions list).
I tested this by adding the IP of a server outside my home network with 'cscli decisions add -i <IP of server>' in a shell, which works (it shows up in 'cscli decisions list').
The IP is on the 'crowdsec_blacklists' alias and shows up in the output of the 'pfctl -t crowdsec_blacklists -T show' command.
Yet the IP isn't blocked by the firewall and I can still access the SSH server from the banned IP address.
In the firewall rules 'Floating' section I see a rule for this alias in the 'automatically generated rules' section and they are also in the 'WAN' rules section.

Does anybody have any idea what could be wrong?
I suspect it might have something to do with the port-forwarding and NAT rules, but that's also configured in a very standard way, without any weird configuration options as far as I can see. Specifically the Filter rule association in the port-forward configuration, which I have seen mentioned in a topic about a similar issue, is set to 'Rule'.

Thanks in advance!

[dinguz]

I've also noticed an issue with the automatically created floating and WAN rules. When clicking the eye/inspect button to view the rule hit counters, the CrowdSec rules are listed as N/A. I'm not entirely sure what "N/A" means in this context, but it certainly seems there might be a problem.
To address this, I manually recreated the rules, and they now appear to be working correctly.

[dan786]

I have the same issue even manual rule making it does not report right but also noticed Matrail does similar not reporting

[svheel]

I created the rules manually on the WAN interface and indeed, now it works, traffic from the banned IP's is blocked by the firewall.
Also I see the same as 'dinguz' when using the 'Inspect' (or eye) function in the firewall rules: Both automatically generated IPv4 and IPv6 rules have 'N/A' on all inspect columns, so I assume something is not right with those rules (all other rules have numbers there).

I'm not sure what you mean 'dan786' with manual rules not reporting right, maybe you need to turn on logging for those rules? (click on the 'i' icon in the rules list to enable logging, default is disabled).

[dan786]

I created the rules manually on the WAN interface and indeed, now it works, traffic from the banned IP's is blocked by the firewall.
Also I see the same as 'dinguz' when using the 'Inspect' (or eye) function in the firewall rules: Both automatically generated IPv4 and IPv6 rules have 'N/A' on all inspect columns, so I assume something is not right with those rules (all other rules have numbers there).

I'm not sure what you mean 'dan786' with manual rules not reporting right, maybe you need to turn on logging for those rules? (click on the 'i' icon in the rules list to enable logging, default is disabled).

I have been using Opnsense few years now never seen that issue before no i had the logging enabled but still wouldn't work right. there a patch or something that coming to address that . I'm not sure why maltrail did that.