See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/322643568

Final Project Virtual Private Network (VPN) Lab

Technical Report · January 2018

DOI: 10.13140/RG.2.2.17464.24323

CITATIONS READS
0 5,106

2 authors, including:

Mustafa Aljumaily
University of Tennessee
19 PUBLICATIONS   4 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Content Delivery Networks (CDN) architecture and applications View project

Efficiency Comparison between CPU and GPU for several types of benchmarking codes. View project

All content following this page was uploaded by Mustafa Aljumaily on 22 January 2018.

The user has requested enhancement of the downloaded file.

 University Of Tennessee, Knoxville
College of Engineering
Electrical Engineering and Computer Science Department

Computer Networks Security CS-534

Final Project
Virtual Private Network (VPN) Lab

Mustafa Aljumaily Angel Kodituwakku

000413141 000427691
mlatief@vols.utk.edu hkoditu1@vols.utk.edu

1
1 Overview
A Virtual Private Network (VPN) is used for creating a private scope of computer
communications or providing a secure extension of a private network through an insecure
network such as the Internet. VPN is a widely used in network security. VPN can be built upon
IPSec or Secure Socket Layer (SSL). These are two fundamentally different approaches for
building VPNs. In our work, we focused on the SSL-based VPNs which is often referred to as
SSL VPNs.
Designing and implementing the SSL VPNs exemplify a number of security principles and
technologies, including crypto, integrity, authentication, key management, key exchange, and
Public- Key Infrastructure (PKI). To achieve this goal, we implemented a simple SSL VPN for
Linux Ubuntu operating system.

2 Environment setup
After downloading the required documents and files from the lab official web page, we made 3
copies of the Ubuntu in each of the two PCs that we worked on. First copy was the client (the
host) and the second was the server, whereas the third one was the gateway as clarified in the
figure below:

These 6 virtual machines worked on 2 physical PCs for the different parts of the lab and the
following screenshots shows the addresses of the host and the server on one machine:
The server machine:
2
The host machine:

3
For the lab environment, we used the VMware workstation on Ubuntu and Linux Mint
operating systems so, we did not have the UUID problem.
The IP addresses of the virtual machines were changed for different parts of the lab according to
the requirements.
Within the setup steps, we added another Ethernet card to each of the 6 virtual machines and
made one of them NAT and the other (Host-Only) to allow the IP forwarding and the routing
between the 2 remote subnets over the internet as we will explain more later.
After turning on both the host and server in each side, we made sure that they are connected to
each other as following:

4
Finally, the openssl should be activated in all the machines to be able to connect through a
tunnel and we could see that the openssl is already activated in the virtual machines as
following:

3 Create a Host-to-Host Tunnel using TUN/TAP

The enabling technology for the TLS/SSL VPNs is TUN/TAP, which is now widely
implemented in modern operating systems. TUN and TAP are virtual network kernel drivers;
they implement network device that are supported entirely in software. TAP (as in network tap)
5
simulates an Ethernet device and it operates with layer-2 packets such as Ethernet frames; TUN
(as in network TUNnel) simulates a network layer device and it operates with layer-3 packets
such as IP packets. With TUN/TAP, we can create virtual network interfaces, which is what we
did to create the tunnel from host to host as in the figure below:

A user-space program is usually attached to the TUN/TAP virtual network interface. Packets
sent by an operating system via a TUN/TAP network interface are delivered to the user-space
program. On the other hand, packets sent by the program via a TUN/TAP network interface are
injected into the operating system network stack; to the operating system, it appears that the
packets come from an external source through the virtual network interface.
When a program is attached to a TUN/TAP interface, the IP packets that the computer sends to
this interface will be piped into the program; on the other hand, the IP packets that the program
sends to the interface will be piped into the computer, as if they came from the outside through
this virtual network interface. The program can use the standard read() and write() system calls
to receive packets from or send packets to the virtual interface.
We used the program simpleton.c to create tunnels in this lab which we downloaded from the
lab website and could compile it using:
$ gcc -o simpletun simpletun.c
And the results were:

6
Then, to continue the host to host tunnel connection process, we turn on the two hosts, assigned
IP addresses to them as required, operate simpletun in both of them as client (-c) in the first and
as server (-s) in the second, and then we setup the routes then we could see this:

7
Which shows that the two hosts are connected now through the tunnel.
And we could ping from each of them to the other:

4 Create a Host-to-Gateway Tunnel

After succeeded in setting up the tunnel on the two VMs within a single host machine, we set
up a similar tunnel on two VMs on two different host machines. And to make this configuration
work, we used port forwarding for this purpose as shown below:

Here we needed to create a tunnel between a computer and a gateway, allowing the computer to
access the private network that is connected to the gateway. To do so, we needed two physical

8
computers. On one computer, we run several VMs within the computer to set up the gateway
and the private network. We then used a VM in the other computer to communicate to the hosts
on the private network.
After setting up the two machines, we got the following:
The connection established successfully:

The routing table and the ping ability to the other part of the tunnel:

9
On the other machine we got:
Connection established:

10
Pinging the other side of the network (through the tunnel):

11
The tunnel terminal captures the traffic going through the tunnel:

5 Create a Gateway-to-Gateway Tunnel

In this task, we needed to go a step further to establish a tunnel between two gateways of
different private networks. With this tunnel, any host from one private network can
communicate with the hosts on the other private network using the tunnel. The setup for such a
gateway-to-gateway tunnel is shown below:

