Performance Evaluation of Open-Source
VPN Software Implementations
Hasan Redžović, Graduate Student Member, IEEE, Aleksandra Smiljanić, Member, IEEE,
and Slavko Gajin
Abstract—VPN software implementations provide high
flexibility and low cost of development. There are different
approaches for VPN software implementations. One type of VPN
software solution utilizes built-in kernel implementation of AH
and ESP protocols. The second approach are software VPN
solutions that use full user-space IPsec implementation. In this
paper, we analyze these two approaches and compare their
performances on 10Gbps links.
Index Terms— IPsec protocol; strongSwan; Rockhopper VPN;
performance evaluation; software VPN.
I. INTRODUCTION
A virtual private network (VPN) extends a private network
across public network, such as the Internet. VPN enables
users to send and receive data across unsecured public
networks as if their computing devices were connected to the
same cohesive private network. VPNs provide benefit for
everyone who wants to communicate without a fear of
disclosing private information. VPN can be implemented with
various protocols which operate at different levels of OSI
model. IP layer VPN implementation using Internet Protocol
security (IPsec) [1] protocol provides protection for all user-
space applications using particular routes. IPsec protocol
comprises a set of security protocols which have different
functionalities:
• Internet Key Exchange (IKE) - handles authentication
and periodical exchange of symmetric keys. It provides
different methods of authentication such as Pre-Shared
Key and X.509 certificates;
• Authentication Header (AH) - provides data integrity;
• Encapsulating Security Payload (ESP) - provides data
integrity and confidentiality.
IPsec protocol works in two modes: transport and tunnel.
Transport mode protects only IP payload, and tunnel mode
protects entire IP packet which includes IP header and
payload. The common way to implement VPN is to connect
Hasan Redžović is with the Innovation Center of School of Electrical
Engineering, University of Belgrade, 73 Bulevar kralja Aleksandra, 11020
Belgrade, Serbia (e-mail: hasanetf@live.com).
Aleksandra Smiljanić is with the School of Electrical Engineering,
University of Belgrade, 73 Bulevar kralja Aleksandra, 11020 Belgrade, Serbia
(e-mail: aleksandra@etf.rs).
Slavko Gajin is with the School of Electrical Engineering, University of
Belgrade, 73 Bulevar kralja Aleksandra, 11020 Belgrade, Serbia (e-mail:
slavko.gajin@etf.bg.ac.rs).
two or more VPN gateways which have private networks
behind them. The VPN gateway is usually a router with VPN
features that can be realized as hardware or software solution.
VPN hardware solutions are provided by several vendors such
as Cisco, Nortel, IBM, and Checkpoint. Their advantages with
respect to software solutions are better performance and lower
energy consumption achieved by the specialized hardware [2].
On the other hand, software solutions are highly flexible. It is
easier and faster to build and test new features in software
environment. In this paper we evaluate performance of two
different approaches for implementation of VPNs using IPsec
protocol:
• VPN software solutions that use kernel implementation
of AH and ESP protocols. The examples are:
strongSwan, Openswan, Libreswan;
• Full user-space IPsec implementation. Open source
software Rockhopper VPN implements IKE and ESP
protocol in user space.
Our focus is on strongSwan [3] and Rockhopper VPNs [4]
as these are two most commonly used software solutions.
StrongSwan is open source IPsec based VPN solution with
many different features. StrongSwan runs on Linux 2.6, 3.x
and 4.x kernels, Android, Maemo, FreeBSD and Mac OS X.
Rockhopper VPN is IPsec/IKEv2-based VPN software that
provide simple and intuitive interfaces for fast and easy VPN
configuration. In addition, Rockhopper VPN provides a large
variety of functions: Virtual Ethernet (Ethernet over IPsec),
Routing-based VPN, Role-based ID management and
configuration, AJAX-based (Comet) Web management
interface for configuring and monitoring, and so on.
Linux kernel generally cannot achieve I/O speeds of
10Gbps for IP packet smaller than 512 bytes. Implementation
of IPsec protocol have additional negative impact on
performance. Our tests of strongSwan and Rockhopper will
show extent of the performance degradation due to processing
associated with VPN functionalities. AH and ESP protocols
were implemented in kernel to achieve better performance
comparing to the user-space implementations. When IPsec is
implemented in user space, IP packet must travel full path
through kernel network stack before being processed by VPN
software and transformed into IPsec packet.
Kernel ESP/AH protocol implementation is advantageous
with respect to performance, but implementing security
functions in kernel space is intricate as it needs to fit
coherently resource management and protection functions
provided by limited kernel environment. Moreover, AH and ESP defined by IPsec both add frames to the
developing modules in kernel space, such as device drivers, TCP/IP packet itself, ESP also adds an Initialization Vector
generally requires more complicated debugging steps than (IV) and a trailer. The size of this additional data depends on
implementing applications in user space. the IPsec protocol and used mode. Fig. 2 shows ESP protocol
Software solutions, like netmap [5] and Intel DPDK [6], overhead for tests that we conducted.
bypass kernel network stack and provide network interfaces
directly to the user space applications. These platforms Outer IP
ESP header IP packet ESP trailer
improve system I/O performance as they achieve 10Gbps line header
speeds for minimal sized packets. These software tools will be 20 Bytes 16 Bytes 42 - 1500 Bytes 14 - 45 Bytes
used to determine capabilities of IPsec packet processing.
The paper is organized as follows. Impact of the IPsec Fig. 2. IPsec overhead with ESP protocol in tunnel mode.
overhead on performance is examined in Section 2. Sections 3
and 4 describe main features of strongSwan and Rockhopper ESP provides confidentiality protection of different
VPN solutions. Section 5 presents testing environment, and encryption algorithms. In our tests we used AES (Advanced
Section 6 presents results of the performance evaluation. Encryption Standard) algorithm with 256 bits long cipher
Finally, Section 7 concludes the paper. blocks. For every packet, ESP trailer is expanding to a size
that fits the AES cipher block size.
II. IPSEC PROTOCOL OVERHEAD
IPsec protocol encapsulates IP packet with AH or ESP
fields which imposes additional overhead in 10Gbps data
transfers. In this section, we analyse the influence of this
overhead on the transfer rates of IP packets.

