Now Available: pfSense® CE 2.8.1-RELEASE
-
I also updatet from 2.8.0 -> 2.8.1, went without any problems, and I didnt had to de-install aynthing... Thanks to developers and Beta testers!
Didnt had any issue, and Im seeing now, that SNORT shows finally in Dashboard the correct Description row with content...before update, its was showing the Description Row, but empty. Found no issue so far! Thanks!
-
I just upgraded to 2.8.1. Had to restart pfgblocker. Rebooted again as CPU was hovering at 59%. Once reboot took place it is now at 1%
-
I've a couple of random crash restarts since the update and this is the report of the last one.
Crash report begins. Anonymous machine information: amd64 15.0-CURRENT FreeBSD 15.0-CURRENT #21 RELENG_2_8_1-n256095-47c932dcc0e9: Thu Aug 28 16:27:48 UTC 2025 root@pfsense-build-release-amd64-1.eng.atx.netgate.com:/var/jenkins/workspace/pfSense-CE-snapshots-2_8_1-main/obj/amd64/AupY3aTL/var/jenkins/workspace/pfSense-CE- Crash report details: PHP Errors: [06-Sep-2025 01:06:00 Europe/London] PHP Fatal error: Uncaught TypeError: posix_kill(): Argument #1 ($process_id) must be of type int, string given in /etc/inc/openvpn.inc:1552 Stack trace: #0 /etc/inc/openvpn.inc(1552): posix_kill() #1 /etc/inc/openvpn.inc(1575): openvpn_stop_process() #2 /etc/inc/openvpn.inc(2494): openvpn_restart() #3 /etc/inc/service-utils.inc(774): openvpn_restart_by_vpnid() #4 /usr/local/pkg/servicewatchdog.inc(96): service_control_start() #5 /usr/local/pkg/servicewatchdog_cron.php(30): servicewatchdog_check_services() #6 {main} thrown in /etc/inc/openvpn.inc on line 1552 No FreeBSD crash data found. -
@randombits said in Now Available: pfSense
CE 2.8.1-RELEASE:Hi, as many posters have told this
servicewatchdog
is not a good Idea - watchdog is a "dumb" tool that creates more trouble than it resolves.
Another thing is - take a look at openvpn.inc on line 1552 to see whats there.
To the rest may a Specialist take a look.My 2 cents,
fireodo -
Performed dirty upgrade from 2.8.1 RC to 2.8.1-RELEASE with zero issues.
-
@fireodo
Line 1552posix_kill($pid, SIGTERM);And in some context
function openvpn_stop_process($mode, $settings) { global $g; $mode_id = openvpn_name($mode, $settings, 'generic'); $pfile = g_get('varrun_path')."/openvpn_{$mode_id}.pid"; if (file_exists($pfile)) { /* read the pid file */ $pid = rtrim(file_get_contents($pfile)); unlink($pfile); syslog(LOG_INFO, "OpenVPN terminate old pid: {$pid}"); /* send a term signal to the process */ posix_kill($pid, SIGTERM); /* wait until the process exits, or timeout and kill it */ $i = 0; while (posix_kill($pid, 0)) { usleep(250000); if ($i > 10) { log_error(sprintf(gettext('OpenVPN ID %1$s PID %2$s still running, killing.'), $mode_id, $pid)); posix_kill($pid, SIGKILL); usleep(500000); } $i++; } } }I'll stop the watchdog for the time being, it's never been a problem before.
-
@randombits said in Now Available: pfSense
CE 2.8.1-RELEASE:I'll stop the watchdog for the time being, it's never been a problem before.
As I read the code (with my humble knowledge) the killing of the openvpn process was konflicting with watchdogtrying to restart the process (that was dead in his eyes). IMHO
-
@fireodo
It appears something like that, I've removed the Watchdog anyway and I'll see how it goes. -
Any news for the Zabbix Proxy 7 package?
-
@sandrinho1976 said in Now Available: pfSense
CE 2.8.1-RELEASE:Any news for the Zabbix Proxy 7 package?
Is this what you're looking for?

-
Hey Mates, Just completed an upgrade to 2.8.1 from 2.8.0 all is working fine, no crushes despite ignoring the instructions to first remove all packages before doing the upgrade.
I went with my way, and all is perfect. If you haven't please do the necessary.
Africa is up-to-date.............