12
After creating the two networks shown above in the two physical machines, we created the
tunnel between the two gateways and could get connectivity through the tunnel from each of
them to the other as shown below:
Pinging from one side of the tunnel to the other:

13
The tunnel capturing the traffic:

14
The gateway cards:

The gateway on the other side, with the tunnel terminal capturing the traffic:

15
6 Create a Virtual Private Network (VPN)
After creating the gateway to gateway tunnel or the network tunnel. Then, we secured this
tunnel to get the VPN. And to secure this tunnel, we needed to achieve two goals,
confidentiality and integrity. The confidentiality is achieved using encryption, i.e., the contents
that go through the tunnel is encrypted. A real VPN software usually supports a number of
different encryption algorithm. But for our lab, we only needed to support the AES encryption
algorithm, and we used the Cipher Block Chaining (CBC) mode.
The integrity goal is to ensure that nobody can modify the traffic in the tunnel or launch a
replay attack. Integrity can be achieved using various methods. In this lab, we only needed to
support the Message Authentication Code (MAC) method. The AES encryption algorithm and
the HMAC-SHA256 algorithm are both implemented in the OpenSSL library. And we used [1]
to implement the requirements mentioned above. For this task, we assumed that the secret key
is already provided. For encryption, the client and the server also need to agree upon an Initial
Vector (IV). For security purpose, the IV should not be hard-coded the code. Instead, IV should
be randomly generated for each VPN tunnel.
To demonstrate our work for this part, we would like to show the following:
First of all, we worked on the open ssl sample files from the lab website and got the client and
server c++ codes, then we modified, and compiled them to get the following:
16
As it is shown above, we got the executables cli (for client) and serv (for server). Also, to show
the certificate file (server.crt) content we got the following:

17
The client server programs in our work includes simple data exchange over the SSL and the
tunnel (the VPN) and it is shown below:

18
After issuing the server and client programs on the two virtual machines, we entered the shared
key to both of them to get the above messages from each of them to the other and here is
another clarification screenshot:

19
Finally, the following show the client side certificate file contents:

20
7 Authentication and Key Exchange
Before a VPN is established, the VPN client must authenticate the VPN server, making sure
that the server is not a fraudulent one. On the other hand, the VPN server must authenticate the
client (i.e. user), making sure that the user has the permission to create such a VPN tunnel.
After the authentication is done, the client and the server will agree upon a session key for the
VPN tunnel. This session key is only known to the client and the server. The process of
deriving this session key is called key exchange and it can be achieved by following the
following steps.
Step 1: Authenticating VPN Server A typical way to authenticate the server is to use public-key
certificates. The VPN server needs to first get a public-key certificate from a Certificate
Authority (CA), such as Verisign. When the client makes the connection to the VPN server, the
server will use the certificate to prove it is the intended server. The HTTPS protocol in the Web
uses a similar way to authenticate web servers, ensuring that you are talking to an intended web
server, not a fake one. Our MiniVPN used such a method to authenticate the VPN server. We
implemented an authentication protocol (such as SSL) using the OpenSSL’s SSL functions to

21
directly make an SSL connection between the client and the server, where the verification of
certificates is automatically carried out by the SSL functions.
Step 2: Authenticating VPN Client (i.e. User) There are two common ways to authenticate the
user. One is using the public-key certificates. Namely, users need to get their own public-key
certificates. When they try to create a VPN with the server, they need to send their certificates
to the server, which will verify whether they have permissions for such a VPN. OpenSSL’s SSL
functions also support this option.
Since users usually do not have their public-key certificates, a more common way to
authenticate users is to use the traditional user name and password approach. Namely, after the
client and the server have established a secure TCP connection between themselves, the server
can ask the client to type the user name and the password, and the server then decide whether to
allow the user to proceed depending on whether the user name and password matches with the
information in the server’s user database.
Step 3: Key Exchange. Using OpenSSL’s SSL functions, causes a secure channel to be
automatically established (by the OpenSSL functions). However, this TCP connection was not
used for our tunnel, because our VPN tunnel uses UDP. Therefore, we treated this TCP
connection as the control channel between the client and the server. Over this control channel,
the client and the server agree upon a session key for the data channel (i.e. the VPN tunnel).
They can also use the control channel for other functionalities, such as updating the session key,
exchanging the Initial Vector (IV), terminating the VPN tunnel, etc.
Step 4: Dynamic Reconfiguration. Some commands at the client side was implemented to allow
the client to do the following:
• Change the session key on the client end, and inform the server to make the similar change.
• Change the IV on the client end, and inform the server to make the similar change.
• Break the current VPN tunnel. The server needs to be informed, so it can release the
corresponding resources.
 We tried to achieve this but we could not due to the time limitations and exams.

8 Supporting Multiple VPN Tunnels

In the real world, one VPN server often supports multiple VPN tunnels. Namely, the VPN
server allows more than one clients to connect to it simultaneously; each client has its own VPN
tunnel with the server, and the session keys used in different tunnels should be different. Our
22
VPN server was able to support multiple clients. When a packet arrives at the VPN server
through a VPN tunnel, the server needs to figure out from which VPN tunnel the packet come
from. Without this information, the server cannot know which decryption key (and IV) should
be used to decrypt the packet; using a wrong key is going to cause the packet to be dropped,
because the HMAC will not match.

The first machine with multiple clients running the client SSL:

It is shown here that they got the responses from the server side.
The server side with multiple connections to different clients shown below:

23
It is shown here that this server was able to communicate with multiple clients simultaneously.

The Demo. Link

https://www.youtube.com/watch?v=hQmYPu_yis8

24

View publication stats