Start of Ethernet Ethernet Interpacket

Layer Preambule frame IP packet
delimiter header trailer gap

7 Bytes 1 Byte 14-18 Bytes 42 - 1500 Bytes 4 Bytes 12 Bytes

Ethernet
Layer
← 60 – 1522 Bytes →

Physical
layer
← 68 – 1530 Bytes →

Fig. 1. IP packet encapsulation in Ethernet frame.

Fig. 1 depicts an IP packet encapsulated in Ethernet frame.

After adding all necessary fields for transferring IP packet
between two peers in the same network medium, IP packet is
encapsulated into a frame on physical layer which size vary
between 68 and 1530 bytes. Every packet transmitted on
physical layer is followed by an interpacket gap, which
represents idle time between packet transmissions. For 42
bytes long IP packet, it is necessary to send 80 bytes (or 84
bytes for 802.1Q standard) on physical layer.
Operating system communicates with the NIC (Network
Interface Controller) to send or receive Ethernet packets.
Parameter Packets per Second, PPS, can be calculated using
equation:
Bm
PPS = (1)
(20 + Psize ) *8
where parameter Bm is the maximal bit rate of the port,
and Psize is the Ethernet packet size. In Equation (1), 20 bytes
are added fields on physical layer which represent preamble,
start of frame delimiter and interpacket gap.
Fig. 3. Comparison of maximal PPS with and without ESP protocol
overhead.
Due to the alignment, ranges of slightly different IP
packets will have the same IPsec packet sizes. Equation (2)
defines IPsec packet size with ESP protocol in tunnel mode:
 Pl + Bsize − Pl mod Bsize + X , Pl mod Bsize ≠ 0
Pipsec =  (2)
 Pl + X , Pl mod Bsize = 0
In (2), IPsec packet size is defined as Pipsec , Pl represents
data intended for encryption, Bsize is cipher block size, and
parameter X represents combined overhead which includes
ESP header, outer IP header and static fields in ESP trailer.
For observed case of cipher block size of 256 bits, IPsec
overhead vary between 50 and 81 bytes. PPS can calculated
as:
Bm
PPSipsec = (3)
(20 + Pip sec ) *8
 Equation (3) shows that every packet has additional
