Analysis of Current VPN Technologies
Thomas Berger
University of Salzburg
tberger.tks2000@fh-salzburg.ac.at
Abstract
This paper deals with current Virtual Private
Network (VPN) technologies, such as Internet Protocol
Security (IPSec), Layer Two Tunneling Protocol
(L2TP), and Point to Point Tunneling Protocol (PPTP).
Furthermore, the VPN solution of the Austrian
company phion Information Technologies is presented.
After a short introduction to the basics of each
protocol, the strengths and weaknesses of each
technology are outlined, as far as interoperability,
manageability, and practical problems is concerned.
This is done by means of a practical analysis and
comparison of the results. The analysis includes
performance measurement, link quality and stability
analysis, feature comparison, interaction with TCP/IP
protocols, and some basic security attacks. In order to
provide comparable results, all technologies were
tested in the same manner. However, this paper does
not provide explicit recommendations which technology
is to be preferred.
1. Introduction
Data transmission protocols, which are used in the
internet, such as TCP/IP, are originally not designed to
provide data security. In this context, the term security
can be understood as follows: if Alice and Bob wish to
exchange private information in an electronic way, and
Mallory wants to listen into the transmission in order to
find out its content, the transmission is determined as
secure, when Mallory has no chance to succeed. In other
words, by means of data encapsulation, encryption and
authentication, Mallory cannot use the transmitted data.
This is reached by adding secure protocols, such as
IPSec, L2TP or PPTP to the existing protocols which are
used in the internet. These technologies provide secure
data tunnels over an insecure network, which are
referred to as Virtual Private Networks. For more
general information on VPN technologies and
cryptography, refer to [1], and [2]. However, adding
secure technologies to existing, insecure protocols does
not come without drawbacks. Either, the specific
standards are not sophisticated enough to provide secure,
stable and fast data links, or interaction with lower-
levelled protocols causes serious problems. The
following sections cover basic knowledge on the
principles of each technology, and document the
practical analysis, which is performed in respect to the
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
problems mentioned above. Analysis and comparison of
VPN technologies is also the main topic of [6]. In
section 3.1, IPSec policy problems are discussed; [7]
presents a solution for this problem by implementing
policies by means of Boolean expressions. [8] deals with
problems of adding IPSec technology to existing TCP/IP
infrastructure (see also section 3.2.). The authors ported
the open-source IPSec implementation FreeS/WAN to a
router and analyzed its behavior. This paper is based on
[10], where beside the VPN technologies and practical
analysis also symmetric and asymmetric ciphers are
described. [11] deals with a comparison of commercial
and non-commercial IPSec implementations. Further,
Photuris, an alternative key-exchange protocol, is
presented. Another reference, [12] contains a
comparison of VPN protocols, such as PPTP, L2TP,
IPSec, tinc and openVPN in respect to aspects such as
installation, configuration and maintenance.
2. VPN technologies
In this section the widespread VPN technologies
IPSec, L2TP, and PPTP are described. These
technologies are widely used, and well researched;
there are both commercial products and open-source
implementations which rely on these technologies. The
phion VPN solution is introduced and also described in
the same manner.
2.1. IPSec
IPSec provides a collection of standardized
protocols and techniques to establish secure VPN
connections. Raw internet protocol (IP) packets are
basically not secure, since data (such as IP address in
the IP header, the payload, etc.) can be changed or
wiretapped during transmission. IPSec enables
transmission security at IP layer. Therefore, it cannot be
used in combination with other network-layer
protocols.
IPSec ensures data security by means of packet
authentication, checking packet integrity and
encapsulation. Since IPSec is standardized, it is, in
principle, possible to establish VPN tunnels between
IPSec gateways of different manufacturers. However,
IPSec determines basic exchange methods and
protocols, but it does not explicitly prescribe which
level of security (e.g. if packets are encapsulated, type
of cipher, etc.) is to be used. There are two basic modes
 of IPSec connections, transport mode and tunnel mode.
