Skip to content

🔐 Project 05 — VPN Tunnel Setup

Network Security

View the live site — ijk37.com

Project 05: VPN Tunnel Setup

Home All Projects Notes Quiz

Type: Build/design project (Linux VMs) Modules: 07 (Cryptography Fundamentals), 08 (VPN & Secure Tunneling) Difficulty: ⭐⭐⭐

🎯 Objective

Stand up a working VPN tunnel between two Linux hosts — simulating two office sites (or a remote client and a site server) — and verify that traffic between them is actually encrypted end-to-end.

🧭 Scenario

Two VMs sit on separate, simulated networks (e.g. two different host-only/NAT virtual networks, or two network namespaces if you don't have spare VMs) and cannot normally see each other's private subnet. Your job is to build a VPN tunnel so that:

  • Each site keeps its own private LAN.
  • The two sites (or the client and the server) can reach each other's private address range only through the encrypted tunnel.
  • Anyone sniffing the traffic on the underlying physical/NAT link sees ciphertext, not the original packets.

🛠 Setup

VM Role Notes
Site A / Server Runs the VPN server process Has a "private LAN" interface plus a "public/NAT" interface
Site B / Client Runs the VPN client process Same two-interface layout

You need:

  • Two Linux VMs (Ubuntu/Debian/Kali all work) with a shared "public" network between them and a separate private-subnet interface on each.
  • Either OpenVPN or WireGuard installed (pick one — don't try to do both in the same pass).
  • Wireshark or tcpdump on at least one VM to capture the underlying (non-tunnel) interface.

🧩 Tasks

🔹 Part A — Choose a VPN Technology and Generate Keys

  1. Decide between OpenVPN (TLS-based, certificate authentication) and WireGuard (modern, key-pair based, minimal config). Either is acceptable — note which you picked and why.
  2. Generate the cryptographic material:
  3. OpenVPN: build a small PKI (CA cert, server cert/key, client cert/key) with easy-rsa or openssl.
  4. WireGuard: generate a private/public key pair on each peer with wg genkey / wg pubkey.
  5. Before moving on, explain why this step matters — what would go wrong if the tunnel used no authentication at all, or reused the same key on every deployment? Link your explanation to [[07-08-digital-certificates-and-pki]].

🔹 Part B — Configure and Bring Up the Tunnel

  1. Write the server-side config (OpenVPN server config, or WireGuard wg0.conf with [Interface]/[Peer]) and the client-side config.
  2. Bring up the tunnel interface (tun0/wg0) on both ends.
  3. Assign each end an address inside a dedicated VPN address range (e.g. 10.8.0.0/24) — separate from either site's private LAN.
  4. Verify the tunnel is up with ip a, then ping across the tunnel IPs.
  5. Add a route (or note the routing already set up by the VPN software) so each side's private LAN subnet is reachable through the tunnel, and confirm with traceroute/tracepath that the path goes through the tunnel interface, not the raw public interface.

🔹 Part C — Prove the Traffic Is Encrypted

  1. Start a capture on the underlying physical/NAT interface (not the tunnel interface) with Wireshark or tcpdump -i eth0 -w vpn_on.pcap.
  2. Generate some traffic across the tunnel (ping, or a small file transfer) and stop the capture.
  3. Open the capture and confirm the payload is opaque — you should see VPN protocol framing (e.g. OpenVPN or WireGuard UDP packets) but not the original ping payload or file contents in plaintext.
  4. As a control, temporarily send the same kind of traffic without the VPN (e.g. a plain ping/ftp/telnet session directly between the two public interfaces) and capture it too. Confirm this control capture shows the payload in the clear, in contrast to the VPN capture.

✅ Verification Checklist

  • Tunnel interface is up on both ends and each side has an address in the VPN's dedicated subnet.
  • ping across the tunnel IPs succeeds.
  • A host on Site A's private LAN can reach a host on Site B's private LAN (or client reaches server LAN) only via the tunnel.
  • Capture on the underlying interface during VPN traffic shows only encrypted/opaque payloads.
  • Control capture without the VPN shows the same traffic in plaintext, for contrast.
  • Explained the role of the keys/certificates generated in Part A.

📦 Deliverables

  • Server and client tunnel configuration files, with all private keys and certificate private-key material redacted before sharing.
  • A short description (in words, no need to attach raw .pcap files) of what the "VPN on" capture looked like vs. the "VPN off" control capture — what fields/payloads were visible in each.
  • A short write-up: which VPN technology you chose, why, and what specifically was encrypted vs. still visible in metadata (e.g. UDP/IP headers of the tunnel packets themselves are never hidden — only the inner payload is).

🚀 Stretch Goals

  • Configure split-tunneling so that only traffic destined for the remote private subnet goes through the tunnel, while general internet-bound traffic still goes out the normal default route. See [[08-05-split-tunneling-and-configuration]].
  • Measure the throughput and latency overhead the VPN adds (e.g. compare iperf3/ping results with the tunnel up vs. sending the same traffic directly, unencrypted, between the two hosts).

See also notes: [[08-01-vpn-concepts-and-types]], [[08-04-building-a-vpn-tunnel]], [[07-08-digital-certificates-and-pki]]