"Recent posts
#21
25.7, 25.10 Series / IPv4 ONLY Firewall Setup where...
Last post by Dude7 - January 23, 2026, 07:52:47 PMGreetings 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.
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.
#22
25.7, 25.10 Series / Re: Dnsmasq stops occasionaly
Last post by ligand - January 23, 2026, 07:43:04 PMHI! Simon from dnsmasq is asking me to adjust the dnsmasq config as follows:
add
log-queries=extra
log-dhcp
log-facility=/path/to/file
and remove the quiet-* options that are there now.
How do I do this? The template seems to have a lot of logic in it and I don't want to break anything.
add
log-queries=extra
log-dhcp
log-facility=/path/to/file
and remove the quiet-* options that are there now.
How do I do this? The template seems to have a lot of logic in it and I don't want to break anything.
#23
25.1, 25.4 Series / Reply-to not being added to se...
Last post by unfinishedimpact - January 23, 2026, 06:37:06 PMI'm running V25.1.10 and have hit a snag with a multi-WAN setup which I suspect may be a bug (and possibly still present in later versions).
My setup consists of both a FTTP broadband connection (PPPoE) on the "WAN" interface (by identifier) and a Cable internet connection on opt4 (DHCP). Until recently, the Cable gateway was my primary connection (i.e. the default-route), and the PPPoE gateway was my secondary (failover), and everything was fine.
However today, I wanted to flip things around, so I promoted my PPPoE interface's gateway to a higher priority, so it became the default-route. It was then I noticed that inbound connections to my Cable internet's IP address began failing. The reason - the replies were routing asymmetrically and were going back out my PPPoE connection (clearly following the default route!).
I have double checked and I definitely do NOT have the "Disable reply-to on WAN rules" option ticked in Firewall->Settings->Advanced, which means OPNsense should be adding a reply-to flag to my inbound WAN rules for my cable internet connection.
When I dump out my ruleset (i.e. cat /tmp/rules.debug), no reply-to flag is being set on my inbound cable WAN rules. Although reply-to IS being correctly added to my PPPoE connection's inbound WAN rules.
So it almost seems like OPNsense only considers my PPPoE connection a WAN connection (even though I have an active, albeit lower-priority gateway on that interface).
I know I could go through and manually edit all my Cable internet WAN rules to force the reply-to, to the gateway of the cable internet, but this seems a kludge and also I have a few NAT port-forwards setup which don't seem to allow that option when using an associated, auto-generated WAN firewall rule (which cannot be edited). So I'd need to split these port-forwards out into NAT+separate access rules, which is even more kludgy!
This issue was masked when my default-route was set to the cable internet's gateway, because the return packets for inbound connections on my cable IP then just followed the default route back out the right (cable) interface. Seeing as my PPPoE connection IS getting the reply-to added to its rules, inbound connections to it always work OK, regardless of the default-route, which is why I never noticed the issue before switching gateways.
Does anybody have any thoughts on why OPNsense is refusing to add the reply-to flag on my cable interface's inbound WAN rules (but it's working just fine for the PPPoE interface!?!). Any help most appreciated!
My setup consists of both a FTTP broadband connection (PPPoE) on the "WAN" interface (by identifier) and a Cable internet connection on opt4 (DHCP). Until recently, the Cable gateway was my primary connection (i.e. the default-route), and the PPPoE gateway was my secondary (failover), and everything was fine.
However today, I wanted to flip things around, so I promoted my PPPoE interface's gateway to a higher priority, so it became the default-route. It was then I noticed that inbound connections to my Cable internet's IP address began failing. The reason - the replies were routing asymmetrically and were going back out my PPPoE connection (clearly following the default route!).
I have double checked and I definitely do NOT have the "Disable reply-to on WAN rules" option ticked in Firewall->Settings->Advanced, which means OPNsense should be adding a reply-to flag to my inbound WAN rules for my cable internet connection.
When I dump out my ruleset (i.e. cat /tmp/rules.debug), no reply-to flag is being set on my inbound cable WAN rules. Although reply-to IS being correctly added to my PPPoE connection's inbound WAN rules.
So it almost seems like OPNsense only considers my PPPoE connection a WAN connection (even though I have an active, albeit lower-priority gateway on that interface).
I know I could go through and manually edit all my Cable internet WAN rules to force the reply-to, to the gateway of the cable internet, but this seems a kludge and also I have a few NAT port-forwards setup which don't seem to allow that option when using an associated, auto-generated WAN firewall rule (which cannot be edited). So I'd need to split these port-forwards out into NAT+separate access rules, which is even more kludgy!
This issue was masked when my default-route was set to the cable internet's gateway, because the return packets for inbound connections on my cable IP then just followed the default route back out the right (cable) interface. Seeing as my PPPoE connection IS getting the reply-to added to its rules, inbound connections to it always work OK, regardless of the default-route, which is why I never noticed the issue before switching gateways.
Does anybody have any thoughts on why OPNsense is refusing to add the reply-to flag on my cable interface's inbound WAN rules (but it's working just fine for the PPPoE interface!?!). Any help most appreciated!
#24
25.7, 25.10 Series / Re: After updating Opnsense fr...
Last post by franco - January 23, 2026, 06:10:31 PMTwo people ending up identifying Suricata as the culprit on 25.7.11 when it was updated to 8.0.3? Hmm... try reverting, restarting the service and see if that's better.
# opnsense-revert -r 25.7.10 suricata
Cheers,
Franco
# opnsense-revert -r 25.7.10 suricata
Cheers,
Franco
#25
General Discussion / Re: Where is TCP processed - C...
Last post by chemlud - January 23, 2026, 05:58:19 PMTumbleweed is quite stable. Most of the time, you have to know, when you better NOT update, but that's not that hard.
The devices with Coreboot are "in production", so not easy to swap the OS. And as the problem is with TW updates, not with the browser (see above): how to test then?
So largely: Self-inflicted pain, one might say. It bugs me not to know, what is going on here. OPNsense has no traffic shaper enabled, what should IPS/IDS do to the bandwith of one client, but not to another on the same switch?
The devices with Coreboot are "in production", so not easy to swap the OS. And as the problem is with TW updates, not with the browser (see above): how to test then?
So largely: Self-inflicted pain, one might say. It bugs me not to know, what is going on here. OPNsense has no traffic shaper enabled, what should IPS/IDS do to the bandwith of one client, but not to another on the same switch?
#26
25.7, 25.10 Series / Re: OPNsense 25.7.10 . Noti...
Last post by pfry - January 23, 2026, 05:23:16 PMQuote from: nero355 on January 23, 2026, 04:46:33 PM[...]IMHO mainly the Samsung "Pro" Series NVMe SSD's have that issue and the rest not as much.[...]
Overall, it's just a matter of:
- power targets
- thermal mass
- radiative area
- convection/airflow
I get "enterprise" or "data center" devices (a stretch for M.2, but hey), which tend to nail themselves at maximum power (~8W for M.2) for maximum performance. Keeping such devices in the M.2 form factor cool is a challenge, especially where radiative area is constrained. Consumer-type devices keep cool(er) mainly through low power targets (which hurt performance) and PSLC caching (which greatly improves performance, but has a limited endurance). Same old tradeoffs.
#27
26.1 Series / Re: Destination NAT and Firewa...
Last post by keeka - January 23, 2026, 05:17:58 PMOne rule performs the NAT and the second permits the resulting traffic. With the previous system, it was a NAT port forward rule and a (potentially auto-managed) firewall rule.
I have not tried 26.1RC yet. But I have a feeling, with the way I've set up NAT and FW under 25.7, a straight forward migration will not be possible. For example, the change in the priority of floating rules on single interfaces and the lack of auto/associated firewall rules for port forwards.
I have not tried 26.1RC yet. But I have a feeling, with the way I've set up NAT and FW under 25.7, a straight forward migration will not be possible. For example, the change in the priority of floating rules on single interfaces and the lack of auto/associated firewall rules for port forwards.
#28
General Discussion / Re: Where is TCP processed - C...
Last post by nero355 - January 23, 2026, 05:10:58 PMQuote from: chemlud on January 23, 2026, 01:36:40 PMTumbleweedIs that the only thing that shows this issue ?!
AFAIK Tumbleweed is a rolling distro based on "Not yet Stable code" like Debian Testing for example.
Could that be the issue ?
What happens when you boot a random Live environment of any other distro ?
QuoteWhat can downgrade HTTPS for a specific client? Fingerprinting, ID of install, whatever?I would say :
- Traffic Shaping Rules.
- IDS/IPS software anywhere in your network.
#29
General Discussion / Re: Forum connection issues
Last post by OPNenthu - January 23, 2026, 05:00:37 PMThe issues seem to have tapered off for me, too. Haven't noticed the issue with fontawesome.com yet.
#30
General Discussion / Re: ISC-DHCP to KEA Migration ...
Last post by nero355 - January 23, 2026, 04:59:40 PMThis is nice to have, but it's not really needed since you can Import/Export all Static DHCP Mappings by using the .csv files Import/Export option in the OPNsense webGUI ;)
