Quote from: Zugschlus on November 29, 2025, 12:50:27 PMQuote from: viragomann on November 28, 2025, 05:23:42 PMYou need to add the rule to the interface, which the traffic is going out.
If you want to access the LAN IP of the secondary, the packets will go out on the LAN interface. If you access the SYNC interface, the packets go out on SYNC.
Its wise to use ever the same IP to access the firewall. So you need the rule only on a single interface.
And of course you should limit the rule to the admin source and to the secondary as destination.
Best to use an alias, which includes both, the IP of the primary and secondary, so you can sync the rules to the secondary and it will also work in case it has the master role.
Thanks for your advice, that's what I'll do.
Quote from: Zapad on November 30, 2025, 06:24:04 PMtut mir leid, habe da nix nützliches(was man nicht längst weiss) raushören können....
da macht sich einfach einer wichtig.... sowas wie Snowden für Arme.
Quote from: Mpegger on November 30, 2025, 11:10:54 PMI should probably ask if there is a known realiable regularly updated list of DoH servers to use for blocking purposes?
Quote from: jonny5 on July 23, 2025, 10:28:25 PMAs the CrowdSec Parser Agent that is installed will parse what it is told to from the `/usr/local/etc/crowdsec/acquis.d/*.yaml` and `/usr/local/etc/crowdsec/acquis.yaml` on the OPNSense, it is more about the detail there, and the Allowlists and other pre and post processing you configure.Also helpful to remember: the OPNsense CrowdSec plug-in already applies blocklists only on the WAN interface by default. So for most setups, you mainly need to adjust acquis to prevent LAN log parsing and avoid the random connection issues you were seeing.
That all said, by default the plug-in's CrowdSec Agent Parser will parse the firewall/pf logs. You can have it parse more, such as Suricata, and in this case it would be up to you to configure Suricata to only look at WAN or to have CrowdSec collect the logs and apply that filter logic in the acquis details and follow-up pre/post processing configs respectively.
The OPNSense CrowdSec plug-in also includes a Blocker Agent, it will listen to your LAPI (the Server side of your local CrowdSec city brawl plug-in) and update the WAN only blocklist the is configured as a part of the plug-in installation. This already meets your needs from what I understand.
!! Major extra / might not be on your focus !!:
You can do more to modify and retain your modification for the CrowdSec plug-in btw...
From using an external LAPI, to not using the Blocker Agent (keeping only the Parser Agent active on the OPNSense)
Then, making your own Alias and Firewall rules to use the CrowdSec list where and how you want
I have not published my how to on how to do this, as, it isn't really as good as I'd like it to be (it works but on a 10 second scale of update, and updates/refresh to the Alias active content, has took 7 seconds in the past) so once I learn how to update the data in the PF alias list on the back end of OPNSense... I'll post a blog entry on doing more with the CrowdSec feature. Likely I just need to look more into doing a manual install of CrowdSec's FreeBSD blocker on an OPNSense.