CPU to Saturate 150mbit up and down simultaneously via VPN?

whosmatt

I also have to admit I am VERY impressed with this little chip.

I haven't installed pfSense yet, but I am doing some testing in Ubuntu 16.10.

Using the PicoPSU-80 and 60W power brick kit from Mini-Box.com I'm idling on the desktop pulling only 7.1W from the wall (as measured on my Kill-A-Watt).

That's about the same power as my PcEngines low power Quad Core Jaguar at idle.

When I load up the chip with mprime (linux version of Prime95) it peaks at about 46W at the wall.

And that's at 3.9Ghz 2C/4T.

Even the stock Intel cooler (which just BARELY fit inside the M350 case once the drive brackets were removed) doesn't spin up much during load testing.

Very impressed.

The ASRock H270M-ITX/ac is also a great little Mini-ITX board with dual Intel NIC's to pair with it.

Wow. That's really good to know. Yeah, those M350 cases are tiny, but they kind of stand alone in the market, and are perfect for a mini ITX pfSense system provided your NICs are onboard. I have one but it's for a MythTV frontend. Thanks for the info.

mattlach

@whosmatt:

@mattlach:

I also have to admit I am VERY impressed with this little chip.

I haven't installed pfSense yet, but I am doing some testing in Ubuntu 16.10.

Using the PicoPSU-80 and 60W power brick kit from Mini-Box.com I'm idling on the desktop pulling only 7.1W from the wall (as measured on my Kill-A-Watt).

That's about the same power as my PcEngines low power Quad Core Jaguar at idle.

When I load up the chip with mprime (linux version of Prime95) it peaks at about 46W at the wall.

And that's at 3.9Ghz 2C/4T.

Even the stock Intel cooler (which just BARELY fit inside the M350 case once the drive brackets were removed) doesn't spin up much during load testing.

Very impressed.

The ASRock H270M-ITX/ac is also a great little Mini-ITX board with dual Intel NIC's to pair with it.

Wow. That's really good to know. Yeah, those M350 cases are tiny, but they kind of stand alone in the market, and are perfect for a mini ITX pfSense system provided your NICs are onboard. I have one but it's for a MythTV frontend. Thanks for the info.

Any time!

And it gets better. I killed Xorg and the idle wattage measured at the wall went down to 6.2W!

Full specs if anyone else is interested (links to where I bought them, you may find better prices elsewhere):

Intel Core i3-7100 ($119.96 w. Prime)
ASRock H270M-ITX/ac Mini-ITX motherboard with dual Intel NIC's ($96.98)
Crucial 8GB (2x4GB) DDR4-2133 kit ($55.49 w. Prime)
BiWin 60GB M.2 Sata SSD ($40.98)
PicoPSU-80 + 60W Adapter Power Kit ($35)
M350 Universal Mini-ITX enclosure ($39.95)
Molex to P4 power adapter ($4.95)

And that's it. Total: 393.31 (less for me, since I already had a few of the parts left over from other projects.

The CPU comes with a cooler. Before you assemble everything, it looks like it won't fit in the M350 enclosure, but it does (just barely), as long as you don't use the 2.5" drive brackets. (use an M2, USB drive or SATA DOM)

I also pulled out the mini-Wlan card (you loosen two screws on the bottom of the board and it comes right out). I wasn't using it, and I figured I'd rather not have it wasting power. Also disabled everything in BIOS I wasnt planning on using, and enabled all power saving states, except suspend to RAM, as the router needs to be operating 24/7.

I used a fan profile on the board. The CPU puts out so little power that it seems to stay at the coolers minimum fan speed most of the time. Granted it is pretty cold in my basement right now.

(Warmer temps will result in higher fan speeds which will drive up power consumption noticeably. At this low power use the fans use a surprisingly large percentage of the power)

I'm very happy thus far.

Just stay away from the USB3 ports. pfSense doesn't seem to like those at all, and the installers will fail unless booted from one of the USB2 ports.

mattlach

So,

After installing pfSense, my power use at idle went up a little bit to about 8W (compared to 6.2W in Ubuntu).

Part of this may be due to my "Hidaptive" power setting, or maybe BSD 10.3 isnt quite as good at power management as Ubuntu is at this point.

Either way, still good results.

Here are some comparative openSSL numbers,

First the PcEngines APU2C4:


