UI Update output.

>>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.conf: . done Fetching data.pkg: . done Processing entries: . done pfSense-core repository update completed. 5 packages processed. Updating pfSense repository catalogue... Fetching meta.conf: . done Fetching data.pkg: .......... done Processing entries: .......... done pfSense repository update completed. 733 packages processed. All repositories are up to date. >>> Setting vital flag on pkg...done. >>> Setting vital flag on pfSense...done. >>> Renaming current boot environment from 25.03 to 25.03_20250719205419...done. >>> Cloning current boot environment 25.03_20250719205419...done. >>> Removing vital flag from php83...done. >>> Upgrading packages in cloned boot environment 25.03... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking for upgrades (10 candidates): .......... done Processing candidates (10 candidates): .......... done The following 10 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: if_pppoe-kmod: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense-base: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-boot: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-default-config-serial: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-kernel-pfSense: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-pkg-Nexus: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-pkg-System_Patches: 2.2.21_1 -> 2.2.21_2 [pfSense] pfSense-repoc: 20250419 -> 20250520 [pfSense] unbound: 1.22.0_1 -> 1.23.0 [pfSense] Number of packages to be upgraded: 10 The operation will free 12 MiB. 214 MiB to be downloaded. [1/10] Fetching unbound-1.23.0.pkg: .......... done [2/10] Fetching pfSense-pkg-System_Patches-2.2.21_2.pkg: ......... done [3/10] Fetching if_pppoe-kmod-25.07.r.20250715.1733.1500029.pkg: ... done [4/10] Fetching pfSense-pkg-Nexus-25.07.r.20250715.1733.pkg: .......... done [5/10] Fetching pfSense-kernel-pfSense-25.07.r.20250715.1733.pkg: .......... done [6/10] Fetching pfSense-base-25.07.r.20250715.1733.pkg: .......... done [7/10] Fetching pfSense-25.07.r.20250715.1733.1500029.pkg: .......... done [8/10] Fetching pfSense-boot-25.07.r.20250715.1733.pkg: .......... done [9/10] Fetching pfSense-default-config-serial-25.07.r.20250715.1733.pkg: . done [10/10] Fetching pfSense-repoc-20250520.pkg: .......... done Checking integrity... done (0 conflicting) [1/10] Upgrading unbound from 1.22.0_1 to 1.23.0... ===> Creating groups Using existing group 'unbound' ===> Creating users Using existing user 'unbound' [1/10] Extracting unbound-1.23.0: .......... done [2/10] Upgrading pfSense-repoc from 20250419 to 20250520... [2/10] Extracting pfSense-repoc-20250520: .. done [3/10] Upgrading if_pppoe-kmod from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [3/10] Extracting if_pppoe-kmod-25.07.r.20250715.1733.1500029: .. done [4/10] Upgrading pfSense-boot from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [4/10] Extracting pfSense-boot-25.07.r.20250715.1733: .......... done [5/10] Upgrading pfSense-pkg-System_Patches from 2.2.21_1 to 2.2.21_2... [5/10] Extracting pfSense-pkg-System_Patches-2.2.21_2: .......... done [6/10] Upgrading pfSense-pkg-Nexus from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [6/10] Extracting pfSense-pkg-Nexus-25.07.r.20250715.1733: .......... done [7/10] Upgrading pfSense-kernel-pfSense from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [7/10] Extracting pfSense-kernel-pfSense-25.07.r.20250715.1733: .......... done [8/10] Upgrading pfSense-base from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [8/10] Extracting pfSense-base-25.07.r.20250715.1733: ... done ===> Keeping a copy of current version mtree ===> Removing schg flag from base files ===> Extracting new base tarball ===> Removing static obsoleted files [9/10] Upgrading pfSense from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [9/10] Extracting pfSense-25.07.r.20250715.1733.1500029: .......... done [10/10] Upgrading pfSense-default-config-serial from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733: [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733... done Failed

@SteveITS said in pfSense® CE 2.8.1 Beta Now Available!:

Release notes?

https://docs.netgate.com/pfsense/en/latest/releases/2-8-1.html

@chudak said in pfSense Plus 25.03-BETA is here!:

Why is 25.0x taking so long this time?

Because it is a really good update.

☕️

@Sergei_Shablovsky said in pfSense CE 2.8 Release Candidate is Here!:

So, as a solution You propose me just…to stop using ntopng ? Seriously ?

If the unexposed redis vulnerabilities concern you, then yes, I definitely suggest that you stop using ntopng. There are likely much worse vulnerabilities, known and unknown, in ntopng itself.

Running any add-on package increases risk, and ntopng is a large and complicated piece of code which brings a higher level of risk than most. Of course, you have to decide for yourself what level of risk you are willing to operate with.

FWIW, as a whole I recommend use of ntopng as a diagnostic tool only. I do not recommend it as something for continual, routine operation.

@Sergei_Shablovsky said in pfSense CE 2.8 Release Candidate is Here!:

I clearly understand that most of this CVEs are out of Netgate’s obligation. But is this mean the current 2.8.0 would be in BETA until all of this CVEs would be resolved by developer’s community ?

No. It is not practical to stop the release of pfSense because there is a vulnerability in an add-on provided by the community. pfSense itself would never release.

If you want to go down that path, a much more practical approach would be for Netgate to remove the add-on from the repository until all vulnerabilities in the component and all of its dependencies were remediated. Ouch.

I updated to pfSense 2.8.0 RC the other day and noticed when I went through the settings that the time stamp in the ACB Service (Services/Auto Configuration Backup/Restore) is behind my time by 7 hours.

I check my time and it is correct for time and zone in the Dashboard.

I changed the time zone temporarily but the time stamp did not change in ACB but the zone did, i.e. it was +0200 for CEST and when I changed it to ETC/UTC time zone it went to +0000 but time itself did not change.

This is the issue I have on 2 pfsense setups I have running at home.

I did some researching and only found this reference to the issue.

So, am I doing something wrong in my setups or is this a know issue for pfSense 2.8.0 RC?

@mr_nets it's in this beta

I thought it best to create a separate topic so we can keep this one clean.

@sheepthief said in pfSense Software is 16 today!:

but I've not yet found a roadmap

https://redmine.pfsense.org/projects/pfsense/roadmap

Regards,
fireodo

@DominikHoffmann The oven is running and a release build is baking. Soon.

That's this: https://redmine.pfsense.org/issues/15411

It creates some logs at boot that cause it. Once they scroll off the page should display normally.

What about the community version?

@aaronssh said in pfSense Plus Multi-Instance Management Q&A - SNEAK PEEK:

This is great news. The one thing I really care about: can firewall aliases sync between devices? That would be a HUGE productivity gain.

With an API and 300 commands, I don't think they skipped one to push aliases to the devices.

Certainly a very exciting development and improvement. However, like pfSense in general these days, it seems to be heavily inspired by developers' and marketing ideas and less by practical needs of network security professionals.

Some parts of the video call sound a bit far fetched, to be honest:

I never actually heard a complaint about a central management platform being too slow. Anyway, let's assume that a product out there is sluggish. Would it imply that you can move your enterprise firewalling from product x to pfSense, because Netgate's MIM is so much more responsive?

API vs. CLI: Outside of (mostly: cloud) environments that have a really mature, custom control plane, APIs of firewall appliances are rarely used, even on platforms that had them for years. CLIs are being used all the time, athough they are orders of magnitude slower than the slowest API, because they allow efficient manual changes as well as interfacing with a variety of third-party configuration managers with minimal adaptation. Whether a configuration change takes .4 or 78 seconds to apply is hardly relevant in a production environment. How many third-party vendors will support the pfSense API?

Scale: So far, it would have been very tedious to build infrastructures with thousands of pfSense instances. Hence, was it a real world need to support scaling into the tens of thousands, because so many clients with 15,000 instances each are urgently waiting for that feature? Or is it more about the many SMBs and SMB "MSPs" that maybe reach a two- or low three-digit number? The latter would have profited substantially from a CLI. With an API, they either do some very limited improvsation on the side, or have to use the Netgate platform right away.

I applied the 24.03 update today to my 1100. Appears to have executed smoothly and rebooted back into production without issue.

Prior to executing the update, I removed all the packages. After the update, I reinstalled all the packages from scratch.

For some reason, some packages did not start automatically after installation including pfBlocker and Status Traffic Totals.

So I ran the pfBlocker download process and when that was complete it started up normally. I started Status Traffic Totals from the dashboard without incident.

My packages are:

Cron
Mailreport
pfBlockerNG
Service Watchdog
Status Traffic Total
System Patches

My plan is to run this in production for a week or so to verify stability and then update my shelf-spare 1100. This will complete my update cycle.

Cool. I'm a FreeBSD user for a long time, have always preferred ZFS even on single disk systems because of Boot Environments.

Doing a major upgrade I've always done the "create a new BE, mount it, chroot to it and do the upgrade" process.
That lets you do the upgrade kernel, upgrade userlande, upgrade all the packages into the new BE while you are still running, then when you boot into that newly created BE everything is consistent, so you have a lot less risk of things going bad. They still can, but that's where the bootonce flag comes in. If the system fails to boot up completely (where the flag gets cleared) reboot and you are back to pre upgrade.

Automating this process is a very good thing to have. Very good stuff Netgate.

@barindervicky89 That could be phrased better, it actually means “auto Dashboard update check”