PfSense hardware for home router - OpenVPN performance

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).

mauroman33

Hi denova, your results are really interesting.
It could be nice if you'll have the time to run test suggested in the first post. Just out of curiosity.
cheers

denova

@mauroman33:

Hi denova, your results are really interesting.
It could be nice if you'll have the time to run test suggested in the first post. Just out of curiosity.
cheers

8.45 seconds, so 3200/8.45 would be around 380 Mbps. I'm getting up to 850 Mbps though, with about 50% core taxing.

I still don't really get it, is there something I'm missing?

Connection 1000/1000 mbit, Private Internet Access, OpenVPN settings:

Server mode: peer to peer
Protocol: UDP on IP4 only
Peer Certificate Authority: PIA certificate
AES-256-CBC
Compression: LZO compression
Device mode: tun layer 3 tunnel mode
Custom options:

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;
fragment 0;
mssfix 0;
fast-io;
sndbuf 572864;
rcvbuf 572864;

Capture.PNG_thumb

Capture4.PNG_thumb

denova

Think I found whats giving me the very high results on Speedtest.net. With LZO compression disabled in OpenVPN my results are near 500 Mbps again, with LZO enabled its much higher. But it appears speedtest.net is a bit tricked by LZO:

"When doing VPN tests to measure connection speeds, most people turn to the web’s most prominent internet speed testing website, speedtest.net. Unfortunately, although speedtest.net is a very good indicator of naked internet speed, it can yield some very odd results when VPN testing, often indicating speeds much faster than not just the naked internet results, but than the cap put on a service by the ISP . The reason for this is that the Flash based speedtest.net tool does not account for LZO compression, which is built into the OpenVPN protocol.

LZO compression
OpenVPN has built into it the optional ability to use the LZO lossless compression library. Much like the better known .zip format, this compresses the size of some files types, which can indeed increase data throughput, but does not count against your ‘real’ bandwidth usage. Files that are already compressed, such as .zip, .rar, and .mp3, and .jpg files, do not benefit much from additional compression. As we noted earlier, speedtest.net is easily confused by the use of LZO compression" (https://www.bestvpn.com/vpn-speed-test-overview/)

So my real world speed is probably 500 Mbps, still very nice ;D

mauroman33

Nice found!
Your's definitely a great achievement. I also have a PIA connection at moment (swedish server), but I had never exceed the theoretical maximum speed. On what PIA server are you connected?

stephenw10

Interesting. There's nothing wrong with using compression. Speedtests data should probably be non-compressible to test the actual available bandwidth though. But it shows how much it can help if what you're transferring is compressible.

Steve

VAMike

I don't see any point in enabling compression on the modern internet. The majority of data is either encrypted (thus incompressible) or already compressed (like streaming video). So outside of benchmarks it basically never gets used, but it always adds a bit of CPU overhead.

stephenw10

I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.

Steve

VAMike

@stephenw10:

I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.

If the bulk of your traffic isn't encrypted or already compressed, then you've got a very, very unusual traffic profile. If someone's transferring huge quantities of uncompressed text over http, then sure, they should enable link compression.

Pippin

To do a OpenVPN speed test I find that downloading a incompressible BIN or zip or … from a server(s) on the net gives better consistent results. Just search something like "download test bin zip file".
Something like: https://www.thinkbroadband.com/download
And use the download url`s in this program: http://www.nirsoft.net/utils/download_speed_tester.html

I don't see any point in enabling compression on the modern internet

Indeed, according to the manual it adds at least 1 byte/packet for lzo + the needed processing power, for lz4 I don`t know.

denova

@mauroman33:

Nice found!
Your's definitely a great achievement. I also have a PIA connection at moment (swedish server), but I had never exceed the theoretical maximum speed. On what PIA server are you connected?

I use the nl.privateinternetaccess.com server, but I think it's just about selecting one near you. I'll try the Swedish one some day :)

mauroman33

@denova:

@mauroman33:

Nice found!
Your's definitely a great achievement. I also have a PIA connection at moment (swedish server), but I had never exceed the theoretical maximum speed. On what PIA server are you connected?

I use the nl.privateinternetaccess.com server, but I think it's just about selecting one near you. I'll try the Swedish one some day :)

I do use that one because I spend most of the year in Sweden ;).
Staying myself much closer to the Copenhagen servers I tried that connection, but performance was not as good as expected.
I'll take a look on nl servers too. Thanks!

belt9

@VAMike:

@stephenw10:

I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.

If the bulk of your traffic isn't encrypted or already compressed, then you've got a very, very unusual traffic profile. If someone's transferring huge quantities of uncompressed text over http, then sure, they should enable link compression.

This assumes you're just using the connection to do normal browsing and internet usage, i.e., an OpenVPN Client. What about the OpenVPN server. Where I connect to my home or work network from afar, often with a sub-optimal connection and transfer all kinds of files and data (much of it un-encrypted) from my home network to my laptop. This is where LZOv2 is useful.

n3by

why not use adaptive compression and let OVPN to decide when to use it or not ?

ovpn.png_thumb

belt9

no real reason when it comes to actual day to day usage you would notice.

VAMike

@belt9:

@VAMike:

@stephenw10:

I guess it all depends on what your expected traffic is. Yeah if you're mostly using https and netflx then maybe not worth it. I've never actually tried to measure the overhead introduced though.

If the bulk of your traffic isn't encrypted or already compressed, then you've got a very, very unusual traffic profile. If someone's transferring huge quantities of uncompressed text over http, then sure, they should enable link compression.

This assumes you're just using the connection to do normal browsing and internet usage, i.e., an OpenVPN Client. What about the OpenVPN server. Where I connect to my home or work network from afar, often with a sub-optimal connection and transfer all kinds of files and data (much of it un-encrypted) from my home network to my laptop. This is where LZOv2 is useful.

I can't even think of what connections on my home network would consist of very much uncompressed data by volume. Video is compressed, pictures are compressed, documents are compressed. There'd be some uncompressed html & source code, but that would be such a small fraction of traffic as to be negligible. Again, if you really do have an overwhelming workload of uncompressed data then sure it makes sense to compress it. (Although I'd look at doing that somewhere else than the edge in the VPN client, personally–by spreading out the compression work to other places you'll be doing less in the single threaded bottlenecked openvpn process.) But for most people that's not the case, and the compression is just adding overhead with no real benefit.