Now Available: pfSense Plus 26.03.1

pfGeorge

Netgate announces the release of pfSense Plus software version 26.03.1. This maintenance software release contains over 20 fixes and enhancements, including security improvements. All pfSense Plus software users are encouraged to upgrade to this new version.

Key security improvements include fixes for:

Potential Stored XSS in diag_arp.php when using ISC DHCP
Potential XSS in RSS Widget feed content post titles
Potential XSS in Captive Portal widget
Fixes for vulnerabilities discovered in the DHCP client
Several base system packages were updated to address various upstream security issues.

Additional areas of improvement include:

Aliases/Tables
LDAP Authentication
Captive Portal
Console Menu
Dashboard
IPsec
OpenVPN
Firewall Rules/NAT

Fixes and improvements exist in other areas as well. Please see the Release Notes for detailed information.

applesalwaysred

Updated 2100, ok so far.

ROtU4pti

This update keeps replacing the package sources from amd64 to aarch64 and bricks my installation. It's a Netgate SG-8860 (amd64 obviously) and the previous version was 25.11.1.

stephenw10

Checking....

stephenw10

OK should be fixed. Please retry.

ROtU4pti

@stephenw10 thanks, now it works

JonathanLee

@stephenw10 does the mpcie driver show up on this version ??

stephenw10

No, this is a point release so mostly bug fixes. That driver is still broken upstream AFAIK.

luckman212

Noting:

Installed packages to be DOWNGRADED:
	if_pppoe-kmod: 26.03.1600011 -> 26.03.1.1600011 [pfSense]
	pfSense-repoc: 20260521.044308 -> 20260520.151349 [pfSense]
	tailscale: 1.98.3 -> 1.94.1 [pfSense]

tailscale: expected since I did that manually
pfSense-repoc: unexpected?
if_pppoe-kmod: seems to be a parsing error since 26.03.1.1600011 > 26.03.1600011 ?

marcosm

@luckman212 TLDR its all expected. repoc tracks the build, and 26.03 was reubilt recently as part of picking upgrades for stromgswan and (IIRC) unbound.

tinfoilmatt

and (IIRC) unbound.

Recall is correct: https://redmine.pfsense.org/issues/16848.

For any others still on 26.03 (meaning holding off on 26.03.1 for whatever reason), see also: https://redmine.pfsense.org/issues/16849.

JonathanLee

@stephenw10 dang if that is fixed I can do some testing and add that squid status patch again

stephenw10

Let's see what we can do for 26.07. Though it will likely need to be fixed upstream first.

Mission-Ghost

Five minutes on a Newgate 4200 with aftermarket storage upgrade through Starlink. I didn’t remove any packages prior. Trouble-free.

Whatever made the 26.03 upgrade take 45-55 minutes was not a factor in this upgrade.

JeGr

@stephenw10 @pfGeorge

I know it's along shot but it's the only thing that would jump my mind what could have changed:

I'm currently on site for a customer to help migrating from old pfSense boxes to new 8200 pfSense plus. Last week we already did the basic installation for both nodes, checked all interfaces and ordering, created necessary VIPs and CARP stuff, enabled HA (sync on both, config on main) etc. etc.
All was fine, boxes shut down up until today to go ahead with more config and do some Alias and NAT work. As we checked the boxes "oh an update", so we installed 26.03.1 on both and proceeded with configuration.

I've now had big problems with the HA sync for the whole day and can't make heads or tails of it. The secondary node now after a config sync always logs this:

May 28 16:50:28 	php-fpm 	616 	NOTICE [Gateway Monitoring] killed policy routing states for tier 2 in FOGW4_default
May 28 16:50:28 	php-fpm 	36481 	NOTICE [Gateway Monitoring] killed policy routing states for tier 2 in FOGW4_default
May 28 16:50:27 	php-fpm 	8305 	NOTICE The command '/usr/local/sbin/strongswanrc stop' returned exit code '1', the output was 'strongswan not running? (check /var/run/daemon-charon.pid).'
May 28 16:50:27 	check_reload_status 	664 	Reloading filter
May 28 16:50:26 	check_reload_status 	664 	Reloading filter
May 28 16:49:55 	kernel 		carp: demoted by 0 to 0 (pfsync bulk done)
May 28 16:49:55 	kernel 		carp: demoted by 0 to 0 (pfsync bulk start)
May 28 16:49:55 	check_reload_status 	664 	Syncing firewall

Perhaps it didn't jump at me last week but the CARP demotion seemed new and useless(?) as there's nothing to do. It runs standby as it should. Also there were no changes, so GW killing - I don't get but OK.

But the biggest problem is that the master very often reports failure to sync after the smallest changes:

A communications error occurred while attempting to call XMLRPC method restore_config_section: Malformed response: @ 2026-05-28 16:49:30
A communications error occurred while attempting to call XMLRPC method restore_config_section: Malformed response: @ 2026-05-28 16:49:31

Malformed response? Huh. Also the Standby system sees A LOT OF config syncs even when I simply don't do anything as if the main node has e.g. 12 updates in the queue and throws one after another over multiple minutes to the standby, often again timing out with above malformed response.

The curious thing is, ALL was fine last week. And no one did any changes up to now, as the boxes aren't in prod yet. And all we did was updating this morning and then "the fun" started. Did anything go wrong with config versioning in this update? I know I'm going out on a limp here but I don't know why the hell this sync just won't work cleanly anymore.

Cheers
\jens

PS: @pfGeorge you could have mentioned the upcoming update in our tnsr talk yesterday ;) But it was very nice nonetheless.

JeGr

Ah almost forgot:

said in Now Available: pfSense Plus 26.03.1:

May 28 16:50:27 php-fpm 8305 NOTICE The command '/usr/local/sbin/strongswanrc stop' returned exit code '1', the output was 'strongswan not running? (check /var/run/daemon-charon.pid).'

The strongswan thing also now pops up without any IPsec configured whatsoever, I found that weird. No need to stop/start/handle a service thats completely empty and unconfigured?

JeGr

said in Now Available: pfSense Plus 26.03.1:

Malformed response? Huh. Also the Standby system sees A LOT OF config syncs even when I simply don't do anything as if the main node has e.g. 12 updates in the queue and throws one after another over multiple minutes to the standby, often again timing out with above malformed response.

Also as a quick follow up because I find it highly suspicious that the standby node now gets SO many updates after a simple change to the master node:

I did a quick compare of those 4 pushed config syncs, why there are so many as I didn't change a thing on the master. Have a look:

^

Three of them are empty. Nothing changed besides the timestamp of the revision. No "config" update at all? Don't know what's happening here.

stephenw10

Hmm, it's the revision time only?

Digging....

JeGr

@stephenw10 said in Now Available: pfSense Plus 26.03.1:

Hmm, it's the revision time only?

Digging....

Thanks. Also the standby node now has times where it's not really available like all nginx processes or php is blocked. Looking at it via SSH really doesn't reveal much. No real load etc. When restarting FPM and Nginx, its available immediatly again but of course that throws up even more sync errors on the main node. Main runs with 5 , standby with 10 nginx max procs configured in advanced settings to better adapt sync. raised that to 15 but seemingly to no gain.

stephenw10

Unable to replicate it here so far. Does forcing a config sync from Status > Filter Reload trigger it for you?