New features

[sopex8260]

What are some neat features you would like to see on opnsense?

[nero355]

The recent talk about a "Favorites" feature is pretty much all I need so far :)

I would then create sub-folders for each Network/VLAN and add the corresponding settings into each of them.

[OPNenthu]

Some improvements toward IPv6 quality of life:

1) Ability to add static IPv6 address on interfaces in addition to DHCPv6-PD.

Why: As we move closer to IPv6-only or IPv6-mostly networks we need to maintain stable internal IPv6 connectivity even when the prefix on WAN is lost.  To do that, we can assign ULAs in addition to the GUA prefix and we can distribute both with RAs (preferred over DHCPv6 for modern clients).

Currently, OPNsense drops the ULA VIP when WAN is lost: https://github.com/opnsense/core/issues/10048#issuecomment-4141350758


2) Expand Dnsmasq to auto-register discovered SLAAC addresses in DNS.

Why: Modern clients use privacy extensions which makes them untrackable in OPNsense and also unaddressable on the network except in case of IPv4 or static assignment with DNS host entry.

The hostwatch db can be used to find new privacy addresses on a short interval (configurable).


3) Add an option to suppress prefix deprecation RAs (with PreferredLifetime=0) being sent unless the prefix is not seen again on WAN after some configurable amount of time (e.g. 5 minutes).

Why: ISPs love to reboot customer modems for firmware updates and weekly maintenance, or users may need to temporarily take equipment offline.  Clients receive the RA to deprecate the prefix, and then they dutifully follow the RFC guidance which says they should not use that prefix anymore.  The result is that SLAAC breaks and temporary addresses are no longer generated until and unless a new prefix is seen.

This one is a bit nasty and would require OPNsense to track the state and keep a timer for re-transmitting the suppressed RAs, but I see no alternative for fixing this realistically.

[franco]

1) https://github.com/opnsense/core/issues/10048#issuecomment-4141350758 is fixed on master I think

2) Not sure if it has the hostname.  An investigation on how Dnsmasq is configured to do this would be useful.

3) Radvd is pretty strict about its behaviour. It has a few overrides (especially for shutdown nowadays) but we do not have fine-grained outside control over what it is doing.


Cheers,
Franco

[xpendable]

The ability to use the RACK TCP Stack would be nice and might be beneficial to some.

https://github.com/opnsense/core/issues/9452
https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/

[Patrick M. Hausen]

Only a Firewall doesn't do much TCP. The end nodes behind it do.

[meyergru]

Ca depend... with a reverse proxy, it would probably help.

[OPNenthu]

I think a button to toggle the user defined tags-based categorization while in tree view would be useful:
 
You cannot view this attachment.

I've been using the Tree mode together with Inspect mode so that I get a view of all the rules for an interface that are by default pre-grouped by system generated vs. not ("Uncategorized").  This works well for me in certain situations.

The problem is when I started adding my own tags/categories to rules then I lose this view.  Being able to ignore the custom tags temporarily would be the best of both worlds, IMO.

1) https://github.com/opnsense/core/issues/10048#issuecomment-4141350758 is fixed on master I think

Fantastic, thanks @franco!

2) Not sure if it has the hostname.  An investigation on how Dnsmasq is configured to do this would be useful.

IIRC, Dnsmasq has the hostname for IPv6 clients that use SLAAC as long as they have an IPv4 lease to draw from, so it works for dual-stack environments.  But it doesn't work with privacy extensions, I think because it needs to guess the stable SLAAC address in order to ping it and test for a response.

3) Radvd is pretty strict about its behaviour. It has a few overrides (especially for shutdown nowadays) but we do not have fine-grained outside control over what it is doing.

To clarify a couple points:
- The issue impacts both radvd and Dnsmasq
- Both of them (as I tested in older thread) are not impacted by router reboots.  radvd has the option to ignore that, and dnsmasq is anyway ignoring it.
- The issue is only when the WAN prefix is lost, even momentarily.  Then, the RA daemons are required to send a prefix deprecation message.  Also, the clients are required to mark that prefix as permanently unavailable. 

So it's a combination of actors all doing what the RFCs say.  The trouble is that nobody accounted for the case of dynamic prefixes which do not change each time the modem reboots.

To recap:
If you have a statically assigned prefix, there's no problem.
If you have a dynamic prefix that changes often / with modem reboot, then SLAAC heals itself.  (e.g. Verizon FiOS home internet)
If you have a dynamic prefix that is long lived, then SLAAC breaks for you. (e.g. Comcast Xfinity home internet)

If the issue is with the RFCs and requires coordination of so many parties to fix it properly, then I don't see it happening really.  I thought maybe a "hack" in OPNsense could be warranted, if even feasible.

[franco]

The ability to use the RACK TCP Stack would be nice and might be beneficial to some.

https://github.com/opnsense/core/issues/9452
https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/

You phrase it in such a way that it appears to not be usable but you can already use it manually without much effort.

It was also reworked in FreeBSD 15 and that's the reason we're halting further efforts to present it in the GUI until we're on 26.7 and things have stabilised.


Cheers,
Franco

[newsense]

FWIW I have 4 FWs on RACK since December and all are running fine on FreeBSD14.3/OPNsense25.7/26.1

[xpendable]

You phrase it in such a way that it appears to not be usable but you can already use it manually without much effort.

It was also reworked in FreeBSD 15 and that's the reason we're halting further efforts to present it in the GUI until we're on 26.7 and things have stabilised.


Cheers,
Franco

Sorry I was under the impression you still needed to rebuild the kernel, I guess that's not the case since FreeBSD 14. So I went ahead and enabled it with the sysctl tunables and I'll see how it goes.