overhead between 70 and 101 bytes. Fig. 3 shows comparison
between PPS and PPSipsec for different packet sizes on
10Gbps link. The largest packet throughput, PPS, is
14.88Mpps which is achieved for shortest packets 64 bytes
long. The largest PPSipsec value, in the case of IPsec, is
8.56Mpps for shortest packets of 64 bytes, which is about
42.5% slower than the maximal packet throughput with no
IPsec.
III. STRONGSWAN
StrongSwan was originally based on a discontinued
FreeS/WAN project. StrongSwan has IKE daemon that has
been written in a modern object-oriented coding style.
Initially, strongSwan IKE daemon only supported IKEv2.
IKEv1 was handled by an extended version of FreeS/WAN's
Pluto daemon. Support for IKEv1 was added to the new
daemon with strongSwan 5.0.0, because adoption of IKEv2
by other vendors took longer than it was anticipated.
IKE daemon operates in user space. Also this daemon
configures AH and ESP protocols in kernel, and
communicates with them through kernel. This is some of the
strongSwan advanced features:
• Fully tested support of IPv6 IPsec tunnel and transport
connections;
• NAT-Traversal via UDP encapsulation and port floating
(RFC 3947);
• Secure IKEv2 EAP (Extensible Authentication Protocol)
user authentication;
• Authentication based on X.509 certificates or preshared
keys;
• Retrieval and local caching of Certificate Revocation
Lists via HTTP or LDAP;
• Full support of the OCSP (Online Certificate Status
Protocol - RFC 2560);
• Certificate Authority management (OCSP and CRL
URIs, default LDAP server);
• Support of Diffie-Hellman Elliptic Curve groups and
Elliptic Curve Digital Signature Algorithm certificates
(Suite B, RFC 4869).
The focus of strongSwan is on: (i) Simplicity of
configuration; (ii) Strong encryption and authentication
methods; (iii) Powerful IPsec policies supporting large and
complex VPN networks; (iv) Modular design with great
expandability.
IV. ROCKHOPPER VPN
Rockhopper VPN software implements all components of
IPsec protocol in user space only, including ESP protocol
stack. This is implemented using the standard TUN/TAP
device driver supported by the most recent Linux operating
systems. The TUN/TAP device driver emulates virtual
Ethernet functionality. Using TUN/TAP, the ESP protocol
stack is connected to the TCP/IP network stack in kernel space.
The network processing by TCP/IP stacks, such as IP routing
and MAC address resolution, is already completed for the
packet that reaches a virtual Ethernet interface. Rockhopper
VPN encapsulates packets and send them to the appropriate
IPsec tunnel by searching the mapping table storing the
destination MAC address and Security Parameter Index (SPI).
This design decision enables more flexible and useful
development platform for advanced or experimental IPsec
functions.
Rockhopper VPN run two independent processes during
the execution. One of these processes is using privileged
administrator capabilities, and it is used to process protected
services, such as the key store service that manages
authentication information like public/private key pairs, digital
certificates, and Pre-shared Keys (PSK), as well as the
configuration service for provisioning network stacks such as
network interfaces and routing tables.
The other Rockhopper process is used for components that
are executed with restricted user capabilities. These
components handle communication with external entities, such
as the IKE protocol stack or a Web-based management
interface using the socket API. Both processes interact with
each other to provide the VPN service as a whole.
This software contains a different functionalities: Virtual
Ethernet (Ethernet over IPsec), Routing-based VPN, Role-
based ID management and configuration, AJAX-based
(Comet) Web management interface for configuring and
monitoring, and so on.
Users or developers can use Web management interface to
easily develop or customize their original management tools
or consoles on Web browsers.
V. TESTING ENVIRONMENT
Tests were performed using three physical machines
connected with 10Gbps links, shown in Fig. 4. Machine R1
generate IP traffic toward the VPN gateway. Using ESP
protocol, IPsec tunnel was established between VPN gateway
and physical machine R2. VPN gateway encapsulates all
incoming IP packets from R1 and sends them to R2. Physical
machine R2 decapsulates received ESP packets and measures
data rates on NIC interfaces ens6f1.
EPS tunnel
eth0 10Gbit/s enp1s0f0 enp1s0f2 10Gbit/s ens6f1
R1 R2
VPN Gateway
Fig. 4. The testing environment.
VPN gateway and R2 have strongSwan and Rockhopper
VPNs installed, respectively. IPsec tunnel is established using
the same VPN software on both sides. ESP protocol uses the
following configuration for the established IPsec tunnel:
 • Encryption Algorithm - 256 bit key AES-CBC PPS value is around 2Mpps.
