Experiment 5: Virtual Private Networks

(initial alpha release)


  1. Setup a virtual private network (VPN) server for an organization.
  2. Manually configure client and server to reach a web server within the VPN using OpenVPN.
  3. Observe the differences between the internal/external traffic generated by VPN.


You must have performed Experiment 3 first. In addition review network address translation (NAT) and network security from the class notes.

There are many different ways to implement virtual private networks. This experiment demonstrates just one example configuration using OpenVPN. Suppose that an employee of an organization needs access to the services of the internal organization network while travelling. Normally the internal network is not visible from the Internet. Additionally, the employee is likely to connect from insecure external access points (for example hotel and airport wireless networks). The VPN provides a virtual channel to route packets from/to the internal network, marked with a red traced line in the diagram shown below.

VPN conceptual diagram

Network and host IPs in the figure are just illustrative values: actual values for the experiment to be assigned by lab instructor. Software running at the two end points of the red channel encapsulate and encrypt all traffic between the employee’s PC and the organization’s internal network. OpenVPN uses the virtual tunnel interface facility (tun) available in many operating systems to create a detour for all packets from/to the private network, as shown in the following diagram for the client side:

VPM software implementation stack

The traffic to the private network generated by the web browser in the client follows the path indicated in the figure. Traffic from the browser is routed by the operating system to a tun interface which (in this example) is assigned Note that this address does not belong to the organization’s internal network block. The packets received at this address are processed by OpenVPN. After encryption and encapsulation, the traffic is sent to the organization’s router using (again, in this particular example) the UDP protocol through the main network interface.

