I do not know if it is related to the 25.07 RC, or not, but I had an ipv6 WAN outage today, that needed a reboot, instead of a dhcp6 client retry a few moment later. On the dashboard, WAN interface was showing 2001:xxxx:xxxx:xxxx:xxxx:: instead of 2001:xxxx:xxxx:xxxx:xxxx:yyyy:yyyy:yyyy:yyyy Here is the offending lines in the DHCP log : Aug 1 16:34:42 dhcp6c 77684 add an address 2001:xxxx:xxxx:xxxx::/128 on ix3 Aug 1 16:34:42 dhcp6c 77684 dhcp6c Received INFO Aug 1 16:34:42 dhcp6c 77684 Sending Renew Aug 1 16:08:11 kea-dhcp6 50779 ERROR [kea-dhcp6.packets.0x319bcd617400] DHCP6_PACKET_SEND_FAIL duid=[00:01:00:01:2d:4c:12:e7:f8:xx:xx:xx:xx:xx], [no hwaddr info], tid=0x3a7239: failed to send DHCPv6 packet: pkt6 send failed: sendmsg() returned with an error: Permission denied By the way, in the web GUI Dashboard, in the Interface Widget, would it be possible to modify it to see the whole ipv6 without horizontal scrolling in the final version or next beta ?

@reberhar Piece of cake. Really fast with no problems.

@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”