(Advanced Encryption Standard - Cipher Block The second and third tests were conducted for strongSwan
Chaining); and Rockhopper VPN with 4 data flows. Fig. 6 shows
throughput measured by packets per second for strongSwan
• Integrity Algorithm - 256 bit key SHA2_512_256 and Rockhopper VPNs together with the maximal possible
HMAC (Secure Hash Algorithm 2 Hash-based Message throughput. This figure also show experimental and maximal
Authentication Code); throughputs when the IPsec is disabled.
• Pseudo-random Function - SHA2_512 PRF;
• Diffie Hellman Group - 2048 bit, DH Group 14,
modp2048.
StrongSwan and Rockhopper VPNs are using this
configuration, so that the parameters of the testing
environment are as similar as possible.
We use fixed size packets in our tests, which can belong to
one or multiple flows. A data flow is a sequence of packets
from a source to a destination peer, with the same IP/TCP
headers. Many modern NICs have RSS (Receive Side
Scaling) feature that enables kernel-mode network processing
load across multiple processor cores. When RSS is enabled,
the data flows are distributed across different processing
cores, providing parallel packet processing in kernel space.
Generating multiple data flows enable us to evaluate RSS
feature on the overall system network performance, with or
without IPsec tunnel.
Regardless of the RSS feature, Linux kernel packet
processing on 10Gbps links is very demanding due to data
copying, meta-data management and system call overhead.
Fig. 5. PPS values on R2 interface for different number of flows comparted
The highest PPS value on 10Gbps links is 14.88Mpps. Our with maximal theoretical PPS values.
preliminary tests show that Linux kernel network stack can
achieve 2.5 Mpps at best. Thus, R1 is using Intel DPDK
packet generator. This packet generator can process
14.88Mpps by using a single CPU core.
R1 sends IP packet to VPN Gateway, where strongSwan or
Rockhopper VPN encapsulates the IP packet into ESP packet.
Same VPN software decapsulates ESP packets on R2. Also,
R2 is measuring data rate for received and decapsulated IP
packets. From measured data rates we were able to calculate
PPS.

VI. PERFORMANCE EVALUATION

