Added a bug ticket for this issue, as there definitely is something to it. https://redmine.pfsense.org/issues/6589

FWIW, I have been using Samsung SSDs with TRIM enabled (mSata drives specifically) with Centos and Debian Linux for 3+ years on high-use production equipment with no problems. If I remember correctly, there was a specific firmware version that potentially corrupted Sammy drives when TRIM was enabled under Linux and specific kernels, I was never bitten by this, but know others who were. If you are not writing and deleting a bunch of data on the drive over and over enabling TRIM is an arguable benefit, and in my specific use case for pfSense, it is only my OCD that makes me enable it, I use a ram disk and offload all the logging to a remote syslog server which keeps the amount of disk writes/rewrites to a minimum. And no… BSD is not Linux.

That's expected, Unity is most often undesirable and it being enabled by default caused problems more than it helped. There isn't a sure-fire way to determine post-upgrade whether people are relying on it. Now that you have it enabled, it'll stay that way.

The "/usr/local/pkg/haproxy.inc" file is old and should be removed. That should avoid the php error you write above.. That shouldn't affect OpenVPN though..

Haha ok then I came to a totally wrong conclusion  ;D You are right I did select a server the second time! So it has nothing to do with stopping services.

I re-read my reply and it sort of sounds like a rant and that was not the intent.  It's just that this is a somewhat frequent complaint/request that I have answered a number of times. If you consider that the vast majority of actual malicious attacks from the Internet are going to be using the equivalent of "throw away" IP addresses, then maintaining say 100,000 or more previously blocked IP addresses won't be very productive.  The attacker will abandon one and just switch to some other IP address to spoof.  So that attack yesterday from one address is likely to come from a new and different one today.  So why burden your firewall with storing thousands and thousands of old blocked IPs?  Also, what if this month 100 of the ones you blocked last month are now in use by legitimate web sites/users that mysteriously can't reach your system because of the block from last month? If Snort (or Suricata) was smart enough to catch the attack and block it today from IP address 1.2.3.4, then why would you think it can't detect and block the same attack tomorrow from IP address 1.2.3.4?  Why should it keep a running list of previous blocks?  And so long as you don't reboot the firewall (and if you have the Clear Blocked Hosts parameter set to Never), then the IP will stay in the snort2c table and remain blocked until a reboot.  However, I don't recommend folks run Snort that way.  You want the blocked hosts to clear out on a fairly frequent basis.  I personally have mine set to one hour.  What if the block was just a false positive?  Would you want the false positive to stay blocked forever?  Likely not.  So I recommend choosing a reasonably short interval for the Clear Blocked Hosts parameter, but not Never. Bill

here's something weird, .. so i started to look into this dns thing, and what i found out was it was because the dns server didnd't work that dpinger settled down, .. i recently changed the first dns server to 172.16.1.10 which apparently didn't respond to everything except the firewall, probably some gateway issue, however but since it didn't respond, cpu usage went down!?

This seems odd as it sees bge0_vlan8 in the config. I suspect a buggy igmpproxy as it does not see the system interface. Fortunately there is a new home for igmpproxy with a lot of patches included: https://github.com/pali/igmpproxy/tree/next Unfortunately I have no dev environment for FreeBSD where I could try to compile it myself.

When the interface comes up, it goes through the same process as a dynamic gateway, it doesn't matter that it's static. The fact it's logging those things just means it's checking whether anything needs to be done. Yes you can bind a dyndns update to a gif tunnel if you want, you must not, so it just checked and did nothing.

is anybody have an idea ?

Just wanted to post an update on this. The dhcpv6 process started on its own after a power outage during the time I was on vacation and worked until there was maintenance done by the ISP last night causing PPPoE to go down again. I have now changed the two instance of pppoe and updated them to pppoe0. Then rebooted and everything came up fine, upgraded to the latest snapshot and it is working right now. I will leave it for the night to ensure it is stable and will try disconnecting the modem a couple of times to see if I can simulate what has been happening or confirm that the interface name change has fixed it. Thanks, Robbert

That was deprecated a while back and not removed from the description. Fixed, thanks.

Worked like a charmed. :) Thanks!

@laurpaum: If running suricata in inline mode, you have to disable hardware offloading. See https://forum.pfsense.org/index.php?topic=108068.msg601891 Laurent Yeah I just got hit by the bug probably a minute after you replied to my initial post - disabled now! Hope this is just temporary. -Justin