In this guide we will make considerations on the configuration and optimizations of the OpenVPN service, based on the tests we have performed on hardware devices.
In particular on the encryption and traffic compression settings, 2 essential parameters for the optimization of this tool.
For the drafting of the guide we will refer to the OS pfSense® and OPNsense®, however the same speech can be extended to all OpenVPN implementations.
These considerations can help us understand how the protocols used by OpenVPN, used to encrypt and compress traffic, can affect the traffic capacity of the system used and therefore how to size our equipment. In the conclusions, we will make some considerations on the security of the traffic encryption protocol in relation to the performances.
Hardware and software environment used
We carried out the tests in the laboratory with two different hardware devices and with the pfSense system.
The hardware selected for the tests are:
Firewall Entry Level:
Firewall APU 3 NIC
Firewall Datacenter tested:
Firewall A1 Server
All hardware tested and produced by us have strictly Intel NIC chipsets.
The software used on the appliance is pfSense® version 2.4.X.
Introduction
Since the actual traffic capacity depends on multiple factors, in our tests we evaluate the theoretical capabilities of the devices, so that we can understand if and when the device can be a bottleneck when using a VPN.
The tests were carried out on two different hardware appliances, with different computing power (different CPU), while RAM and network cards are not very different, however, having Intel NIC chipsets.
Preliminary considerations on VPN protocols and specifications:
The TCP protocol is a handshake protocol (3-way); this system makes it a “reliable” protocol. This means that if a stable connection exists between two hosts, the TCP protocol ensures that all packets will arrive at their destination.
In particular, the client sends a packet with a unique identifier and with a syn request, the server replies with a syn-ack packet, then the client sends an ack packet. If the communication is not closed, the packet is sent again until success or after a time out and all communication is interrupted and defined closed.
Conversely, the UDP protocol is a connection less protocol, that is, there are no requests for verification or reordering of packets. This makes it less reliable since some packets may be lost and will not be retransmitted, however this mechanism also makes it much faster.
For the implementation of VPNs it is better to use the UDP protocol as it is faster. We don’t have to worry about reliability as the VPN encapsulates the protocols that travel in the tunnel, and if, for example, the encapsulated protocol is TCP, he will worry about getting all the packets coming. To implement a VPN you can use the TCP protocol, but normally it is used due to restrictions or blockages that prevent the use of UDP.
When implementing a VPN some operations are carried out, the first consists in establishing a tunnel, subsequently the data can be encrypted and / or compressed
In particular, the client sends a packet with a unique identifier and with a syn request, the server replies with a syn-ack packet, then the client sends an ack packet. If the communication is not closed, the packet is sent again until success or after a time out and all communication is interrupted and defined closed.
Conversely, the UDP protocol is a connection less protocol, that is, there are no requests for verification or reordering of packets. This makes it less reliable since some packets may be lost and will not be retransmitted, however this mechanism also makes it much faster.
For the implementation of VPNs it is better to use the UDP protocol as it is faster. We don’t have to worry about reliability as the VPN encapsulates the protocols that travel in the tunnel, and if, for example, the encapsulated protocol is TCP, he will worry about getting all the packets coming. To implement a VPN you can use the TCP protocol, but normally it is used due to restrictions or blockages that prevent the use of UDP.
When implementing a VPN some operations are carried out, the first consists in establishing a tunnel, subsequently the data can be encrypted and / or compressed.
We talked about it in depth in this guide: https://blog.miniserver.it/en/pfsense-and-vpn-differences-and-insights-on-ipsec-and-openvpn-security/
The creation of a tunnel is not part of this guide, we will only say that it is the fundamental part for making the VPN work, allowing direct communication between the two remote networks, even private ones.
Encryption is optional, but strongly recommended, and in fact protects our data as they pass through the VPN tunnel, through the use of keys.
Compression is optional and takes care of optimizing the communication speed by compressing the data passing through the tunnel.
Introduction to made tests
Having mainly to verify the impact of the VPN system on the performance of hardware and network traffic, the parameter that interests us mainly at this moment is the Encryption Algorithm and in part compression. The other parameters are of less interest.
The parameters covered by this guide can be set on PFSenese and OPNSense through a graphical interface. In particular:
- Parameters for data encryption with PFSense:
From VPN→OpenVPN→Server (it is assumed that at least one OpenVpn server has already been created), eedit the desired OpenVpn server, in the Cryptographics setting section, select the data cryptographic parameter from the drop-down menu Encryption algorithms and/or NCP Algoritm ( negotiation system by the cryttography algorithm).
- Parameters for data compression with pfSense:
On the same page where we configured the encryption, under tunnel settings, select the desired compression from the “compression” menu.
- Parameters for data compression with OPNSense:
From VPN→OpenVpn→Server (assuming an OpenVpn server has already been created), edit the desired OpenVpn server.
Look for the “Compression” drop-down menu, select the desired compression. For the possible choices, from the figure below see information notes.
- Parameters for data cryptography with OPNSense:
Also from this web page Use the “Encryption Algoritm” menu to select the type of encryption to be used for the data
Made tests:
The tests were carried out using and processing the results through the use of a pfSense shell and with the commands:
[“openssl speed”] and [“OpenVPN”+”time”]- openssl speed md5 sha1 ….
openssl is the system (library) used by OPENVPN for the implementation of the VPNs, the command actually tests the execution speed of the command for data compression and decompression. The result is the maximum speed that the openssl library can have for data cryptography.
Literally: This command is used to test the performance of cryptographic algorithms - # OpenVPN –genkey –secret /tmp/secret
# time OpenVPN –test-crypto –secret /tmp/secret –verb 0 –tun-mtu 20000 –cipher aes-256-cbc
OpenVPN, used with time, performs a speed test directly with OpenVPN’s compression and decompression tools through a static key generated with OpenVPN itself; therefore time generates a result that obeys the following formula(3200 / tempoDiEecreationInSeconds) = Maximum projection of OpenVPN performance in Mbps
Note: We also carried out tests by changing the “Cryptographic Hardware” parameter
On PPSense you can find it in: System → Advanced → Miscellaneous
However, changing this parameter did not make any significant difference.
1. Hardware test: A1Server
Now let’s move on to the actual test and data analysis.
Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
8 CPUs: 1 package(s) x 8 core(s)
AES-NI CPU Crypto: Yes (inactive)
Theoretical results using the following commands
# OpenVPN — genkey — secret /tmp/secret
# time OpenVPN — test-crypto — secret/tmp/secret — verb 0 — tun-mtu 20000 — cipher aes-256-cbc
| Theoretical Mbps | Algorithm used |
|---|---|
| 146,838022674072 140,765373449459 139,752030035798 138,90789131001 103,908045977011 91,1830408023706 69,338071197972 69,2795289227572 103,177714727882 116,2342002034 91,1596638655462 116,47534121929 91,1077580071174 | no encryption aes-128-cbc AES-192-CBC Aes-256-cbc DES-CBC RC2-CBC DES-EDE-CBC DES-EDE3-CBC DESX-CBC BF-CBC RC2-40-CBC CAST5-CBC RC2-64-CBC |
Results obtained with the following command
#openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048
dsa2048
The ‘numbers’ are in 1000s of bytes per second processed.
| type | 16 bytes | 64 bytes | 256 bytes | 1024 bytes | 8192 bytes |
|---|---|---|---|---|---|
| md5 sha1 des cbc des ede3 aes-128 cbc aes-192 cbc aes-256 cbc sha256 sha512 | 21190.45k 21710.91k 41221.46k 15988.63k 38312.81k 32731.46k 28285.92k 21627.88k 13847.41k | 70594.55k 65473.75k 44227.26k 16365.97k 43219.39k 36044.84k 30700.84k 49864.17k 55176.02k | 182172.84k 148563.20k 45445.11k 16509.70k 44714.80k 37102.34k 31754.84k 87007.91k 85171.11k | 300125.18k 217115.81k 45549.91k 16545.79k 119669.42k 102306.47k 88846.97k 107239.77k 119439.36k | 369085.06k 250563.24k 45544.79k 16599.26k 122071.72k 103322.97k 89260.03k 115149.48k 135876.83k |
sign verify sign/s verify/s
rsa 2048 bits 0.005019s 0.000179s 199.3 5580.9
sign verify sign/s verify/s
dsa 2048 bits 0.001918s 0.001778s 521.3 562.3
2. Test performed with HardWare MINISERVER: AMD GX-412TC SOC
4 CPUs: 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (inactive)
Theoretical results using the following commands
# OpenVPN — genkey — secret /tmp/secret
# time OpenVPN — test-crypto — secret /tmp/secret — verb 0 — tun-mtu 20000 — cipher aes-256-cbc
| Theoretical Mbps | Algorithm used |
|---|---|
| 43,4804334247617 43,4804334247617 43,2800972841508 43,474532577135 32,3910582908885 | none aes-128-cbc AES-192-CBC Aes-256-cbc DESX-CBC |
Results obtained with the following command
# openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048
The ‘numbers’ are in 1000s of bytes per second processed.
| type | 16 bytes | 64 bytes | 256 bytes | 1024 bytes | 8192 bytes |
|---|---|---|---|---|---|
| md5 sha1 des cbc des ede3 aes-128 cbc aes-192 cbc aes-256 cbc sha256 sha512 | 6091.10k 6273.40k 14113.51k 5392.94k 15351.43k 12678.31k 11186.83k 7626.93k 5065.17k | 20796.97k 20775.26k 14949.49k 5503.06k 16479.76k 13439.26k 11697.27k 18208.54k 20386.18k | 55149.83k 49754.39k 15007.49k 5499.17k 16752.60k 13956.93k 11974.06k 31935.64k 32140.75k | 102651.56k 75995.34k 15168.85k 5542.91k 42753.73k 36587.81k 31814.29k 39095.85k 46066.56k | 135633.57k 90409.66k 15192.41k 5480.00k 43496.29k 36842.15k 31850.50k 41115.50k 51883.22k |
sign verify sign/s verify/s
rsa 2048 bits 0.010064s 0.000284s 99.4 3517.3
sign verify sign/s verify/s
dsa 2048 bits 0.003835s 0.003517s 260.8 284.3
Looking at the result of the tests carried out, the large speed difference in Mbs is immediately noticeable, which can be seen from the two tests depending on the CPU used.
i.e. con openssl e algoritmo di crittografia aes-128
- First test: 140Mbps aes-128-cbc
- Second test: 43Mbps aes-128-cbc
Even the use of algorithms other than quite different results, however less evident.
i.e From the first test, the result of the encryption algorithm between aes-256 and DES-EDE
- 138Mbps Aes-256-cbc
- 69Mbps DES-EDE-CBC
Unlike what we would have expected, using the same algorithm but increasing the number of encryption bits, the differences are not very large.
i.e From the first test, the result of the 128, 192 and 256 bit encryption algorithm
- 140Mbps aes-128-cbc
- 139Mbs AES-192-CBC
- 138Mbps Aes-256-cbc
Another result to keep in mind, are the differences that increase with increasing CPU power, even if at a percentage level they are similar, obviously the amount of Mbps changes. This can be uninteresting from a theoretical point of view, it changes instead from a practical point of view. Below an example
First test:
- 138Mbps Aes-256-cbc
- 103Mbps DESX-CBC
- difference around 30%
- difference around 25 Mbps
Second Test:
- 43Mbps Aes-256-cbc
- 32Mbps DESX-CBC
- difference around 30%
- difference around Mbps
Conclusions and considerations.
First consideration: the encryption protocol does not exclude the overhead due to the encapsulation of the VPN, since in order to make the VPN work you must first create a tunnel that involves operations of modification and addition of data to the TCP / IP packets ( with obvious use of computing power and addition of information in TCP / IP packets)
The overhead can change depending on the configuration and the software used (OpenVPN, IPSEC, L2TP, …), a parameter that can affect performance, but in a way much less than encryption.
So not using encryption does not correspond to obtaining the maximum network, but it could be little influential.
Second consideration: the greater security of a protocol does not mean lower execution speed, therefore the choice to use AES (more secure) than DES (less secure) is certainly better.
Third consideration: unless very critical situations, the advantage (in terms of speed) of using fewer bits with the same algorithm, for example the choice between AES-128 and AES-256 (algorithm: AES number of bits: 128 or 256), it may not justify the least security that would be obtained. Therefore, in this case, it is normally convenient to use AES-256
VPN / OpenVPN Protocol Considerations – TCP/UDP Compression
The standard protocol of OpenVPN and of vpn in general is UDP, the reason is that it is not necessary to load / weight the VPN of a protocol with a handshake system such as TCP, in fact it will be the applications that will use the VPN to choose the most suitable protocol. is suitable for their purpose.
TCP over vpn is chosen if there are no alternatives due to security protocols or the obligation to use some services for access to the external network, such as proxies.
Considerations for the VPN traffic compression system.
Also in this case it is necessary to consider the fact that by now most of the traffic is already compressed, in any case the compression default for OpenVPN is lzo, which has a very high compression level, but greatly engages the system resources, moreover not it is very optimized in case of already compressed protocols.
For this reason, compression systems such as lz4 and lz4-v2 (specifically designed for OpenVPN) were born.
Therefore if your system has the resources already very busy, choose the compression level appropriately (for example avoid lzo), or consider the option to disable it.
In addition, the compression protocol could create compatibility problems especially in P2P VPNs, therefore in case of VPN malfunctions it is recommended to disable compression first.