When IPSec is operated using transport mode, a so-
called IPSec header is added to the original IP header.
This IPSec header contains authentication and integrity
information. Tunnel mode provides more flexibility,
because each original IP packet is surrounded by a new
IP packet, which consists of a new IP header and the
IPSec header. Therefore, information on the content of
the original IP packet is hidden in the payload of the
new IP packet.
In order to determine which IPSec mode is applied,
both connection partners have to agree on a common
security association (SA). It contains information on
the IPSec mode, symmetric ciphers, and keys which are
used during secure data transmission. Of course, both
partners have to keep their SA secret, and exchange of
SA information must be done by means of a public-key
protocol.
There are two different types of IPSec headers, the
Authentication Header (AH), and Encapsulating
Security Payload (ESP). The authentication header
contains information providing data authenticity and
integrity, and contains a Security Parameter Index
(SPI), authentication data and an integrity checksum
(MD5 or SHA-1 hash) on the whole IP packet. Since
AH does not include encryption methods, it does not
offer privacy. Therefore, ESP, which includes data
encryption, is more often used than AH. The ESP
header includes an initialization field, which is used by
symmetric block ciphers. When IPSec is used in tunnel
mode and ESP, it provides a maximum of security and
flexibility.
The internet key exchange protocol (IKE) is used to
establish IPSec connections, exchange encryption keys,
and sharing authentication data. It is also referred to as
negotiating - both tunnel partners negotiate the
parameters of the VPN connection in order to agree on
a common SA. IKE messages are exchanged via UDP
packets at port 500, and rely on the Internet security
association and key management protocol (ISAKMP).
When establishing an IPSec connection, there are two
phases of negotiations. During phase one, the SA for
IKE is negotiated. Of course, there is no data
encryption or authentication at that point of time.
Therefore, both tunnel partners have to authenticate
themselves, and exchange keys using the Diffie-
Hellman key exchange method. This is an asymmetric
public-key protocol which relies on the complexity of
solving the discrete logarithm problem, refer to [1] for
details.
Once an IKE SA is established, phase two is initiated.
During this phase, which is already protected by the SA
determined during phase one, the parameters for the
VPN tunnel(s) are negotiated, including symmetric
cipher keys (and key expiry information), security
policy, network routes, and other connection-relevant
information. After that, data can be exchanged in a
secure way. Since keys should always have a limited
time of validity, a process of re-keying should be
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
performed periodically. For this purpose, only phase
two is repeated - the complete IKE process including
both phases is only performed at time of connection
establishment. However, IPSec does not prescribe re-
keying in general, which depends on the
implementation. For detailed information on the IPSec
standard, refer to [3].
2.2. L2TP
The layer two tunneling protocol is based on the
Layer Two Forwarding protocol (L2F), which is
described in [RFC2341]. It enables encapsulation of a
complete data-link-layer frame (e.g. an Ethernet frame)
into a UDP packet at transport layer. Therefore, a data
packet with local (or private) network addresses can be
sent through the internet. The UDP packet, carrying the
layer two frame, consists of the following data fields:
after the UDP header (port 1701), several control bits
represent various options, version, and length of the
packet. After that, sequence number and tunnel-ID
fields keep track of the current VPN connection in
order to ensure correct packet processing. Then, layer
two frame follows, containing, for example, media
access code (MAC) addresses, and the payload. It is
obvious, that solely encapsulating a layer two frame
into a UDP packet does not provide data authenticity or
privacy. Therefore, L2TP is often combined with IPSec
by adding the IPSec header in front of the L2TP header.
Of course, IPSec transport modus is applied in this
case, as encapsulating the L2TP packet (which already
encapsulates a layer two frame) into a new IP packet
would result in excessive protocol overhead.
2.3. PPTP
Microsoft’s point-to-point tunneling protocol is an
extension to the point-to-point protocol (PPP) and is
supported by any version of Microsoft Windows, which
is described in [4]. PPTP uses two different packet
types to establish a VPN connection. First, generic
routing encapsulation (GRE) packets carry the VPN
payload by adding the GRE header to the original
packet. The GRE header is quite similar to the L2TP
header, and contains various control bits, sequence and
tunnel numbers. The second packet type is the PPTP
control message. This is simply a TCP packet (port
1723), containing control information, such as
connection requests and responses, connection
parameters, and error messages. Since neither GRE nor
PPTP messages provide authentication or encryption,
PPTP must be combined with additional security
methods. For this purpose, Microsoft uses the challenge
authentication protocol (MS-CHAP) in order to
authenticate both tunnel partners. For data privacy,
GRE payload is encrypted using the symmetric RC4
stream cipher.
Thus it appears that the design of PPTP is quite simple.
 Because Microsoft Windows is widely used, PPTP can
