Yeah... pkg 1.8 added the "vital" flag which can prevent accidental removal of the GUI package, which could happen either due to pkg resolver bugs during challenging LibreSSL/OpenSSL transitions, or due to manual errors during a package switch.

The "vital" flag is actually going to be used for FreeBSD's base pkg support where base and kernel components really should not be uninstalled under any circumstances. Base pkg was originally scheduled for 11.0, then rescheduled for 11.1, but maybe we won't see it before 12.0.

But long story short, it's a very useful feature in OPNsense already although one can't appreciate it because it will prevent bad things from happening in the first place. :)

The way it was bundled/distributed by OpenVPN, regenerating binaries for every point release. Split between different architectures at that. I hear 2.4 has reduced the binary pool.

This can be put back in using a more clever "grab binaries from remote using embedded hashes to confirm their authenticity", the former state wasn't maintainable from a "shipped by default" perspective, putting large binary blobs into our repositories. Not to mention that we do not have a dedicated maintainer for OpenVPN export.

The pressure to resolve this "impossible" state by removing the binaries was high so we did it for a consistent experience. Note that client files can still be exported.

I'm picking up OpenVPN 2.4 after 17.1 is out. Much of this is gentle but frequent user feedback and incentive to provide testing. :)

Not without the direct involvement of the author of the software. I don't think it is likely.

Hello Franco,

Users are banned for less, what do you think it will happen with BBcan if J. finds out he helps OPNsense? So I don't think he will agree.

But besides that, maybe something like pfblockerNG can be created by OPNsense.

I'm interested because Suricata (or Snort) and pfblockerNG are the most used packages(IMHO) in that other project. These two I'm using myself too. For Suricata I wan't to thank you that you keep it updated in comparison with that other project.

I would hope he would help out, though I don't see any reason why that would happen. As long as something works, why fix it / rebuild it somewhere else. If anything, he should continue to provide top notch pfBlockerNG updates. :)

We did, however, implement similar functionality, but it's not as condensed as the original package. Aliases have received GeoIP support, it makes their use a bit more flexible. The web proxy received fine-grained remote blacklist support. Probably more, I don't remember all.

I believe there are simple knobs missing for "block bad reputation, block the top x things" etc. We need to identify and separate those to find a way for a streamlined integration. Taking a small requirement is often way quicker and easier and also more aligned with the code that we have now than trying to mimic all at once.

It's true that it's harder for someone expecting the same features to be presented in the same way, but also think of the larger body of new users who've never seem something like pfBlockerNG and naturally find the GeoIP blocking in the aliases. We should build the features for them too. :)