"Recent posts
#21
25.7, 25.10 Series / Re: WAN has no IPv6 connectivi...
Last post by meyergru - January 23, 2026, 10:24:28 PMTry this.
#22
25.7, 25.10 Series / [SOLVED] WAN has no IPv6 conne...
Last post by andicniko - January 23, 2026, 10:08:42 PMMy WAN doesn't seem able to reach IPv6 addresses (e.g. if I "ping -6 2606:4700:4700::1111" from opnsense itself).
My configuration type is DHCP and DHCPv6, and my ISP provides me with a static /56 prefix. Clients on LAN get IPv6 addresses and communicate just fine, they can reach IPv6 addresses and "ping -6 2606:4700:4700::1111" getting a response just fine.
My interfaces overview suggests WAN has the following IPv6 addresses only:
::2e0:97ff:fe1d:8a79/64
fe80::2e0:97ff:fe1d:8a79/64
Question: How can I give my WAN interface a usable IPv6 address, or get the one's it already has to communicate with external IPv6 addresses?
Sorry I know this has been asked in the past, but I can't seem to find a clear answer. Any help is appreciated!
- I wonder if this is the root cause of update checks going painfully slowly unless I enable System: Settings: General: Prefer to use IPv4 even if IPv6 is available.
- I also wonder if this is the root cause of IPv6 connectivity tests (e.g. https://test-ipv6.com/) suggesting "Your DNS server (possibly run by your ISP) appears to have no access to the IPv6 Internet". I can get around this by adding DNS over TLS entries in Unbound pointing to an external DNS, but it didn't help the above issues.
My configuration type is DHCP and DHCPv6, and my ISP provides me with a static /56 prefix. Clients on LAN get IPv6 addresses and communicate just fine, they can reach IPv6 addresses and "ping -6 2606:4700:4700::1111" getting a response just fine.
My interfaces overview suggests WAN has the following IPv6 addresses only:
::2e0:97ff:fe1d:8a79/64
fe80::2e0:97ff:fe1d:8a79/64
Question: How can I give my WAN interface a usable IPv6 address, or get the one's it already has to communicate with external IPv6 addresses?
Sorry I know this has been asked in the past, but I can't seem to find a clear answer. Any help is appreciated!
#23
25.7, 25.10 Series / Re: OPNsense 25.7.10 . Noti...
Last post by iMx - January 23, 2026, 09:31:29 PMDid you check the suggested operating temperature for the drive in the specs?
#24
General Discussion / Re: Port Forwarding issue insi...
Last post by Land_Strider - January 23, 2026, 09:29:04 PMI figured out what the problem was. It was the "Disable reply-to on WAN rules" firewall settings default behavior. Ticking its box and leaving others at default values now makes the Port Forwarding work like a charm.
You cannot view this attachment.
You cannot view this attachment.
#25
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by iMx - January 23, 2026, 09:24:45 PMI think there's definitely an argument for it to be disabled by default.
... I'm not sure I need to put unnecessary wear on an SSD for this.
I'd have thought that most Business Edition customers will disable it and they bring in the money!
... I'm not sure I need to put unnecessary wear on an SSD for this.
I'd have thought that most Business Edition customers will disable it and they bring in the money!
#26
General Discussion / Re: ISC-DHCP to KEA Migration ...
Last post by Sheridan Computers - January 23, 2026, 08:45:39 PMQuote from: nero355 on 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 ;)
Not for IPv6, IPv4 only
#27
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by Cljackhammer - January 23, 2026, 08:34:15 PMI think that it might be beneficial to remove this capability. The issue with the disk writes is a major problem and introduces instability. I had it enabled and the disk writes are higher than my production elastic search instance by a factor 700%
#28
25.7, 25.10 Series / Re: OPNsense 25.7.10 . Noti...
Last post by dmacgowan - January 23, 2026, 08:33:54 PMos-smart was enabled on my machine.
Information section says that
Warning Comp. Temp. Threshold: 100 Celsius
Critical Comp. Temp. Threshold: 110 Celsius
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
- temperature is above or below threshold
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x02
Temperature: -1 Celsius
It would appear that the program doesn't know what to do with a negative temperature reading. It certainly isn't overheating in my -28 degree C garage in the middle of winter.
Information section says that
Warning Comp. Temp. Threshold: 100 Celsius
Critical Comp. Temp. Threshold: 110 Celsius
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
- temperature is above or below threshold
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x02
Temperature: -1 Celsius
It would appear that the program doesn't know what to do with a negative temperature reading. It certainly isn't overheating in my -28 degree C garage in the middle of winter.
#29
25.7, 25.10 Series / Re: Dnsmasq stops occasionaly
Last post by Monviech (Cedrik) - January 23, 2026, 07:57:42 PMHello,
the quiet options are a small bug in the template, please execute the following in the shell:
opnsense-patch https://github.com/opnsense/core/commit/664c80e7cab26725872c5b6f3ce2a2b6c0f566e5
Afterwards in the Dnsmasq general settings in the GUI select the following (enable advanced mode toggle):
- Log the results of DNS queries
- Log DHCP options and tags
I dont think you need a log facility, dnsmasqs log output is redirected to syslog-ng. You can find all logs in
- /var/log/dnsmasq/...
You can find events like interface up/down events with this command:
- dmesg
Other interesting logs are redirected here:
- /var/log/system/...
- /var/log/configd/...
I would suggest you only run dnsmasq features and not use radvd since that will tighten the scope.
If you need something else let me know.
the quiet options are a small bug in the template, please execute the following in the shell:
opnsense-patch https://github.com/opnsense/core/commit/664c80e7cab26725872c5b6f3ce2a2b6c0f566e5
Afterwards in the Dnsmasq general settings in the GUI select the following (enable advanced mode toggle):
- Log the results of DNS queries
- Log DHCP options and tags
I dont think you need a log facility, dnsmasqs log output is redirected to syslog-ng. You can find all logs in
- /var/log/dnsmasq/...
You can find events like interface up/down events with this command:
- dmesg
Other interesting logs are redirected here:
- /var/log/system/...
- /var/log/configd/...
I would suggest you only run dnsmasq features and not use radvd since that will tighten the scope.
If you need something else let me know.
#30
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.
