1) The document describes a vulnerability in IPSec/L2TP VPN connections where filtering UDP port 500 to drop IKEv2 negotiation packets allows an insecure L2TP connection to still be established, compromising confidentiality. 2) A simulation was created using 3 VMs to demonstrate exploiting this by capturing plain text traffic. 3) The only current workaround is changing the Windows VPN encryption setting, but a patch is needed to fully address the vulnerability.

1. IST 452
Advanced Networking
Professor Attaie
12/19/2014
ITERA Paper
MITM attack on an IPsec/L2TP
VPN connection
BillyGallagher
Linyue Zhang
Kunal Sharma

2. IPSec Vulnerability 1
Introduction
In the ever-growing world of computer networks, the constant objectives of data
and network security are becoming even more of a priority. Organizations need a way to
securely transport data, whether it is via remote access capabilities of end users or
whether it is remote communications between organizations. This is where an IPSec
security operations scheme and an L2TP protocol for establishing a VPN connection has
become so prevalent in successful information security.
The main concept is that remote users can access a VPN over a public IP network
without having to go through dedicated router lines. In this VPN, the internet connection
is made directly to the network, so all applications on the remote user’s device that
require internet access will work with this self-hosted VPN and receive unrestricted
access to any website or web service associated with the VPN.
The two parts of IPSec/L2TP VPN are IPSec and L2TP. IPsec provides
encryption and authentication for the IP packets that are transported between your end
user device and the VPN, providing data confidentiality and integrity. L2TP provides the
virtual “tunnel” for all of this to be possible. IPSec also grants data integrity and
confidentiality by encrypting packets and requiring authentication for packets. It includes
protocols, such as IKEv2, for establishing mutual authentication between agents at the
beginning of the session and negotiation of cryptographic keys to be used during the
session.
Explanation of the Problem
When a user connects to a VPN server, it goes through the following process:
1. A user at an IPSec/L2TP client initiates a connection to a VPN server.
2. The IPSec/L2TP client starts an IKEv2 (Internet Key Exchange) negotiation with the
VPN server on UDP 500.
3. Both peers exchange encryption keys, and the IKE negotiation ends.
4. Encryption is now established between the client and the VPN server. All connections
are encrypted inside this VPN tunnel, using the IPSec standard.
5. The Client starts a short L2TP negotiation, at the end of which the client can pass to
the VPN server L2TP frames that are IPSec encrypted and encapsulated.
Normally, if the key exchange process fails, an IPSec connection will not be able to
establish, and thus, the entire IPSec/L2TP connection should fail. Otherwise, the
standalone L2TP connection will be in plaintext and insecure. In our experiment, we

3. IPSec Vulnerability 2
interfered with the IKEv2 negotiation by filtering UDP 500 on the default gateway. With
Windows, after a packet is dropped at UDP port 500, the L2TP connection will still be
established, but in plain text (without IPSec), which made eavesdrops possible. This
means that without the presence of IPSec, anyone can undermine the confidentiality,
authenticity, and integrity of the data packets being sent through the L2TP connection.
Man-in-the-middle attack, including packet sniffing and forging, can occur as a result.
We will simulate this issue, and explain how this vulnerability occurs and how it can be
exploited.
Simulation
In order to create a controlled simulation of this exploit, we created an enclosed
test network of three virtual machines; a VPN client, a server machine operating as the
default gateway, and an IPSec/L2TP VPN server. The basic topology looks similar to the
one below.
These three machines were configured with the following IP and OS setup.
# Operating System IP Description
1 Ubuntu Server 14.04 10.0.0.1 IPsec/L2TP VPN
Server
2 Ubuntu Server 14.04 172.16.10.1/24 Default Gateway
3 Windows 7 172.16.10.2/24 VPN Client (filtered)
Before beginning on the IPSec server machine, we made sure that the root doesn’t login
via SSH, and then started the command execution as the root user.
For the IPSec server machine, we installed PPP (an open source point-to-point protocol),
Openswan (an IPSec VPN service built for Linux), and Xelerance Layer 2 Tunneling
Protocol (known as xl2tpd). We did this using the following terminal command:
apt-get install openswan xl2tpd ppp lsof

