SEED Labs - VPN Lab Copyright © 2006 - 2016 by Wenliang Du. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. If you remix, transform, or build upon the material, this copyright notice must be left intact, or reproduced in a way that is reasonable to the medium in which the work is being re-published. 1 Overview A Virtual Private Network (VPN) is used for creating a private scope of computer communications or pro- viding a secure extension of a private network into an insecure network such as the Internet. VPN is a widely used security technology. VPN can be built upon IPSec or TLS/SSL (Transport Layer Security/Se- cure Socket Layer). These are two fundamentally different approaches for building VPNs. In this lab, we focus on the TLS/SSL-based VPNs. This type of VPNs is often referred to as TLS/SSL VPNs. The learning objective of this lab is for students to master the network and security technologies under- lying VPNs. To achieve this goal, students will be asked to implement a simple TLS/SSL VPN. Although this VPN is simple, it does include all the essential elements of a VPN. The design and implementation of TLS/SSL VPNs exemplify a number of security principles, including the following: • Virtual Private Network • TUN/TAP, and IP tunneling Virtual Private Network (VPN) Lab Routing Public-key cryptography, PKI, and X.509 certificate • TLS/SSL programming Authentication ● ● Readings and videos. Detailed coverage of VPN, PKI, and TLS can be found in the following: Chapters 19, 24, and 25 of the SEED Book, Computer & Internet Security: A Hands-on Approach, 2nd Edition, by Wenliang Du. See details at https://www.handsonsecurity.net. ● ● Section 8 of the SEED Lecture, Internet Security: A Hands-on Approach, by Wenliang Du. See details at https://www.handsonsecurity.net/video.html. Related labs. We have a separate SEED lab on PKI, and another one on TLS. It is recommended that students finish these two crypto labs before working on this comprehensive VPN lab. If students are only interested in the tunneling part of the VPN (without the crypto part), they should use the VPN Tunneling Lab, instead of this one. Lab Environment. This lab has been tested on our pre-built Ubuntu 20.04 VM, which can be downloaded from the SEED website. We need to use the openss1package in this lab. The package includes the header files, libraries, and commands. The package was already installed in our pre-built VM image. SEED Labs - VPN Lab 2 Lab Tasks In this lab, students need to implement a simple VPN for Linux. We will call it miniVPN. 2.1 Task 1: VM Setup We will create a VPN tunnel between a computer (client) and a gateway, allowing the computer to securely access a private network via the gateway. We need at least three VMs: VPN client (also serving as Host U), VPN server (the gateway), and a host in the private network (Host V). The network setup is depicted in Figure 1. User 10.0.2.7 Host U VPN Client "NAT Network" Adapter 10.0.2.8 Gateway (VPN Server) "Internal Network" Adapter 192.168.60.101 Host V 2 192.168.60.1 Figure 1: VM setup for this lab In practice, the VPN client and VPN server are connected via the Internet. For the sake of simplicity, we directly connect these two machines to the same LAN in this lab, i.e., this LAN simulates the Internet. We will use the "NAT Network" adaptor for this LAN. The third machine, Host V, is a computer inside the private network. Users on Host U (outside of the private network) want to communicate with Host V via the VPN tunnel. To simulate this setup, we connect Host V to VPN Server (also serving as a gateway) via an "Internal Network". In such a setup, Host V is not directly accessible from the Internet; nor is it directly accessible from Host U. Note if a VM uses the "Internal Network" mode, VirtualBox provides no DHCP to it, so the VM must be statically configured. To do this, click the network icon on the top-right corner of the desktop, and select "Edit Connections". You will see a list of "Wired connections", one for each of the network adaptors used by the VM. For Host V, there is only one connection, but for VPN Server, we will see two. To make sure that you pick the one that is corresponding to the "Internal Network" adapter, You can check the MAC address displayed in the pop-up window after you have picked a connection to edit. Compare this MAC address with the one that you get from ifconfig, and you will know whether you picked the right connection. After you have selected the right connection to edit, pick the "ipv4 Settings" tab and select the "Manual" method, instead of the default "Automatic (DHCP)". Click the "Add" button to set up the new IP address for the VM. See Figure 2 for details. SEED Labs - VPN Lab Network Connections Last Used Name Ethernet Wired connection 1 2 minutes ago Wired connection 2 1 hour ago Add Edit Delete Close Editing Wired connection 2 Connection name: Wired connection 2 General Ethernet 802.1x Security DCB IPv4 Settings IPv6 Settings Method: Manual Addresses Address 192.168.60.1 Netmask 24 Gateway 192.168.60.1 DNS servers: Search domains: DHCP client ID: Require IPv4 addressing for this connection to complete Add Delete Routes... Cancel Save Figure 2: Manually set up the IP address for the "Internal Network" adaptor on VPN Server. 3 2.2 Task 2: Creating a VPN 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) 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. 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 have created a sample VPN client program (vpnclient) and a server program (vpnserver), both of which can be downloaded from this lab's web site. The programs are explained in details in Chapter 16 of the SEED book titled Computer & Internet Security: A Hands-on Approach, 2nd Edition; the chapter also explains how TUN/TAP works and how to use it to create VPN. The vpnclient and vpnserver programs are the two ends of a VPN tunnel. They communicate with each other using either TCP or UDP via the sockets depicted in Figure 3. In our sample code, we choose to use UDP for the sake of simplicity. The dotted line between the client and server depicts the path for the VPN tunnel. The VPN client and server programs connect to the hosting system via a TUN interface, through which they do two things: (1) get IP packets from the hosting system, so the packets can be sent through the tunnel, (2) get IP packets from the tunnel, and then forward it to the hosting system, which will forward the packet to its final destination. The following procedure describes how to create a VPN tunnel using the vpnclient and vpnserver programs. SEED Labs - VPN Lab VPN Client Program 192.168.53.5 VPN Client VM tun0 10.0.2.7 socket VPN Tunnel (TCP or UDP) Internet Figure 3: VPN client and server On VPN Client VM: $ sudo ./vpnclient socket Run the following command in another window: $ sudo ifconfig tun0 192.168.53.1/24 up VPN Server Program -0.0 Run the following command in a different window $ sudo ifconfig tun0 192.168.53.5/24 up 192.168.53.1 tun0 10.0.2.8 Step 1: Run VPN Server. We first run the VPN server program vpnserver on the Server VM. Af- ter the program runs, a virtual TUN network interface will appear in the system (we can see it using the "ifconfig -a" command; the name of the interface will be tun0 in most cases, but they can be tunx, where X is a number). This new interface is not yet configured, so we need to configure it by giving it an IP address. We use 192.168.53.1 for this interface. Run the following commands. The first command will start the server program, and the second command assigns an IP address to the tun0 interface and then activates it. It should be noted that the first command will block and wait for connections, so we need to find another window run the second command. $ sudo ./vpnserver VPN Server VM Unless specifically configured, a computer will only act as a host, not as a gateway. The VPN Server needs to forward packets between the private network and the tunnel, so it needs to function as a gateway. We need to enable the IP forwarding for a computer to behave like a gateway. IP forwarding can be enabled using the following command: $ sudo sysctl net.ipv4.ip_forward=1 Step 2: Run VPN Client. We now run the VPN client program on the Client VM. We run the following commands on this machine. The first command will connect to the VPN server program (the server's IP address is hardcoded inside the program, and you need to change it accordingly). This command will block as well, so we need to find another window to configure the tun0 interface created by the VPN client program. We assign IP address 192.168.53.5 to the tun0 interface. SEED Labs - VPN Lab 5 Step 3: Set Up Routing on Client and Server VMs: After the above two steps, the tunnel will be established. Before we can use the tunnel, we need to set up routing paths on both client and server machines to direct the intended traffic through the tunnel. On the client machine, we need to direct all the packets going to the private network (192.168.60.0/24) towards the tun0 interface, from where the packets can be forwarded through the VPN tunnel. Without this setup, we will not be able to access the private network at all. We can use the route command to add an routing entry. The following example shows how to route the 10.20.30.0/24-bound packets to the interface eth0. $ sudo route add -net 10.20.30.0/24 eth0 On both client and server machines, we also need to set up a routing entry so all the traffic going to the 192.168.53.0/24 network are directed to the tun0 interface. This entry will usually be automatically added when we assign 192.168.53.X to the tun0 interface. If for some reasons it is not added, we can use the route command to add it. Step 4: Set Up Routing on Host V. When Host V replies to a packet sent from Host U, it needs to route the packets to the VPN Server VM, from where, it can be fed into the VPN tunnel toward the other end. You need to find out what entry to add, and then use the route command to add the routing entry. Hint: when Host V receives a packet from Host U (via the tunnel), you need to know what the source IP is in the packet; in the reply packet, the source IP becomes the destination IP, which will be used by the routing table. Therefore, you need to figure out the source IP of the packets from U to V. It is your task to figure this out and set the routing correctly in this step. Step 5: Test the VPN Tunnel: After everything is set up, we can access Host V from Host U via the tunnel. Please conduct the following tests using ping and telnet; please report your results. You should use Wireshark to capture the network traffics on all the interfaces on the client VM, and pinpoint which packets are part of the tunnel traffic, and which packets are not the tunnel traffic. On Host U: $ ping 192.168.60.101 $telnet 192.168.60.101 Step 6: Tunnel-Breaking Test. On Host U, telnet to Host V. While keeping the telnet connection alive, we break the VPN tunnel. We then type something in the telnet window, and report what you observe. We then reconnect the VPN tunnel. What is going to happen to the telnet connection? Will it be broken or resumed? Please describe and explain your observations. 2.3 Task 3: Encrypting the Tunnel At this point, we have created an IP tunnel, but our tunnel is not protected. Only after we have secured this tunnel, can we call it a VPN tunnel. This is what we are going to achieve in this task. To secure this tunnel, we need to achieve two goals, confidentiality and integrity. The confidentiality is achieved using encryption, i.e., the contents that go through the tunnel is encrypted. The integrity goal ensures that nobody can tamper with the traffic in the tunnel or launch a replay attack. Integrity can be achieved using Message Authentication Code (MAC). Both goals can be achieved using Transport Layer Protocol (TLS). TLS is typically built on top of TCP. The sample VPN client and server programs in Task 2 use UDP, so we first need to replace the UDP channel in the sample code with a TCP channel, and then establish a TLS session between the two ends of the tunnel. A sample TLS client and server program (tlsclient