{"id":20105,"date":"2022-03-28T16:23:00","date_gmt":"2022-03-28T14:23:00","guid":{"rendered":"http:\/\/www.firewallhardware.it\/openvpn-e-pfsense-opnsense-ottimizzazione-della-crittografia-e-compressione-del-traffico-per-ottimizzare-hardware-e-migliorare-la-sicurezza\/"},"modified":"2022-03-28T16:24:32","modified_gmt":"2022-03-28T14:24:32","slug":"encryption","status":"publish","type":"post","link":"https:\/\/blog.miniserver.it\/en\/pfsense\/encryption\/","title":{"rendered":"OpenVPN: Encryption and traffic compression (optimize hardware and improve security)"},"content":{"rendered":"\n

In this guide we will make considerations on the configuration and optimizations of the OpenVPN<\/strong> service, based on the tests we have performed on hardware devices.<\/strong><\/p>\n\n\n\n

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<\/a>\u00ae<\/strong> and OPNsense\u00ae,<\/strong> however the same speech can be extended to all OpenVPN<\/strong> implementations.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Hardware and software environment used<\/h3>\n\n\n\n

We carried out the tests in the laboratory with two different hardware devices and with the pfSense <\/strong>system.
The hardware selected for the tests are:<\/p>\n\n\n\n

Firewall Entry Level:<\/strong>
Firewall APU 3 NIC<\/a><\/p>\n\n\n\n

Firewall Datacenter tested:<\/strong>
Firewall A1 Server<\/a><\/p>\n\n\n\n

All hardware tested and produced by us have strictly Intel NIC chipsets.
The software used on the appliance is pfSense\u00ae version 2.4.X<\/strong>.<\/p>\n\n\n\n

Introduction<\/h3>\n\n\n\n

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<\/strong> can be a bottleneck when using a VPN<\/strong>.<\/p>\n\n\n\n

The tests were carried out on two different hardware appliances<\/strong>, with different computing power<\/strong> (different CPU), while RAM and network cards are not very different, however, having Intel NIC chipsets<\/strong>.<\/p>\n\n\n\n

Preliminary considerations on VPN protocols and specifications:<\/h3>\n\n\n\n

The TCP protocol<\/strong> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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\/<\/a><\/p>\n\n\n\n

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<\/strong>, but strongly recommended, and in fact protects our data as they pass through the VPN tunnel, through the use of keys.
Compression is optional<\/strong> and takes care of optimizing the communication speed by compressing the data passing through the tunnel.<\/p>\n\n\n\n

Introduction to made tests<\/h3>\n\n\n\n

Having mainly to verify the impact of the VPN system on the performance of hardware<\/strong> and network traffic, the parameter that interests us mainly at this moment is the Encryption Algorithm<\/strong> and in part compression. The other parameters are of less interest.<\/p>\n\n\n\n

The parameters covered by this guide can be set on PFSenese and OPNSense<\/strong> through a graphical interface. In particular:<\/p>\n\n\n\n

  • Parameters for data encryption with PFSense<\/strong>:
    From VPN\u2192OpenVPN\u2192Server (it is assumed that at least one OpenVpn server has already been created<\/strong>), 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).<\/li><\/ul>\n\n\n\n
    \"Openvpn<\/figure>\n\n\n\n
    • 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.<\/li><\/ul>\n\n\n\n
      \"Openvpn<\/figure>\n\n\n\n
      • Parameters for data compression with OPNSense:
        From VPN<\/strong>\u2192OpenVpn<\/strong>\u2192Server<\/strong> (assuming an OpenVpn server has already been created), edit the desired OpenVpn server<\/strong>.
        Look for the “Compression” drop-down menu, select the desired compression. For the possible choices, from the figure below see information notes.<\/li><\/ul>\n\n\n\n
        \"Openvpn<\/figure>\n\n\n\n