If you could have 1 feature added - what would it be?

keyser

Like the title said: A little “just dreaming” thread on new features.

Personally I’m very happy with where 24.03 has brought us on pfsense, and my previously wanted “killer feature” (IP pools for IPSec Mobile warriors) is now working right out of the box
I litterally had customers jumping with joy when it was released, and has already sold and implemented no less than 3 boxes for enterprise mobile VPN. IPsec mobile VPN using the native OS IPSec client (Windows, Linux, Apple, iPhone and Android) just works now with azure mfa and separated firewall rules for different AD usergroups. All at the FRACTION of the cost of a Cisco or similar box!

So my new “dream feature” is automatic DHCP client DNS registration using the python plugin so it can scale and doesn’t restart unbound on every registration. I know @cmcdonald is supposedly looking into this, so here’s crossing my fingers

What is your “killer feature”?

mcury

@keyser I would vote for a dping replacement, something that could ping two IPs at the same for example.
So, if one of the monitors IP eventually stops responding but not the other, it wouldn't affect the gateway group.

tinfoilmatt

QAT support for CE.

stephenw10

@keyser said in If you could have 1 feature added - what would it be?:

I know @cmcdonald is supposedly looking into this, so here’s crossing my fingers

He sure is.

I think Multi-Instance Management is at the top of many peoples lists.

Multiple ping targets in dpinger is interesting. Have to get @dennypage to chnage his name if you want it to be called something other than 'dpinger' though.
But that might be better served by multiple instances of existing dpinger and a simple script anyway.

mcury

@stephenw10 said in If you could have 1 feature added - what would it be?:

Have to get @dennypage to chnage his name if you want it to be called something other than 'dpinger' though.

JonathanLee

Dream feature is for the Squid package to have the ability to have auto splice databases for steaming, gaming, mobile phones, banking etc. So you’re not stuck hand creating them. Databases just built in like Palo Alto has “Facebook Base” and items like that the ability to simplify most often accessed sites for splicing per what you’re using.

dennypage

@stephenw10 said in If you could have 1 feature added - what would it be?:

But that might be better served by multiple instances of existing dpinger and a simple script anyway.

You are quite correct.

This has been throughly discussed before. See dpinger issues #22, #24 and #31. Also see the redmine, particularly note 28.

Honestly, if it made sense for dpinger to support multiple targets, I would have done it. Even without someone offering me $2,500.

keyser

@stephenw10 said in If you could have 1 feature added - what would it be?:

I think Multi-Instance Management is at the top of many peoples lists.

Ohh, yeah, that would be a VERY welcome feature if it was featurerich enough. But honestly I don’t think it’s really feasible to adapt/change all the pfSense code to actually be master managed without a complete rewrite with central management in mind.

But: I have been experimenting with using the various XMLRPC sync features originally designed for HA as a “sort of” master manager, and I think a multi-instance manager should consider looking in that direction instead. I have a setup where I have one pfSense being master and any changes made to alias’es, users, pfBlockerNG, Unbound and Freeradius is automatically synced to a remote site firewall (There is no HA , I just use the XMLRPC sync). It requires a little tweaking in the setup of the various services (fx. Freeradius needs to be listening to 127.0.0.1 because it also replicates interface setup), but it works.

A core requirement of a multi-Instance manager would be automatic mesh and hub/spoke VPN setup, firewall alias syncing, NAT rules syncing and firewall rules syncing. This would require all of the synced services on each managed firewall to both have a LOCAL section and a MASTER Synced section that can only be edited on the master.

Fx:

In Aliases local aliases are possible, and then there’s all the aliases recieved from the master.
In NAT rules there is two sections: Local NAT rules first, then Master synced NAT rules
In firewall rules on each interface there would be three sections: LOCAL rules, master synced rules, and LOCAL rules again at the end.
In VPN there is local VPN setup section and then all the centrally synced VPN setup.

That way you can use aliases inside aliases to allow both local and central firewall rules to use both local and master synced aliases within the rules.

In essense an alternative XMLRPC sync setup with Multi-Instance management as the goal rather than HA. That would require only “minor” adaptations of the various modules’s code to allow for both Local and central config sections.

bschapendonk

Some more IPv6 things to learn / play with.

Better dhcpc6 status information (the PD_PREFIX is only printed once in the logs when debugging is enabled)
Option to use a PD_PREFIX "template" in other configuration fields (eg rules/wireguard) instead of hardcoding a IPv6 address in those. (might already be possible for rules?)
Make IPv6 the primary stack vs IPv4 (UI / design / thinking wise)
NAT64 / 464XLAT support so that IPv6 only networks are possible (Should be feasible for most big OS'es, expect Windows although CLAT support for non WWAN interfaces was announced, no timeline yet tho)
Better (UI) way to handle manual DNS registrations (IPv4/6) versus automatic DHCP ones (no need for DHCPv6 in my use case, SLAAC is great and the latest Windows 24H2 works with RDNSS on dual-stack)