[2.3.1-RELEASE][root@pfSense.localdomain]/root: openssl speed -elapsed -evp aes-128-ecb
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-ecb for 3s on 16 size blocks: 23413097 aes-128-ecb's in 3.00s
Doing aes-128-ecb for 3s on 64 size blocks: 18438085 aes-128-ecb's in 3.00s
Doing aes-128-ecb for 3s on 256 size blocks: 7473361 aes-128-ecb's in 3.00s
Doing aes-128-ecb for 3s on 1024 size blocks: 2115520 aes-128-ecb's in 3.01s
Doing aes-128-ecb for 3s on 8192 size blocks: 279464 aes-128-ecb's in 3.00s
OpenSSL 1.0.1s-freebsd  1 Mar 2016
built on: date not available
options:bn(64,64) rc4(8x,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-ecb     124869.85k   393345.81k   637726.81k   720221.92k   763123.03k

Now the i3-7100:

[2.3.3-RELEASE][admin@router.localdomain]/var/log: openssl speed -elapsed -evp aes-128-ecb
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-ecb for 3s on 16 size blocks: 242729953 aes-128-ecb's in 3.00s
Doing aes-128-ecb for 3s on 64 size blocks: 207367303 aes-128-ecb's in 3.01s
Doing aes-128-ecb for 3s on 256 size blocks: 69510589 aes-128-ecb's in 3.00s
Doing aes-128-ecb for 3s on 1024 size blocks: 17831161 aes-128-ecb's in 3.00s
Doing aes-128-ecb for 3s on 8192 size blocks: 2219499 aes-128-ecb's in 3.00s
OpenSSL 1.0.1s-freebsd  1 Mar 2016
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-ecb    1294559.75k  4412345.31k  5931570.26k  6086369.62k  6060711.94k

Looks like an average of about an order of magnitude improvement across the board.

Now if I could only get OpenVPN to work, I'd be happy.

mattlach

To follow up on this, I did some testing using this benchmark method suggested by Ira (note the time you want is the one with the U, I think)

My old APU2C4 - according to this test - is able to handle ~45Mbps in OpenVPN.

The i3-7100 using the same method appears to be able to handle ~425Mpbs

Since OpenVPN uses one thread per connection, the way I interpret this is that it can support up to 425Mbps per core.

Since - by necessity - up and down are on separate threads, and I have to cores, I could max it out at 425/425 at the same time.

mattlach

@pfBasic:

This is also encrypting at AES-256-CBC, which I also don't recommend. AES-128-GCM is more than enough for your privacy and significantly more efficient.

I have some questions regarding your statements about different ciphers.

1.) Are GCM ciphers even compatible with pfSense?

[2.3.3-RELEASE][admin@router.localdomain]/root: openvpn --show-ciphers
The following ciphers and cipher modes are available
for use with OpenVPN.  Each cipher shown below may be
used as a parameter to the --cipher option.  The default
key size is shown as well as whether or not it can be
changed with the --keysize directive.  Using a CBC mode
is recommended. In static key mode only CBC mode is allowed.

AES-128-CBC  (128 bit key, 128 bit block)
AES-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-192-CBC  (192 bit key, 128 bit block)
AES-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-256-CBC  (256 bit key, 128 bit block)
AES-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CBC  (128 bit key, 128 bit block)
CAMELLIA-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CBC  (192 bit key, 128 bit block)
CAMELLIA-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CBC  (256 bit key, 128 bit block)
CAMELLIA-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
SEED-CBC  (128 bit key, 128 bit block)
SEED-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
SEED-OFB  (128 bit key, 128 bit block, TLS client/server mode only)

The following ciphers have a block size of less than 128 bits, 
and are therefore deprecated.  Do not use unless you have to.

