Netgate U Turn: ‘AES-NI Not Required’

Soldato
Joined
29 Dec 2002
Posts
7,470
https://www.netgate.com/blog/pfsense-2-5-0-development-snapshots-now-available.html

Not sure how I missed this, but Netgate sneaked this little gem on the bottom of the 2.5 dev snapshot announcement.

AES-NI Not Required
The original plan was to include a RESTCONF API in pfSense 2.5.0, which for security reasons would have required hardware AES-NI or equivalent support. Plans have since changed, and pfSense 2.5.0 does not contain the planned RESTCONF API, thus pfSense 2.5.0 will not require AES-NI.

Yep, that R210-II I pimped up with iDRAC Enterprise, SSD and a Xeon 1270 suddenly looks like a less than great investment compared to virtualising the whole lot (at leat till i need to reboot the host). The NetHate is strong at present!
 
https://www.netgate.com/blog/pfsense-2-5-0-development-snapshots-now-available.html

Not sure how I missed this, but Netgate sneaked this little gem on the bottom of the 2.5 dev snapshot announcement.

Indeed. There's been quite a lot of disquiet on the /r/pfsense subreddit about it, especially from those who went out and replaced banks of hardware based on the upcoming 'requirement'. The behaviour of the owner/lead dev and his recent attitudes towards users/customers, and the OPNsense project (again), has also raised hackles. It's all a bit silly really. I've been running Linux on my router the last six months (ish?), as I needed WireGuard and *sense doesn't have it yet (there's a dev plugin for OPNsense but it's crashy due to an upstream bug in FreeBSD with WireGuard on UFS, which the *sense distros both use). Given the current drama/nonsense, I'm pretty glad.
 
It's generally the people whinging the loudest about it whose involvement with pfSense extends as far as using it as an alternative to a more expensive firewall (either commercially or time cost of learning a new platform). If you went and preemptively bought new hardware for unreleased software and are upset that the features that require it are going to arrive maybe eight months later then you thought, then suck it up tbh.
 
Indeed. There's been quite a lot of disquiet on the /r/pfsense subreddit about it, especially from those who went out and replaced banks of hardware based on the upcoming 'requirement'. The behaviour of the owner/lead dev and his recent attitudes towards users/customers, and the OPNsense project (again), has also raised hackles. It's all a bit silly really. I've been running Linux on my router the last six months (ish?), as I needed WireGuard and *sense doesn't have it yet (there's a dev plugin for OPNsense but it's crashy due to an upstream bug in FreeBSD with WireGuard on UFS, which the *sense distros both use). Given the current drama/nonsense, I'm pretty glad.

Yep, seen it, cringed at the posts from users and cringed really hard at some of the team/dev's comments. Pfsense want to be taken seriously as a credible alternative to commercial options by offering a commercial product/hardware/support. Unfortunately this has more in common with Dick on the Smoothwall mailing lists back in the day, except I often agreed with his pov as he was usually right.

It's generally the people whinging the loudest about it whose involvement with pfSense extends as far as using it as an alternative to a more expensive firewall (either commercially or time cost of learning a new platform). If you went and preemptively bought new hardware for unreleased software and are upset that the features that require it are going to arrive maybe eight months later then you thought, then suck it up tbh.

I'd 100% agree normally, why would anyone be dumb enough to speculatively buy hardware pre-release? Possibly because on multiple occasions it was officially stated that AES-NI was required for 2.5. Plans change, nothing wrong with that, but to bury the U turn at the bottom of the release notes is not good practice, to insult customers for pointing out they were mislead and tell them to ... off etc. just isn't right. In my case I use OpenVPN, AES-NI is basically required either way for anything like near line speed on g.fast.
 
I also made sure that I specified AES-NI compliant hardware for any new installs, because it was supposedly going to be a requirement. It didn’t actually add anything to my costs as I always sourced the Netgate appliance hardware (it all supports AES-NI) and the real shocker for me was the way people were treated when they complained.
 
It’s one thing to say ‘Due to a security issue identified during the early 2.5 development, we chose not to implement the AES-NI requirement at this time, we will however look to include it in 2.6, so if upgrading/deploying new hardware please consider AES-NI compatibility.’ and another to say ‘.... off to Cisco’ or any of the other statements made.
 
Back
Top Bottom