VPN Fundamentals Study Notes networking vpn

VPN (Virtual Private Network)

A VPN is software on your machine and software on a remote server (VPN server) that agree to encapsulate and encrypt IP packets between them.

Then VPN server is just a normal server connected to the internet with a public IP running VPN software configured to forward traffic on behalf of clients.

To use a VPN or the internet itself you need internet connectivity first, usually by an ISP, keep that in mind.

You can reach the VPN server like any website, ones the VPN client and server authenticate each other, the VPN client creates a virtual network interface, assigns it an IP then change the OS routing table. Your OS now believes there is a network reachable through this interface.

but those packets before reaching the VPN server gets:

  1. Encrypted
  2. Encapsulated inside another packet

Ones sent to the VPN server, get decrypted and forwarded onward

So conceptually:

I am sending packets to google.com

becomes:

I am sending encrypted packets to the VPN server, and it will send them to google.com for me

The destination never sees you, it sees the VPN server. Your ISP never sees the destination, but sees encrypted traffic to the VPN server.

VPN tunnel

A tunnel is not a physical thing and not a special path in the internet. A tunnel is simply packets placed inside other packets.

Inside the tunnel is normal IP traffic. Encryption happens after the packet is created and before it leaves your machine.

VPN Trust

A VPN is not private by default, it is private with respect to everyone except the VPN operator. The VPN server:

  • Sees your real IP (need to send traffic back to you)
  • It sees all your traffic in decrypted form (unless it’s already encrypted before)
  • It knows your destinations
  • Timing, size, and patterns of traffic.
  • It can log everything

What a VPN really does is move trust only. You stop trusting your ISP, and start trusting the VPN provider, whoever controls that server

In enterprise cybersecurity, this is acceptable because you own the VPN but in consumer VPNs, this is a gamble.

Split Tunnel vs Full Tunnel

Full Tunnel

All traffic goes through VPN.

0.0.0.0/0 → tun0

Split Tunnel

Only some subnets use VPN.

Example:

10.0.0.0/8 → tun0
everything else → normal gateway

TUN (Network TUNnel) / TAP (Network TAP)

TUN/TAP are basically software NICs connected to userspace programs instead of physical hardware.

TUN = Layer 3 Device

TUN simulates the Network Layer (OSI Layer 3)

It carries:

  • IPv4 packets
  • IPv6 packets

ONLY. No Ethernet headers.

TAP = Layer 2 Device

TAP simulates Data Link Layer (OSI Layer 2)

It carries full Ethernet frames.

Most VPNs only need IP routing.

They do NOT need:

  • Ethernet broadcasts
  • ARP
  • switching
  • Layer 2 bridging

So TUN is:

  • simpler
  • faster
  • lower overhead

TAP is useful when software must emulate a real Ethernet LAN.

Examples:

  • VM networking
  • Ethernet bridging
  • legacy broadcast protocols
  • transparent LAN extension

Common VPN Protocols

WireGuard

Modern protocol. Uses:

  • NoiseIK
  • Curve25519
  • ChaCha20
  • UDP only

Fast and minimal.

OpenVPN

TLS-based VPN protocol. Flexible but heavier.

Uses:

  • OpenSSL
  • TLS
  • TUN/TAP

IPsec

Enterprise-grade VPN suite.

Often used with:

  • IKEv2
  • ESP

Very common in corporate networking.

PPTP

Point-to-Point Tunneling Protocol

Old and insecure. Broken cryptographically.

L2TP/IPsec

Layer 2 Tunneling Protocol

Older enterprise approach.

Usually paired with IPsec for encryption.

SSTP (Secure Socket Tunneling Protocol)

Microsoft VPN protocol over HTTPS/TLS.

Examples of Custom VPN Protocols

NordLynx

NordLynx From NordVPN

Based on WireGuard with additional privacy layers.

Lightway

Lightway From ExpressVPN

Custom lightweight protocol. Inspired partly by WireGuard philosophy.

Tailscale

Tailscale Built on WireGuard.

ProtonVPN

Supports:

  • OpenVPN
  • WireGuard

Many custom VPN protocols are still heavily based on:

  • TLS
  • WireGuard concepts
  • UDP tunnels
  • Noise-like handshakes

Very few invent crypto completely from scratch safely.

Full VPN connection example

Step 1 - Virtual Interface Creation

You start WireGuard, OpenVPN or any another VPN client. The VPN software now creates virtual interface. Example:

tun0

Kernel now believes this is a real network interface

Step 2 - Encrypted Tunnel Established

Now client must securely establish keys with VPN server. At this stage no user traffic is tunneled yet. First the secure session keys must exist.

Now both sides share symmetric session keys between:

