Recent posts

#1
General Discussion / The OPNsense Plugins System Si...
Last post by Majx - Today at 10:12:36 PM
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.
#2
26.1 Series / Re: Issue Removing Gateway Gro...
Last post by Ben S - Today at 10:12:31 PM
This looks like it's due to not having any old style rules.  I'm guessing you've migrated to new style rules, and deleted all of your old rules?  I can reproduce this by ensuring at least one old style rule exists, running step 5 of the rules migration, and then trying to delete a gateway group.  Deleting the last rule by hand doesn't cause the problem.

As a workaround until this is fixed, if you add any old style rule (even if it is disabled) then you should be able to delete the gateway group.
#3
26.1 Series / Re: Can Unbound DNSSEC be used...
Last post by LemurTech - Today at 10:09:58 PM
Hello, Ben!

I already have 'Do not forward to system defined DNS servers' enabled. Dnsmasq should not be doing any forwarding. I also do not have DNSSEC enabled in Dnsmasq. Are you saying that you have a configuration similar to mine and it is working for you? That would at least give me hope that it's just a matter of settings on my side.

The order of the parameters doesn't seem to matter here:

root@fw01:~ # drill @127.0.0.1 -p 53053 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 6682
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; emporia.iot.lan.     IN      A

;; ANSWER SECTION:
emporia.iot.lan.        1       IN      A       192.168.12.86

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Feb 14 12:55:22 2026
;; MSG SIZE  rcvd: 49

root@fw01:~ # drill -p 53053 @127.0.0.1 emporia.iot.lan
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 33100
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; emporia.iot.lan.     IN      A

