Depending on individual use cases, different hardware firewalls may be useful for different types of network applications and as such, Protectli offers different hardware with varying capabilities. Frequently, it is useful for a customer to know the performance characteristics of specific hardware before making a decision to purchase. This article aims to provide a baseline of OpenVPN performance for several different Vaults, as tested in a lab environment, so the customer can make an informed decision as to what products best suit their needs.
In a basic setup, The Vault is capable of routing packets at wire speed on all ports for all models. For a 1 Gbps ethernet interface, the actual data throughput is ~940 Mbps due to overhead in an IP packet. The test network consists of 2 computers running Ubuntu 20.04.1 version of Linux and 2 Vaults running pfSense® CE version 2.4.5_1. One of the Ubuntu computers is running iperf3 as a server, the other is running iperf3 as a client.
OpenVPN is a popular protocol that is used to authenticate and encrypt/decrypt packets to provide secure transport of packets through the network. An OpenVPN “tunnel” encrypts the entire packet, not just the payload, and is commonly used to create Virtual Private Networks (VPN).
When configuring OpenVPN tunnels (and other secure connections) multiple parameters must be configured. The set of parameters is known as a “cipher suite”. The main parameters for OpenVPN consist of an Encryption method and a Message Authentication method. The configuration must be identical at each end of the tunnel in order to make a connection. With OpenVPN, one side of the tunnel is the “server” and the other end is the “client”. Multiple clients can be connected to a single server for a hub and spoke type of architecture.
The diagram below shows an OpenVPN tunnel. The difference between the LAN example above and the OpenVPN tunnel is that the entire packet is encrypted “end-to-end” between the Vault/Firewalls and the data can travel through the network securely.
Adding an OpenVPN tunnel introduces “overhead” which is added when a packet enters a tunnel and stripped off when a packet leaves the tunnel. This process adds additional data to each packet, but is not part of the payload. Therefore, when running performance measurement tests, the indicated traffic throughput will be less than throughput achieved without an OpenVPN encrypted tunnel. In addition to the pure impact on the payload due to additional overhead, the device that adds the overhead must also encrypt the data. Similarly, the device at the other end of the tunnel receiving the packet must decrypt the data before sending it onward. Encryption and decryption of the packet requires significant processing power and affects the throughput of the devices. The latest versions of The Vault include Intel’s AES-NI hardware support which facilitates faster encryption/decryption with less impact on CPU performance. The performance varies depending on the parameters of the many different cipher suites. For example, a cipher suite that uses AES128 may perform better than AES256 due to easier encryption/decryption. It would be difficult if not impossible to test all possible cipher suites. For this purpose, a variety of different iterations have been tested, including ones that are not optimal in terms of performance, or commonplace. In order to test performance, pfSense® CE 2.4.5_1 was installed on the Vaults and OpenVPN tunnels were configured with the following initial cipher suite which provided the most optimal results found across all platforms:
- AES128 bit encryption algorithm with 128 bit blocks using the Cipher Block Chaining mode (CBC) operation
- Secure Hash Algorithm (SHA) 256 bit Message Authentication
The main configuration page for VPN->OpenVPN->Servers is shown below.
The main configuration page for VPN->OpenVPN->Clients is shown below.
In this example, data from LAN network 192.168.50.0 is “tunneled” to LAN network 192.168.60.0 over the WAN interface. In the reverse direction, data from LAN network 192.168.60.0 is “tunneled” to LAN network 192.168.50.0 over the WAN interface. The results of performance tests run on the Vaults are shown in the table below.
For more detailed information on the performance results, please click on the following link: OpenVPN Performance Sheet
|Vault Model||Unencrypted LAN (Mbps)||Encrypted IPSec AES-128-GCM/AES-XCBC/ AES128-GCM||Encrypted OpenVPN AES-256-CBC/SHA256 (Mbps)|
Configuration Files for OpenVPN Performance Testing
Provided is the configuration files for both the OpenVPN server and OpenVPN client to be used for performance testing purposes. Please note that configuration changes will have to be made for the OpenVPN tunnel depending on the WAN IP address issued via DHCP.
|Config||OpenVPN Server||OpenVPN Client|
|FW6C Server to FW1 Client||FW6C to FW1-OpenVPN Server||FW1 OpenVPN Client|
|FW6C Server to FW2 Client||FW6C to FW2- OpenVPN Server||FW2- OpenVPN Client|
|FW6C Server to FW2B Client||FW6C to FW2B- OpenVPN Server||FW2B- OpenVPN Client|
|FW6C Server to FW4A Client||FW6C to FW4A OpenVPN Server||FW4A- OpenVPN Client|
|FW6C Server to FW4B Client||FW6C to FW4B- OpenVPN Server||FW4B- OpenVPN Client|
|FW6C Server to FW6A Client||FW6C to FW6A-OpenVPN Server||FW6A- OpenVPN Client|
|FW6C Server to FW6B Client||FW6C to FW6B- Open VPN Server||FW6B- OpenVPN Client|
|FW6C Server to FW6C Client||FW6C to FW6C- OpenVPN Server||FW6C- OpenVPN Client|
|FW6E Server to FW6D Client||FW6D to FW6E- OpenVPN Server||FW6D OpenVPN Client|
|FW6E Server to FW6E Client||FW6E to FW6E- OpenVPN Server||FW6E- OpenVPN Client|
Conclusions on OpenVPN Performance
OpenVPN is a critical set of protocols used to provide secure communication through the Internet. There are many different cipher suites that can be used depending on the requirements of the user. The configuration used may impact the performance and therefore the throughput of the devices in the network. This tutorial is an aid to selecting the best Vault for your application. If you have any questions, feel free to reach out to us! You can submit a ticket here, find more information in our Knowledge Base, or visit the pages at IETF as reference.