be applied to establish VPN connections between the
networks of internet service providers and their
customers, who do not have to install additional VPN
software. In Austria, PPTP is used to establish ADSL
connections, as PPTP is low-cost and GRE packets do
not add much protocol overhead.
2.4. phion VPN
The Austrian company phion Information
Technologies ([5]) develops and sells security gateway
software called netfence, which includes a VPN
solution. Netfence is a commercial product providing a
complete IT-security solution for enterprise networks,
including firewall, VPN, mail and web security with
central management and monitoring capabilities. VPN
tunnel establishment is performed by means of a newly
developed handshake process. Establishing VPN
tunnels is described as follows, using the terms initiator
as the Client who wants to establish a connection, and
responder acting as server which checks the identity of
the initiator before a VPN tunnel is established.
At time of configuration, a unique tunnel-id string is
assigned to each VPN connection. First of all, the
initiator sends a tunnel request, including the tunnel-ID,
to the responder, which keeps an encrypted server-
cookie in a file. The server does not need to calculate a
new cookie every time when an initiator sends a
request, but it can use the stored cookie, which provides
a basic denial of service (DOS) protection of the VPN
server. The server cookie is sent to the initiator, which
has to decrypt the cookie in order to authenticate him.
After decryption the server cookie is returned to the
server, together with an encrypted client-cookie. The
responder checks the decrypted server cookie and
decrypts the client-cookie received from the client.
After successful authentication, both partners generate
new cookies, so an eventually wiretapped cookie can no
longer be used. The next step is exchange of tunnel
parameters, such as ciphers, network routes, and
various options. After that, the VPN connection is
established.
The messages exchanged during the handshake process
rely on a proprietary protocol called transport
independent network architecture (TINA). Using UDP
at port 691, TINA messages consist of length and
message type fields. There are several message types,
such as tunnel requests, cookie exchange,
authentication, tunnel keep-alive messages, and re-
keying requests. By means of these messages, the VPN
link is under constant surveillance, and re-keying is
performed periodically.
After successful connection establishment, VPN traffic
can be exchanged by four different tunnel modes,
which are determined at time of configuration. The first
and second one, named TCP and UDP tunnel, add an
additional TCP header, or UDP header to the
encapsulated packet. The third tunnel mode, referred to
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
as hybrid mode, represents a combination of TCP and
UDP tunnels, sending TCP traffic into a UDP tunnel,
and vice versa. Since it is not efficient sending TCP
traffic into a TCP tunnel, resulting in double TCP
traffic ensuring mechanisms (such as retransmission,
acknowledgement ...), hybrid mode was introduced. On
the other hand, sending UDP traffic into a UDP tunnel
would not provide any transmission ensuring methods,
since UDP is not connection oriented. The last tunnel
mode is ESP, which is equivalent to IPSec ESP.
3. Problems caused by VPN
Current VPN technologies suffer from the fact that
originally, protocols used in the internet, were not
designed to provide data security, and technologies
presented in the previous section were added
afterwards. This causes several drawbacks, which are
described in the following section.
3.1. Technology-specific aspects
Development of IPSec followed a long lasting
process, and suffers from its complexity. The IPSec
standard, in general, aroused disappointment within the
IT industry. Tunnel negotiations using IKE should
provide VPN connections between security gateways of
different vendors, but they are complex and inefficient.
Therefore, many implementations do not fulfill all
requirements of the IPSec standard, leading to reduced
interoperability capabilities. Another drawback of
IPSec is the fact, that important and necessary
mechanisms are not part of the standard. For example,
there is no mechanism for tunnel probing to check
whether a tunnel partner is still reachable or not. Only
at time of re-keying, tunnel status information is
exchanged. This could eventually lead to loss of VPN
connectivity, and tunnel downtime. Further, IPSec does
not include any policies for network route exchange,
i.e. which network routes are allowed for VPN
connections. In the worst case, a VPN partner could
propagate a default route (0.0.0.0/0) for VPN
connections, and all hosts in the network would use this
route instead of their original default route, leading to
loss of internet connectivity. IPSec places the burden of
tunnel probing and network route policy on the
developers of IPSec implementations.
As already mentioned, L2TP does not include
mechanisms for authentication and data privacy. Thus,
it is not suitable for mission-critical applications.
Internal network addresses and the payload are not
encrypted, and transmitted in plain text. Combining
L2TP and IPSec provides a solution for this problem,
but comes with several other drawbacks. Since IPSec
and L2TP headers are added to each packet, protocol
overhead is very high, which leads to decreased VPN
performance. VPN protocol overhead in general causes
problems, which are outlined in the following section.
Originally, PPTP did not include mechanisms for data
 authenticity, integrity and privacy, as well as L2TP.
