Learning VPN Basics: A Beginner's Guide

How VPNs Work: The Technology Behind Secure Connections

Understanding VPN Protocols

VPNs create an encrypted tunnel between a client and a VPN server. The protocol determines how packets are encapsulated, which encryption primitives are used, and how keys are negotiated. Common protocols include:

• OpenVPN — mature, TLS-based; widely supported on many platforms (use OpenVPN 2.5+ compatible clients).
• WireGuard — lightweight, modern crypto, included in Linux kernel since 5.6; recommended for high performance and simple configs.
• IKEv2/IPsec — stable for mobile connections with built-in rekeying and good NAT traversal behavior.
• PPTP — legacy and insecure; avoid for privacy/security use cases.

Protocol choice affects CPU usage, MTU/fragmentation, handshake overhead, and latency. When evaluating protocols, measure throughput (Mbps), latency (ms), and CPU utilization on the client and server under realistic load to choose the best fit for your use case.

# Example: start an OpenVPN connection with a client configuration
sudo openvpn --config client.ovpn

Types of VPNs: Understanding Your Options

Different VPN Types Explained

Common deployment types:

• Remote Access VPN: Individual users connect to a central network (telecommuting).
• Site-to-Site VPN: Connects two networks (e.g., branch offices).
• Mobile VPN: Maintains sessions while switching networks (useful for field devices).
• Client-based VPN: Software installed and managed on each endpoint (common for consumer VPNs).

# Pseudocode: connect to a corporate VPN using a vendor client
sudo vpnclient connect

Hands-on: Client Setup on Windows 10/11

The most common user scenario is installing a vendor client on Windows. Below is a tested, practical checklist using mainstream providers and the client-side security choices to make.

1. Download the provider client from the vendor home page (examples: NordVPN, ExpressVPN, or the OpenVPN client at OpenVPN).
2. Run the installer (Accept UAC prompt); allow the TAP/WireGuard driver during installation.
3. Create/login to your account and follow the onboarding flow.
4. Enable security features: Kill switch (blocks traffic if VPN drops) and DNS leak protection.
5. Select protocol: choose WireGuard (NordLynx) if available for best performance, or OpenVPN (UDP) for compatibility.
6. Connect to a nearby server and verify your IP address and DNS using a trusted site or by using:

# Quick verification (PowerShell or WSL) - check public IP
curl ifconfig.me

Provider selection checklist (client-side perspective):

• Does the provider offer WireGuard or OpenVPN 2.5+? (performance + auditability).
• Is there an audited no-logs policy and clear jurisdictional information? Look for published audit reports on the provider's site.
• Does the client implement a reliable kill switch and DNS leak protection?
• Is split tunneling available if you need local network access while connected?

Notes and tips:

• On Windows, some clients expose split tunneling options. Use split tunneling to exclude specific apps from the VPN when necessary (e.g., local printers).
• For corporate setups, enroll the client using enterprise configuration files or SAML/SSO if provided by your organization.

Self-hosted WireGuard on a Cloud VPS

This section provides a minimal, reproducible WireGuard server example on a Linux VPS (Debian/Ubuntu). WireGuard is included in Linux kernel 5.6+; userland tools are available as the wireguard-tools package (wg, wg-quick).

Prerequisites

• A cloud VPS (e.g., AWS, DigitalOcean, or other provider) with a public IPv4 address.
• Ubuntu 20.04/22.04 or Debian 11+ with kernel >= 5.6 recommended.
• Root or sudo privileges.

Server-side steps (minimal) — with safer key handling

Use secure file creation for private keys (avoid leaving them world-readable or exposing them in process pipelines). The example below uses a safe shell pattern that sets a restrictive umask before writing the private key file as root.

# Update and install WireGuard tools (wireguard-tools provides wg, wg-quick)
sudo apt-get update && sudo apt-get install -y wireguard iptables-persistent

# Generate server keys securely (run as root via sudo). This sets a restrictive umask so the private key is created with tight permissions.
sudo bash -c 'umask 077; wg genkey > /etc/wireguard/server_private.key'
sudo bash -c 'cat /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key'
# Ensure permissions
sudo chmod 600 /etc/wireguard/server_private.key
sudo chown root:root /etc/wireguard/server_private.key

