"Recent posts
#1
German - Deutsch / IPV6 Tunnel mit Route64
Last post by Swtrse - Today at 02:46:02 AMHallo,
Ich bin am ende mit meinem Latein und Copilot schickt mich auch nur noch im Kreis ^^.
Ich habe ein Setup mit PPPoE. Mein "Steinzeit"-Provider (A1) Bietet kein IPv6 auf meinem Anschluss also habe ich einen GIF Tunnel mit Rout64 eingerichtet.
Mein Problem
Nach einem Reboot der Firewall funktioniert IPv6 ~120 Sekunden lang dann bekomme ich nur noch timeouts.
Was Copilot mir vorgeschlagen hat und umgesetzt wurde (ohne Erfolg):
Gateway monitoring deaktiviert
Statische Route gesetzt zur Endadresse von Rout64 (Weil ich nicht die eigenliche Tunneladresse verwende sondern das ebenfalls geroutete /56 subnetz)
Eine Allow All Rule auf dem Interace für den GIF Tunnel
Bei der Regel auf dem Wan Interface ür Protocol 41 ["Antwort-an" deaktivieren] angehackt und [Status-Typ] auf "Kein Zustand" gestellt.
MTU alles mögliche und MSS auch.
Sobald meine Pings nur noch timeouts werfen. Sehe ich selbst bei der Paketaufzeichnung nichts.
Ich bin am ende mit meinem Latein und Copilot schickt mich auch nur noch im Kreis ^^.
Ich habe ein Setup mit PPPoE. Mein "Steinzeit"-Provider (A1) Bietet kein IPv6 auf meinem Anschluss also habe ich einen GIF Tunnel mit Rout64 eingerichtet.
Mein Problem
Nach einem Reboot der Firewall funktioniert IPv6 ~120 Sekunden lang dann bekomme ich nur noch timeouts.
Was Copilot mir vorgeschlagen hat und umgesetzt wurde (ohne Erfolg):
Gateway monitoring deaktiviert
Statische Route gesetzt zur Endadresse von Rout64 (Weil ich nicht die eigenliche Tunneladresse verwende sondern das ebenfalls geroutete /56 subnetz)
Eine Allow All Rule auf dem Interace für den GIF Tunnel
Bei der Regel auf dem Wan Interface ür Protocol 41 ["Antwort-an" deaktivieren] angehackt und [Status-Typ] auf "Kein Zustand" gestellt.
MTU alles mögliche und MSS auch.
Sobald meine Pings nur noch timeouts werfen. Sehe ich selbst bei der Paketaufzeichnung nichts.
#2
Hardware and Performance / Re: [solved] Intel i226 Firmwa...
Last post by BrandyWine - Today at 02:44:48 AMpromox is debian linux, so you need the linux tool, not the freeBSD tool.
You can find the etrackID of your existing nvm, so find it and put that in cfg for replaces. Inventory and log using the util tool, in there it should show etrackID.
Make sure everything in cfg is correct and spelling is good.
You can find the etrackID of your existing nvm, so find it and put that in cfg for replaces. Inventory and log using the util tool, in there it should show etrackID.
Make sure everything in cfg is correct and spelling is good.
#3
Hardware and Performance / Re: [HOWTO] Install OPNsense 2...
Last post by rumshot - Today at 02:17:46 AMHello Team,
I bought a EC-XS too and could figure out most of the steps, until arrive this thread.
My issue is due to the fact the device is not detecting my usb stick and im unable to boot from it and install opnsense.
I was wondering if someone face that or would have a tip to give me.
I could potentially install the opnsense in another computer with ec-xs hd, but i dont know if when i swap it back to ec-xs it will detect the interfaces and so on.
Any guidance its welcome.
ps.: im mac user, then maybe im struggling a little bit and not sure if my usb stick its really booting.
I bought a EC-XS too and could figure out most of the steps, until arrive this thread.
My issue is due to the fact the device is not detecting my usb stick and im unable to boot from it and install opnsense.
I was wondering if someone face that or would have a tip to give me.
I could potentially install the opnsense in another computer with ec-xs hd, but i dont know if when i swap it back to ec-xs it will detect the interfaces and so on.
Any guidance its welcome.
ps.: im mac user, then maybe im struggling a little bit and not sure if my usb stick its really booting.
#4
26.1 Series / Re: KEH reservations
Last post by passeri - Today at 02:11:23 AMReservations remain as you would expect.
Are your reservations outside your dynamic pools?
Did you miss an Apply somewhere along the line?
Are your reservations outside your dynamic pools?
Did you miss an Apply somewhere along the line?
#5
26.1 Series / Re: KEH reservations
Last post by nero355 - Today at 12:32:06 AMQuote from: unixpgmr on February 14, 2026, 11:03:32 PMCan't it save reservation between reboots?I think your upgrade procedure wasn't the most optimal one...
You should have migrated to something else BEFORE upgrading to a release that moves ISC DHCP Server to the plug-in and then start the upgrades.
All your old DHCP Reservations could have been exported to .CSV files and imported into either KEA DHCP Server or DNSmasqd DHCP & DNS Server.
And all reservations should just stay where they are after a reboot! :)
#6
26.1 Series / Re: Register DHCP Static Mappi...
Last post by nero355 - Today at 12:27:03 AMQuote from: teclab on February 14, 2026, 08:59:28 PMI 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.Then you need to read this : https://docs.opnsense.org/manual/kea.html
QuoteFrom the link you provided I read that Dnsmasq is required as a connector.That's not what it means...
QuoteBut 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.Because of this :
Quote from: Patrick M. Hausen on February 14, 2026, 09:17:01 PMKea has a hook to Unbound for static mappings only.;)
QuoteDoes KEA only have a hook towards Dnsmasq?NOFI, but PLEASE READ the documentation first carefully before you decide to just configure something and then hope it works !!
OPNsense does some things different than you would expect so you need to take those differences in account when configuring services ;)
#7
26.1 Series / KEH reservations
Last post by unixpgmr - February 14, 2026, 11:03:32 PMI was a couple of releases behind so I graded. Well, the upgrade didn't go so well. It removed the ICS dhcp server, didn't migrate ANYTHING and didn't start the KEA dhcp server. My whole network went down. I was more than a little miffed. I finally got in and setup KEA and started. Got my network back up. Today I started setting up my reservations. I rebooted the system. NONE of my reservations was preserved. WTH? I am sorry if I sound a bit angry, but I am. What is going on with KEA dhcp server? Can't it save reservation between reboots?
#8
26.1 Series / Re: Register DHCP Static Mappi...
Last post by LisaMT - February 14, 2026, 11:02:33 PMunbound works great with Kea DHCP. All devices are accessed by hostnames on the network. For those few that the names are duplicates, I add them to the override list; such as when a server has multiple names for clarity.
Dnsmasq is a last resort for me; I've used it for many years when forced to, but the other issues with it are simply not worth using it. True if we were still running with 56k modems it was great.
Dnsmasq is a last resort for me; I've used it for many years when forced to, but the other issues with it are simply not worth using it. True if we were still running with 56k modems it was great.
#9
26.1 Series / Re: Destination NAT (port forw...
Last post by LisaMT - February 14, 2026, 10:52:52 PMI'm still getting port forwarding messages in my log file that claim my 'Camera' network (which should be very isolated) has members trying to reach 8.8.8.8:53.
The 'Camera' interface is NOT listed in the port forwarding rule. Only the LAN and PHONE interfaces. So why do the logs show the rule is acting on the 'Camera' interface?
The 'Camera' interface is NOT listed in the port forwarding rule. Only the LAN and PHONE interfaces. So why do the logs show the rule is acting on the 'Camera' interface?
#10
General Discussion / The OPNsense Plugins System Si...
Last post by Majx - February 14, 2026, 10:12:36 PMI 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:
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'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.