Microsoft combined PPTP with the asynchronous
authentication protocol MS-CHAP, and GRE packets
are encrypted by means of the symmetric stream cipher
RC4. These mechanisms offer a basic security level,
but do not meet high security standards. Bruce Schneier
describes in [9] the drawbacks of PPTP using MS-
CHAP and RC4, and presents weaknesses ant possible
points of attack.
Phion VPN is part of the commercial product called
netfence security gateway series, and therefore only
available in combination with this product. The
connection handshake protocol, and TINA,
respectively, which were described in the previous
section, are not standardized and therefore only applied
within phion netfence systems. However, one of the
critical aspects of a cryptosystem is that it is fully
researched by specialists, and its security is proven by
resisting all kinds of known security attacks. Phion
VPN is a fairly new product, and not widely applied; as
such it is not that researched and tested like the other
presented VPN technologies. Anyway, there are no
weaknesses and security issues reported so far. In order
to ensure interoperability with other VPN system
vendors, netfence also includes an IPSec
implementation.
3.2. Interaction of VPN with TCP/IP
As already mentioned before, secure VPN
technologies were added to existing internet
technologies. This may cause several undesired issues.
Network address translation (NAT), which translates
private IP network addresses (e.g. 192.168.x.x) into
public IP addresses, which can be routed through the
internet, could lead to various problems, since it means
a modification of an IP header.
VPN technologies, such as IPSec transport mode, do
not allow any changes to the IP packet, because
authentication and packet integrity checks (MD5 or
SHA-1 hash) would fail if an IP header is modified by a
routing device during transmission. By means of
network address port translation (NAPT), which
enables a router to translate various numbers of internal
network addresses into one public IP address, a router
keeps track of the single connections by modifying the
source port address in the TCP (or UDP, respectively)
header. However, since also the payload of an IP packet
cannot be changed during transmission without
violating integrity checksums, NAPT cannot be
applied. When a VPN technology is used, encapsulating
a whole IP packet into a new one, a router cannot keep
track of the original TCP header.
The interaction of VPNs and firewalls, in practice, and
under circumstances, may cause other problems. Of
course, firewall packet filtering rules must be con-
figured properly, and in the best case, VPN and firewall
functionality is performed by the same device (which is
often referred to as security gateway), which
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
dynamically decides, according to its routing table,
which traffic is to be sent through a VPN tunnel. But if
there are any other firewalls on the route through the
internet (e.g. located at the internet service providers),
which filter VPN packets, an alternative way must be
found in order to establish a VPN tunnel.
Another challenging problem related with VPN and IP
is the fact that VPN technologies add additional
transmission protocol overhead. As a consequence, the
maximum transmission unit (MTU) of a packet is
reached earlier. IP provides a mechanism to counter this
problem, called fragmentation. If the size of an IP
packet would increase a pre-determined value, the IP
packet is fragmented, and the corresponding flags in the
IP header are set. It is obvious that packet
fragmentation means a modification to the IP packet,
causing VPN packet integrity checks to fail. Setting the
“don’t fragment” flag in the IP header before adding the
VPN header seems to be a fast and simple solution for
this problem. But transmitted packets through the
internet can sometimes not be processed by routers (or
other network devices), and will simply be discarded
when the size exceeds a critical value, and the don’t
fragment field is set. VPN technologies add additional
data overhead, but they also suffer from causing
additional packet processing time, resulting in increased
packet round-trip time and decreased data throughput.
Packet authentication, encapsulation, adding VPN
headers and checksums, and especially encryption
algorithms need extra calculation time. In most cases,
the effects are not dramatic, causing file transfers to last
longer. But when using response time critical
applications (such as multimedia applications, database
access systems), VPN technologies could lead to a
significant loss of performance, and in the worst case,
these applications do no longer work, because they
permanently run into time-outs.
These are the major problems caused by adding VPN
technologies to existing technologies. However, VPN
implementations provide different solutions, which are,
among other aspects, analyzed in the following
sections.
4. Practical analysis
This section documents the practical analysis of the
presented VPN technologies. Each testing scenario is
described by explaining the testing environment, testing
method and the results of each test, including a table for
comparison.
4.1. Testing environments
The testing environment for IPSec tests is illustrated
in figure 1. Four different VPN appliances and their
interaction with the phion netfence IPSec
implementation were tested:
 • Cisco Systems Pix 501
