pfSense® Plus software version 24.03-RELEASE is here! 🥳

Cylosoft

24.03_1 is out now?

the other

@Cylosoft yeah, scroll to the very first post in this thread...it's explained there (update)... :)

Antibiotic

@Cylosoft Where did you get about 24.03_1 as only 24.03 out?

dennypage

@Antibiotic said in pfSense Plus software version 24.03-RELEASE is here! 🥳:

Where did you get about 24.03_1 as only 24.03 out?

See the announcement at the top of this thread.

crucialguy

Seems to have worked OK in the main biw, but a bit of oddness with my upgrade process.

It seemed to be taking too long and I was a bit nervous (I was still waiting for pings 8 mins in) - so I hooked up a monitor to my appliance to have a quick look. As per the upgrade process it was refreshing the packages and it was reinstalling Snort, I'm not sure if this is an issue with the Snort package or pfSense....but....it was trying to download all the block lists/community rule sets for Snort etc BEFORE any interface had initiated, so the reason it took ages to come up is because every rule set was trying and timing out on the download, as expected...because it was trying to do it before it brought the interfaces up!

I did another couple of reboots after that and the same symptom didn't re-occur, so I imagine this was just an upgrade oddity and it sorted it's self out (just needed to be patient).

There is also a fundamental issue with pfBlocker, but this is resolved with a custom patch someone has made (see this thread - https://forum.netgate.com/topic/185207/24-03-development-php-fatal-error-uncaught-valueerror-range-argument-3) - Hopefully that's updated at some point to remove that issue from the main release.

The first thing I wanted to try, something I've been keen to test is the WAN Gateway failover...failback, and it works a charm. I don't know if anyone else uses Wireguard tunnels, but on a gateway failback these never, ever came back to the primary connection without pulling the plug on the backup connection - but now they do recover and swing back to the primary on gateway restore without any intervention. It does take a bit of time, 2-3 mins, so I'm going to look and see if there's anything I can do to improve it slightly - but it's still an improvement and removes the manual intervention.

Antibiotic

@crucialguy Do you use traffic shaping?

crucialguy

@Antibiotic Nope, no traffic shaping whatsoever here.

Standard traffic flows and gateway groups with PBR etc.

sandie

@crucialguy For me slowly upgraded 7100 DT router (15 minutes) has Suricata. 6100 which upgraded reasonably fast does not have Suricata.
It could be the reason you pointed.
I am happy to run latest pfSense+ software.

Phizix

Woooohooooo!

Up and running 24.03-RELEASE.
SG-5100 on ZFS (128 GB M.2 SSD & 16 GB RAM). Took about 10 mins and not glitches.

I run pfBlockerNG, but no issues that I see yet.

Phizix

SteveITS

@crucialguy Believe your issue of pre interface downloads was discussed somewhere here a week or two ago.

Thanks for the pfB pointer.

Bob.Dig

@the-other said in pfSense Plus software version 24.03-RELEASE is here! 🥳:

So of course all ULAs were gone from tables...re-aplied that patch and all is well again.
Sorry for any confusion...

Now I am confused, so you are saying, you still need that patch?

mvikman

Looks like 24.03 upgraded bootloaders on both disks on ZFS mirror, redmine #15084 is still open though.
Maybe it was fixed in FreeBSD 15.0...?

ronv42

Ran the update on a Protectli FW4C this morning before anyone needed the internet. Started at 6:15 and by 6:45 everything was updated and no issues. I was able to log in at about 6:35 and some services were still offline with red checks while being updated.

jimp

@mvikman said in pfSense Plus software version 24.03-RELEASE is here! 🥳:

Looks like 24.03 upgraded bootloaders on both disks on ZFS mirror, redmine #15084 is still open though.
Maybe it was fixed in FreeBSD 15.0...?

There was some work done to help there but there may still be an edge case or two around that needs work yet (or at least testing/confirmation). Since that's a rather critical part we kept it open until we know for sure that all of the problem scenarios are working properly now.

the other

@Bob-Dig well, as mentioned under System > Patches:
"After upgrading, do not revert a patch if the changes from the patch were included in the upgrade. This will remove the changes, which is unlikely to be helpful."

So, yeah...
I made the mistake to revert and delete said patch. So tables did not get my ULAs anymore.
Re-applied the patch, and ULAs are back in tables and also all rules are working again (with ULA) without EXTRA ULA rules...(workaraound before that patch was published, remember?)
:)

Bob.Dig

@the-other said in pfSense Plus software version 24.03-RELEASE is here! 🥳:

Re-applied the patch, and ULAs are back in tables and also all rules are working again (with ULA) without EXTRA ULA rules...(workaraound before that patch was published, remember?)
:)

Not really, all the IPv6 discussions go that route anyways. But as I read the changelog, you don't need a patch for this anymore. I would tripple check this. I don't use ULAs anymore, so I can't test this.

MoonKnight

Hi,
Got this message today.

I updated and still stays:

MoonKnight

@MoonKnight
Ups, I didn't read this :(

Update (Wednesday April 24):

Devices running pfSense Plus software version 24.03 may be seeing a "24.03_1" update available which is a very minor revision made to address a missing dependency on 64-bit ARM devices (https://redmine.pfsense.org/issues/15433). The revision is kept the same on all platforms for consistency.

Upgrading to this version is safe, but not necessary at this time unless users are running on 64-bit ARM devices and want access to S.M.A.R.T. disk data (e.g. Netgate 2100 devices which have an add-on SSD).

Using the GUI or pfSense-upgrade from the console or shell to upgrade from 24.03 to 24.03_1, the device will want to reboot, but in this case that is unnecessary. However, doing so is harmless except for the minimal downtime involved in the reboot during that upgrade process.

Manually updating from the shell via pkg update; pkg upgrade will pull in the new revision and fixed dependency as needed. Run those commands from a shell prompt and confirm that the proposed changes are OK. No additional action is necessary.

Devices which have not yet upgraded to 24.03 or those installed fresh via the Online Network Installer will obtain the latest version automatically and do not require any additional action after upgrading.

chudak

Upgraded and forgot to uninstall some packages.
Still, all went fine, so far no issues.

Thank you!

the other

@Bob-Dig hey there again,
I did try that twice...but for you I just tried a third time ;)...
Reverted ULA patch...rebooted...ULAs gone from Tables.
Then re-applied that patch...rebooted...ULAs back in Tables.
:)

So I think, in case you never applied that patch and update (or install completely new) 24.03...well it is included. Won't even show under Patches I'd assume.
But in case you did apply it before, then upgrade...it is still showing under System > Patches. Now, in case you revert it...that function is lost and ULAs are broken again.
Tried it as said just 5 minutes ago for a third time and each time I revert, ULAs (as put under VIPs) are lost from tables and no routing is done / extra rules for ULAs (in subnets/VLANs) must be used (which sux).
That's why (I guess) it is extra mentioned under System > Patches (my quote in my posting above).