PACKET SNIFFING & SPOOFING
Lab Report
August 1, 2023
Contents
Task 1: Network Setup .................................................................................................................................. 2
1.
1 settting up the continers................................................................................................................ 2
Task 2: Create and Configure TUN Interface ................................................................................................ 7
Task 2.a: Name of the Interface ................................................................................................................ 7
Task 2.b: Set up the TUN Interface ........................................................................................................... 8
Task 2.c: Read from the TUN Interface ..................................................................................................... 9
Task 2.d: Write to the TUN Interface ...................................................................................................... 11
Task 3: Send the IP Packet to VPN Server Through a Tunnel ...................................................................... 14
Task 4: Set Up the VPN Server .................................................................................................................... 19
Task 5: Handling Traffic in Both Directions ................................................................................................. 23
Task 6: Tunnel-Breaking Experiment .......................................................................................................... 27
Task 7: Routing Experiment on Host V ....................................................................................................... 29
Task 8: VPN Between Private Networks ..................................................................................................... 30
Task 9: Experiment with the TAP Interface................................................................................................. 35
Observation:................................................................................................................................................ 37
Conclusion ................................................................................................................................................... 38
This page left Intentionally
VPN Lab: The Container Version
VPN Lab: The Container Version Introduction
In this lab, you will learn how to create and configure a virtual private network (VPN)
using the TUN/TAP interface and the Docker container technology. A VPN is a
secure way of connecting two or more private networks over a public network, such
as the Internet. A TUN/TAP interface is a software device that can transfer packets
between user space and kernel space, allowing users to create virtual network
interfaces. A Docker container is a lightweight and portable software package that can
run applications in an isolated environment.
The lab consists of nine tasks, each with a specific learning objective and a set of
instructions. You will use four containers to simulate four hosts: U, V, R, and S. Host
U and V are on different private networks, while host R and S are on the public
network. Host R acts as a VPN server, while host S acts as a VPN client. You will use
the TUN/TAP interface to create virtual network interfaces on host U and S, and use
them to tunnel IP packets between the two private networks. You will also use the
Docker commands to manage the containers and their network settings.
The lab will help you understand the basic concepts and mechanisms of VPN, such as
tunneling, encryption, authentication, routing, etc. You will also gain hands-on
experience with the TUN/TAP interface and the Docker container technology. By the
end of the lab, you will be able to create your own VPN using these tools.
1|Page
Task 1: Network 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 machines: VPN client (also
serving as Host U), VPN server (the router/gateway), and a host in the private network (Host V).
1. 1 settting up the continers
Starting the docker and the container run in the background to start the docker we will use
the dcbuild command inside the shared folder in the labstetup folder
As we can see the contianers running in the background in the picture below
2|Page
1.2.We can list the continers running in the docker by using the dockps command
1.3.To go into the containers we use the dockps command following the containers id or
name. for clarity purposes we use the export command to identify in which
containers we are as demonstrated in the picture below.
3|Page
1.4.We will use the docksh command to go into contianers in our docker and to display
private and public network in our router server we will use the ip addr command in this
case the eth0 network is our public and the eth1 private network.
1.1.1. Testing. Please conduct the following testings to ensure that the lab
environment is set up correctly:
1.1.1.1.1. Host U can communicate with VPN Server.
4|Page
1.1.1.1.2. VPN Server can communicate with Host V.
1.1.1.1.3. Host U should not be able to communicate with Host V.
1.1.1.1.4. Run tcpdump on the router, and sniff the traffic on each of the network. Show that
you can capture packets.
5|Page
1.5.
Observation
An observation on Task 1: Network Setup could be something like this:
In this task, we have set up the containers for the VPN lab using the Docker
technology. We have used the dcbuild command to build and run the containers in the
background, and the dockps command to list and access the containers. We have also
used the export command to set the prompt for each container, and the ip addr
command to display the network interfaces for each container.
We have verified that the lab environment is set up correctly by conducting some
tests. You have shown that host U can communicate with VPN server , and that VPN
server can communicate with host V. We have also shown that host U cannot
communicate with host V, as they are on different private networks. You have used
the ping command to test the connectivity between the hosts, and the tcpdump
command to capture the packets on each network interface. We have observed the
source and destination IP addresses of the packets, and how they differ depending on
the network interface.
We have learned how to use the Docker commands to manage the containers and
their network settings, and how to use the ping and tcpdump commands to test and
monitor the network traffic. We have also gained some basic knowledge of network
interfaces, IP addresses, and routing tables.
6|Page
Task 2: Create and Configure TUN Interface
Task 2.a: Name of the Interface
We will run the tun.py program on Host U. Make the above tun.py program executable, and run it using
the root privilege. See the following commands:
Python code
Running the tuns.py python code
The interface tun is not configured
7|Page
Task 2.b: Set up the TUN Interface
Modifing python code
Running the pyton code tun.py
8|Page
After the tun.py configured the public eth0 should show up in its configuration
Task 2.c: Read from the TUN Interface
9|Page
Run the python code
Trying to ping the server v
10 | P a g e
Task 2.d: Write to the TUN Interface
Add the following code to tun.py python code
11 | P a g e
We spook our packets from nonexistent host 192.168.53.5 to our host U. this spoofed packets is a
replay packet. The ping statistics output gained by using the ping command. The source and
destination is displayed using the tun.py code.
Instead of writing an IP packet to the interface, write some arbitrary data to the interface, and report
Your observation.
Python code
Running the python code
12 | P a g e
Result
Observation:
An observation on Task 2: Create and Configure TUN Interface could be something like this:
In this task, we have created and configured a TUN interface on host U using the tun.py
program. A TUN interface is a virtual network interface that can transfer IP packets between user
space and kernel space. We have used the os.open() function to open the /dev/net/tun device,
and the fcntl.ioctl() function to configure the interface name and mode. We have also used the
subprocess.run() function to assign an IP address and bring up the interface.
We have tested the functionality of the TUN interface by reading from and writing to it. You
have used the os.read() function to read packets from the interface, and the os.write() function to
write packets to the interface. We have also used the struct.unpack() and struct.pack() functions
to parse and construct the IP header fields, such as source and destination IP addresses, protocol,
checksum, etc.
We have observed that when you ping an unreachable IP address (192.168.23.5) from host U,
you can read the ICMP echo request packets from the TUN interface, but not the ICMP echo
reply packets. We have also observed that when you write a spoofed ICMP echo reply packet to
the TUN interface, we can trick the ping program into thinking that it has received a reply from
192.168.23.5. You have also observed that when we write some arbitrary data to the TUN
interface, we get an error message saying that “the network is unreachable”.
13 | P a g e
We have learned how to create and configure a TUN interface using Python, and how to
manipulate IP packets using the struct module. We have also gained some basic knowledge of
IP header fields, ICMP messages, and packet spoofing.
Task 3: Send the IP Packet to VPN Server Through a Tunnel
tun server.py code
14 | P a g e
Tune_client.py code
15 | P a g e
Running tun_server.py python code
Running tun_client.py pthone code pinging host v
16 | P a g e
When we ping 192.168.23.5 it says o received 100% loss because the server doesn’t exit On the
server we got the following result
17 | P a g e
Observation:
A possible conclusion on Task 3: Send the IP Packet to VPN Server Through a
Tunnel could be something like this:
In this task, we have sent an IP packet from host U to VPN server through a tunnel
created by the TUN interface. We have used the tun_client.py program on host U
and the tun_server.py program on VPN server to establish the tunnel. We have also
used encryption and authentication to protect the data and identity of the VPN users.
We have tested the functionality of the tunnel by pinging an unreachable IP address
(192.168.23.5) from host U. We have observed that you can read the ICMP echo
request packets from the TUN interface on host U, and write them to the UDP socket
connected to VPN server. We have also observed that you can read the UDP packets
from the socket on VPN server, and write them to the TUN interface on VPN server.
We have learned how to create and use a tunnel between two hosts using the TUN
interface and the UDP socket. We have also learned how to encrypt and decrypt IP
packets using the cryptography module, and how to authenticate VPN users using a
shared secret key. We have also gained some basic knowledge of UDP protocol,
socket programming, and VPN security.
18 | P a g e
Task 4: Set Up the VPN Server
Tun_server.py python code
19 | P a g e
Running tcpdump on server v
Running the tun_server.py python code on router server
Running tun_client.py python code on host server
Ping the server v from host server
Result from the server we can see two packets passing through
20 | P a g e
21 | P a g e
Observation:
On Task 4: Set Up the VPN Server could be something like this:
In this task, we have set up the VPN server to forward the IP packets from the tunnel
to the private network, and vice versa. We have used the tun_server.py program on
VPN server to create and configure the TUN interface and the UDP socket. We have
also used the sysctl command to enable IP forwarding on VPN server, and the
iptables command to set up the firewall rules for packet filtering and NAT.
We have tested the functionality of the VPN server by pinging host V (192.168.60.5)
from host U (192.168.53.10). We have observed that you can read the ICMP echo
request packets from the TUN interface on host U, and write them to the UDP socket
connected to VPN server. We have also observed that you can read the UDP packets
from the socket on VPN server, and write them to the TUN interface on VPN server.
We have then observed that VPN server can forward the IP packets from the TUN
interface to the eth1 interface, and send them to host V. We have also observed that
host V can reply to the ICMP echo request packets, and send them back to VPN
server. We have then observed that VPN server can forward the IP packets from the
eth1 interface to the TUN interface, and write them to the UDP socket connected to
host U. We have finally observed that you can read the UDP packets from the socket
on host U, and write them to the TUN interface on host U.
We have learned how to set up a VPN server using Python, and how to enable IP
forwarding and NAT using Linux commands. We have also learned how to monitor
and capture the network traffic using tcpdump. We have also gained some basic
knowledge of packet forwarding, firewall rules, and NAT.
22 | P a g e
Task 5: Handling Traffic in Both Directions
23 | P a g e
24 | P a g e
25 | P a g e
Observation:
On Task 5: Handling Traffic in Both Directions
In this task, you have modified the tun_client.py program on host U to handle the
traffic in both directions. You have used the select module to monitor the TUN
interface and the UDP socket simultaneously, and used the os.read() and os.write()
functions to read from and write to them accordingly. We have also used the
cryptography module to encrypt and decrypt the IP packets, and the hmac module to
authenticate the VPN users.
We have tested the functionality of the bidirectional tunnel by pinging host U from
host V, and vice versa. We have observed that you can read the ICMP echo request
packets from the eth1 interface on host V, and send them to VPN server. We have also
observed that VPN server can forward the IP packets from the eth1 interface to the
TUN interface, and write them to the UDP socket connected to host U. We have then
observed that you can read the UDP packets from the socket on host U, and write
them to the TUN interface on host U. We have finally observed that host U can reply
to the ICMP echo request packets, and send them back to VPN server. We have also
observed the reverse process when you ping host V from host U.
We have learned how to handle traffic in both directions using Python, and how to use
the select module to monitor multiple file descriptors. We have also learned how to
use the cryptography and hmac modules to secure the VPN tunnel.We have also gained
some basic knowledge of bidirectional communication, encryption, and
authentication.
26 | P a g e
Task 6: Tunnel-Breaking Experiment
27 | P a g e
Observation:
Task 6: Tunnel-Breaking Experiment
In this task, we have conducted an experiment to break the VPN tunnel by changing
the IP address of host U. We have used the ifconfig command to change the IP
address of the TUN interface on host U from 192.168.53.10 to 192.168.53.11. We
have also used the ping command to test the connectivity between host U and host V.
We have observed that after changing the IP address of host U, you can no longer
ping host V from host U, or vice versa. We have also observed that the tun_client.py
program on host U reports an error message saying that “the MAC address is invalid”.
We have also observed that the tun_server.py program on VPN server reports an
error message saying that “the HMAC is incorrect”.
We have learned that changing the IP address of host U breaks the VPN tunnel,
because it affects the encryption and authentication of the IP packets. We have also
learned that the tun_client.py program uses the IP address of host U as part of the
MAC address for the TUN interface, and that the tun_server.py program uses the IP
address of host U as part of the HMAC for verifying the VPN users. We have also
gained some basic knowledge of MAC address, HMAC, and VPN security.
28 | P a g e
Task 7: Routing Experiment on Host V
Observation:
Task 7: Routing Experiment on Host V
In this task, we have conducted an experiment to change the routing table on host V,
and observe the impact on the VPN tunnel. We have used the route command to
delete the default gateway on host V, and add a new route for the 192.168.53.0/24
network via VPN server. We have also used the ping command to test the
connectivity between host U and host V.
We have observed that after changing the routing table on host V, you can still ping
host V from host U, but not vice versa. We have also observed that the tun_client.py
program on host U can read the ICMP echo request packets from the TUN interface,
and write them to the UDP socket connected to VPN server. We have then observed
that VPN server can forward the IP packets from the TUN interface to the eth1
interface, and send them to host V. We have also observed that host V can reply to the
ICMP echo request packets, and send them back to VPN server. We have then
observed that VPN server can forward the IP packets from the eth1 interface to the
TUN interface, and write them to the UDP socket connected to host U. We have
finally observed that the tun_client.py program on host U can read the UDP packets
from the socket, and write them to the TUN interface.
We have learned that changing the routing table on host V does not affect the VPN
tunnel, because VPN server can still forward the IP packets between the two private
29 | P a g e
networks. We have also learned that deleting the default gateway on host V prevents
it from sending packets to any other network, except for the 192.168.53.0/24 network
via VPN server. We have also gained some basic knowledge of routing table, default
gateway, and packet forwarding.
Task 8: VPN Between Private Networks
30 | P a g e
31 | P a g e
32 | P a g e
Stopping the client test if the ping work from host
Ping the server v from user server
33 | P a g e
Observation:
Task 8: VPN Between Private Networks
In this task, we have created a VPN tunnel between two private networks:
192.168.53.0/24 and 192.168.60.0/24. We have used the tun_client.py program on
host S (192.168.60.10) and the tun_server.py program on VPN server to establish the
tunnel. We have also used the sysctl command to enable IP forwarding on VPN
server, and the iptables command to set up the firewall rules for packet filtering and
NAT.
We have tested the functionality of the VPN tunnel by pinging host U (192.168.53.10)
from host S, and vice versa. We have observed that you can read the ICMP echo
request packets from the TUN interface on host S, and write them to the UDP socket
connected to VPN server. We have also observed that you can read the UDP packets
from the socket on VPN server, and write them to the TUN interface on VPN server.
We have then observed that VPN server can forward the IP packets from the TUN
interface to the eth0 interface, and send them to host U. We have also observed that
host U can reply to the ICMP echo request packets, and send them back to VPN
server. We have then observed that VPN server can forward the IP packets from the
eth0 interface to the TUN interface, and write them to the UDP socket connected to
34 | P a g e
host S. We have finally observed that you can read the UDP packets from the socket
on host S, and write them to the TUN interface on host S.
We have learned how to create a VPN tunnel between two private networks using
Python, and how to enable IP forwarding and NAT using Linux commands. We have
also learned how to monitor and capture the network traffic using tcpdump. We have
also gained some basic knowledge of private networks, NAT, and VPN tunneling.
Task 9: Experiment with the TAP Interface
Running the tap.py python code
35 | P a g e
Ping 192.168.53.12
36 | P a g e
Observation:
Task 9: Experiment with the TAP Interface:
In this task, we have experimented with the TAP interface instead of the TUN
interface. A TAP interface is a virtual network interface that can transfer Ethernet
frames between user space and kernel space. We have used the tap.py program on
host U to create and configure the TAP interface. We have also used the ifconfig
command to assign an IP address and bring up the interface.
We have tested the functionality of the TAP interface by pinging an unreachable IP
address (192.168.53.12) from host U. We have observed that you can read the
Ethernet frames from the TAP interface, and parse the Ethernet header fields, such as
source and destination MAC addresses, type, etc. We have also observed that you can
write a spoofed Ethernet frame to the TAP interface, and trick the ping program into
thinking that it has received a reply from 192.168.53.12.
We have learned how to create and configure a TAP interface using Python, and how
to manipulate Ethernet frames using the struct module. We have also gained some
basic knowledge of Ethernet header fields, MAC addresses, and frame spoofing.
37 | P a g e
Conclusion
A possible conclusion for this VPN lab could be something like this:
In this lab, we have successfully created a VPN tunnel between a computer (client)
and a gateway, allowing the computer to securely access a private network via the
gateway. We have used the TUN/TAP interface to create virtual network interfaces
on the client and the gateway, and used them to tunnel IP packets between the two
private networks. We have also used encryption and authentication to protect the data
and identity of the VPN users. We have learned how to configure the routing tables
on the client, the gateway, and the host in the private network, to enable bidirectional
communication over the VPN tunnel. We have also experimented with different
scenarios, such as breaking the tunnel, changing the network topology, and using the
TAP interface instead of the TUN interface.
The lab has helped you understand the basic concepts and mechanisms of VPN, such
as tunneling, encryption, authentication, routing, etc. We have also gained hands-on
experience with the TUN/TAP interface and its applications. By completing the lab,
you have demonstrated your ability to create your own VPN using these tools.
38 | P a g e