• Netscreen 5XP
• Soho Watchguard WG2500
• Symantec FW/VPN 100

Figure 2: L2TP/PPTP testing environment

Figure 1: IPSec testing environment

The Linux workstations Alice and Bob were target

workstations which exchanged data, either directly (via
the Ethernet network 10.0.6.0/24, not shown in the
diagram), or via the IPSec tunnels between the phion
netfence gateway and the different appliances.
Therefore, Alice and Bob got assigned IP addresses
from the network 172.16.0.0/16, and 192.168.0.0/16,
respectively, as shown in the diagram. The workstation
called Mallory was put into the VPN network
172.31.70.0/24 (wiretap VPN traffic) and into
172.16.0.0/16 (wiretap normal traffic).

Since phion VPN gateways also support L2TP and

PPTP tunnels, one tunnel side was provided by a phion
system, on the other side (Alice), a Microsoft Windows
XP professional workstation was installed, because
Figure 3: phion VPN testing environment
both L2TP and PPTP are supported (WAN miniport).
In order to distinguish the two types of VPN tunnel,
For the various test series, beside the used operating
different IP addresses were used, as shown in figure 2.
systems and VPN gateway software, special
L2TP was configured in combination with IPSec,
applications were used to generate and analyze IP
because in practice, this level of security is widely
traffic. For this purpose, open-source software was
applied. The phion router gateway between the phion
used.
VPN gateway and Alice just performed packet
For packet analysis, the free program Ethereal was
forwarding and address translation; Bob was a Linux
used. For traffic generation, throughput and roundtrip
workstation and exchanged data with Alice either
time measurement, Iperf was used. Iperf is a command-
directly or through the two different VPN tunnels, and
line oriented tool for generating UDP or TCP data.
Mallory was used to wiretap and analyze traffic
Further, for packet manipulation and security attacks,
(equivalent to the IPSec testing environment).
Hping was applied in order to infiltrate self-designed
packets into the network.
For testing phion VPN connections the testing
environment which is illustrated in figure 3 was
In order to get comparable test results, the configuration
installed and configured. Between the phion VPN
of all different VPN technologies must be as similar as
gateways, a router was placed to perform forwarding
possible. However, since the tested VPN technologies
and translation tasks. Alice and Bob were Linux
use different techniques for connection establishment
workstations, and Mallory was also included for
(e.g. IPSec uses Diffie-Hellman key exchange, PPTP
wiretapping. These workstations had the same purpose
uses MS-CHAP, phion VPN uses the described
as described in the previous testing environments.
handshake-process), a complete identical configuration

Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
 was not possible. Anyway, these testing configurations