4. IPSec Vulnerability 3
Next, we configured xl2tpd in order for the VPN server to assign a private range of IP
addresses to its clients. We decided to use 192.168.0.0 with a /24 subnet mask. We
configured this through the xl2tpd .conf file located at /etc/xl2tpd/xl2tpd.conf in the
Linux directory. Our config file looked like this after completion:
[lns default]
ip range = 192.168.0.2-192.168.0.254
local ip = 192.168.0.1
After setting up xl2tpd, we configured PPP to have two test users (test1 and test2) that
allowed for devices to connect using point-to-point. We did this using the /etc/ppp/chap-
secrets file. The file looked like this:
# Secrets for authentication using CHAP
# client server secret IP addresses
test1 l2tpd secret1 *
test2 l2tpd secret2 *
Now that our VPN/IPSec server was properly set up for the simulation, we tried to
connect 172.16.10.2 (the VPN client) to 10.0.0.1 (VPN server). The connection was
successfully established. After this confirmation, we observed two things; the auth.log
file and the ppp logs in syslog file with debug enabled. In auth.log we were able to see
that an IPSec SA was installed on the machine and transport mode was established as can
be seen by the last update in the log:
(IPSec SA installed)
(Transport mode established)
You can see the communication between the two devices in the ppp syslog file,
confirming a secure connection was established correctly:
When running this simulation, we flagged all traffic being sent to the VPN server’s UDP
500 port and log it. We did this with the following command:
Iptables -A INPUT –p udp --dport 500 -j LOG --log-prefix “IKEv2: ”
Iptables -A OUTPUT –p udp --dport 500 -j LOG --log-prefix “IKEv2: “

5. IPSec Vulnerability 4
These logs can be seen below:
After observing these logs, we configured iptables (the firewall on our machine) to drop
all traffic going to UDP port 500, which is the default port used by IKE. We configured
this so that the packets were dropped at the default gateway with the following command:
Iptables -A OUTPUT –p udp --dport 500 -j DROP
In theory, this should prevent the VPN client from establishing an IPSec connection with
the VPN server. When we tried to connect again with UDP 500 filtered, however, the
L2TP connection was still established. This new connection transmits all of its traffic as
plain text, which can be easily intercepted and interpreted. This bug completely
eliminates the benefits of using a L2TP VPN connection and makes it extremely insecure.
(Wireshark capturing plain text packets of the connection)

6. IPSec Vulnerability 5
Temporary Solution
Thankfully, there is a work around to this bug, albeit one that is a little
convoluted and difficult to discover. Windows has a built in properties module for VPNs
like it does for all other forms of network connection with its own set of options and
general settings. There is a security tab pictured below that has several different options
for VPN encryption.
By default, the data encryption option is set to “require encryption (disconnect if server
declines)”. However, this setting does not prevent the VPN client from establishing the
insecure L2TP connection. If a user chooses the last option “Maximum strength
encryption (disconnect if server declines)” and try connecting again, the connection will
fail with Error 742.

7. IPSec Vulnerability 6
While this solution does work and can prevent the insecure connection from being
established, it will almost certainly be done after an attack or by someone who already is
aware of the bug. The only way it can be correctly fixed is through a Windows patch that
either directly solves the problem or changes default VPN settings.
Conclusions
Because of the rapidly growing demand for remote access and private networks,
security and confidentiality of transported data is perhaps the highest priority in the
network field today. An organization or group of people should have confidence that a
“private network” they have created remain private and secure from man in the middle
attacks like the bug we have described and simulated above. When packets are
transported through clear text, the victims could lose data, passwords, financial
information, or a host of other vital information that should be kept secure from the
outside internet.
We highly recommend that Microsoft or an organization involved in IPsec/L2TP patch
this vulnerability as soon as possible. Although it can be temporarily worked around
through Windows settings, it is not enough to ensure that every user be safe from this
attack. Until this bug is removed or remedied, one of the most common forms of remote
communication between businesses, universities, and private individuals will remain
vulnerable to being compromised entirely, and that should be a pressing and major
concern for Microsoft and the entirety of the information technology field.
Works Cited
1) http://technet.microsoft.com/en-us/library/cc977622.aspx
2) http://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf
_gd/l2tp_ips.html
3) https://www.softether.org/index.php?title=4-docs/2-
howto/9.L2TPIPsec_Setup_Guide_for_SoftEther_VPN_Server/1.Setup_L2TP%2
F%2F%2F%2FIPsec_VPN_Server_on_SoftEther_VPN_Server
4) http://www.vpngate.net/en/howto_l2tp.aspx
5) http://riobard.com/2010/04/30/l2tp-over-ipsec-ubuntu/
6) https://raymii.org/s/tutorials/IPSEC_L2TP_vpn_with_Ubuntu_14.04.html
7) https://sc1.checkpoint.com/documents/R77/CP_R77_VPN_AdminGuide/14529.ht
m