# Create a basic wg0.conf (replace  with the file's contents or use the path in production management)
sudo tee /etc/wireguard/wg0.conf >/dev/null <<'WGCONF'
[Interface]
Address = 10.200.200.1/24
ListenPort = 51820
PrivateKey = REPLACE_WITH_SERVER_PRIVATE_KEY
# SaveConfig = true    # DO NOT enable in production unless you understand the behavior (see note below)

# Example Peer (client) - add real client PublicKey and AllowedIPs as you create peers
#[Peer]
#PublicKey = 
#AllowedIPs = 10.200.200.2/32
WGCONF

# Enable IP forwarding temporarily and persistently
sudo sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf

# Allow UDP port 51820 in firewall (example with ufw)
sudo ufw allow 51820/udp

# Start the interface
sudo systemctl enable wg-quick@wg0 --now

# Verify the interface
sudo wg show

Important notes about SaveConfig and configuration management:

• SaveConfig = true (wg-quick behavior): when set, wg-quick will write the runtime configuration back to the config file on shutdown. This can overwrite manual edits or injected configuration and may unintentionally leak secrets if misused. For production, prefer manual configuration management (e.g., manage files with a configuration management system or keep SaveConfig commented out) and only use SaveConfig in controlled contexts.
• Prefer to store the server private key in a location with root-only access and manage it via secure tooling (e.g., secret manager, restricted filesystems) rather than embedding it in orchestration scripts with loose permissions.

Client example (Linux)

# Generate client keys locally and keep the private key secure
wg genkey | tee client_private.key >/dev/null
cat client_private.key | wg pubkey | tee client_public.key

# Client configuration (wg-client.conf)
[Interface]
PrivateKey = REPLACE_WITH_CLIENT_PRIVATE_KEY
Address = 10.200.200.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = REPLACE_WITH_SERVER_PUBLIC_KEY
Endpoint = :51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

# On Linux: bring up the client (requires root)
sudo wg-quick up wg-client.conf
# Verify
sudo wg
ip a

For mobile devices, use the official WireGuard app and import the config or QR code. For production use, rotate keys and revoke peers by removing their [Peer] section and reloading the interface.

Security hardening & production notes

• Restrict SSH access (use key-based auth, consider changing default port, and use cloud provider firewall rules).
• Use iptables/nftables to NAT VPN traffic out via the server's public interface (e.g., sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE), but maintain explicit rules rather than broad allow rules.
• Enable automatic unattended security updates on the VPS and monitor kernel/security patches.
• Store private keys only on trusted hosts, set file permissions to root-only (chmod 600), and rotate keys if you suspect compromise.

Verifying VPN Performance

Measure VPN throughput and latency using well-known tools. Two practical tools are speedtest-cli (for an Internet-facing speed check) and iperf3 (for controlled server/client throughput tests).

Using speedtest-cli

Install and run a quick check to get a baseline for public upload/download latency and throughput.

# Install speedtest-cli (Python-based) on many distributions
sudo apt-get update && sudo apt-get install -y speedtest-cli

# Run a speed test (compare with/without VPN connected)
speedtest-cli --simple

Using iperf3 for controlled tests

iperf3 gives a repeatable way to measure TCP/UDP throughput between a client and a server under your control. Run an iperf3 server on a host outside the VPN and then test from the VPN client (or vice versa) to measure end-to-end performance.

# On the test server (outside/inside VPN):
iperf3 -s

# On the test client:
iperf3 -c  -P 4 -t 30    # -P parallel streams, -t seconds

# For UDP testing (useful to test MTU/fragmentation influence):
iperf3 -c  -u -b 100M -t 30

# Evaluate CPU load during tests (on the server/client)
# Linux example: show CPU and interrupts
top -b -n 1 | head -n 20

What to measure and why

• Throughput (Mbps): establishes bandwidth impact from the VPN protocol and encryption on both client and server.
• Latency (ms): critical for interactive applications; measure ping to internal VPN IP and to public IPs.
• CPU utilization: encryption is CPU-bound for small packets; measure on both ends to identify bottlenecks.
• MTU/fragmentation: WireGuard generally works well, but misconfigured MTUs can cause throughput drops; use smaller MTU if you see packet loss or retransmits.