you (client) ↔ VPN server

Step 3 - Routing Table Changes

VPN client changes routes. Example:

Before VPN:

default via 192.168.1.1 dev wlan0

After VPN:

default via 10.8.0.1 dev tun0

Now it send internet traffic into VPN interface tun0

Step 4 - Application Sends Traffic

Suppose you visits:

https://google.com

Browsers by itself for example usually does NOT know VPN exists. Browser simply creates TCP socket and try to connect normally.

Kernel creates normal IP packet:

SRC = your VPN-assigned IP
DST = Google IP

packet goes into:

tun0

instead of physical NIC directly.

Step 5 - VPN Software Receives Packet

VPN software now receives the raw packet.

Example packet:

[IP][TCP][TLS][HTTP]

This is still the ORIGINAL packet.

Step 6 - VPN Client Encrypts Packet

Now VPN encapsulates it. Original packet becomes payload.

Before:

[Inner IP][TCP][TLS][HTTP]

After:

[Outer IP][UDP][VPN Header][Encrypted Inner Packet]

This is tunneling.

The original packet is usually ALREADY HTTPS encrypted.

VPN adds ANOTHER encryption layer around entire packet. So you get HTTPS inside VPN encryption this is layered encryption.

Step 7 - Encapsulated Packet Goes to ISP

Now VPN software sends encrypted UDP packet to router then to the ISP.

tun0 is not a physical transmission interface.

It is a virtual packet interception/injection point inside the kernel networking stack. Eventually, the encrypted VPN traffic MUST leave through a real network interface like:

wlan0
eth0

otherwise it could never reach the VPN server.

Step 8 - What ISP Can See

ISP CAN see:

  • your real IP
  • VPN server IP
  • packet sizes
  • timing
  • bandwidth usage
  • protocol type sometimes
  • UDP/TCP ports

ISP CANNOT see:

  • websites visited (usually)
  • packet payload
  • DNS queries if tunneled
  • page contents
  • inner IP packets

So instead of:

You → Google

ISP sees:

You → VPN server

Step 9 - VPN Server Receives Packet

VPN server receives and decrypts payload.

Step 10 - VPN Server NATs/Forwards Packet

VPN server typically performs NAT masquerading

Example:

Original inner packet:

SRC = 10.8.0.2
DST = Google

Cannot send private address onto internet.

So server rewrites source:

SRC = VPN server public IP
DST = Google

Now packet becomes normal internet traffic and send it to destination.

Website sees:

VPN server IP

NOT your real home IP. That’s why websites think you’re in another country.

Website then responds:

DST = VPN server public IP

because from Google’s perspective, VPN server initiated connection.

Step 11 - VPN Server Maps Connection Back

Server connection tracking remembers, this flow belongs to VPN client X.

Using:

  • conntrack
  • NAT tables
  • session mappings

Server rewrites destination back:

DST = 10.8.0.2

Step 12 - VPN Server Encrypts Return Packet

Server encapsulates inner packet again and sends to your real IP.

Step 13 - Your VPN Client Receives Response

VPN software receives encrypted packet. Decrypts it. Extracts original inner packet.

Step 14 - Packet Injected Into Kernel

VPN software writes packet into:

tun0

Kernel treats packet as legitimate incoming network traffic.

Step 15 - Browser Receives Response

Browser gets HTTPS response normally. Browser never directly handled VPN logic. Everything happened underneath.

Important DNS Detail:

If VPN Handles DNS Properly, DNS queries also go through tunnel. ISP cannot see domains queried. But:

If DNS leaks, possible situation:

  • Web traffic goes to VPN
  • DNS traffic goes to ISP DNS

Then ISP still sees domains visited.

Multi-Hop VPNs

Some VPNs chain servers:

You → VPN1 → VPN2 → Internet

Makes correlation harder. But adds latency.

Userspace vs Kernel space

  • Browser → userspace
  • Discord → userspace
  • Network drivers → kernel space
  • Linux networking stack → kernel space

OpenVPN Userspace

OpenVPN mostly runs in userspace, meaning packets have to move:

Kernel → OpenVPN app → Kernel

for encryption and sending. That adds extra copying and context switching, which makes it slower.

WireGuard Kernel space

WireGuard usually runs directly inside the kernel on Linux:

Kernel → WireGuard → Network

So packets stay inside the OS networking layer, making it faster, lower latency, and more efficient.

Point-to-Point vs Site-to-Site

Point-to-Point VPN

Single client ↔ server. Example:

Laptop ↔ VPN provider

Site-to-Site VPN

Entire networks connected together. Example:

Office A LAN ↔ Office B LAN

Routers tunnel traffic between subnets.