"Recent posts
#1
German - Deutsch / Re: DSL Zwangstrennung verschi...
Last post by k0ns0l3 - Today at 04:18:30 AMDanke 😉
Lg
Lg
#2
26.1 Series / Unbound: how to configure stub...
Last post by ColinJCrawford - Today at 03:57:12 AMHi all, long time user here, first time asker.
When using Unbound for DNS recursive resolving, is it possible to configure stub zones in Unbound within OPNsense's UI somehow? I'm familiar with the dialog at Services -> Unbound -> Query Forwarding, but that creates "Forward Zones," per Unbound's terminology, which behave differently. With forward zones, queries to the specified servers are sent with the "recurison desired" flag set, and DNSSEC validation is skipped. Both of these are fine when forwarding to another recursive DNS resolver.
However, in my environment, I've got a pair of authoritative DNS servers for the local domains, and want to configure Unbound to use those when performing recursive resolution for the local domains. In this case, recursive queries to these authoritative servers would fail.
I'm aware that I can most likely manually configure the stub zones I want with a .conf file per https://docs.opnsense.org/manual/unbound.html#advanced-configurations. However, is there a way I've missed to do so in OPNsense's UI? I'd prefer that, if possible, for easier maintenance.
Thanks in advance!
When using Unbound for DNS recursive resolving, is it possible to configure stub zones in Unbound within OPNsense's UI somehow? I'm familiar with the dialog at Services -> Unbound -> Query Forwarding, but that creates "Forward Zones," per Unbound's terminology, which behave differently. With forward zones, queries to the specified servers are sent with the "recurison desired" flag set, and DNSSEC validation is skipped. Both of these are fine when forwarding to another recursive DNS resolver.
However, in my environment, I've got a pair of authoritative DNS servers for the local domains, and want to configure Unbound to use those when performing recursive resolution for the local domains. In this case, recursive queries to these authoritative servers would fail.
I'm aware that I can most likely manually configure the stub zones I want with a .conf file per https://docs.opnsense.org/manual/unbound.html#advanced-configurations. However, is there a way I've missed to do so in OPNsense's UI? I'd prefer that, if possible, for easier maintenance.
Thanks in advance!
#3
General Discussion / What is The Purpose of Setting...
Last post by amuckart - Today at 03:25:06 AMAfter a recent upgrade to Business Edition 25.10.2 resulted in a kernel panic that required on-site assisance to recover because it hung the firewall I went looking at the 'panic' related sysctls and noticed the sysctl
Having this set means the firewall requires on site intervention to recover from a kernel panic which is suboptimal for a remote office firewall.
What's the purpose of this setting in OPNsense?
Thanks.
Code Select
debug.debugger_on_panic is set to 1.Having this set means the firewall requires on site intervention to recover from a kernel panic which is suboptimal for a remote office firewall.
What's the purpose of this setting in OPNsense?
Thanks.
#4
General Discussion / Re: The OPNsense Plugins Syste...
Last post by Majx - Today at 01:46:33 AMThank 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
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
#5
26.1 Series / Re: Neighbors: Automatic Disco...
Last post by nero355 - Today at 12:27:23 AMQuote from: kasper93 on February 26, 2026, 04:23:30 PMthere is the fact that static arp is not possible with ISC alternatives, currently.Depends on how you look at it :
- https://dnsmasq-discuss.thekelleys.org.narkive.com/TJwZNwvD/how-to-set-static-arp-entry-according-to-dhcp-request
- https://github.com/imp/dnsmasq/blob/master/contrib/static-arp/static-arp
:)
#6
26.1 Series / Re: Enabling WireGuard causes ...
Last post by devrandom - Today at 12:25:35 AMThis seems to be the preferred way : https://docs.opnsense.org/manual/how-tos/nat_reflection.html#method-1-creating-manual-port-forward-nat-dnat-manual-outbound-nat-snat-and-automatic-firewall-rules
As mentioned at the start of that article : https://docs.opnsense.org/manual/how-tos/nat_reflection.html#introduction-to-reflection-and-hairpin-nat
Another reference here : https://docs.opnsense.org/manual/firewall_settings.html
So the 'Automatically Generated Firewall Rules' that are made because of 'Manually Configured Destination/Source NAT Rules' should be perfectly fine!
Can we assume you have always done it like that and never mixed any of the methods ?!
[/quote]
That is correct, I haven't mixed any of the methods. At least for this fresh install of 26.1. The good news is I have my replacement hardware and I'm just finishing up the setup on it. Once I drop it back into my network tomorrow I can start over again with the WireGuard setup while I'm home for the weekend and be able to test things without locking myself out of my network while I'm at a remote location (work).
Thank you for clarifying some of this for me. I'll go over all the documentation in these links again and make sure I'm not missing something. And then I'll report back again.
As mentioned at the start of that article : https://docs.opnsense.org/manual/how-tos/nat_reflection.html#introduction-to-reflection-and-hairpin-nat
Another reference here : https://docs.opnsense.org/manual/firewall_settings.html
So the 'Automatically Generated Firewall Rules' that are made because of 'Manually Configured Destination/Source NAT Rules' should be perfectly fine!
Can we assume you have always done it like that and never mixed any of the methods ?!
[/quote]
That is correct, I haven't mixed any of the methods. At least for this fresh install of 26.1. The good news is I have my replacement hardware and I'm just finishing up the setup on it. Once I drop it back into my network tomorrow I can start over again with the WireGuard setup while I'm home for the weekend and be able to test things without locking myself out of my network while I'm at a remote location (work).
Thank you for clarifying some of this for me. I'll go over all the documentation in these links again and make sure I'm not missing something. And then I'll report back again.
#7
General Discussion / Re: Configuring Unbound DNS fo...
Last post by Patrick M. Hausen - Today at 12:20:52 AMIf there is a DNAT/port-forward on that external IP address, yes. If it's a reverse proxy, no. That's the beauty of reverse proxies.
#8
26.1 Series / Re: Failed upgrade 23.1.11_2 t...
Last post by nero355 - Today at 12:19:48 AMQuote from: mfalkvidd on February 26, 2026, 06:42:23 PMHow can I check the disk, besides scrubbing the pool?AFAIK there are two options :
- https://man.freebsd.org/cgi/man.cgi?query=nvmecontrol&sektion=8&format=html
- System > Firmware > Plugins > os-smart which installs smartctl : https://docs.dasnipe.com/docs/opnsense/smart/installation/
Those two would be the first thing I would look into :)
#9
General Discussion / Re: Configuring Unbound DNS fo...
Last post by foss-johnny - Today at 12:16:10 AMQuote from: Monviech (Cedrik) on February 26, 2026, 02:46:50 PMYou can use the external IP address of the OPNsense, split DNS is not necessary.
Would a reflection or hairpin NAT be needed so that various internal LAN subnet clients can connect back to the external IP address?
#10
26.1 Series / Re: Log search/filtering inter...
Last post by nero355 - Today at 12:07:47 AMQuote from: rackenthogg on February 26, 2026, 08:28:29 PMScreenshot 2: Interface under Palemoon-based New Moon Browser:Actually you should be using https://www.basilisk-browser.org/ who is also based on Goanna Rendering Engine just like Pale Moon :)
But indeed :
- My up-to-date Pale Moon 34.0.1 64-bit (GTK2) shows the same issue!
- LibreWolf 148.0-1 shows it correctly.
But that's because it's basically Mozilla Firefox but it's just heavily modded...
