OpenVPN Optimization (peer id)
-
I am trying to optimize OpenVPN to be as fast as possible.
I have tried increase Send/Receive Buffer but I see no speed difference. I have tried hardware acceleration of intel RDRAND, dev/crypto and none with all of them producing the same speed. I was going to try turning off the peer id to save three bytes. What is the correct command for doing this? I thought it was:
pull-filter ignore "peer-id"
but I still see peer-id mentioned in the debug logs.
Right now I have a bandwidth of 400-300 Mbps down 180-130 Mbps up with AES-256-GCM on Sha1 and using tls for authentication. I am using i5-7600K CPU @ 3.80GHz with 8 GB of RAM.
-
Have you eneabled AES-NI?
-
@jknott Yes, that is the Intel RDRAND I tried out. I saw no difference between it turned on and it turned off.
-
AES-NI and RDRAND are 2 different things. AES-NI and BSD Crypto Device settings are found in System / Advanced / Misc, whereas RDRAND is found in the server and client settings. I have another thread about RDRAND. According to the help, normal config is to enable both AES-NI and BSD Crypto on the misc. page. I expect RDRAND to work on my pfsense system, as that computer is just a few months old. I'm not sure if it will work on my ThinkPad, as it is 10 years old.
Maybe someone who knows more about OpenVPN on pfsense can advise further on these.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@jknott said in OpenVPN Optimization (peer id):
I'm not sure if it will work on my ThinkPad, as it is 10 years old.
Nope. RDNAND came in with the Ivy Bridge processors. My ThinkPad has Sandy Bridge.
Bottom line, assuming hardware support, is AES-NI, BSD Crypto and RDRAND on the server and RDRAND on the client.
Maybe someone else with more knowledge can comment on this.
-
@jknott I had a conversation last night with someone about AES-NI. Apparently, turning it on in the System-> Advance -> Misc menu does not affect OpenVPN at all. They believed that the drivers were built into Openvpn and if your CPU has AES-NI, it will use AES-NI regardless of your settings. That does explain why speeds are the same regardless of whether I have that turned on in the menu or not. I believe that setting does affect other VPN types though.
Now I wonder if there are other tweaks I can do. I already have fast-io and UDP set. I heard I can turn off the transmission of the peer-id which will save three bytes of overhead but I haven't figured out how to do that yet. I was wondering if I could speed up the connection by forcing TLS version 1.3 . I believe the command to do this is:
tls-version-min 1.3
What is strange is that AES-256-GCM and SHA1 with TLS for authentication still connects. I thought Sha1 was remove from tls 1.3 . Any idea what is going on here?
I tried adjusting the drop down menu that controls Send/Receive Buffer but that seems to have no effect on speed in my setup.
Anything else I can tweak?
-
@ryu945 said in OpenVPN Optimization (peer id):
Anything else I can tweak?
No idea. Encryption isn't my strong suit. A while ago, the plan was for pfsense to require AES-NI, but that was dropped. It would be nice if there was some good documentation on this stuff.
Here's the link for Advanced / Misc, where this is discussed in the Cryptographic Hardware section. It doesn't mention anything about whether it's used for OpenVPN, etc.. It just says both AES-NI and BSD Crypto is optimal in most cases.
Well, my firewall supports both AES-NI/BSD Crypto and RDRAND, so they're enabled, whether they do anything or not.
What might provide an improvement is OpenVPN supporting multiple CPU cores. I have 2 real & 2 virtual cores in an i5 CPU.
Until recently, this wasn't that important, but now we're seeing Internet connections running at 500 Mb or even Gb. I have 500/20, but a friend has 500/500 and another friend Gb/30 Mb. IIRC, when I first got a cable modem, it was 6 Mb down, which was quite an improvement over the 56k/33k dial up modem I had been using before that.
BTW, many years ago, when I first started working in telecom, some of the equipment I worked on ran at a blazing 45.4 bits/sec.!!!
-
@ryu945 said in OpenVPN Optimization (peer id):
They believed that the drivers were built into Openvpn and if your CPU has AES-NI, it will use AES-NI regardless of your settings.
OpenVPN hands over crypto operations to OpenSSL.
OpenSSL has built-in AES-NI instructions since version 1.0.X.
It means, for OpenVPN it does not require any Hardware acceleration to be selected in pfSense GUI.I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
Halton Arp -
@pippin said in OpenVPN Optimization (peer id):
It means, for OpenVPN it does not require any Hardware acceleration to be selected in pfSense GUI.
That's dumb. Why not use hardware when available? It tends to be faster. I wonder if this is why pfsense dropped the planned requirement for AES-NI.
-
If the CPU supports AES-NI, OpenVPN, or more accurately OpenSSL, will use it.
So no need to load any crypto modules.I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
Halton Arp -
@pippin said in OpenVPN Optimization (peer id):
It means, for OpenVPN it does not require any Hardware acceleration to be selected in pfSense GUI.
On rereading that, does that mean it will use hardware if available?
I came across this article.
As I mentioned, some good docs would be nice.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@pippin said in OpenVPN Optimization (peer id):
So no need to load any crypto modules.
It would be nice if that was mentioned somewhere in the pfsense docs. There's not much mentioned about RDRAND either.
-
@jknott said in OpenVPN Optimization (peer id):
I just tried the test described in the 2nd link. The 1st & 3rd runs are with AES-NI enabled and the 2nd and 4th without.
[2.5.2-RELEASE][root@firewall.jknott.net]/root: openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 25636690 aes-128 cbc's in 3.03s
Doing aes-128 cbc for 3s on 64 size blocks: 6645567 aes-128 cbc's in 3.02s
Doing aes-128 cbc for 3s on 256 size blocks: 1666553 aes-128 cbc's in 3.01s
Doing aes-128 cbc for 3s on 1024 size blocks: 419373 aes-128 cbc's in 3.02s
Doing aes-128 cbc for 3s on 8192 size blocks: 52444 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 26180 aes-128 cbc's in 3.01s
OpenSSL 1.1.1k-freebsd 25 Mar 2021
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 135319.44k 141037.53k 141843.14k 142404.29k 143207.08k 142606.34k
[2.5.2-RELEASE][root@firewall.jknott.net]/root: openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 25330588 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 6627583 aes-128 cbc's in 3.01s
Doing aes-128 cbc for 3s on 256 size blocks: 1673390 aes-128 cbc's in 3.02s
Doing aes-128 cbc for 3s on 1024 size blocks: 417364 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 53873 aes-128 cbc's in 3.09s
Doing aes-128 cbc for 3s on 16384 size blocks: 26240 aes-128 cbc's in 3.02s
OpenSSL 1.1.1k-freebsd 25 Mar 2021
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 135096.47k 141021.19k 141689.00k 142460.25k 143012.49k 142562.87k
[2.5.2-RELEASE][root@firewall.jknott.net]/root: openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 26072625 aes-128 cbc's in 3.08s
Doing aes-128 cbc for 3s on 64 size blocks: 6763860 aes-128 cbc's in 3.09s
Doing aes-128 cbc for 3s on 256 size blocks: 1672403 aes-128 cbc's in 3.02s
Doing aes-128 cbc for 3s on 1024 size blocks: 421159 aes-128 cbc's in 3.02s
Doing aes-128 cbc for 3s on 8192 size blocks: 52262 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 26208 aes-128 cbc's in 3.00s
OpenSSL 1.1.1k-freebsd 25 Mar 2021
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 135524.71k 140277.32k 141972.28k 143010.76k 142710.10k 143130.62k
[2.5.2-RELEASE][root@firewall.jknott.net]/root: openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 25433637 aes-128 cbc's in 3.01s
Doing aes-128 cbc for 3s on 64 size blocks: 6800719 aes-128 cbc's in 3.09s
Doing aes-128 cbc for 3s on 256 size blocks: 1663307 aes-128 cbc's in 3.01s
Doing aes-128 cbc for 3s on 1024 size blocks: 417174 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 51998 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 26190 aes-128 cbc's in 3.01s
OpenSSL 1.1.1k-freebsd 25 Mar 2021
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 135293.74k 141041.75k 141566.87k 142395.39k 141989.21k 142660.81k
[2.5.2-RELEASE][root@firewall.jknott.net]/root:If I'm reading that right, it appears there's a very slight, but probably not significant benefit to enabling it.
