Messages

> Your idea makes sense, but it would give legitimacy to plugins that are not vetted.

That concern is valid, and I agree it is one of the main risks in the current proposal. However, I do not think the proposal has to be adopted exactly as written. It can be refined and improved.

The objective is to shift responsibility and maintenance burden to plugin authors while allowing the core team to focus more on OPNsense itself. If we can design a model that makes plugin creators clearly responsible for their own code, without implying endorsement or legitimacy by the core project, then we could achieve that goal without compromising security standards.

At the moment, the team spends significant time reviewing PRs, vetting plugins, and maintaining a large and growing ecosystem. As OPNsense continues to grow in popularity, that workload will only increase. Reducing that overhead would directly benefit the core product and its long term stability.

> I just wanted to make this part clear, because it is an uncontrollable risk in your suggestion, because nobody is vetting the code.

It is indeed an uncontrollable risk to some extent. The real question is who owns that risk.

If third party plugins are clearly separated from the OPNsense core, both technically and in terms of branding and messaging, then the responsibility shifts to the user who decides to install them. Many software ecosystems operate this way. Not every extension is vetted by core maintainers, but they are clearly identified as community maintained or third party.

As long as there is no implied endorsement and users are clearly informed that these plugins are not reviewed by the core team, the responsibility model becomes much clearer.

> A GUI click is NOT a responsibility shift in the minds of (some) users.

That is true to a certain degree. Some users will always assume that if something appears in the GUI, it is officially supported.

However, we also have to define reasonable boundaries. It is not realistic to eliminate every possible misunderstanding. At some point, clear labeling and explicit warnings have to be considered sufficient.

If the interface clearly states that certain plugins are community maintained, not reviewed by the core team, and installed at the user's own risk, then the project has taken reasonable steps to communicate that distinction.

Ultimately, this is about balance. We need to protect the reputation and security posture of OPNsense, avoid an unsustainable maintenance burden for the core team, and still allow the ecosystem to grow without becoming a bottleneck.

I am not arguing for removing safeguards. I am just suggesting that we explore a structure that preserves the security expectations while enabling the project to scale. If we do not adjust the model, the maintenance burden of plugins will only continue to grow, and that may become a larger long term risk than clearly marked third party plugins.

/Majx

Thank you for your reply Franco.

I believe there may have been a small misunderstanding and that I may not have expressed my point clearly enough in my original post.

> Hmm, you want to contribute 2-Clause BSD code? Sure. You want leeway? Nope.

I completely understand and agree that OPNsense is licensed under 2-Clause BSD and that any contribution to core, plugins, or ports must follow that same license. I am not looking for exceptions or alternative licensing inside the official repositories. The integrity of the project depends on consistency, and I respect that.

> The biggest issue with the plugin system at the moment is that we don't have enough time to vet PRs and submission and even cover the use cases of the plugins proposed. AI is used more and more to generate full plugins in a heartbeat. We will likely have to say "no" more than before to make time for other submissions.

Regarding the current pressure on the plugin system and the limited time available to vet PRs, I fully understand the challenge as the volume of contributions can easily exceed what is realistically reviewable. That is one of the reasons why I was thinking about a new structural separation instead of the current broad inclusion.

> On the subject of binaries... if you have the source code in the open addition to FreeBSD ports is the usual way to get it intergrated as a plugin because that adds peer review to the functionality and reduces risk over security concerns (now or in the future).

My proposal is not about introducing non-reviewable binaries into core. Instead, what I am trying to explore is whether plugin discoverability must necessarily require governance and code inclusion.

In other words, there could be a conceptual difference between "official plugins" that are reviewed, merged, and maintained under the OPNsense umbrella, and "community-listed plugins" that remain entirely owned and maintained by their original developers. These would not be part of the official repositories and not maintained by the OPNsense team. They would simply be discoverable through a structured registry mechanism inside the GUI. Installation could require an explicit opt-in action from the user, such as enabling a "community sources" section or confirming a clear trust warning, without requiring manual command-line repository configuration.

Such a separation would preserve the strict review standards and security model of OPNsense, while avoiding additional maintenance burden for the core team. It would also make the trust boundary explicit to users, for example by clearly distinguishing official plugins from externally maintained ones. That would provide visibility without transferring responsibility.

If even listing external plugins creates an implied endorsement that the project is not comfortable with, I completely understand that position. My goal is not to argue against the current standards, but to explore whether there is room for a middle ground between full integration and practical invisibility.

Thank you again for taking the time to respond and for making OPNsense reliable and trusted.

/Majx

[Introduction]

I would first like to thank the OPNsense team for all of their hard work and the consistent support they provide to the community.

I'm not sure whether this topic has been discussed before. I searched the forum but couldn't find a clear discussion about it. If this has already been addressed, I would appreciate being pointed to the relevant resources.

Introduction

Many of us invest our free time developing plugins for OPNsense.

From what I have observed, there are currently two ways to publish a plugin for public use:

• Host your own repository
  Developers can maintain a separate repository, host the plugin themselves, and provide users with command-line instructions to add the repository to their system. Once added, the plugin appears under System → Firmware → Plugins.
  
• Submit the plugin to the official repository
  Developers can contribute their plugin to the opnsense/plugins repository, allowing it to appear directly in the default OPNsense plugin list without requiring users to add external repositories.
  

Where Is the Problem?

If a developer wants their plugin to be easily discoverable by users, the most practical route is publishing it under the official opnsense/plugins GitHub repository. However, doing so requires compliance with the BSD-2-Clause license and effectively places the code under the project's governance and license. For some developers, this creates concerns about licensing flexibility and long-term control over their work.

On the other hand, publishing plugins in private repositories significantly reduces their visibility, meaning many users may never discover them unless they happen to find them independently and manually add the external repository to their system in order to install the plugin.

This creates a trade-off between visibility and accessibility versus licensing flexibility and control.

Possible Solution?

One possible approach would be to implement an official plugin registry or indexing system within OPNsense, enabling third-party developers to register plugin metadata (name, description, version, repository URL) and have these plugins displayed via the "Show Community Plugins" section of the GUI.

This approach would maintain developer ownership and licensing flexibility, improve the visibility of third-party plugins, and enhance the user experience. It would also strengthen OPNsense as a platform, since there are plugins that expand its capabilities currently exist outside the official repository and are not widely known. Furthermore, it could reduce maintenance overhead by enabling plugin-related issues and support to be managed by their respective maintainers instead of being centralized within the opnsense/plugins project.

I would be very interested to hear the thoughts of the OPNsense team and the community on this matter.

I can confirm almost the exact same behavior on my end.

The issue is that when a connection state already exists before the killswitch rule is enabled, traffic continues to follow the previously created state. As a result, the killswitch rule is bypassed until those states are cleared. Manually clearing the relevant states forces the firewall to create new ones that will then be evaluated and blocked by the killswitch rule as intended.

The larger problem is that you need to clear all connection states for hosts in the subnet (10.0.10.0/24). Doing so will kill all active connections (gaming, downloads, streaming, etc.), since every existing state for that subnet will be dropped, which is very bad.

The alternative would be to disable state tracking completely, but that will result in reduced performance (and might break other features?).

The most reliable solution is still to clear the states, even though it will impact the entire 10.0.10.0/24 network. Fortunately, this state reset is typically required only once (when you first apply the killswitch rule). VPN clients (PC or mobile) do the same thing on connection, the difference is that they affect only a single device rather than the whole subnet.