BF-CBC  (128 bit key by default, 64 bit block)
BF-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
BF-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
CAST5-CBC  (128 bit key by default, 64 bit block)
CAST5-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
CAST5-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
DES-CBC  (64 bit key, 64 bit block)
DES-CFB  (64 bit key, 64 bit block, TLS client/server mode only)
DES-CFB1  (64 bit key, 64 bit block, TLS client/server mode only)
DES-CFB8  (64 bit key, 64 bit block, TLS client/server mode only)
DES-EDE-CBC  (128 bit key, 64 bit block)
DES-EDE-CFB  (128 bit key, 64 bit block, TLS client/server mode only)
DES-EDE-OFB  (128 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CBC  (192 bit key, 64 bit block)
DES-EDE3-CFB  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CFB1  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CFB8  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-OFB  (192 bit key, 64 bit block, TLS client/server mode only)
DES-OFB  (64 bit key, 64 bit block, TLS client/server mode only)
DESX-CBC  (192 bit key, 64 bit block)
IDEA-CBC  (128 bit key, 64 bit block)
IDEA-CFB  (128 bit key, 64 bit block, TLS client/server mode only)
IDEA-OFB  (128 bit key, 64 bit block, TLS client/server mode only)
RC2-40-CBC  (40 bit key by default, 64 bit block)
RC2-64-CBC  (64 bit key by default, 64 bit block)
RC2-CBC  (128 bit key by default, 64 bit block)
RC2-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
RC2-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
RC5-CBC  (128 bit key by default, 64 bit block)
RC5-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
RC5-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)

I don't see any GCM modes in that list.

2.) I did some performance testing using the method suggested by Ira, and I found an almost negligible difference in performance between AES-256-CBC and AES-128-CBC. If that is the case, why not just use 256 bit as it is stronger?

Would appreciate your input.

pfBasic

AES-GCM is supported in 2.4, if you're interested you can use 2.4.0 BETA which I have had zero stability issues with for home use.

I couldn't tell you what is happening behind the scenes with AES-NI & OpenVPN between 128 bit and 256 bit encrypt/decrypt. And yes, there is often not a massive performance gain by switching from AES 256 to 128 CBC, but it is normally big enough to matter. https://forum.pfsense.org/index.php?topic=127793.msg705162#msg705162

CBC to GCM should be a significant jump.

While I like the benchmark that Ira put together, take it with a grain of salt for real world performance. I doubt that it works well across different architectures, different versions of AES-NI, different versions of AES. I can tell you that it is not correct for my i5-2400.

I can tell you that when I did real world testing (not by any means rigorous) on a J3355B switching from AES-256-CBC to AES-128-CBC (my VPN provider does not support GCM) and the difference was dramatic. https://forum.pfsense.org/index.php?topic=127793.msg705046#msg705046
That doesn't mean the same applies to your CPU though, but only real world tests can tell you that.

And saying that 256 bit encryption is better/more secure than 128 bit encryption is arguable.
As far as anyone knows AES-128 has no known vulnerabilities and is effectively uncrackable. The same is true of AES-256.
Most likely no one will ever attempt to decrypt your data at any encryption level. If they do, no one can brute force AES-128 so there's no known value of using stronger encryption.
If a (not third world) state level entity wants to hack you, they will and they won't care what encryption you are using. So don't bother trying.

A very rough analogue would be that if you want to protect your crystal ball collection during a bombing raid, keeping them in a 50' thick concrete bunker is more secure than keeping them in a 25' thick concrete bunker. Even the best crystal ball thieves only have hand grenades so they will effectively never penetrate the 25' bunker and those guys aren't even interested in your crystal balls.
But then the US Gov't has the GBU-57A/B, so if they ever feel like getting into your crystal ball collection they most certainly can :).

mattlach

@pfBasic:

AES-GCM is supported in 2.4, if you're interested you can use 2.4.0 BETA which I have had zero stability issues with for home use.

I couldn't tell you what is happening behind the scenes with AES-NI & OpenVPN between 128 bit and 256 bit encrypt/decrypt. And yes, there is often not a massive performance gain by switching from AES 256 to 128 CBC, but it is normally big enough to matter. https://forum.pfsense.org/index.php?topic=127793.msg705162#msg705162

CBC to GCM should be a significant jump.

While I like the benchmark that Ira put together, take it with a grain of salt for real world performance. I doubt that it works well across different architectures, different versions of AES-NI, different versions of AES. I can tell you that it is not correct for my i5-2400.

I can tell you that when I did real world testing (not by any means rigorous) on a J3355B switching from AES-256-CBC to AES-128-CBC (my VPN provider does not support GCM) and the difference was dramatic. https://forum.pfsense.org/index.php?topic=127793.msg705046#msg705046
That doesn't mean the same applies to your CPU though, but only real world tests can tell you that.

Thanks. I appreciate the input on that.

Do you know what about GCM it is that makes it so much faster? Is it a weaker cipher, or just more efficient somehow?

pfBasic

