Now Available: pfSense® Plus 25.11-RELEASE

pfGeorge

pfSense Plus software, the world’s leading firewall, router, and VPN solution, provides secure network edge and cloud networking solutions for millions of deployments worldwide.

Netgate is excited to announce the release of pfSense Plus software version 25.11. This is a maintenance release that includes numerous updates, bug fixes, and enhancements, with more to come. All pfSense Plus customers are encouraged to upgrade to this new version.

Key Features and Improvements Include:

OpenVPN Changes - DH parameters that are less than 2048 bits have been deprecated. OpenVPN users will notice that if the update process detects a setting of 1024, the update process will automatically change this setting to 2048.
Netgate Nexus Updates - Many new updates have been made to Netgate Nexus, and this version 25.11 is required for support of this product. Additional information will be provided at the product launch for Netgate Nexus soon.

Note: New installs will require downloading of the latest Netgate Installer version 1.1.1 which is available for download here.

Read the blog here: https://www.netgate.com/blog/netgate-releases-pfsense-plus-software-version-25.11

Release Notes here:
https://docs.netgate.com/pfsense/en/latest/releases/25-11.html

keyser

@pfGeorge Thank you for the status update. Looking forward to test the upgrade process on my testbed and later production systems.

herozero

@pfGeorge Release notes state FreeBSD has been brought up to 16-Current, which gave me a good chuckle.

Patch

@herozero My understanding is new Netgate released are based on FreeBSD Current. This post may help clarify https://www.netgate.com/blog/pfsense-software-is-moving-ahead

4o4rh

Qotom Q800GE with 25.7.1 plus upgraded to 25.11

updated all packages
list of install error/warnings below seems related to php84
a number of packages without maintainer warnings

Warning: foreach() argument must be of type array|object, null given in Command.php on line 249
Warning: Trying to access array offset on null in Role.php on line 250
Warning: Trying to access array offset on null in Role.php on line 251
Warning: Undefined array key "honorsbaseinstall" in Role.php on line 173
Warning: Undefined array key "installable" in Role.php on line 139
Warning: Undefined array key "phpfile" in Role.php on line 204
Warning: Undefined array key "config_vars" in Role.php on line 46
XML Extension not found
Warning: foreach() argument must be of type array|object, null given in Command.php on line 249

efibootmgr: efi variables not supported on this system. kldload efirt?

otherwise, all seems good

Gcon

I am seeing an issue already. Dpinger data is way off for OpenVPN site-to-site tunnels.

OpenVPN tunnel "TN_GT1_LT1_VPNV4" goes over the WAN1_IPV4 WAN link.
OpenVPN tunnel "TN_GT2_LT2_VPNV4" goes over the WAN2_IPV4 WAN link.

The tunnel RTT should always be bigger than the WAN it goes over, as essentially it's the RTT of the local WAN + RTT of remote WAN + a bit more for processing overhead.

On the other side, you can see those two tunnels at the "LT" end reporting normally. That remote end is on CE 2.8.1.

Please investigate why dpinger stats for OpenVPN tunnels are incorrect. I will go away now and investigate in my GNS3 simulation lab if this affects dual WAN tunnel failover or not. If it doesn't then I may keep this version on, but if it does, I may have to roll this one back.

For devs. "GT" and "LT" are site designations with GT being the main site and LT being remote site. They both have primary and backup WANs, using different ISPs. I have a WAN1 to WAN1 tunnel, and WAN2 to WAN2 tunnel. Cheers.

Bob.Dig

@Gcon said in Now Available: pfSense Plus 25.11-RELEASE:

I am seeing an issue already

Why is the IP the same on both sides?

Gcon

I can't seem to edit but just to be clear, the first screenshot is the newly upgraded pfSense Plus 25.11, and the bottom one is a remote site on CE 2.8.1. The dpinger stats are accurate on CE 2.8.1, but not Plus 25.11. The WAN gateways ping the ISP end of the connection. Thus, the RTT should always be bigger for the OpenVPN tunnels.

Bob.Dig

@Patch said in Now Available: pfSense Plus 25.11-RELEASE:

My understanding is new Netgate released are based on FreeBSD Current. This post may help clarify https://www.netgate.com/blog/pfsense-software-is-moving-ahead

Also this might be of interest (translated from German):

Package filter pf(4) continues to converge with OpenBSD's pf(4)
The package filter pf(4) in FreeBSD 15 now also supports the NAT syntax of its counterpart in OpenBSD. Since 2004, FreeBSD has been using the package filter pf(4) ported from OpenBSD in addition to IPFW, which, among other things, prompted the development of pfSense. Due to different goals—FreeBSD focuses on performance, OpenBSD on security and new features—the originally identical pf(4) implementations increasingly drifted apart, especially since FreeBSD did not adopt major syntax changes such as those in OpenBSD 4.7. Since around 2013, the two variants have no longer been compatible; differences can be seen, for example, in memory allocation or the interpretation of IP values. However, both projects recognize that closer cooperation could bring more security for FreeBSD and more performance for OpenBSD.
The industry has apparently recognized this as well: Netgate and InnoGames jointly financed long-time FreeBSD developer Kristof Provost to adapt the outdated FreeBSD variant of pf(4) to the current state of OpenBSD. Of course, Netgate wants to make the central function of pfSense, its in-house firewall distribution based on FreeBSD, more modern and secure.

Translated with DeepL.com (free version)

https://www.heise.de/news/FreeBSD-15-Grosse-Fortschritte-dank-Industrie-Unterstuetzung-11100859.html

Gcon

@Bob.Dig

Hey that would do it! Dpinger is pinging the local IP on the 25.11 box, not the remote end!

These are auto-configured and they've always been accurate for me in the past.

