Take a look at this box from Netgate themselves. It was originally announced as the SG-2340, but they wound up having issues with the HDMI port when trying to plug in a monitor after it's already running so it's no longer an official pfSense box.

I'm using the quadcore version on gigabit wan (along with a few vlans on the lan side) and CPU never goes above 20%.

You don't really say what your requirements are as far as speeds, vpn, other services.

I've been using a few of these for projects. Great little boxes.

Minnowboard Turbot Dual-E (formerly known as SG-2300 series) comes in two flavors:

$249 dual core: https://www.amazon.com/Firewall-Appliance-Gigabit-MinnowBoard-Turbot/dp/B071XNG1BZ

$349 quad core: https://www.amazon.com/Firewall-Appliance-Gigabit-MinnowBoard-Turbot/dp/B0722JRVCH

Goodness an i3 or i5 would be overkill. Not sure why you would limit to Skylake or later as well.

The SG-3100 would handle his connection just fine. That said, he could also grab one of the Minnowboard Turbots off of Amazon as well.

If he wants to build it himself, he could use any of the C2000 series Atom processors as well. While it would be consume significantly more power, a Pentium G4560 would be even more powerful (though you may want to pair it with an external NIC).

First, if you're running hardware that is capable of running AES-NI instructions (or another hw offload), why are you concerned with the AES-NI (or, again, another offload), requirement of pfSense version 2.5, which I've said many times won't be out for years (and that 2.4 will be supported for at least a year after 2.5-RELEASE)?

> If you don't mind my asking, how do you figure?

The paper my blog post references is "Cache-timing Attacks on AES"

Your claim, "The problem is the paper your blog posts references has been reviewed by the OpenSSL community and found not to be an issue with their software solutions." is not substantiated.

The papers referenced in that blog post are:
"Key Recovery Attacks of Practical Complexity on AES Variants With Up To 10 Rounds"

"Cache-timing attacks on AES" (same title, different authors, from 2005, not 2013)

"Wait a minute! A fast, Cross-VM attack on AES"

"Fine grain Cross-VM Attacks on Xen and VMware are possible!"

None of these are the paper I referenced.

In particular, your attention is draw to the fact that the authors of the paper I cite were using OpenSSL, and, to put a sharp point on things, you are invited to read the paper, paying particular attention to the last two paragraphs of section 7, which I will quote here in full:

-----

In order to verify the effectiveness of AES-NI to against cache timing attack, we tried to disable the AES-NI in Intel Core i5 by clearing some of the bits of the runtime environment variable OPENSSL_ia32cap, with a command that disables the use of AES-NI, PCLMULQDQ, and SSE3 optimizations for x86-64:

OPENSSL_ia32cap=~0x200000200000000

After we ran the test again, one line of the correlation result showed less than 256 possibilities, specifically 16 (as shown Table 3). Although it is only one line, it still proves that after we disabled the AES-NI, the processor became vulnerable to the cache-timing attack.

---

Now, it's clear that by disabling SSE3, they've also disabled the VPAES and BSAES implementations. What we're left with is the speed of those implementations on an otherwise limited platform, such as today's Atom CPUs.

Here are the timings on my 4860 (running 2.4-beta), so you can verify:

AES-NI & SSE3 'on' (but AES-NI 'wins)

$ openssl speed -evp aes-128-gcm
Doing aes-128-gcm for 3s on 16 size blocks: 21030166 aes-128-gcm's in 3.00s
Doing aes-128-gcm for 3s on 64 size blocks: 11297251 aes-128-gcm's in 3.16s
Doing aes-128-gcm for 3s on 256 size blocks: 3739058 aes-128-gcm's in 3.00s
Doing aes-128-gcm for 3s on 1024 size blocks: 1059494 aes-128-gcm's in 3.03s
Doing aes-128-gcm for 3s on 8192 size blocks: 134865 aes-128-gcm's in 3.00s
OpenSSL 1.0.2k-freebsd 26 Jan 2017
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 112160.89k 229076.93k 319066.28k 357912.36k 368271.36k

AES-NI & SSE3 'off'

$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -evp aes-128-gcm
Doing aes-128-gcm for 3s on 16 size blocks: 5147119 aes-128-gcm's in 3.05s
Doing aes-128-gcm for 3s on 64 size blocks: 1580615 aes-128-gcm's in 3.01s
Doing aes-128-gcm for 3s on 256 size blocks: 1037022 aes-128-gcm's in 3.05s
Doing aes-128-gcm for 3s on 1024 size blocks: 278781 aes-128-gcm's in 3.00s
Doing aes-128-gcm for 3s on 8192 size blocks: 35880 aes-128-gcm's in 3.03s
OpenSSL 1.0.2k-freebsd 26 Jan 2017
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 27028.97k 33632.20k 87131.12k 95157.25k 96966.25k

AES-NI off, SSE3 'on', so bit-sliced:

$ OPENSSL_ia32cap="~0x200000000000000" openssl speed -evp aes-128-gcm
Doing aes-128-gcm for 3s on 16 size blocks: 6227190 aes-128-gcm's in 3.03s
Doing aes-128-gcm for 3s on 64 size blocks: 1846954 aes-128-gcm's in 3.04s
Doing aes-128-gcm for 3s on 256 size blocks: 1527407 aes-128-gcm's in 3.02s
Doing aes-128-gcm for 3s on 1024 size blocks: 438555 aes-128-gcm's in 3.09s
Doing aes-128-gcm for 3s on 8192 size blocks: 56102 aes-128-gcm's in 3.09s
OpenSSL 1.0.2k-freebsd 26 Jan 2017
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 32869.29k 38895.24k 129328.35k 145157.28k 148929.65k

But wait, there's more. What about those precious Protectli boxes that you seem so willing to castigate me about, how well do they run OpenSSL?

Frankly, they suck at it.

Pic posted so there is no doubt that I'm testing a Protectli box (which the box said was barebones, but shure 'nuff, it came with pfSense 2.3.4 on it.)

