"Recent posts
#1
Hardware and Performance / Re: DEC3920 Quick Review
Last post by patient0 - Today at 05:29:17 PMYou started the thread on Easter Friday (bank holiday) and it's now Easter Monday (bank holiday), give Deciso some time to react.
#2
25.7, 25.10 Series / Re: IPv4 ONLY Firewall Setup w...
Last post by Dude7 - Today at 05:19:14 PMI want to provide an update to the problem from my initial post above. I will do so in my best effort as to not invoke the compulsion of people who are experts at thinking they are experts.
I hope that this helps someone in the future who may come across this post while searching for answers to the same problem if still unresolved.
The problem still is apparent with a fresh install as of version 26.1.2 of OPNsense. HOWEVER, upon further research and some great help from a Youtube content creator, who provided some excellent perspective on this that I could not acquire elsewhere, the issue persists with the integration of dnsmasq DHCP. More specifically how a user goes thru the initial IP range and DHCP setup process.
To see a thread that another user found of the same replicatable issues, check this link out--> https://github.com/opnsense/core/issues/9578
I can repeatedly and consistently create this error, as others are showing they can as well.
----HERE ARE THE KEY FACTORS and THE WORKAROUNDS TO AVOID THE BUG THAT I HAVE FOUND----
A) This is most prevalent with hardware where there are multiple LAN ports. This problem does not persists with single LAN/WAN port systems
B) What is show in the CLI and validated once you complete the steps DOES NOT actually get completed in setup and use by OPNsense UNTIL you go thru and complete (sometimes even redoing steps) in the GUI.
C) You MUST go thru the GUI to validate that EVERYTHING that you initially setup in the CLI is consistently provisioned as it should be in the OPNsense entire "ecosystem" as the first steps before proceeding further with any setup. You can do this before or after using the wizard if you choose. However, You cannot proceed under the assumption that everything that you entered via the CLI is integrated and/or functioning properly until you validate it in the GUI.
----Here is what did to work around the current issues with IP range and DHCP network assignment to ports that persist. Specifically the ones that were causing the issues I found----
1) Go thru the initial setup process, and if using the CLI, setup all of your LAN ports with the IP addresses, DHCP and ranges provisioned. WRITE DOWN OR LOG EXACTLY EVERY IP ADDRESS AND RANGE DETAIL FOR EVERY PORT. YOU MAY NEED THIS AGAIN ONCE INSIDE THE GUI.
2) Use that one network that you setup as the LAN management network moving forward, even after creating other LAN networks. Moving this port after initial creation causes issues where some system components like dnsmasq DHCP to not entirely release the initial port and use the new port chose instead. This is an issue that I could only replicate at random, but it was repeatable even though irregular with the same result.
3)Once you have completed your initial CLI setup, and are in the GUI, go to dnsmasq DHCP and verify that your ranges are showing for each port as they should. Likely they will not be. TO RESOLVE THIS....
4)Edit the initial LAN Management port in that list. All you will have to do is select the address information that you have provided the port, along with the range. There is no need to update with new information, or a different IP range. Once you select the original information that you have provided and then apply and exit that window, one of two things will happen.
A) All of your other ranges, along with the missing LAN ports will show up in that same list with the proper IP and DHCP range information that yo uprovided.
B) You may only see the LAN port and IP address/range information still listed
If option A happened then....
1) Go thru and validate that every LAN port, IP address for that port and DHCP range is what it should be. You again will likely not have to re-enter information, but simply select was is now showing up. By doing so this is actually validating in the system what should have been validated when you created it in the CLI.
2) Once finished with doing this for every LAN port IP address/range, make sure to apply in the primary dnsmasq DHCP window
If option B happened then....
1) Go thru and build out every LAN port, IP address/dhcp range that you wrote down and used in the CLI initially upon setup before entering the GUI.
2) After setting all of them up to reflect the values that you created in the CLI, make sure to click apply in the primary dnsmasq DHCP window where all ports and IP ranges are listed.
From what I have found up until present (April 2026)...This problem persists only if you are going thru the CLI for initial setup. If using the GUI, and wizard which is easier on a single LAN and single WAN port system it is not a replicatable error.
I hope this info helps someone in the future with working around a very frustrating problem that caused months of frustration for me before I found it.
I hope that this helps someone in the future who may come across this post while searching for answers to the same problem if still unresolved.
The problem still is apparent with a fresh install as of version 26.1.2 of OPNsense. HOWEVER, upon further research and some great help from a Youtube content creator, who provided some excellent perspective on this that I could not acquire elsewhere, the issue persists with the integration of dnsmasq DHCP. More specifically how a user goes thru the initial IP range and DHCP setup process.
To see a thread that another user found of the same replicatable issues, check this link out--> https://github.com/opnsense/core/issues/9578
I can repeatedly and consistently create this error, as others are showing they can as well.
----HERE ARE THE KEY FACTORS and THE WORKAROUNDS TO AVOID THE BUG THAT I HAVE FOUND----
A) This is most prevalent with hardware where there are multiple LAN ports. This problem does not persists with single LAN/WAN port systems
B) What is show in the CLI and validated once you complete the steps DOES NOT actually get completed in setup and use by OPNsense UNTIL you go thru and complete (sometimes even redoing steps) in the GUI.
C) You MUST go thru the GUI to validate that EVERYTHING that you initially setup in the CLI is consistently provisioned as it should be in the OPNsense entire "ecosystem" as the first steps before proceeding further with any setup. You can do this before or after using the wizard if you choose. However, You cannot proceed under the assumption that everything that you entered via the CLI is integrated and/or functioning properly until you validate it in the GUI.
----Here is what did to work around the current issues with IP range and DHCP network assignment to ports that persist. Specifically the ones that were causing the issues I found----
1) Go thru the initial setup process, and if using the CLI, setup all of your LAN ports with the IP addresses, DHCP and ranges provisioned. WRITE DOWN OR LOG EXACTLY EVERY IP ADDRESS AND RANGE DETAIL FOR EVERY PORT. YOU MAY NEED THIS AGAIN ONCE INSIDE THE GUI.
2) Use that one network that you setup as the LAN management network moving forward, even after creating other LAN networks. Moving this port after initial creation causes issues where some system components like dnsmasq DHCP to not entirely release the initial port and use the new port chose instead. This is an issue that I could only replicate at random, but it was repeatable even though irregular with the same result.
3)Once you have completed your initial CLI setup, and are in the GUI, go to dnsmasq DHCP and verify that your ranges are showing for each port as they should. Likely they will not be. TO RESOLVE THIS....
4)Edit the initial LAN Management port in that list. All you will have to do is select the address information that you have provided the port, along with the range. There is no need to update with new information, or a different IP range. Once you select the original information that you have provided and then apply and exit that window, one of two things will happen.
A) All of your other ranges, along with the missing LAN ports will show up in that same list with the proper IP and DHCP range information that yo uprovided.
B) You may only see the LAN port and IP address/range information still listed
If option A happened then....
1) Go thru and validate that every LAN port, IP address for that port and DHCP range is what it should be. You again will likely not have to re-enter information, but simply select was is now showing up. By doing so this is actually validating in the system what should have been validated when you created it in the CLI.
2) Once finished with doing this for every LAN port IP address/range, make sure to apply in the primary dnsmasq DHCP window
If option B happened then....
1) Go thru and build out every LAN port, IP address/dhcp range that you wrote down and used in the CLI initially upon setup before entering the GUI.
2) After setting all of them up to reflect the values that you created in the CLI, make sure to click apply in the primary dnsmasq DHCP window where all ports and IP ranges are listed.
From what I have found up until present (April 2026)...This problem persists only if you are going thru the CLI for initial setup. If using the GUI, and wizard which is easier on a single LAN and single WAN port system it is not a replicatable error.
I hope this info helps someone in the future with working around a very frustrating problem that caused months of frustration for me before I found it.
#3
26.1 Series / Re: Unbound DNS
Last post by bamf - Today at 05:15:04 PMQuote from: (MARLOO) on Today at 03:45:17 AMClear Cache Properly
In Services > Unbound DNS > General > Advanced, enable Flush DNS cache on restart. Apply changes, then Reload Unbound (full reload, not just cache refresh). Also restart the service via CLI: service unbound restart.
It should be sufficient to just clear the specific entry:
Code Select
unbound-control -c /var/unbound/unbound.conf flush_zone example.comBut I'd also recommend running a dedicated solution for this. I run AdGuard Home in an DietPi LXC Container and it uses my OPNSense Unbound as upstream DNS.
#4
26.1 Series / Re: [SOLVED] DHCP reservations...
Last post by chemlud - Today at 05:11:42 PM #5
26.1 Series / [SOLVED] Re: DHCP reservations...
Last post by Amicably6896 - Today at 05:07:34 PMYes, i have confirmed the static assigned IP is the one that didn't get internet.
I ripped off the band aid and setup Kea DHCPv4. Previously I was confused with the changes to the GUI but I found a migrate script that worked remarkeable well.
All issues are resolved after migrating to Kea DHCPv4. So I guess the issue was something to do with the deprecated ISC DHCPv4.
Thanks for pushing me to finally update.
I ripped off the band aid and setup Kea DHCPv4. Previously I was confused with the changes to the GUI but I found a migrate script that worked remarkeable well.
All issues are resolved after migrating to Kea DHCPv4. So I guess the issue was something to do with the deprecated ISC DHCPv4.
Thanks for pushing me to finally update.
#6
Hardware and Performance / Re: DEC3920 Quick Review
Last post by dirtyfreebooter - Today at 04:24:26 PMresponse from deciso
i know they can't test everything, but i have used this config in so many varieties of OPNsense and it worked fine. Supermicro X11SCL-iF, Protectli VP2440, Odroid H4 Ultra, Lenovo P3 tiny, Aliexpress N200 topton and no issues.
its not a complex config and i didn't use any tuneables except from the shipping config and the 2 zenarmor adds. since friday i have had now 4 cases of networking goes down on i226, no logs, no output from kernel. NOTHING. unplug/plug the WAN cable and instant connection again.
i plugged my VP2440 back in last night and its now its been 12+ hours of working fine.
prior, my OPNsense uptimes are basically the OPNsense business release dates, and my internet, fiber, has also only went out 1 time is over 5 years and that was due to construction company cutting lines in the neighborhood.
my take at this point is that, Decsio $3000 firewall doesn't work and i have to pay to maybe figure out the issue with their firmware is sus. at this point, i guess my only other option is to send it back and pay for return shipping.
frankly what seems amazing, turned quickly in a horrible experience
QuoteThere's a lot of misinformation about the Intel nics unfortunately, on our end these have proven to be highly stable for years, currently we use the Intel 226, but the 225 versions we had before have been solid as well (using the right firmware and powered properly, poor hardware design choices in our experience cause quite some issues as well).
When the machine reports "host down" the first question you need to ask yourself is if the port is properly linked, our documentation contains some pointers about where to look in these cases, you can find it here https://docs.opnsense.org/hardware/support.html#network-connectivity-issues
Please make sure to test using default settings, no specific tunables whatsoever to prevent these causing unforeseen issues. You can always share the output of the commands in our documentation for us to have a small look, if you need an engineer to assist, that's also possible, but comes at additional cost.
i know they can't test everything, but i have used this config in so many varieties of OPNsense and it worked fine. Supermicro X11SCL-iF, Protectli VP2440, Odroid H4 Ultra, Lenovo P3 tiny, Aliexpress N200 topton and no issues.
its not a complex config and i didn't use any tuneables except from the shipping config and the 2 zenarmor adds. since friday i have had now 4 cases of networking goes down on i226, no logs, no output from kernel. NOTHING. unplug/plug the WAN cable and instant connection again.
i plugged my VP2440 back in last night and its now its been 12+ hours of working fine.
prior, my OPNsense uptimes are basically the OPNsense business release dates, and my internet, fiber, has also only went out 1 time is over 5 years and that was due to construction company cutting lines in the neighborhood.
my take at this point is that, Decsio $3000 firewall doesn't work and i have to pay to maybe figure out the issue with their firmware is sus. at this point, i guess my only other option is to send it back and pay for return shipping.
frankly what seems amazing, turned quickly in a horrible experience
#7
26.1 Series / Re: Unbound DNS
Last post by Patrick M. Hausen - Today at 04:16:17 PMQuote from: nero355 on Today at 03:24:42 PMMaybe one day there will be some kind of OPNsense alternative
AdGuard Home is available as a community plug in and works very well. I prefer it over Pihole.
#8
General Discussion / Re: Port OPNsense to Linux?
Last post by Greg_E - Today at 03:45:11 PMTo throw gas on the fire, there is a small group working on a GUI for VyOS, he has a github set up for this and is working along as fast as time allows. It might be really interesting once it's done.
#9
Tutorials and FAQs / Re: HOWTO - Redirect all DNS R...
Last post by hushcoden - Today at 03:40:17 PMQuote from: nero355 on Today at 03:12:16 PMLAN Net = Your network's subnet so let's say 192.168.1.0/24Yes, but which one is more accurate (and if possible, also why)?
LAN Address = The Gateway IP Address so let's say 192.168.1.1
#10
26.1 Series / Re: Everytime I install Opnsen...
Last post by meyergru - Today at 03:37:49 PMQuote from: Billy2010 on Today at 02:08:54 PMSo this is my last stop before I order a ubiquiti that just works.
Like this? Or this? Want more?
