"Recent posts
#81
General Discussion / Re: Strange WiFi issue
Last post by suur13 - January 19, 2026, 09:36:07 PMThanks, looks like it helped. My WLAN connection is part of Bridge (together w/ OPT1, OPT2 and OPT3) and therefore also LAN. Firewall rules were applied only for LAN. Now I made similar Default rules also for WLAN. OPTx connections still are without rules and relay on LAN rules. Everything in other rooms work (via switch, via separate AP, via LAN, via OPT1). Strange that WLAN requires special approach, to me it was just like another port involved in bridge.
#82
General Discussion / Re: Unsense - new GUI theme
Last post by hierros - January 19, 2026, 09:33:53 PMyour ssl certificate is expired...
#83
Zenarmor (Sensei) / Re: Latest Zenarmor update bre...
Last post by Irishfluter - January 19, 2026, 09:30:48 PMQuote from: sy on January 19, 2026, 04:28:48 PMHi,
Please create a ticket by using "Have Feedback" option in the bottom left corner of UI. Then please share the sessions as .csv file in Live Sessions.
https://www.zenarmor.com/docs/reporting-analytics/live-session-explorer#exporting-csv
I have sent a feedback ticket as requested.
UPDATE: I have received the email and submitted the csv report to the Help Desk. Thanks.
#84
General Discussion / Re: Strange WiFi issue
Last post by viragomann - January 19, 2026, 09:05:20 PMDid you add proper firewall rules to the interfaces to permit UPnP?
In addition to the access to the other LAN devices, it's also required pass the UPnP multicasts to the other interface.
In addition to the access to the other LAN devices, it's also required pass the UPnP multicasts to the other interface.
#85
25.7, 25.10 Series / Hostwatch features / improveme...
Last post by psharkauburn - January 19, 2026, 08:37:58 PMNot sure if this is the right place in the forum to put this, so move if needed (and/or i'll take constructive criticism for future posts). Coming from a consumer based router (asus merlin) I definitely appreciate the new addition, I know it has/had some bugs and i'm sure it'll improve. Just saw it today when I noticed an update, wanted to make a couple quick notes for improvements along with some questions:
Discovery -> Static flow: Nothing crazy here, just expecting a command available on the DiscoveredHosts row detail for 'Create Static Entry' that would pre-fill the static entry form with the values from the DiscoveredHosts row detail. Pretty similar to a normal DHCP flow in DNSMASQ from looking at dynamic lease table and turning a dynamic entry -> create static entry via [add reservation] command.
Remove IP Requirement from Static Mapping -> I know I have plenty of IOT type devices like light bulbs that I don't do static DHCP for, and their OUI org names can be fun to sleuth out (sarcasm). I DO very much want to be able to label them meaningfully (garage exterior light, front porch light, etc...) based just on MAC while keeping them dynamic on IP (maybe playing with setting up VLAN for them, etc...). Occasional use old tablets/phones are in the same boat for me. Plenty of old devices I very occasionally turn on for some reason (or the kids) and love knowing what the device actually is but definitely don't want to waste an IP assignment for it.
Staleness trimming -> My assumption is that the DiscoveredHosts table is meant to serve as a 'devices currently on the network' in some sort of loose interpretation (like recently on the network). I'd expect devices to fall off this list from some concept of last seen versus a staleness threshold (1 min, 10 min, 1 hour, etc...). Just looking for this threshold to be stated / configurable at least on a global level, I can see usefulness in a per host setting also from the static table.
Additional fields/GUI stuff -> On the DiscoveredHosts table a [Last Seen] is VERY useful, especially if we don't know the staleness trimming default. I've had systems that may not trim the discovery table but will change font color/weight/etc... to indicate a stale entry that hasn't been seen in awhile (I think FING does this for example). Bringing static [description] over to DiscoveredHosts seems really natural; if I've gone to the trouble to do the static mapping I want the friendly name showing on the DiscoveredHosts table to show what's currently on the network. Taking this out a step further, may want to consider a distinct field for [FriendlyName] (or [HostName]) on the static table so description can be used for its intended purpose (longer description of something) but a shorter helpful name can be used throughout reporting / firewall stuff / etc... May want to bring the [Last Seen] field to the static table, give an easy way to potentially help folks trim out old entries from their system that may not be used anymore.
Question side - curious about interplay with DNSMASQ DHCP static mappings for example. I was about to go thru the process in DNSMASQ [Hosts] to do most of this mapping between hardware MAC -> friendly device hostname/description. It looks like the [Hosts] table has concepts like tagging so I can add useful logical groups like 'Light Bulbs/Switches/TVs' etc... and doesn't require a fixed IP address assignment. Just wanting to kinda get validation I'm interpreting this right, I haven't moved forward and done the work yet to implement. The next logical question then becomes, what is the best place to do this sort of mapping; DHCP [Hosts] or Neighbor [Static] ? It seems like DHCP [Hosts] does all of what I want and doesn't require any changes, but surfacing that data thru to Neighbor [DiscoveredHosts] would be EXTREMELY beneficial. Just looking for guidance before going down some path trying to map out 100-200 devices in one area and then being told HostWatch is the new/future best practice, and need to redo it.
- Should be a flow from discovery -> static assignment
- Remove IP address requirement from static assignment
- Should be some control over discovery staleness trimming/garbage collection
- Should be some additional fields shown/tracked on discovery + static assignment
Discovery -> Static flow: Nothing crazy here, just expecting a command available on the DiscoveredHosts row detail for 'Create Static Entry' that would pre-fill the static entry form with the values from the DiscoveredHosts row detail. Pretty similar to a normal DHCP flow in DNSMASQ from looking at dynamic lease table and turning a dynamic entry -> create static entry via [add reservation] command.
Remove IP Requirement from Static Mapping -> I know I have plenty of IOT type devices like light bulbs that I don't do static DHCP for, and their OUI org names can be fun to sleuth out (sarcasm). I DO very much want to be able to label them meaningfully (garage exterior light, front porch light, etc...) based just on MAC while keeping them dynamic on IP (maybe playing with setting up VLAN for them, etc...). Occasional use old tablets/phones are in the same boat for me. Plenty of old devices I very occasionally turn on for some reason (or the kids) and love knowing what the device actually is but definitely don't want to waste an IP assignment for it.
Staleness trimming -> My assumption is that the DiscoveredHosts table is meant to serve as a 'devices currently on the network' in some sort of loose interpretation (like recently on the network). I'd expect devices to fall off this list from some concept of last seen versus a staleness threshold (1 min, 10 min, 1 hour, etc...). Just looking for this threshold to be stated / configurable at least on a global level, I can see usefulness in a per host setting also from the static table.
Additional fields/GUI stuff -> On the DiscoveredHosts table a [Last Seen] is VERY useful, especially if we don't know the staleness trimming default. I've had systems that may not trim the discovery table but will change font color/weight/etc... to indicate a stale entry that hasn't been seen in awhile (I think FING does this for example). Bringing static [description] over to DiscoveredHosts seems really natural; if I've gone to the trouble to do the static mapping I want the friendly name showing on the DiscoveredHosts table to show what's currently on the network. Taking this out a step further, may want to consider a distinct field for [FriendlyName] (or [HostName]) on the static table so description can be used for its intended purpose (longer description of something) but a shorter helpful name can be used throughout reporting / firewall stuff / etc... May want to bring the [Last Seen] field to the static table, give an easy way to potentially help folks trim out old entries from their system that may not be used anymore.
Question side - curious about interplay with DNSMASQ DHCP static mappings for example. I was about to go thru the process in DNSMASQ [Hosts] to do most of this mapping between hardware MAC -> friendly device hostname/description. It looks like the [Hosts] table has concepts like tagging so I can add useful logical groups like 'Light Bulbs/Switches/TVs' etc... and doesn't require a fixed IP address assignment. Just wanting to kinda get validation I'm interpreting this right, I haven't moved forward and done the work yet to implement. The next logical question then becomes, what is the best place to do this sort of mapping; DHCP [Hosts] or Neighbor [Static] ? It seems like DHCP [Hosts] does all of what I want and doesn't require any changes, but surfacing that data thru to Neighbor [DiscoveredHosts] would be EXTREMELY beneficial. Just looking for guidance before going down some path trying to map out 100-200 devices in one area and then being told HostWatch is the new/future best practice, and need to redo it.
#86
25.7, 25.10 Series / Re: After updating Opnsense fr...
Last post by wide - January 19, 2026, 08:27:54 PMI managed to update to version 25.7.11_2 by using opnsense-shell and then run restart all the services from shell also.
System remains stable. No exessive disk writes, normal memory consuption and regular CPU load.
But still immediately after I open the WebGUI the systems goes haywire. Tens and then hundreds of PHP processes spawn and system runs out of memory.
System remains stable. No exessive disk writes, normal memory consuption and regular CPU load.
But still immediately after I open the WebGUI the systems goes haywire. Tens and then hundreds of PHP processes spawn and system runs out of memory.
#87
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by meyergru - January 19, 2026, 08:24:55 PMAnd the difference to DHCPv6-derived IPs is that SLAAC-provided IPs are pushed, i.e. they are applied immediately when the GUA prefix changes.
The only thing you do not have is "known" static IPv6s that you can reference in DNS names (because the prefix can change). Usually, you do not need them anyways, because you can always use the IPv4 for internal purposes in DNS. All of that is covered in the HOWTO I linked above.
The only thing you do not have is "known" static IPv6s that you can reference in DNS names (because the prefix can change). Usually, you do not need them anyways, because you can always use the IPv4 for internal purposes in DNS. All of that is covered in the HOWTO I linked above.
#88
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by Patrick M. Hausen - January 19, 2026, 08:08:20 PMThe IPs will be automatic but predictable and stable. Unless the clients use privacy extensions but they are free to do that with DHCP, too.
A server configured with SLAAC will always get the same GUA unless its MAC address changes.
A server configured with SLAAC will always get the same GUA unless its MAC address changes.
#89
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by stanthewizzard - January 19, 2026, 08:04:46 PMQuote from: Patrick M. Hausen on January 19, 2026, 07:50:19 PMQuote from: stanthewizzard on January 19, 2026, 07:44:48 PMISC DHCPv6 gives wan routable ipv6 from my ISP [...] to other devices
SLAAC can do that without any DHCP present at all.
Yes but at my knowledge without fixed IPs ?
#90
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by Patrick M. Hausen - January 19, 2026, 07:50:19 PMQuote from: stanthewizzard on January 19, 2026, 07:44:48 PMISC DHCPv6 gives wan routable ipv6 from my ISP [...] to other devices
SLAAC can do that without any DHCP present at all.
