PfSense 2.5 will only work with AES-NI capable CPUs
-
The Devs have indicated that there are other reasons for this new requirement. And it's not about VPNS etc. I think in the long term users will appreciate all the effort that pfSense is implementing to make this a solid and secure platform. Please keep the pitchforks at home. ;)
-
I just happened to pop up on the forum to see what's up since my current j1900 celeron based "overkill" rig is running nicely. This really, really surprised me. People told me it was too much power, but now I'm lacking features of higher end cpus. LOL. I guess I can throw an old i5 3570k I have laying around at the issue & undervolt it. ::) No money out of pocket for me, but for most people, I totally understand the frustration.
-
I don't get the pullback.
I'm excited for this.
-
What is the predicted release date for 2.5? I bet all your shoeboxes that can't do AES-NI will be obsolete anyway by that time.
-
So our 5 PC Engines APU with the AMD G-T40E will become nice expensive paper weights? Well played, Netgate, well played, for trying to boost your own hardware sales.
Netgate is not the only vendor selling hardware with AES-NI.
-
@kpa:
What is the predicted release date for 2.5? I bet all your shoeboxes that can't do AES-NI will be obsolete anyway by that time.
2.5 will release in probably over a year. Depends when FreeBSD 12 is released. After pfSense 2.5 is released we will support 2.4 for about a year.
-
Funny english language. I wrote:
I bet all your shoeboxes that can't do AES-NI will be obsolete anyway by that time.
I meant that hardware that doesn't have an AES-NI capable CPU by the time 2.5 is released is likely to be obsolete at the time.
-
@kpa:
Funny english language. I wrote:
I bet all your shoeboxes that can't do AES-NI will be obsolete anyway by that time.
I meant that hardware that doesn't have an AES-NI capable CPU by the time 2.5 is released is likely to be obsolete at the time.
Oh yes, sorry. I will edit that part ;)
-
So when AES-NI is found to be a defective all users will be affected, instead of a subset of users.
Look at Intel ME experience for example. Is that what were going for? All racked servers affected.
Homogeneity is bad for security.
-
So when AES-NI is found to be a defective all users will be affected, instead of a subset of users.
Look at Intel ME experience for example. Is that what were going for? All racked servers affected.
Homogeneity is bad for security.
https://en.wikipedia.org/wiki/AES_instruction_set
-
After all I had read, OPNsense is not really an alternative if you want honest software developed by trustworthy people,
I think you need to chill. You're welcome to use any kind of software you want, but don't claim we are dishonest or not trustworthy.
There's a "not" in my sentence, and I stand by it. So yes, I do think pfSense is better than it's fork (at least as of <2.5).
On another note though, proclaiming 2 year old hardware obsolete in 1 years time - not my cup of tea. I have servers here that are more than 5 years old and there is no need to replace them. I don't see any reason to replace our APUs which are running our AES256 OpenVPN traffic just fine without hardware acceleration at less than 10% load only because suddenly AES-NI becomes a requirement.
Stefan
-
Push the AES-NI requirement to pfSense 3.0 roadmap.
Lots of people here have re-purposed older hardware which they have under-volted and under-clocked with the plan to dial it up as needs arise..
Dropping 32-bit support recently was understandable but this is ludicrous!
-
@thehammer86:
Push the AES-NI requirement to pfSense 3.0 roadmap.
Lots of people here have re-purposed older hardware which they have under-volted and under-clocked with the plan to dial it up as needs arise..
Dropping 32-bit support recently was understandable but this is ludicrous!
Is it? Or is it ludicrous to be running any internet facing hardware that is 6 years after EOL. Is it not common knowledge that most hardware is designed with planned obsolescence? This isn't a slap in the face to anyone IMO.
-
After all I had read, OPNsense is not really an alternative if you want honest software developed by trustworthy people,
I think you need to chill. You're welcome to use any kind of software you want, but don't claim we are dishonest or not trustworthy.
There's a "not" in my sentence, and I stand by it. So yes, I do think pfSense is better than it's fork (at least as of <2.5).
On another note though, proclaiming 2 year old hardware obsolete in 1 years time - not my cup of tea. I have servers here that are more than 5 years old and there is no need to replace them. I don't see any reason to replace our APUs which are running our AES256 OpenVPN traffic just fine without hardware acceleration at less than 10% load only because suddenly AES-NI becomes a requirement.
Stefan
Now I feel stupid. I am sorry as I have misread your initial comment. I have fixed it. Please note that we will be supporting pfSense 2.4 for around a year once 2.5 is out. 2.5 won't be out for over a year (really depends from FreeBSD 12 release date).
-
Come on, just because a new version is out sometime in the future it doesn't mean the version you currently run (or that will be released in the foreseeable future, aka 2.3.4) is rendered useless.
Same with 32bit hardware and v2.4 in the future. Just keep using 2.3.x on that.The goal of each and every pfSense installation I have out there is to do its job. And it does exactly that, otherwise I would have chosen a different solution. That won't change with a new release.
My job is not to update all systems just because a new version is available. Is yours?Only if you want to run the latest version with all new bells and whistles you'll need moderatly new hardware for that. So what?
This discussion reminds me of a crying kid whom you've taken away the favorite toy. With the exception that it is only an announcement due in 12+ months to get you prepared (with a new toy).
So you're mourning a year or so in advance. Really? -
I have pfSense running in SOHO environment using ATOM (Cedarview), with VPN, and no resource constraints
whatsoeverunder light to moderate load. I've recommended the platform to others who've used it for ICS, and through AWS. I won't be able to, in good conscience, recommend the product with these restrictions. I won't be upgrading my hardware. I find AES-NI requirement more of a security weakness than enhancement, and will likely begin going with plain old *BSD.Bullrun aside, a 7 year old critical remote exploit was just disclosed in Intel's AMT. The CVE was published today: https://nvd.nist.gov/vuln/detail/CVE-2017-5689
You guys chose a hell of a week to announce a baked in Intel requirement!
-
Some additional info:
https://www.reddit.com/r/PFSENSE/comments/68nd6y/pfsense_25_and_aesni/dh0qi53/ -
Now I feel stupid. I am sorry as I have misread your initial comment. I have fixed it. Please note that we will be supporting pfSense 2.4 for around a year once 2.5 is out. 2.5 won't be out for over a year (really depends from FreeBSD 12 release date).
Actually, if this ~2 year timeline on 2.4 viability is even close, this announcement should be very well taken by everyone. 24 months is a professional notice time period.
Maybe some could use to think about this for a moment before jumping in and venting in a negative manner.
-
Wow, that (full) reddit post kind of threw me of my chair ::)
Amazed by the anger/frustration. If they put equal effort in coding as they do in trying to clarifying their motivations, hats off…
Interesting read of Gonzo's post though, that's probably the best part (for me) as I learned new things.So I just got an actual legit reason to go looking for a new home router in the near future -> life is good ;D
-
@thehammer86:
Push the AES-NI requirement to pfSense 3.0 roadmap.
Lots of people here have re-purposed older hardware which they have under-volted and under-clocked with the plan to dial it up as needs arise..
Dropping 32-bit support recently was understandable but this is ludicrous!
Is it? Or is it ludicrous to be running any internet facing hardware that is 6 years after EOL.
The first one.