Run comparative tests with and without the VPN to quantify the overhead and to choose protocol/configuration that meets your performance requirements.

Setting Up Your First VPN: Provider Selection

This section focuses on provider selection criteria and removes redundant step-by-step installation details already covered in the Windows client and WireGuard server sections.

Provider selection criteria

• Protocols & technology: Prefer providers offering WireGuard and OpenVPN 2.5+; these provide modern crypto and interoperability.
• Transparency: Look for published independent audits and a clear no-logs policy on the provider's root domain. Audits and transparency reports help build trust.
• Jurisdiction: Providers under different legal regimes have different obligations; choose a provider whose jurisdiction aligns with your privacy needs.
• Security features: Kill switch, DNS leak protection, multi-hop (if required), and split tunneling as needed.
• Support & tooling: Verify client support for your OS (Windows/macOS/Linux/iOS/Android) and CLI/API options if you need automation.
• Server locations & performance: Good geographic distribution and low-latency servers matter for global teams—verify with provider speed checks or independent tests.

After selecting a provider, use the vendor's root domain to download the client and follow their documented onboarding flow (see vendor home pages linked earlier). For self-hosting, follow the WireGuard VPS section above and apply production hardening.

Troubleshooting & Security Checklist

Common Diagnostics

• Verify interface and keys: sudo wg (WireGuard) or sudo systemctl status openvpn@client (OpenVPN).
• Logs: sudo journalctl -u wg-quick@wg0 -e or sudo journalctl -u openvpn@client -e. Check for handshake errors and permission issues when reading keys/files.
• Connectivity: ping the server's VPN IP and then a public IP (e.g., ping 8.8.8.8), test DNS resolution via dig @1.1.1.1 example.com.
• Packet capture: use sudo tcpdump -i eth0 udp port 51820 or port 1194 to inspect handshake packets; filter metadata and avoid logging private keys.

Security Checklist

• Use modern ciphers (AES-256-GCM for OpenVPN; WireGuard uses its own modern primitives) and avoid obsolete protocols (PPTP).
• Enable the client's kill switch and DNS leak protection where available.
• Harden server access: SSH keys, restricted firewall rules, and principle of least privilege for users and services.
• Monitor for unusual client IPs and revoke client keys if a device is lost; rotate keys periodically in production.

Specific troubleshooting tips

• If the client shows the tunnel up but traffic doesn't route, verify IP forwarding (sysctl net.ipv4.ip_forward) and NAT rules on the server.
• Handshake failures: confirm public keys and endpoints, check NAT/firewall blocking UDP ports (51820 for WireGuard, 1194/other for OpenVPN).
• Check file permissions on private keys (should be root-only, e.g., chmod 600 /etc/wireguard/server_private.key).

Common Use Cases for VPNs: When and Why to Use Them

Enhanced Security for Public Wi-Fi

Using a VPN on public Wi-Fi encrypts your traffic and reduces the risk of eavesdropping. For streaming and geo-unblocking, a VPN can route traffic through a server in another country, though some streaming providers actively detect and block VPNs.

• Protect sensitive data on public Wi-Fi.
• Access geo-restricted content where permitted by the service's terms.
• Provide secure remote access for employees to corporate resources.

# Example: connect using a vendor CLI (vendor specific)
nordvpn connect

Best Practices for Using VPNs: Staying Safe and Secure

Understanding VPN Security Features

Key client/server features to prefer:

• Strong encryption (AES-GCM or WireGuard default primitives).
• Kill switch to prevent leaks on disconnect.
• DNS leak protection to ensure DNS queries traverse the VPN.
• Independent security audits and transparent privacy policies.

Avoiding Common VPN Pitfalls

Avoid free VPNs with unclear business models or excessive permissions. Prioritize vendors with clear audit reports and good operational hygiene. Keep clients and server packages updated to receive security fixes.

# Update VPN client or server packages on Debian/Ubuntu
sudo apt-get update && sudo apt-get upgrade -y