On the remote end, you can see the IP that it should be pinging...

So on the 25.11 box I'll manually punch in the "Monitor IP" changing it from "<blank>" to put in those correct remote IPs.

Gcon

Hey Bob I manually punched in the correct monitor IPs and now my RTT and RTTsd values are back to the expected values. See below:

So now it is showing "local_ip (remote_ip)" whereas previously it just worked it out on its own (it's a /30 IPv4 tunnel). It seems now it needs some guidance as it can't work out the remote end on its own. Not sure if this is a bug or feature, but I'll leave it like that, and leave it up to Netgate to see if they want to investigate this.

If it's an expected feature, then it should be mentioned explicitly in the release notes (which I did read beforehand... I skim read :). To me though it seems like a bug. If you leave it blank - it should assume the other end of a /30, rather than local IP, yes? which is how it was for as long as I can remember, all the way up to this release.

Gcon

Actually this situation looks really bad. Under System / Routing / Gateways

This is the main site that got upgraded to 25.11:

Shouldn't the gateway always be a remote IP on a connected network? The Gateway for those OpenVPN tunnels "TN_xxxxx" ones are the firewall's own IP addresses! I can't configure that. They all show this:

It's coming up with the wrong gateway IP address!

Take the other side of the tunnel for comparison, which is on 2.8.1-CE:

The gateway there is the same as the monitor IP, as it should be.

Netgate devs - I'd be pulling this release ASAP, then thrashing it out further as a beta. It's got serious issues as demonstrated here.

Now time to roll this back, as it's scaring the bejesus out of me. Confidence shot if it can't work out the correct gateway IP.

Bob.Dig

@Gcon said in Now Available: pfSense Plus 25.11-RELEASE:

Now time to roll this back, as it's scaring the bejesus out of me.

It has been the case for a long time (forever?) that you can use the interface as the gateway for tunnel-interfaces with only two ends, so I wouldn't be scared. I am not a OpenVPN user though and be interested if something changed in that regard how pfSense does this on its own.

Gcon

@Bob.Dig

I've decided to not roll back, since I seem to have full connectivity via the VPN tunnels. i.e. nothing in practice seems to be broken. My monitoring server (CheckMK) can reach all the devices behind the remote sites, and vice versa. So, I will inform the site manager to just let me know of any strange network issues going forward, not encountered earlier in the week.

This may be related.
https://redmine.pfsense.org/issues/16351

It's a little strange to me, to see the local address as a gateway. Only 127.0.0.0/8 should be a gateway to one's self. Usually the gateway is a remote machine on a connected subnet. For instance if My PC is 192.168.0.10/24, the "gateway" is quite often 192.168.0.1 - i.e. another address.

But maybe with the OpenVPN tunnel construct, the "gateway" is in fact the tunnel endpoint local IP, and it just knows where to pop the traffic out at the other end. So I could be looking at it wrong, and that perhaps 2.8.1 is in fact the broken setup - but one that works in practice, because although it shows the remote end of the /30 as the gateway, it knows that reachability to the remote end is via the local end.

I have eBGP over two of the tunnels, and OSPF over a third tunnel. All peerings / neighbour relationships are up fine (I use FRR on the local and remote pfSense servers).

Anyway, will let others decide if it's a bug or a feature. Either way - it's certainly a change I was not expecting, and gave me quite the shock.

johnpoz

Just updated my + vm and my 4860 to 25.11 - have not seen any issues as of yet.. Take a bit to run through everything. But clearly I have internet.. Took about 20 min for the 4860.

edit: looks like everything is up and running only issue was tailscale.. I have it set to never expire on the tailscale site, and think this causes an issue where you get this error

You are logged out. The last login error was: invalid key: API key does not exist

I comment out

# pfsense_tailscaled_up_flags="--auth-key=${pfsense_tailscaled_authkey}"

Restart the service and back up and running.

openvpn working, wireguard working. dhcp (isc), dns, haproxy, ipv6 via HE tunnel, etc. look like another great update from netgate to me.

My monitor for wireguard vpn tunnel working and using the remote end for monitoring, but I had set that up long time ago to use the remote end vs local end.

WN1X

Updated my 4200 this morning. No issues other than my usual dpinger stuck in pending for IPv6. A quick restart of dpinger gets it going.

patient0

@WN1X said in Now Available: pfSense Plus 25.11-RELEASE:

No issues other than my usual dpinger stuck in pending for IPv6. A quick restart of dpinger gets it going.

Btw: I got the dpinger stuck in pending because my WAN is an ULA address.

Adding a once-after-reboot cronjob did help with that, in case you get tired of manually restarting it. Maybe it works in your case too (and if you're a bit familiar with the command line)

As root (the root crontab it most probably empty):

$ crontab -e
@reboot /usr/local/sbin/pfSsh.php playback svc restart dpinger
## exit vi

WN1X

@patient0 said in Now Available: pfSense Plus 25.11-RELEASE:

@reboot /usr/local/sbin/pfSsh.php playback svc restart dpinger

Awesome suggestion. I've added it to my firewall. My Fios connection almost never goes down, so it has only been an annoyance.

dennypage

@patient0 said in Now Available: pfSense Plus 25.11-RELEASE:

As root (the root crontab it most probably empty):
$ crontab -e
@reboot /usr/local/sbin/pfSsh.php playback svc restart dpinger
## exit vi

FWIW, I think it would be preferable to do this via the cron package so the job is backed up.

patient0

@dennypage said in Now Available: pfSense Plus 25.11-RELEASE:

FWIW, I think it would be preferable to do this via the cron package so the job is backed up.

You are right, I thought that I can only specify a time in the GUI, I didn't read the text below the minute field :). I just re-read it and I see I can specify events or delays.