PfSense hardware for home router - OpenVPN performance

Dalsland

Here is my benchmark for

Intel J1900 Quad Core 4x2GHz
Network 4*Intel WG82583
Eglobal Fanless Mini PC

[2.3.2-RELEASE][admin@pfSense.localdomain]/root: time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc
30.309u 0.023s 0:30.35 99.9%    742+177k 0+0io 0pf+0w

30s = 106 Mbps according to the calculation.

"Real world" performance:
I have a 100/100 connection

No VPN

VPN

mauroman33

@spon901:

No, was the same OS . I did not change anything. Just test directly and the immediately run same test through openvpn. The again run same test directly just to be sure. The results are :

Directly 300/150, through vpn 32/43.

Don't you have doubt that it could be related to your VPN provider?

spon901

Both i5 laptop and RK3288 box are in my location connected through a gigabit network. There is no VPN provider involved, only normal ISP that provide connection with 300Mbit/150Mbit. On laptop I have Windows 7 installed and on RK3288 Ubuntu 14.10. As I said the RK3288 act like a VLAN router and connected directly , on laptop I can successfully reach maximum speed provider offer (300/150). Now maing the same speed but through openvpn (I simulate laptop using openvpn client tried to conect to RK3288 openvpn server that connect to internet. In this case the speed was just 32/43. he issue here is not why the speed is so low. It maybe because RK3288 cannot do more (however this is also strange becasue is a capable processor having crypto hardware accelerated). The issue is why testing openvpn speed (and not openssl) gives a so big difference. And all those tests were repeated several times, just to be sure. The results were consistent. Is there any way to be sure that openvpn use hardware accelerated crypto or not. Because maybe this is the reason of so big difference.

mauroman33

Sorry mate, but I didn't understand how pfSense is involved in your test.

spon901

It is not yet. I intend to install it. ut what I wrote has nothing to do with pfsense, or to any operating system. It has to do with theoretical speed calculation cs real speed.

mauroman33

You should consider this thread is about the theoretical speed and the real speed obtained through a device running pfSense.

spon901

Ok, so on a non pFsense device there is no correlation between theoretical and real sped ?

VAMike

@spon901:

Ok, so on a non pFsense device there is no correlation between theoretical and real sped ?

The test is a heuristic, and it remains to be seen how accurate it is across a wide variety of machines. In this case I'd specifically wonder whether the abnormally large blocks used to pad the test runtime give wildly inaccurate results for off-board crypto processors. (On the RK3288, IIRC, the crypto is handled by a specific module, as in the old via padlock stuff, and those generally do much better for large blocks than small blocks because of a high fixed setup cost. On systems with onboard crypto like AES-NI for which the heuristic was initially developed, there's a much lower penalty for small blocks.) I doubt that linux vs fbsd has much to do with it.

mauroman33

@spon901:

Ok, so on a non pFsense device there is no correlation between theoretical and real sped ?

I think there is also correlation for not pfSense devices, but I don't think you could be sure to get a definitive answer on the pfSense forum.

teh g

Figured I'd show my J3455 results:

Intel Celeron J3455 4x1.5GHz -TDP 10W -CPU Mark 2134 -Single Thread 782

AES-256-CBC : 267.9 Mbps
AES-256-GCM: 282.4 Mbps

AES-128-CBC: 270.0 Mbps
AES-128-GCM: 284.9Mbps

denova

I know it's a bit of an old topic but I'm currently looking at some pfsense hardware with openvpn capabilities as well..

As I have a 1000/1000 fiber connection, I was wondering if a kaby lake celeron 3865u (1.8 GHz, dual core) would do similar or better than a j3355 for pfsense+openvpn purposes?

pfBasic

Probably pretty similar to j3355, but that's a mobile part.

chrcoluk

aes256 is just needlessly throwing away performance especially on CBC, I suggest sticking to aes128-gcm guys.

denova

@teh:

Figured I'd show my J3455 results:

Intel Celeron J3455 4x1.5GHz -TDP 10W -CPU Mark 2134 -Single Thread 782

AES-256-CBC : 267.9 Mbps
AES-256-GCM: 282.4 Mbps

AES-128-CBC: 270.0 Mbps
AES-128-GCM: 284.9Mbps

Ended up with a G4400 build myself, speed with PIA using OpenVPN and AES-128-CBC is near 500 Mbps. I never see the CPU taxed above 30% though with AES-NI enabled.

Also, the idle power consumption for the total system is about 13 watts, which is still fine for me.

stephenw10

Nice result. I would assume one core is at 100% in those conditions?

Steve

denova

While using some of the tips and tricks in this topic: https://forum.pfsense.org/index.php?topic=112877.15 I was able to increase my speed to 700-800 Mbps with a Speedtest.net test using a nearby 1000 mbit server (see attached).

That's actually a lot better than I had expected. While testing, the OpenVPN WCPU goes up to a about 50% and the max one core is used is also about 50%. Is this normal? I thought OpenVPN would be harder on my processor? (3.3 Ghz G4400 Skylake processor with AES-NI enabled) I'm quite sure my VPN is working fine as the OpenVPN process is spiking and both speedtest.net and privateinternetaccess.com report my PIA ip address. The cipher used is AES-256-CBC.

speedtest.PNG_thumb

stephenw10

Hmm, that is surprisingly fast. Almost suspiciously so.

Increasing the buffers and setting fast-io can help quite a bit though. Those options are in the gui in 2.4.

Steve

denova

Thanks Steve. Yeah, I'm not sure what to think of it yet (1000/1000 mbit connection)

These are the settings I've used:

tls-client;
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
remote-cert-tls server;
persist-key;
persist-tun;
persist-remote-ip;
keysize 256;
reneg-sec 0;
link-mtu 1540;
fragment 0;
mssfix 0;
fast-io;
sndbuf 1572864;
rcvbuf 1572864;

All seemed fine in the logs until I just received this error in the OpenVPN log: 38532 tun packet too large on write (tried=1500,max=1482).
Is that bad news? Can't seem to find anything decisive about it.

stephenw10

There's no way the link-mtu is 1540, you should probably remove that.

I'm not sure what setting mssfix and fragment to 0 does. Probably nothing, it seems to be undefined.

When I tested locally I found increasing the send receive buffers above 512k made negligible difference.

Steve

denova

Think you are correct, changed to this settings:

tls-client;
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
remote-cert-tls server;
persist-key;
keysize 256;
reneg-sec 0;
fast-io;
sndbuf 572864;
rcvbuf 572864;

No more errors in the log but the same speed (700-800 Mbps).

EDIT: a bit too soon, a new error occurs every approx. 5 minutes: PID_ERR replay-window backtrack occurred [13] [SSL-0] [000000000000__00000000000000000000000000000000000000000000000000] 0:4803054 0:4803041 t=1505773250[0] r=[-3,64,15,13,1] sl=[22,64,64,528]. Apparently this is connected to having some packet loss while using UDP instead of TCP.

Back on topic: apparently a G4400 is able to reach 700+ Mbps with PIA under favorable circumstances (server very close etc).