No, not really. The buzz words I've read say that it has better parallelization than CBC, but I don't really know what that means. It also includes the authentication portion of the VPN whereas CBC does not (it handles it with some level of SHA encryption).

I've never read anything that suggests its in any way weaker than CBC, in fact everything I've read suggests that it might be more secure. But that's probably more secure in a similar sense to my above analogy about bunkers and bombs.

There are definitely users on this board that could answer your question though.

VAMike

@mattlach:

Do you know what about GCM it is that makes it so much faster? Is it a weaker cipher, or just more efficient somehow?

It's stronger. By combining the encryption and authentication (instead of having, e.g., a separate SHA MAC) it can be more efficiently pipelined in the CPU. Intel also added the PCLMULQDQ instructions mainly to speed up GCM (so it gets an additional hardware assist on newer CPUs).

Pippin

To add to this, AES-256-GCM = AES-256-CTR and SHA256 combined.

VAMike

@Pippin:

To add to this, AES-256-GCM = AES-256-CTR and SHA256 combined.

N.b., there is zero reason to use AES-256 on your home VPN rather than AES-128.

psulions5

I ordered parts for a 7700K pfsense router. Probably a little overkill, but I wanted to future proof and honestly, that CPU isn't very expensive considering. Spent about 700 total, but should be decent. Got an intel quad NIC also.

pfBasic

@psulions5:

I ordered parts for a 7700K pfsense router. Probably a little overkill, but I wanted to future proof and honestly, that CPU isn't very expensive considering. Spent about 700 total, but should be decent. Got an intel quad NIC also.

Make sure you get a pair of GTX-1080Ti's in SLI to go with that, they can really be leveraged for outstanding IDS/IPS throughput.

And I'd suggest a pair of 1TB Samsung 960 PRO's in a ZFS mirror so it doesn't bottleneck your logs.

psulions5

I mean I could do that, but my gaming machine already has that :p

Pippin

@VAMike:

@Pippin:

To add to this, AES-256-GCM = AES-256-CTR and SHA256 combined.

N.b., there is zero reason to use AES-256 on your home VPN rather than AES-128.

There is not a lot done with "good reason" in this world…
Depends on needs and "craziness"... also in the home ;)

B.t.w., the default OpenVPN 2.4 or higher selects is AES-256-GCM, when both sides are on OpenVPN 2.4.
See --ncp in OpenVPN manual 2.4

VAMike

@Pippin:

B.t.w., the default OpenVPN 2.4 or higher selects is AES-256-GCM, when both sides are on OpenVPN 2.4.
See –ncp in OpenVPN manual 2.4

Defaults are made to be changed

meruem

@mattlach:

Just stay away from the USB3 ports. pfSense doesn't seem to like those at all, and the installers will fail unless booted from one of the USB2 ports.

From the mobo quick installation guide pdf page 3, "CAUTION: For operating system installation, be sure to plug your USB flash drive into the USB 2.0 Ports (USB12)."

mattlach

@mattlach:

@whosmatt:

@mattlach:

I also have to admit I am VERY impressed with this little chip.

I haven't installed pfSense yet, but I am doing some testing in Ubuntu 16.10.

Using the PicoPSU-80 and 60W power brick kit from Mini-Box.com I'm idling on the desktop pulling only 7.1W from the wall (as measured on my Kill-A-Watt).

That's about the same power as my PcEngines low power Quad Core Jaguar at idle.

When I load up the chip with mprime (linux version of Prime95) it peaks at about 46W at the wall.

And that's at 3.9Ghz 2C/4T.

Even the stock Intel cooler (which just BARELY fit inside the M350 case once the drive brackets were removed) doesn't spin up much during load testing.

Very impressed.

The ASRock H270M-ITX/ac is also a great little Mini-ITX board with dual Intel NIC's to pair with it.

Wow. That's really good to know. Yeah, those M350 cases are tiny, but they kind of stand alone in the market, and are perfect for a mini ITX pfSense system provided your NICs are onboard. I have one but it's for a MythTV frontend. Thanks for the info.

Any time!

And it gets better. I killed Xorg and the idle wattage measured at the wall went down to 6.2W!

Full specs if anyone else is interested (links to where I bought them, you may find better prices elsewhere):

Intel Core i3-7100 ($119.96 w. Prime)

ASRock H270M-ITX/ac Mini-ITX motherboard with dual Intel NIC's ($96.98)