deliver comparable results, and since for all testing
environments the same hardware is used, which is
naturally always faster by far than the maximum
throughput of the network traffic would require,
differences in throughput and roundtrip measurement
can be lead back to the properties of each VPN
technology. The configuration parameters of all VPN
technologies are listed in table 1.
Table 1: VPN Configuration
4.2. Basic functionality
The first test series considers basic VPN
functionality, such as VPN tunnel establishment time,
link quality, and tunnel re-initiation time. VPN tunnel
establishment time was measured using Ethereal, with
provides accurate time stamps on the transmitted
packets. Alice and Bob exchanged ICMP (ping)
messages (with a time interval of 100ms).
After successful tunnel initiation, these ICMP messages
reached their destination. The time interval between the
first packet of tunnel initiation and the first transmitted
ICMP message was measured, and documented in table
2 (Init. time).
For link quality measurement, Alice and Bob
exchanged 1400-Byte ICMP messages, and the
roundtrip time (RTT) was measured. This test was also
performed for the direct connection (without VPN) in
order to outline which additional packet processing
time is necessary when using a VPN technology.
The third test series of this testing scenario considered
tunnel re-initiation time, with other words, how long
does it take that after connection interruption a VPN
link is up again. For this purpose, Alice and Bob
exchanged (every 100ms) ICMP messages through the
VPN tunnel. Then, network link (between the two VPN
gateways) was manually interrupted by disconnecting
the network link. After 10 seconds, the link was
reestablished, and the time between link
reestablishment and the occurrence of the first ICMP
message through the tunnel was measured, which is
also listed in table 2 (Re-init. time).
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
Table 2: Results of basic functionality tests
Although IPSec suffers from a complex connection
establishment process, all IPSec Appliances delivered
acceptable results in tunnel initiation time, while L2TP
and PPTP, and phion VPN tunnels need more time for
tunnel establishment. When considering the results for
RTT (round-trip time) measurement, PPTP shows the
best result, this goes back to the small GRE overhead
and the simple RC4 cipher. All other technologies,
which used 3DES, showed poorer results. The RTT
value for the test where no VPN is used is dramatically
lower than with VPN tunnels, thus it appears that
adding VPN technologies results in a significant loss of
performance. The result of tunnel re-initiation time
measurement shows that IPSec (which does not
prescribe tunnel probing) requires a significant amount
of time, especially the Symantec implementation. This
does not necessarily go back to a bad IPSec
implementation of Symantec, but maybe to a bad
interaction between Symantec and phion IPSec
gateways. This outlines the fact that IPSec
interoperability is not always cleanly guaranteed, which
goes back to the drawbacks of IPSec. L2TP and PPTP
tunnels were not re-initiated automatically, it was
necessary to manually trigger tunnel initiation in
Windows XP. Since phion netfence VPN uses special
protocol messages for tunnel probing, the best result
during this test was achieved by this technology.
4.3. Performance
For performance measurement, Iperf was used to
exchange traffic between the workstations Alice and
Bob. For all VPN technologies, the same amount of
traffic was exchanged: TCP traffic, window size 32
KBytes, duration 10 seconds. The first test series was
performed using only one TCP session, for the second
one, 100 concurrent TCP sessions were generated. Iperf
prints the average throughput; the values are
documented in table 3.
 Table 3: Performance measurement results