;; ANSWER SECTION:
emporia.iot.lan.        1       IN      A       192.168.12.86

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Feb 14 12:55:52 2026
;; MSG SIZE  rcvd: 49
#4
26.1 Series / Re: Destination NAT (port forw...
Last post by optimal_agency - Today at 09:54:01 PM
I totally get the frustration with the manual NAT configuration after the upgrade; it can be quite a headache to get the rules right. At our digital marketing agency, we often handle these technical infrastructure challenges when setting up secure, high-performance environments for our clients' websites.

Have you checked the 'Filter rule association' setting in your NAT rule? Sometimes manually creating the associated WAN rule while setting the association to 'None' helps clear up those silent blocks. Technical stability is definitely the foundation for a solid digital presence.
#5
26.1 Series / Re: Destination NAT (port forw...
Last post by Klabautermann - Today at 09:51:02 PM
Can someone please explain in more detail how the rules need to look when you create them manually. I am experiencing the same issue, upgraded OPNSense, migrated the rules and not I am unable to create a destination NAT. I followed the instruction in the official documentation to set them to pass but it does not work. I also tried to set them to registered and rules appear in the WAN section but it still does not work.

This is super unintuitive and I can't figure it out on my own.
#6
General Discussion / Re: OPNsense 26.1.1 with Adgua...
Last post by akore - Today at 09:32:37 PM
Spent the day yesterday researching and then installing while documenting. I am getting 96 out of 100 on https://adblock-tester.com/

On Adguards own site it shows all 3 as Not running which is strange unless they are only looking at the PC itself?

For anyone that wants to run Adguardhome and Unbound on OPNsense at the same time (and future me for when I forget how as I am 62) here is what I documented:

Run AdGuard Home and Unbound DNS simultaneously in OPNsense

Step-by-Step Configuration
      1. Install AdGuard Home (Frontend):
        ◦  Enable SSH: Go to System > Settings > Administration and enable Secure Shell.
        ◦  Add Repo via Terminal: Log in to your OPNsense shell via SSH and run the following command to add the repository: 
        ◦  fetch -o /tmp/mimugmail.conf https://www.routerperformance.net/mimugmail.conf
mv /tmp/mimugmail.conf /usr/local/etc/pkg/repos/
        ◦  Update Package List: Run the following command to refresh the repository:
        ◦  pkg update
        ◦  Install Plugin: Go to System > Firmware > Plugins in the WebGUI, search for os-adguardhome-maxit, and click the + button to install
        ◦  Go to Services > AdGuardHome > General, enable the service.
      2. Prepare Unbound DNS (Backend):
        ◦  Go to Services > Unbound DNS > General.
        ◦  Change the Listen Port from 53 to 5353.
        ◦  Save and Apply.
      3. Configure AdGuard Home Upstream:
        ◦  Access the AdGuard Home web GUI (usually http://<opnsense-ip>:3000 initially, then port 8080/443 after setup).
        ◦  During Adguard setup at step one change the Listen interface to Port 8080 since port 80 is most likely already in use, and leave DNS server set all 53. Both should be set on All interfaces.
         
        ◦  Navigate to Settings > DNS Settings.
        ◦  Set Upstream DNS servers to 127.0.0.1:5353.
        ◦  Set Private reverse DNS servers to 127.0.0.1:5353.
     
      4. Configure OPNsense System DNS:
        ◦ Go to System > Settings > General.
        ◦  Under Networking section Set DNS servers to 127.0.0.1 (AdGuard).
        ◦  Uncheck Allow DNS server list to be overridden by DHCP on WAN.
        ◦  Check Do not use the local DNS server as a name server for this system (if you want to    force all traffic through AdGuard).
      5. Configure DHCP (Clients):
        ◦  Go to Services->Dnsmasq & DHCP->DHCP options Add a new entry; under "Option" pick dns-server [6] and put your OPNsense ip in the "Value" section (usually 192.168.1.1); select the interface you want it to apply to (usually  LAN) then save and apply, restart Dnsmasq.
         
Notes:
Alternative Port: Some users prefer high ports like 65353 for Unbound to avoid conflicts with mDNS.
Conflicts: If AdGuard Home fails to start, it is likely a port conflict (another service using port 53). Ensure Unbound has moved to 5353.
    •  Alternative: Instead of using AdGuard + Unbound, you can use Services > Unbound DNS > Blocklist to use DNSBL lists directly within Unbound for similar, albeit less feature-rich, ad-blocking.
#7
German - Deutsch / Re: letsencrypt DNS Problem
Last post by Simaryp - Today at 09:28:12 PM
Ich habe jetzt in der Netzwerkverbindung des Servers eingetragen, dass ein anderer DNS-Server genutzt werden soll.
Damit geht das ganze und ich kann auch unbound wohl wieder auf 53 umziehen.

Ich finde es aber schade, dass das ganze in einer früheren Version von opnsense auch mit benutzung von unbound für den server lief, jetzt aber mit dnsmasq nicht mehr geht.
Ich kann es halt leider nicht mehr reproduzieren, weil ich das alte system nicht mehr habe.
#8
26.1 Series / Re: Register DHCP Static Mappi...
Last post by Patrick M. Hausen - Today at 09:17:01 PM
Kea has a hook to Unbound for static mappings only. And none to DNSmasq if I am not mistaken.

For dynamic leases to be registered in DNS the current standard way is to use DNSmasq for DHCP and for DNS for the local domain. If you use Unbound as the client facing server and configure a forward for the local domain to DNSmasq of if you have DNSmasq answer to the clients and forward all recursive lookups to Unbound is a matter of taste, IMHO.
#9
26.1 Series / Re: Register DHCP Static Mappi...
Last post by teclab - Today at 08:59:28 PM
I need to participate here, because I'am struggling with the same issue. I have upgraded to 26.1 and now using KEA DHCP together with Unbound DNS, Dnsmasq DNS & DHCP is disabled.

From the link you provided I read that Dnsmasq is required as a connector. But in Unbound I have enabled Register DHCP Static Mappings and I thought this does exactly what I wanted: Having hosts which got a DHCP lease from KEA will be served via DNS. ... but it's not working.

Does KEA only have a hook towards Dnsmasq?

BR
#10
German - Deutsch / Re: letsencrypt DNS Problem
Last post by Simaryp - Today at 08:31:23 PM
Ich habe jetzt unbound auf Port 53153 gesetzt, dnsmasq ist weiterhin auf 53053.
Ich habe unter settings general einen DNS Server eingetragen.
Dann habe ich ein Portforward, der bis auf den Server allen traefic auf 53 weiterleitet an 53153.

DNS funktioniert für alle Geräte, aber der Server kriegt jetzt gar kein DNS mehr. Irgendwie scheint die Eintragung eines DNS-Servers wie 8.8.8.8 oder 1.1.1.1 überhaupt keinen Effekt zu haben.
Leite ich wirklich alles auf 53153 also unbound um, hat der Server auch wieder dns.

Ich könnte hier wirklich Hilfe gebrauchen.