Crucial 8GB (2x4GB) DDR4-2133 kit ($55.49 w. Prime)

BiWin 60GB M.2 Sata SSD ($40.98)

PicoPSU-80 + 60W Adapter Power Kit ($35)

M350 Universal Mini-ITX enclosure ($39.95)

Molex to P4 power adapter ($4.95)

And that's it. Total: 393.31 (less for me, since I already had a few of the parts left over from other projects.

The CPU comes with a cooler. Before you assemble everything, it looks like it won't fit in the M350 enclosure, but it does (just barely), as long as you don't use the 2.5" drive brackets. (use an M2, USB drive or SATA DOM)

I also pulled out the mini-Wlan card (you loosen two screws on the bottom of the board and it comes right out). I wasn't using it, and I figured I'd rather not have it wasting power. Also disabled everything in BIOS I wasnt planning on using, and enabled all power saving states, except suspend to RAM, as the router needs to be operating 24/7.

I used a fan profile on the board. The CPU puts out so little power that it seems to stay at the coolers minimum fan speed most of the time. Granted it is pretty cold in my basement right now.

(Warmer temps will result in higher fan speeds which will drive up power consumption noticeably. At this low power use the fans use a surprisingly large percentage of the power)

I'm very happy thus far.

Just stay away from the USB3 ports. pfSense doesn't seem to like those at all, and the installers will fail unless booted from one of the USB2 ports.

So I finally had time to get this working (a month and a half later), as I had trouble getting PIA VPN working the first time around.

Now that it is up and running I can definitely say that the i3-7100 is overkill by more than I expected.

@VAMike:

@Pippin:

To add to this, AES-256-GCM = AES-256-CTR and SHA256 combined.

N.b., there is zero reason to use AES-256 on your home VPN rather than AES-128.

I did wind up going with AES-256-CBC and SHA256 just because I could as my router is overkill, but honestly, I didn't notice much (any?) CPU load difference between the two, so might as well use the stronger one, even if it might not be necessary.

Anyway, with AES-256-CBC and SHA256, loading up the connection in one direction (it peaks at about 135Mbit, due to my traffic shaping rules) I only get about 9-10% load on the CPU. So, under a theoretical full load in both directions I ought to hit 18-20% somewhere.

I'm glad to have some room to grow should anything change, but this little i3-7100 has definitely outperformed my expectations.

whosmatt

@mattlach:

I did wind up going with AES-256-CBC and SHA256 just because I could as my router is overkill, but honestly, I didn't notice much (any?) CPU load difference between the two, so might as well use the stronger one, even if it might not be necessary.

I also use AES-256 and SHA256 on my PIA tunnels and have never noticed a tangible performance difference between the two. I'm still on AES-128 and SHA1 on my personal OpenVPN server, mostly because I set it up that way years ago and haven't felt the need to change. SHA1 is approaching deprecation anyhow as far as I'm aware. Anyway, thanks for the update.

mattlach

@mattlach:

I did wind up going with AES-256-CBC and SHA256 just because I could as my router is overkill, but honestly, I didn't notice much (any?) CPU load difference between the two, so might as well use the stronger one, even if it might not be necessary.

Anyway, with AES-256-CBC and SHA256, loading up the connection in one direction (it peaks at about 135Mbit, due to my traffic shaping rules) I only get about 9-10% load on the CPU. So, under a theoretical full load in both directions I ought to hit 18-20% somewhere.

I'm glad to have some room to grow should anything change, but this little i3-7100 has definitely outperformed my expectations.

@whosmatt:

I also use AES-256 and SHA256 on my PIA tunnels and have never noticed a tangible performance difference between the two. I'm still on AES-128 and SHA1 on my personal OpenVPN server, mostly because I set it up that way years ago and haven't felt the need to change. SHA1 is approaching deprecation anyhow as far as I'm aware. Anyway, thanks for the update.

I should follow up with the fact that since my initial tests (just speedtest.net) I have succeeded in getting the CPU load up much higher.

I was under the impression that OpenVPN CPU load was really just dependent on raw throughput, but that doesn't seem to be the case, More connections at the same bandwidth use more CPU it would seem.

Downloaded a new Ubuntu ISO today using rtorrent, which resulted in downstream maxed, and a little upstream. This was about 38% CPU on the router. Still very respectable, but I wanted to update you guys in case someone takes my earlier results too seriously.