11–20 of 90 posts
Sounds like a move to sell more hardware. My pfsense barely does any crypto. This will push me over to openbsd.
Indeed, AES-NI is very rare. Few computers if any have it. Edit: /s ... ?!
With AES-NI: http://ark.intel.com/Search/FeatureFilter?productType=proces...
Without: http://ark.intel.com/Search/FeatureFilter?productType=proces...
Sounds like a move to sell more hardware. My pfsense barely does any crypto. This will push me over to openbsd.
Indeed, AES-NI is very rare. Few computers if any have it. Edit: /s ... ?!
Why are you surprised? If you are trying to make a point that AES-NI is common, just say so. Trying to do so by saying the opposite and expecting people will pick up on the sarcasm through a pure text medium without necessarily sharing the same knowledge to know whether that statement is true or not just adds confusion to the conversation.
The point itself is useful, but the manner in which you expressed it emphasizes the delivery over the content, to the degree the content is sometimes obscured.
If I had to guess, I'd say Netgate is working on an SD-WAN service of sorts. Many players in this market are displacing the edge firewall, and offering a built-in service of their own or in partnership with a third-party might be a smart move.
What if we just added and SD-WAN implementation to pfSense?
Both are smart strategies and well within your core competency. As long as you're not building your own SD-WAN service you're golden.
TL, DR: If you are building a pfSense box with an x86 chip made in the past ~7 years [1], stop reading and carry on. Those of you on a power budget, and want e.g. VPN support at closer to wire speeds, you're being advised to select a CPU with AES-NI to get hardware crypto offload. It's great we have software crypto in the first place, but under load it's likely to put a cap on your max throughput. Kudos to pfSense/Ne…
Intel started in 2010 with Westmere, but kept it out of the lower-end models like Pentium, Celeron, and i3 for several generations. Only since Skylake (2015) is it included in every model produced from a supporting architecture. At least for Intel processors, the generalization above, absent other disclaimers, does not apply.
Actual lookup tables are linked in other posts like this one [1].
TL, DR: If you are building a pfSense box with an x86 chip made in the past ~7 years [1], stop reading and carry on. Those of you on a power budget, and want e.g. VPN support at closer to wire speeds, you're being advised to select a CPU with AES-NI to get hardware crypto offload. It's great we have software crypto in the first place, but under load it's likely to put a cap on your max throughput. Kudos to pfSense/Ne…
https://www.newegg.com/Product/Product.aspx?Item=N82E1681911...
Do newer, but still cheap CPU's work with AES-NI?
Sounds like a move to sell more hardware. My pfsense barely does any crypto. This will push me over to openbsd.
If this was a move to sell more hardware, why wouldn't we make the decision for 2.4 (which is imminent) rather than 2.5, which is based on FreeBSD 12, when 12.0R isn't even scheduled?
Hints:
1) The post implies this restriction will only be for the community (free) edition. "pfSense Community Edition version 2.5 will include a requirement that the CPU supports AES-NI"
2) There is zero reason to require AES-NI, as running with a software fallback will simply yield lower performance. Taking this option away makes no sense unless you want to encourage those who don't pay for software support to buy your hardware, while those already paying for support are free to use their existing gear.