Without VPN, a data rate of 94 MBit/sec was achieved,
which approximately corresponds to the maximum
throughput that can be reached by means of 100 Mbit
fast Ethernet connections. Compared with the results of
the different VPN technologies, there is a dramatic loss
of performance, especially when IPSec appliances were
used. The IPSec appliances, which are not equipped
with high performance CPUs, were not able to handle
100 simultaneous TCP sessions through the IPSec
tunnel - all IPSec connections broke down, and had to
be re-initiated. Thus it appears that VPN appliances are
not suitable to be stressed hard. PPTP delivers the best
performance value, but this goes back, as already
mentioned, to the simple RC4 cipher. Additional packet
processing time, which is required when using any
VPN technology, leads to significant loss of
performance.
4.4. Interaction with TCP/IP
The next test series were performed to analyze the
problems of VPNs in combination with TCP/IP, which
are discussed in section 3.2. By means of ICMP
messages (of different size), additional VPN header
overhead, IP packet fragmentation behavior, and
NAT/NAPT capabilities were examined. The first test
considers additional data overhead caused by VPN
technologies. For this purpose, ICMP messages (1000
Bytes size) were exchanged, and the actual size of
packets transmitted through the VPN tunnel was
measured using Ethereal. The results are listed in table
4, where ICMP and ICMP echo messages are printed in
different columns.
Table 4: Actual VPN packet size
Without VPN, only 42 additional bytes of protocol
overhead are added to the original 1000-Byte ICMP
packet. IPSec and phion netfence VPN, which use ESP-
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
packets, cause a total data overhead of 94 bytes. Since
L2TP requires L2TP and IPSec headers, this is the
technology with most data overhead (110 bytes, and
118 bytes for the echo message). PPTP, of course, adds
fewest VPN data overhead. In order to analyze packet
fragmentation behavior, the size of the ICMP messages
was increased to 1600 bytes. Since default MTU of
Ethernet connections is 1500 bytes, these packets need
to be fragmented at IP layer. This test showed
differences in behavior of the VPN technologies, which
are listed in table 5.
Table 5: VPN Packet fragmentation behavior
Packet fragmentation seemed to be no problem for all
VPN technologies, except one: the IPSec
implementation of Symantec, where the destination
workstation could no longer be reached (however, this
may go back to a bad interoperability of different IPSec
implementations). A very interesting point is that the
number of transmitted packets of one ICMP message,
and ICMP echo message, respectively, differs; and
when using Cisco IPSec and PPTP, the “Don’t
fragment” flag of the IP header was set.
For testing NAT / NAPT behavior, the router between
the security gateways (as shown in the testing
environment diagrams in section 4.1) was configured to
perform address translation. Since all tested VPN
technologies (except PPTP) exchanged traffic by means
of ESP packets, where the encrypted and authenticated
IP packet is encapsulated into an other IP packet, the
header of which can be modified, NAT was possible
without problems. With PPTP, where only the payload
is encrypted and authenticated, and not the whole IP
packet, it was also possible to change IP network
addresses during transmission.
4.5. Security attacks
The last testing series was performed to analyze the
VPN technologies from Mallory’s point of view. By
means of Ethereal and Hping, different methods were
tried to find out whether VPN traffic could be disturbed
or wiretapped in any way. However, the applied
techniques are quite basic and low-level, and do not
really represent an all-embracing cryptanalysis, but in
practice, most security attacks rely on these techniques.
Using a network hub, the workstation Mallory was
attached to the network between the VPN gateways to
wiretap network traffic.
However, wiretapping and analyzing VPN traffic
 during tunnel establishment phase and VPN traffic