Protectli running openssl speed -evp aes-128-gcm

And, so people don't have to transcribe this themselves (note that I redirected the output to a file):

openssl speed -evp aes-128-gcm > /tmp/y 2>&1

Doing aes-128-gcm for 3s on 16 size blocks: 5716071 aes-128-gcm's in 3.02s<br />
Doing aes-128-gcm for 3s on 64 size blocks: 1615150 aes-128-gcm's in 3.00s<br />
Doing aes-128-gcm for 3s on 256 size blocks: 1152054 aes-128-gcm's in 3.01s<br />
Doing aes-128-gcm for 3s on 1024 size blocks: 319423 aes-128-gcm's in 3.00s<br />
Doing aes-128-gcm for 3s on 8192 size blocks: 41082 aes-128-gcm's in 3.00s<br />
OpenSSL 1.0.1s-freebsd  1 Mar 2016<br />
built on: date not available<br />
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)<br />
compiler: clang<br />
The 'numbers' are in 1000s of bytes per second processed.<br />
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes<br />
aes-128-gcm      30249.39k    34456.53k    98053.26k   109029.72k   112181.25k<br />

Take a look, I didn't disable anything. As I've pointedly said before, the bit-sliced implementations are s-l-o-w. To refresh your memory, again, here is what I said:

With AES you either design, test, and verify a bitslice software implementation, (giving up a lot of performance in the process), leverage hardware offloads, or leave the resulting system open to several known attacks. We have selected the “leverage hardware offloads” path. The other two options are either unthinkable, or involve a lot of effort for diminishing returns.

Without a hw offload (like AES-NI), the GUI in pfSense 2.5 is just going to be too slow on these platforms.

As for this (your words):

> There is a second far more obvious answer however, economics. Netgate hardware all supports AES-NI, lots of hardware people use for pfSense today doesn't. Lots of hardware shipped by competitors do not support AES-NI. It's a perfect product differentiation, and they can leverage their control over the software stack to give their hardware offerings an advantage.

First, you don't think this is you being a dick? I do. With that out of the way, let me refute your baseless bullshit.

Most of our "competitors" (and by that, I'm going to assume you mean companies that ship pfSense CE on hardware that doesn't come from Netgate) actually do have hardware that supports AES-NI.

• Everyone who ships the PC Engines APU/APU2 ships hardware that supports AES-NI.
  
• Deciso (the company behind OPNsense) and their resellers who sell the "Netboard A10" with pfSense pre-loaded ship hardware that supports AES-NI
  
• Companies that resell Lanner, Axiomtek, Portwell, etc with pfSense CE pre-loaded may or may not have a problem.
  
  I could go on, but the point is made. I must conclude that you refer to resellers of the Qotom (and similar) boxes. We've just shown that these suck so badly at crypto that they're all but useless for 2.5. The Ethernet controllers, 4 82583Vs, are awful. No RSS queues, so with pfSense, that quad core CPU (oh, baby) is never going to get used.
  
  Frankly, if I wanted to engage in economic war with Protectli and their ilk, I'd not do it by announcing a change that won't impact anyone with a Qotom box until, at the earliest, 2019. Instead, I'd do it by offering a low-margin product in their channel.
  
  Oh wait, I just did. The MinnowBoard Dual Ethernet units just started selling on Amazon!
  
  https://www.amazon.com/gp/product/B071XNG1BZ/ref=s9_acsd_hps_bw_c_x_3_w
  
  And, BTW, these support AES-NI. The quad core one is literally my low-end target for "3.0". And, hey now, I speced the QC unit to have i210s, with (hey, look!) 4 RSS queues each for tx/rx. The dual-core "Turbot Dual-E" has i211s, because it reduced cost a tiny bit, and having more RSS queues than cores isn't advancing the ball.
  
  I'll post some throughput numbers at a later date, but... let's just say "10X" for now. My goal is to get the QC Turbot Dual-E to 1Gbps IPsec, and much faster routing performance than even netmap-fwd can achieve on the same hardware.
  
  And finally:
  
  > [...] I am not exactly trusting you right now not to take some kind of retaliatory action.
  
  Against a customer? Very, very unlikely.