From my perspective the issue is the scope for a users contingency planning on pfsense router failure (initially of unknown cause). Netgate's current device locked licensing and lack of an off line installer doubles the cost of ownership and significantly reduces pfsense functionality. It is the reason I have not purchased plus licences.

My contingency planning is focussed on rapid restoration of service with minimum dependences, limited technical complexity, and a short time. Doing so involves the ability to swap out a failed physical system and replace it with another. First line using a box with pfsense pre-installed. Second line with my locally stored copy of pfsense installation media. The installation media has to work within my system without a functional router, for which an off line installer is most reliable. An online installer which uses that sites pfsense configuration may work but at best introduces higher risk in a contingency plan.

To achieve this economically I run pfsense on third party hardware which also does other roles. I have multiple physical devices performing tasks of varying importance (set top box for each TV, router a several sites). As well as each device running
running multiple virtual machines for other functions (PABX, Unifi controller, surveillance cameras etc). The overall effect is all hardware is utilised but relatively spare hardware can be rapidly commandeered if required.

For this to work with pfsense plus I need to be able to install pfsense on multiple virtual machines and transfer a licence from a failed to a replacement device if required. Ideally by entering registration details in the replacement hardware (which would warns doing so inactivates the prior registration) or doing the same via a Netgate portal. Either of which implies such a transferable pfsense plus licensed device regularly checks licence validity with a Netgate server (making a transferable licence incompatible with a pfsense installation without online access to the Netgate licence server).

I'm not sure how large the market is for off line Netgate routers. Such an installation would require a non trivial protocol to update pfsense software, which even on Netgate hardware would not be simple. With an off line installer including all patches was available, this could be taken into the secure environment and used to re-install / update pfsense. My understanding there has never been an off line installer with all patches (or packages) as such I suspect software update would require secure erasing the pfsense disk, physically moving the hardware out side of the secured environment, programming it with current pfsense software, returning it to the secure environment, import the sites pfsense configuration file. Not something done frequently and probably not a large market but I could be wrong.

Similarly my use case is probably also a small market, however I suspect the market for economic contingency planning is much broader. As such many users are likely to benefit from the licence transferability and off line installation options which maybe possible it a monitored plus licence option was offered.

I don't know how Truenas would set that up but in Proxmox you could add an address to the bridge and use that to access Proxmox. It could be dhcp or static. I would probably leave it as dhcp and set a static dhcp lease in pfSense so it always get the same IP address.

Just to be clear though that is config in Proxmox it is not a bridge in pfSense.

@Wylbur Thank you!

I know you said this wasn't your problem, but I had mine all set up with static reservations in DHCP and had modified them to use DHCP assignments. I was able to periodically log in and check their connection strength and whatnot without issue. At some point I needed to do a firmware update and noticed they would no longer respond to ping or bring up the webgui at the statically assigned IP. This was after switching to KEA DHCP. I had to connect to each one individually with a laptop, reset it, and flash the firmware. I then decided to set them back to DHCP and they disappeared into the void again. I haven't been able to connect to them since but assume they will be back at some point once something gets ironed out in KEA.

@tgl You're absolutely right. Hardcoding the password (and especially pushing it to a repo, even a private one) was a poor decision. That part was initially just for testing, and I forgot to replace it before pushing.

@provels said in Just a simple, informative network utility from Y2K:

a 486DX4-100

Ooo fancy!

Fast forward 9 years... the FreeRADIUS package includes bash as a dependency. So simply install FreeRADIUS

@tedquade Oh, great news! Thank you for the update, Ted.

@LukasInCloud
I run pfSense+ as my firewall and, yes, I create new BE copy after every major change and switch to it as WIP. I also have a computer running FreeBSD 14.2 with KDE Plasma 6 DE. I create new BE copy in CLI.

@voxmagna1 Something else that may help: Firewall Optimization Options

Nice! 👍