phase delivered no usable results; no passwords or
other security relevant data was transmitted in plain
text. Therefore, other methods to disturb VPN
connections had to be applied. The first packet for
tunnel initiation request was wiretapped and stored in a
file. By means of Hping, a new IP packet was
generated, using the source IP address of one VPN
gateway, and destination IP address of the other VPN
gateway. The payload of this fake packet was filled
with the content of the previously wiretapped packet.
Therefore, an exact copy of the VPN tunnel initiation
packet was generated by Mallory. The VPN gateways
of all technologies responded with the corresponding
reply message for authentication. Of course,
authentication is practically not possible without the
knowledge of the correct authentication data.
During the next try, the payload of the fake packet was
filled with arbitrary values. All VPN gateways
responded with error messages (e.g. IPSec appliances
reacted with the error message Error: Invalid initiator
cookie). These errors had no effects, even VPN traffic
between Alice and Bob was not affected.
The next test was performed to try a denial of service
(DOS) attack on the security gateways. For this
purpose, the fake tunnel initiation message was sent to
the security gateway in time intervals of 10 ms. Each of
these tunnel requests had to be answered by the VPN
gateways. At the same time, ICMP traffic was
exchanged between Alice and Bob via the VPN tunnels.
Again, this had no effect to all VPN gateways, except
the Watchguard VPN appliance. Here, the VPN traffic
immediately came to an end, Alice and Bob could no
longer reach each other. Wiretapping VPN traffic with
Ethereal showed that the Watchguard appliance
permanently answered Mallory’s fake tunnel requests,
and no ESP packet was generated during this phase,
which results in a successful DOS attack.
5. Conclusion
The results of the tests described in the previous
section show that current VPN technologies offer
secure and quite stable data connections. One
significant drawback which concerns all tested
technologies is the dramatic loss of performance and
throughput, which goes back to the complex
encapsulation and authentication techniques. Thus it
appears that adding VPN technologies to existing
protocols comes with additional complexity and high
data processing costs. IPSec suffers from a complex
tunnel negotiation process, causing interoperability
problems between different implementations. L2TP
offers data privacy and authenticity if and only if it is
combined with IPSec, resulting in excessive data
overhead. PPTP is the fastest of the presented
technologies, but its security level is, for critical
applications, not sufficient (refer to [9]). Finally, phion
netfence VPN offers acceptable solutions for the
Proceedings of the First International Conference on Availability, Reliability and Security (ARES’06)
0-7695-2567-9/06 $20.00 © 2006 IEEE
problems which may occur when using e.g. IPSec, but
it is only available in combination with the commercial
product netfence security gateway series.
References
[1] K. Schmeh, Cryptography and Public Key Infrastructure
on the Internet, John Wiley & Sons Inc., New York, 2003
[2] R. Yuan, W.T. Strayer, Virtual Private Networks:
Technologies and Solutions, Addison-Wesley
Professional, Boston, 2001
[3] N. Doraswamy, D. Karkins, IPSec: The New Security
Standard for the Internet, Intranets and Virtual
Private Networks, Prentice Hall PTR Internet
Infrastructure Series, New York, 1999
[4] E. Lewis, J. Davies, Deploying Virtual Private
Networks with Microsoft Windows Server 2003, Microsoft
Press, Redmond, 2003
[5] PHION Information Technologies GmbH,
Austria, A-6020 Innsbruck, Eduard-Bodem-Gasse 1,
www.phion.com (2006-02-05)
[6] M. Finlayson, J. Harrison, R. Sugarman,
VPN Technologies - A Comparison,
Data Connection Ltd., Enfield, UK,
http://www.cse.iitb.ac.in/˜varsha/
allpapers/network-misc/vpntechwp.pdf (2006-02-05)
[7] H. Hamed, E. Al-Shaer, W. Marrero, “Modeling
and Verification of IPSec and VPN Security
Policies”, In Proceedings of the 13th IEEE International
Conference on Network Protocols (ICNP’05),
pp. 259-278, 2005
[8] L. Jin-Cherng, C. Ching-Tien, C. Wei-Tao
“Design, Implementation and Performance Evaluation
of IP-VPN”, In Proceedings of the 17th International
Conference on Advanced Information Networking and
Applications (AINA’03), p. 206, 2003
[9] B. Schneier, Mudge, Cryptanalysis of Microsoft’s
PPTP, Mountain View, CA,
http://www.schneier.com/paper-pptp.pdf (2006-02-05)
[10] T. Berger, Analyse aktueller VPN Technologien in Bezug
auf kryptographische Methoden, Performance und Tunnel-
management, Dipl. Thesis, University of Salzburg, 2005
[11] C. Draschl, Querkopplung von kommerziellen
und nichtkommerziellen IPsec-Systemen, Dipl.
Thesis, Salzburg University of Applied Sciences and
Technologies, 2004
[12] R. Kämpfe, Analyse und Vergleich von VPN Protokollen,
Dipl. Thesis, University of Mittweida, 2002