-
This post is deleted! -
Has anyone updated from CE 2.7.2 to 2.8.1?
I'm asking because the upgrade to 2.8.0 for me failed and recovery required re-installing 2.7.1 (ISO), and then upgrade to 2.7.2 (which I've been running for a while now).
Since I have two systems, I can upgrade the one and keep the other as a backup.... I just dislike going back through manually putting in the various IP pools and static addresses for my network.
Regards,
Wylbur -
@Wylbur worked fine form me
I suspect the easiest is to- backup your pfsense configuration
- Connect your backup pfsense routers want to your main units lan (so you can crash the backup unit and your internet continues to function
- Download pfsense iso v2.70 v2.71 v2.72 from https://atxfiles.netgate.com/mirror/downloads/
- download the free pfsense installer (internet connection during install required) from https://shop.netgate.com/products/netgate-installer
- Try installing various versions of pfsense to confirm which are compatable with your hardware
- restore your configuration to your preferred working pfsense version
-
@Wylbur worked fine form me
I suspect the easiest for you is to- backup your pfsense configuration
- Connect your backup pfsense router WAN to your main units LAN (so you can crash the backup unit and your internet continues to function)
- Download pfsense iso v2.70 v2.71 v2.72 from https://atxfiles.netgate.com/mirror/downloads/
- download the free pfsense installer (internet connection during install required) from https://shop.netgate.com/products/netgate-installer
- Try installing various versions of pfsense to confirm which are compatible with your hardware
restore your configuration to your preferred working pfsense version
(re-entered as editing prior posts is not working atm)
-
@Patch Thanx. I'll find time to set up to do this. I just wanted to not be a guinea pig for this update. Last time it took me a few hours to re-install and configure both fire wal/gateway servers.
-
@Wylbur said in Now Available: pfSense
CE 2.8.1-RELEASE:. I just dislike going back through manually putting in the various IP pools and static addresses for my network.
That's why you have to put all chances on your side.
As already said above : make use of the very single reason why pfSense exists (in the first place) : this is not the presence of a GUI t set things up, it's the fact that you can 'backup' or 'save' one single config file, and later on, on the same system ( ! ) you can install from an USB drive, do minimal initialisation, probably mostly accepting the default) and as soon as the GUI comes up : import the config, and 'done'.
If your connection is slow, or you have (had) many pfSense packages installed, just be patient. All packages will get installed 'fresh', and their settings will get applied before they are started.
Be ware that race conditions can exist, like you use the OpenVPN (client or server) and to opted for FreeRadius authentification, but the pfSense FreeRadius package wasn't installed yet ...
So, when hing have settled out, the dust is cleared, just reboot pfSense (GUI or console command) onces more.My update/upgrade check list :
First : if you made any special changes to your system, document them all. Use for example the pfSense Notes packages, as this info will get stored in the config file, so it will be in your backup.
Before you update/upgrade, go to the console or GUI, and restart the system.
It would be perfect if you could use the console access (not SSH) and log this reboot process.
Scan that log for any potentiel issue. This will be the perfect moment you'll your disk is full - or in bas shape (disk always die)
Let your system running for a while, and test any functionality that you depend on.
Then use the same console access (or SSH) to do the upgrade. If possible, have this logged to disk on your device. If an issue shows up, you have a trace. If you have trace, you can copy past here exactly what happens, so we see the exact issue, so fast answer are possible.Me writing all this took probably more time as you doing all this.
Getting experiences in learning all this isn't lost time. The day a re install really counts, and it has to be done fast (as always), you know the drill.
This was previously known as 'learning'.Using a plan and prepare well with reverse the Murphy's law : all your good preparation will be for nothing as everybody goes smooth.
-
IGMP:
It seems the IGMP block logging issue is still up.
Even if it set any-any pass rule, and every logging is turned off.
Is it possible to fix this in a later version?OpenVPN:
What is the highest supported version of the OpenVPN Community Edition (V2) client for 2.8.1 CE from these links below?
Last time I tested it did not work above 2.5.9.https://community.openvpn.net/ReleaseHistory
https://build.openvpn.net/downloads/releases/
-
@Viktor.V re IGMP, I have excellent news for you :)
https://redmine.pfsense.org/issues/16068Also if you just need to ignore them you can do that without allowing it.
-
Thank you!
Yes, I figured out how to "pass" the IGMP without logging blocked.
Adding a destination rule with "multicast4" and "Allow IP options" checked.
This is a widespread issue, and having to manually add rules to stop IGMP packets from being logged is a workaround but not a solution.If I am understanding well, these will be the new rule sets for IGMP in the future version 2.9.0?
Feature #16110: Automatically check
Allow IP optionswhen IGMP is selected Resolved
Feature #16215: Allow floating rules using the "match" action to match based on IP OptionsBut I am using Interface and Group rules instead of Floating rules with IGMP, because an IGMP Floating rule can create other type of packets in the same rule, if you do not create TCP and/or UPD Floating rules as well, which is not the most convinient to see in one specific rule.