We conducted three tests. For all tests, R1 generated
packets between 64B and 1500B in range from one to six data
flows. Every stream of packets was measured for 30 second in
which the average packet throughput, PPS, was calculated and
recorded. The measured data rates and PPS were used to
compare the performance of strongSwan and Rockhopper.
In the first test, IPsec was disabled. The purpose of this test
is to determine capabilities of kernel in our testing
environment. Fig. 5 shows PPS values for different numbers
of data flows measured on the R2 interface. The PPS values in
Fig. 5 have small variance for different measurements, and the
best overall PPS is achieved for 4 data flows. Our physical
Fig. 6. StrongSwan and Rockhopper VPN PPS values for 4 data flows,
machines use CPUs with 4 cores, and the best mapping with together with the maximal possible throughput.
RSS features is achieved for 4 data flows. The maximal PPS
value that we measured is 2.5Mpps, and the maximal average Packet throughput of StrongSwan does not change
significantly as packet sizes vary. The maximal strongSwan
packet throughput is 0.35Mpps, which is much smaller than
the maximal theoretical IPsec packet throughput for 10Gbps
links, as shown in Fig.6. The maximal packet throughput of
Rockhopper VPN is unacceptably low, equal to, 0.054Mpps.
Fig. 7. StrongSwan and Rockhopper Gbps values for 4 data flows, together
with the maximal possible throughput
The throughputs of Fig.6 measured in Gbps are presented in
Fig.7. StrongSwan minimal and maximal data rates are
0.9Gbps for 64B packet size and 4.2Gbps for 1500, packet
size respectively. Rockhopper minimal and maximal data
rates are 0.01Gbps for 64B packet size, and 0.64Gbps for
1500 packet size respectively. The maximal network kernel
performance degradation caused by strongSwan is 84.5 %,
and the maximal degradation caused by Rockhopper is 98.7%.
The encryption algorithms used in IPsec protocol require
intensive processing, and many commercial IPsec routers use
hardware acceleration modules to achieve required speeds.
Also, there are software routers that use IPsec optimization
with GPU cards which are well suited for cryptographic
processing [7]. Paper [8] explores PacketShader, a high-
performance software router framework, in combination with
massively-parallel processing power of GPU to address the
CPU bottleneck in current software routers. The results of
initial tests with CPU-only IPsec packet processing with
optimized RouteBricks software framework is 1.9Gbps for
64B and 6.1Gbps [9]. They were able to outperform
RouteBricks by factor of 3.5 regardless of packet sizes. Paper
[10] proposed exploiting parallelism to scale RouteBricks
software router, and achieved 1.4Gbps for 64B on a single
RouteBricks router. In all these cases, simplified IPsec
processing was assumed, and it was shown that it demands
large computing resources, so that CPU becomes a bottleneck
in packet processing path through system.
StrongSwan uses AH and ESP protocol that are
implemented in kernel space. Depending on the CPU type,
kernel can use different cryptographic optimization
mechanisms such as Intel AES-NI [11]. This can partially
improve performance of IPsec packet processing. In addition
to the performance optimization, kernel space provides faster
network processing environment, because packets do not
travel to user space. All mentioned optimization mechanisms
give advantage to strongSwan when compared to the
Rockhopper VPN.
However, software platform that bypass kernel, such as
DPDK and netmap, provide very fast I/O interface to user
space with unnoticeable impact on CPU performance. User
space application such as Rockhopper VPN could be
significantly improved with fast I/O interface and encryption
algorithms optimizations mentioned in [8] and [10].
VII. CONCLUSION
We looked how IPsec overhead affects maximal packet
throughputs on 10Gbps links. IPsec protocol overhead
depends on used protocols (AH or ESP) and encryption
algorithms. We presented and tested two different types of
VPN software implementations, strongSwan and Rockhopper.
These two IPsec softwars comprise a complete set of IPsec
algorithms and options, and can be used in practice. The
extent of performance degradation caused by IPsec
functionality of strongSwan and Rockhopper was analyzed.
Both protocols have unacceptably low performance for
shortest packets which is less than 0.5Mpps. However,
strongSwan can achieve 4Gbps for largest packets.
StrongSwan has much better performance than Rockhopper as
it is implemented in kernel. Performance of Rockhopper
which is implemented in user space, might be improved by
bypassing of kernel with softwares such as DPDK and
netmap, and by utilization of different encryption algorithms
optimization mechanisms.
ACKNOWLEDGMENT
This work was supported by the Serbian Ministry of
Science and Education (project TR-32022), and companies
Telekom Srbija, and Informatika.
REFERENCES
[1] "RFC4301: Security Architecture for the Internet Protocol," Network
Working Group of the IETF, 2005. [Online]. Available:
http://tools.ietf.org/html/rfc4301#page-4. [Accessed 2016].
[2] E. Guillen, A. M. Sossa and E. P. Estupiñán, "Performance Analysis
over Software Router vs. Hardware Router: A Practical Approach," in
World Congress on Engineering and Computer Science WCECS, San
Francisco, 2012.
[3] A. Steffen, "strongSwan," Institute for Internet Technologies and
Applications, 2005. [Online]. Available: https://www.strongswan.org/.
[Accessed 2016].
[4] T. Hanada, "Rockhopper VPN," 2011. [Online]. Available:
http://rockhoppervpn.sourceforge.net/. [Accessed 2016].
[5] L. Rizzo, "netmap: a novel framework for fast packet I/O," in USENIX
Annual Technical Conference, 2012.
[6] "DPDK - Data Plane Development Kit," Intel, 2011. [Online].
Available: http://dpdk.org/. [Accessed 2016].
[7] O. Harrison and J. Waldron, "Practical Symmetric Key Cryptography on
Modern Graphics Hardware," in USENIX Security Symposium, Dublin,
2009.
[8] S. Han, K. Jang, K. Park and S. Moon, "PacketShader: a GPU-
Accelerated Software Router," in SIGCOMM, New Delhi, 2010.
[9] "RouteBricks," 2009. [Online]. Available: http://routebricks.org/.
[Accessed 2016].
[10] M. Dobrescu, N. Egi and K. Argyraki, "RouteBricks: Exploiting
Parallelism To Scale Software Routers," Intel Labs Berkeley, Lausanne,
2008.
[11] "Intel® Data Protection Technology with AES-NI and Secure Key,"
Intel Corporation, 2016. [Online]. Available: http://goo.gl/N6lsPi.
[Accessed 2016].