Greetings to all,
I'm posting this 9 days away from the end of month of January 2026 when everyone is expecting version 26.1 to be released.
Before I do, I want to make sure I mention that in no way do I intend this as a "nasty-gram" to those who very consistently, and patiently, provide great feedback on here for users from level "noob" to advanced. Any frustration or sarcasm from me is not vented at any of you, but has just been seared into my brain with this entire experience as a result of this problem that I cannot get past. So know that I appreciate your support, feedback, and even consideration of this persistent issue that quite a few continue to experience, and which has turned a few frustrated with no resolution to it away from OPNsense.
Also, this post is certainly in the TL;DR category. I get it. I'm trying to provide details here that will hopefully be considered by the engineers/dev team that may help in finding the source of the problem which can resolve it before the next big release.
With all of that said, here's the problem-
I have encountered a problem which based on reading various posts on this forum, on Reddit, and posted on personal blogs, etc. seems to have been a persistent issue since version 24 of OPNsense. To date it seems to still not be resolved.
The common thread for all individuals experiencing this problem is that we need, and have built an IPv4 exclusive firewall that blocks, and does not handle IPv6 traffic for whatever the reasons that we may have. For me it's a known security leak with some software and hardware that I am wanting to put behind the firewall that is known on IPv6, but that I can manage and block currently on IPv4. All that is unrelated to OPNsense, but which I am needing OPNsense's capabilities to provide security and block the known traffic issues within the network and also outbound to the WAN at the firewall level.
Here are just three of the many posts where you will find others stating similar, if not identical problems-
https://forum.opnsense.org/index.php?topic=47277.0
and
https://forum.opnsense.org/index.php?topic=47135.30
Also on Reddit here-
https://www.reddit.com/r/opnsense/comments/1dixd9y/opnsense_dhcp_server_not_assigning_ip_addresses/
What I have found is that everyone is having a problem once they get to building out their secondary or "optional" LAN networks providing DHCP clients addresses. This is not noticeable in the system if you use IPv6 in tandem with IPv4 for some reason. However, an exclusive IPv4 setup brings this gremlin out. You also do not notice this problem either if you are just using your initial LAN Management port. Everything works dandy there for inexplicable reasons.
Forget VLAN setups as well. The problem may persist there as well, but all people experiencing this problem have simply been trying to get their LAN ports working, including myself, before proceeding to setting up VLANs.
When you start to build out your router with other LAN (optional) ports, that is where the problem comes up for everyone.
What I can deduce from reading through these many threads is one common point. That is where people started having these issues is in version 24 it seems. They all run into this problem, especially once DNSMasq and DHCP migration from ISC became a thing.
A critical point to note- This was not a problem and people have stated that no issues like this were present with ISC.
The same problem, while inconsistent, comes up with Kea as well. From posts that I've been reading this problem has been persistent since version 24.x.x, and it continues thru 25.7.11 (or whatever is current).
I personally have tried using both DNS Masq / DHCP, then disabling and activating DHCP management via KEA. The problem persists with both.
While the is a known issue, it hasn't been solved, nor has there been a workaround to it that has been posted that I could find. If there is one that I have missed, please do advise.
For the sake of helping to provide some troubleshooting information here are some additional steps that I have taken to diagnose where the problem might be.
Everyone experiencing the same issues, including myself, are experiencing this on a virtual machine environment. For the most part, although not exclusively, it was with Proxmox; at whatever the latest version was at the time of their posting of the issue.
One other key clue that may help out in finding the issue is something I found with a Mac. I found that this issue would not show up in Windows and Linux when the DHCP handshake process happens, at the level of detail as I could see in real time on osX. It doesn't show up in the other OS's only because likely the GUI doesn't provide a real-time view of the DHCP IP lease process in real-time like the GUI does in Mac osX.
A few details / side notes that should be stated at this point-
Keep in mind that no IP address is provisioned, but also no router and/or gateway address is provided, nor DNS addresses to the client on any secondary LAN ports.
Also, this is with the firewall opened fully up, and allowing all traffic on all LAN's. One default rule on each subnet to allow all traffic thru via IPv4. No custom NAT redirection that would alter each of these individual LANs from behaving properly as well.
The same issue persists when attempting to acquire an address from another virtual machine or container residing on any of the secondary networks as well that live on the Proxmox datacenter. Same behavior.
Here is what I noticed while watching this on a Mac-
When engaging the NIC on the Mac connected to any of the optional / secondary LAN's, on ALL of them, for a brief second a router address is provided for a split second and then goes away (it goes blank as if none was ever provided). However, the router address that is provided for that split second is NOT the IP address designated for that specific LAN, but rather the IP address of the primary / management LAN port which is assigned a completely different IP address/range, even though in the same subnet (/24).
Just to re-emphasize, there are no NAT rules that would cause an address forward like this. Also, this problem persists whether running with DNSMasq / DHCP or KEA.
I know that's a lot of info, but I am at a loss, and hoping that the solution for this problem will be caught and resolved by version 26. I am at a standstill while waiting for it.
I hope that taking the time to present this information will help the team provide a solution that many have been looking for, but to-date has not been presented sending many to find a firewall solution elsewhere.
Any additional information that I can provide, please let me know and I will do my best to fill in any blanks for you.
Thank you in advance for any insight in response.
Thank you for taking the time to document your experience in detail. It is clear you have invested significant effort into troubleshooting, and the level of detail is appreciated.
That said, in its current form this report does not describe a demonstrable software defect in OPNsense, Kea, or dnsmasq, but rather a set of symptoms that are most commonly associated with layer-2 topology or virtualization configuration issues—particularly in Proxmox environments.
A few observations that are important to clarify:
OPNsense does not require IPv6 to be enabled for IPv4 DHCP to function correctly. IPv4-only deployments with multiple LAN interfaces are widely deployed and fully supported.
If a DHCP client briefly receives a gateway address belonging to a different interface, that almost always indicates that the interfaces are not properly isolated at layer-2 (for example, multiple interfaces attached to the same Proxmox bridge, shared subnets across interfaces, or unintended bridging).
DHCP servers do not "forward" router addresses between interfaces. If a client sees an address from another interface, it is responding to a broadcast originating from the same L2 domain.
To move this forward constructively, the following information would be required before this can be treated as a potential bug:
- Interface assignments and IP/subnet configuration for all OPNsense interfaces
- Proxmox bridge configuration (vmbr layout, VLAN awareness, and NIC attachment or in the case off passthru, physical hardware type)
- Confirmation that each LAN interface is in a unique IPv4 subnet
- DHCP logs from Kea or dnsmasq during a failed lease attempt
- A packet capture (tcpdump) on the affected interface showing the DHCP exchange
Without this information, it is not possible to distinguish between a software defect and a topology issue. To date, there is no known regression in OPNsense 24.x–25.x that prevents IPv4 DHCP from functioning on secondary interfaces in correctly isolated networks.
If you are willing to provide the above details, the community will be better positioned to help identify the root cause.
That being said, you have chosen to use one of the most advanced setups with OpnSense there is (i.e. OpnSense under Proxmox). I assume you have read all the helpful hints to this (like this (https://forum.opnsense.org/index.php?topic=50182.0)) or have tried to get a setup running on bare metal first?