Guide

OpenVPN and pfSense® / OPNsense®: optimization of encryption and traffic compression to optimize hardware and improve security

Objective of this guide:

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://www.firewallhardware.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).
Openvpn Compression And Encryption R3
  • 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.
Openvpn Compression And Encryption R3
  • Parameters for data compression with OPNSense:
    From VPNOpenVpnServer (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.
Openvpn Compression And Encryption R3
  • 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
Openvpn Compression And Encryption R3

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”]

  1. 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
  2. # 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.

  ti posso interessare anche