For this example we will use a pre-shared secret key using the AES algorithm. This means that the employee must obtain the secret key (using a secure method) before leaving the company. This method has some advantages: it is easy to setup and no keys are exchanged at connection time. However, it also has the disadvantage that if the key is ever compromised, all communications (even past communications) can be read. Other setups using public keys (RSA + Diffie-Hellman) are also possible.


  1. Ask the lab instructor to be assigned a group number (n), a private network ID and the host IP in virtual LAN. It is recommended to use the same group number used in Experiment 3.

  2. Launch the remote desktop client. Log-in to the virtual network server (at5030-eng2453server.lakeheadu.ca). The account name is : group<n>, where <n> is the number assigned by the lab instructor. Only one student in the group should log-in.

  3. At the server prompt run startrouter to bring the router virtual machine up:

    group2@at5030-eng2543server:~$ startrouter
    mkdir: cannot create directory `workspace': File exists
    0+0 records in
    0+0 records out
    0 bytes (0 B) copied, 1.1313e-05 s, 0.0 kB/s
    Setting up swapspace version 1, size = 524284 KiB
    no label, UUID=9761b76d-aad6-4885-99f1-7918b29427c9
    Core dump limits :
     soft - 0
     hard - NONE
    Checking that ptrace can change system call numbers...OK
    Checking syscall emulation patch for ptrace...OK
    Checking advanced syscall emulation patch for ptrace...OK
    <more output suppressed>

    After the router is up, you should see the router login screen:

    Debian GNU/Linux 9 router tty0
    router login:

    Log-in as ‘root’, password is ‘default’. You have full administrator privileges on the virtual router. You need at least 2 router consoles to run this experiment: one to run the openvpn server and see log messages and another to type additional commands. Change to run level 3 to enable 2 extra consoles:

    root@router:~# init 3

    Two additional login terminals should pop up. Configure the router as in Experiment 3. After this you should be able to ping the web server in the private network or connect to the server using the text-mode web browser (w3m):

    root@router:~# w3m 3

    Verify that the information given by the webserver is correct and quit the browser by pressing q. Remember to enable packet forwarding in the kernel (net.ipv4.ip_forward).

  4. Setup encryption: the first step is to generate a file with secret key (secret.key):

    root@router:~# openvpn --genkey --secret secret.key
    root@router:~# ls
    root@router:~# cat secret.key
    # 2048 bit OpenVPN static key
    -----BEGIN OpenVPN Static key V1-----
    -----END OpenVPN Static key V1-----
Copy that key to a working directory in your Windows machine (I used cut-and-paste from putty session into Notepad++).
  1. The VPN connection will be established as a point-to-point link between two tun interfaces (one in the router and one in your PC). The IP addresses assigned to these interfaces must not conflict with any of the local networks for the client or the server. In this example we’ll assign the following parameters:

    • Network device type: tun (as opposed to the Layer 2 device tap)
    • Server point-to-point IP:
    • Client point-to-point IP:
    • Secret key file: secret.key
    • Encryption type: AES-256-CBC
    • Port to listen for connections: 1194 (default connection is over UDP)
    • User and group: nobody, nogroup (this is to prevent openvpn running with root privileges).

    All these parameters would normally be stored in a configuration file (in /etc/openvpn/server/) for a permanent setup, but for flexibility in this example, we’ll include them directly in the command line as follows:

    root@router:~# openvpn --dev tun --ifconfig --secret secret.key --cipher AES-256-CBC --port 1194 --user nobody --group nogroup
    Tue Dec 11 11:22:34 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
    Tue Dec 11 11:22:34 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
    Tue Dec 11 11:22:34 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
    Tue Dec 11 11:22:34 2018 WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
    Tue Dec 11 11:22:34 2018 WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
    Tue Dec 11 11:22:34 2018 TUN/TAP device tun0 opened
    Tue Dec 11 11:22:34 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
    Tue Dec 11 11:22:34 2018 /sbin/ip link set dev tun0 up mtu 1500
    Tue Dec 11 11:22:34 2018 /sbin/ip addr add dev tun0 local peer
    Tue Dec 11 11:22:34 2018 Could not determine IPv4/IPv6 protocol. Using AF_INET
    Tue Dec 11 11:22:34 2018 UDPv4 link local (bound): [AF_INET][undef]:1194
    Tue Dec 11 11:22:34 2018 UDPv4 link remote: [AF_UNSPEC]
    Tue Dec 11 11:22:34 2018 GID set to nogroup
    Tue Dec 11 11:22:34 2018 UID set to nobody

    You will be able to observer openvpn messages (connection established, errors, etc.) in that console, but you can no longer type commands in that console. If you made a mistake in the command line, use CTRL-C to stop the server. The server should be ready to accept connections. Check that the new tun0 interface is created and assigned the correct IP address:

    root@router:~# ip -4 a show
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        inet scope host lo
           valid_lft forever preferred_lft forever
    6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
        inet brd scope global eth0
           valid_lft forever preferred_lft forever
    7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
        inet brd scope global eth1
           valid_lft forever preferred_lft forever
    9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
        inet peer scope global tun0
           valid_lft forever preferred_lft forever

    We’ll leave the server running for now and switch back to configure the client side (the Windows computer).

  2. Open two administrator cmd windows (one for openvpn and the other to enter other commands). OpenVPN should be installed and available in your path. Go to the working directory where your secret key is saved. The client parameters are similar to the server ones, but we must also specify the server address (the external server interface is eth0):

    • Server external address:
    • Network device type: tun (as opposed to the Layer 2 device tap)
    • Client point-to-point IP:
    • Server point-to-point IP:
    • Secret key file: secret.key
    • Encryption type: AES-256-CBC
    • Port to connect: 1194 (default connection is over UDP)

    Run openvpn using the same syntax as in the server. If everything goes well, you should see a successful connection message, a new route to through should appear and you should be able to ping the other side of the tunnel ( as shown in the capture below:

    Windows VPN client screenshot 1

    Now add a route to the organization private network as follows:

    C:\>route add mask

    Try pinging the router address in the private network (it should work). Due to the particular setup of the webserver in the private LAN, pinging the webserver will not work because the source address in your packets is We need to do some more router configuration first.

  3. To make the packets from the Windows machine to appear to come from the internal network (, we’ll enable NAT translation in the router as follows:

    root@router:~# iptables -t nat -A POSTROUTING -s -d -o eth1 -j MASQUERADE

    These parameters specify to add an entry to the nat table. After routing is performed, for packets with source address and destination in, output interface eth1, replace the source address with the address assigned to eth1 (MASQUERADE). This means that the web server will see in the source address of packets from the Windows client. Conversely, the router will also switch the addresses of packets from the web server to the Window client. Please note that for a secure router, more iptables entries are required.

    Try connecting to the webserver using a web browser on the Windows computer. You should get a page with consistent addresses as shown in the screen capture as shown below:

    Windows VPN client screenshot 1
  4. Capture packets in tun interface and Ethernet interface in client. Verify that the Ethernet traffic is indeed encrypted. To generate traffic, reload the web page, or run ping (as shown in figure above) or tracert to the web server.

  5. After the experiment is finished, stop openvpn in the client and stop the router:

    root@router:~# shutdown -h now

    When the router is down you will see the server prompt. Close all programs and logout from the remote session before leaving.

Report preparation and questions

  1. Prepare a formal report summarizing this experiment in pdf format and submit it to the lab instructor. Report writing rules:

    • One report per group
    • All students are responsible for the contents of the report, but one student in the group must coordinate, write and submit the report for the experiment. Each student in a group must prepare at least one of the five reports in the term.
    • Clearly state in the report cover the name of all students in the group and indicate who prepared the report
  2. Include supporting screen captures.

  3. List all IP addresses in the client and the router and to what interface is each one assigned.

  4. Show which of the captured packets in Wireshark for each of the two interfaces correspond to the connection initiated by the ping (or tracert or web browser).

  5. List potential security risks for this setup.