What Is a VPN and How It Actually Works

The VPN industry generates approximately $45 billion annually. The companies selling that product describe it as a shield against "hackers," a tool for "complete anonymity," and occasionally use the phrase "military-grade encryption" — which means exactly as much as it sounds like. VPN vendor marketing is among the most deliberately misleading in consumer technology.

Here is what a VPN actually does: it creates an encrypted tunnel between your device and a server. All traffic entering the tunnel is encrypted before it leaves your device and decrypted at the other end. That is the complete functional description.

What this means in practice:

• Your ISP sees encrypted bytes going to the VPN server — not which websites you visit
• Websites you visit see the VPN server's IP address — not yours
• Anyone on your local network (coffee shop, hotel, airport) sees only encrypted data to one destination

What this does not mean:

• Anonymity (the VPN provider knows everything your ISP previously knew)
• Protection from malware on your device
• Security of the websites you visit
• Hiding your identity from sites where you are logged in
• Any meaningful protection from a determined adversary

Understanding the actual mechanics — not the marketing — lets you make an informed decision about whether a VPN is useful for your specific situation, and if so, which one to trust.

The Tunnel: What It Protects and What It Doesn't

When you activate a VPN, your device negotiates an encrypted tunnel with the VPN server. All traffic from your device is encrypted before transmission, travels through this tunnel to the VPN server, is decrypted there, and then exits to its destination as regular internet traffic.

Without VPN:
Your Device → [Plaintext or TLS to destination] → Destination
  ↑ ISP sees: all connections, DNS queries, metadata
  ↑ Local network sees: same as ISP

With VPN:
Your Device → [Encrypted VPN Tunnel] → VPN Server → [Regular internet] → Destination
  ↑ ISP sees: encrypted data going to VPN server IP. That's it.
  ↑ Local network sees: same as ISP
  ↑ VPN provider sees: everything your ISP previously saw
  ↑ Destination sees: VPN server's IP address, not yours

The trust shift: you are moving who can see your traffic from your ISP and local network to the VPN provider. This is an improvement only if the VPN provider is more trustworthy and has less data retention than your ISP. That is a non-trivial assumption that requires evidence — not marketing claims.

VPN Protocols: The Technical Foundation

Three protocols dominate modern VPN deployments. Each makes different trade-offs between performance, security, attack surface, and compatibility.

WireGuard: The Current Best Choice

WireGuard was written by Jason Donenfeld and merged into the Linux kernel in version 5.6 (March 2020). It has approximately 4,000 lines of code — compared to OpenVPN's 100,000+ and IPsec's even larger implementation surface. Smaller code means smaller attack surface, easier auditing, and more reliable implementation.

The cryptographic primitives are fixed — WireGuard uses exactly:

• Curve25519 for key exchange (Diffie-Hellman)
• ChaCha20 for symmetric encryption of data
• Poly1305 for message authentication (AEAD)
• BLAKE2s for hashing
• SipHash24 for hashtable keys
• HKDF for key derivation

There are no cipher negotiation options, no version negotiation, no possibility of downgrade attacks. You cannot misconfigure WireGuard into using weak cryptography — the only choice is to use it or not use it.

Performance compared to OpenVPN: WireGuard throughput is typically 3-5x higher than OpenVPN in the same hardware. On a typical cloud server, WireGuard handles 1+ Gbps with minimal CPU overhead, while OpenVPN tops out at 100-200 Mbps due to TLS overhead.

WireGuard server setup from scratch:

# Install WireGuard (Debian/Ubuntu)
apt-get update && apt-get install -y wireguard
 
# Generate server keys
cd /etc/wireguard
wg genkey | tee server_private.key | wg pubkey > server_public.key
chmod 600 server_private.key  # Private key must be readable only by root
 
# Enable IP forwarding (required for VPN clients to reach the internet)
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding = 1" >> /etc/sysctl.conf
sysctl -p
 
# Get your primary network interface name
ip route show default | awk '{print $5}'  # Usually eth0 or ens3
 
# Create the server configuration
cat > /etc/wireguard/wg0.conf << EOF
[Interface]
PrivateKey = $(cat server_private.key)
Address = 10.10.10.1/24, fd86:ea04:1115::1/64  # IPv4 + IPv6 VPN range
ListenPort = 51820
 
# Enable NAT so VPN clients can reach the internet through the server
# Replace eth0 with your actual interface
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
EOF
 
# Open the firewall port
ufw allow 51820/udp
ufw allow 22/tcp  # Don't lock yourself out!
 
# Start WireGuard
systemctl enable --now wg-quick@wg0
wg show  # Verify it's running

Adding a client to the server:

# Generate client keys
wg genkey | tee client1_private.key | wg pubkey > client1_public.key
 
# Add client to server config
cat >> /etc/wireguard/wg0.conf << EOF
 
[Peer]
# Client 1
PublicKey = $(cat client1_public.key)
AllowedIPs = 10.10.10.2/32, fd86:ea04:1115::2/128
EOF
 
# Apply the change without restarting (live reload)
wg addconf wg0 <(wg-quick strip wg0)
# Or restart: systemctl restart wg-quick@wg0

Client configuration (the file you send to the user):

# Save as /etc/wireguard/wg0.conf on the client
[Interface]
PrivateKey = [CLIENT-PRIVATE-KEY-HERE]
Address = 10.10.10.2/32, fd86:ea04:1115::2/128
# Use the VPN server as DNS — prevents DNS leaks
DNS = 10.10.10.1
 
[Peer]
PublicKey = [SERVER-PUBLIC-KEY-HERE]
Endpoint = YOUR-SERVER-IP:51820
# Route ALL traffic through the VPN (no split tunneling)
AllowedIPs = 0.0.0.0/0, ::/0
# Maintain NAT mapping behind home routers
PersistentKeepalive = 25

# On the client: bring up the VPN
wg-quick up wg0
# Or with systemd:
systemctl enable --now wg-quick@wg0
 
# Verify the VPN is active and routing correctly
wg show                    # Shows connection status and last handshake
curl -s https://ifconfig.me  # Should return VPN server IP

OpenVPN: The Legacy Standard

OpenVPN uses TLS for the control channel (authentication, key exchange) and OpenSSL for the data channel (packet encryption). It has been the dominant open-source VPN protocol since 2001 and remains widely deployed despite WireGuard being the better technical choice for new deployments.

When to still use OpenVPN:

• Corporate environments that have standardized on it and cannot migrate
• Situations where you need to traverse restrictive firewalls (OpenVPN on TCP port 443 looks like HTTPS)
• Compatibility with clients that do not support WireGuard

The correct configuration options for OpenVPN (insecure defaults to override):

# Server: /etc/openvpn/server/server.conf
# These options harden against weak cipher negotiation

# Use TLS 1.3 only (TLS 1.2 is acceptable, 1.0 and 1.1 are not)
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

# Data channel cipher — AES-256-GCM only
cipher AES-256-GCM
ncp-ciphers AES-256-GCM  # Disable cipher negotiation to weaker options
auth SHA512               # HMAC for TLS control channel

# Elliptic curve for DH key exchange
tls-groups prime256v1    # Or X25519 if your OpenVPN version supports it

# Perfect forward secrecy — new keys each TLS session
tls-crypt /etc/openvpn/tls-crypt.key  # Also authenticates the control channel
# tls-crypt is stronger than tls-auth (the older option)

# Hardening
user nobody
group nogroup
persist-key
persist-tun

# Security monitoring
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

# Certificate requirements
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh none  # Using ECDH, so DH parameters file not needed

IPsec/IKEv2: The Enterprise and Mobile Standard

IPsec is native to Windows, macOS, iOS, and Android — requiring no additional software for basic connectivity. This makes it the default choice for corporate remote access deployments where software management is a concern.

IKEv2 (Internet Key Exchange version 2) handles authentication and key negotiation. IPsec ESP (Encapsulating Security Payload) handles the actual data encryption.

StrongSwan server configuration for IKEv2/EAP-TLS:

# Install strongSwan
apt-get install -y strongswan strongswan-pki libcharon-extra-plugins
 
# Generate PKI infrastructure
# Certificate Authority
pki --gen --type ec --size 384 --outform pem > /etc/ipsec.d/private/ca.key
pki --self --ca --lifetime 3650 --in /etc/ipsec.d/private/ca.key \
    --type ec --dn "CN=VPN-CA" --outform pem > /etc/ipsec.d/cacerts/ca.crt
 
# Server certificate (must have the server's IP or DNS name as SAN)
pki --gen --type ec --size 384 --outform pem > /etc/ipsec.d/private/server.key
pki --pub --in /etc/ipsec.d/private/server.key --type ec | \
    pki --issue --lifetime 1825 --cacert /etc/ipsec.d/cacerts/ca.crt \
        --cakey /etc/ipsec.d/private/ca.key \
        --dn "CN=VPN-SERVER-DNS-OR-IP" \
        --san VPN-SERVER-DNS-OR-IP \
        --flag serverAuth --flag ikeIntermediate \
        --outform pem > /etc/ipsec.d/certs/server.crt

L2TP/PPTP: Never Use These

PPTP (Point-to-Point Tunneling Protocol) uses RC4 for encryption. RC4 is broken. PPTP's MS-CHAPv2 authentication is crackable with commodity hardware. Microsoft has advised against PPTP since 2012. There is no scenario where PPTP is an acceptable choice.

L2TP alone provides no encryption — it is a tunneling protocol only. L2TP is typically combined with IPsec (L2TP/IPsec), but this combination is frequently misconfigured, and using L2TP/IPsec when IKEv2 is available offers no advantages with more complexity.

If a VPN provider offers only PPTP or L2TP as options, that is sufficient reason to choose a different provider.

The Key Exchange: Why You Can Establish Encryption Without Pre-Sharing a Key

The most unintuitive aspect of VPN encryption: two parties who have never communicated before can agree on a shared encryption key over a public channel without an attacker who intercepts the entire exchange being able to determine the key. This seems impossible until you understand the mathematics.

Diffie-Hellman Key Exchange (Conceptual)

The Diffie-Hellman protocol (1976) solved the key distribution problem using one-way mathematical functions. The analogy that works:

Imagine you and a stranger want to agree on a color that only you two know
without an eavesdropper seeing the color being transmitted.

1. You both start with a publicly known base color: Yellow
2. You pick a secret color: Red
   Stranger picks a secret color: Blue
3. You mix your secret with the public color: Yellow+Red = Orange
   Stranger mixes their secret with the public color: Yellow+Blue = Green
4. You send Orange to the stranger. Stranger sends Green to you.
   (An eavesdropper sees Yellow, Orange, and Green)
5. You mix your secret Red with received Green: Green+Red = Brown
   Stranger mixes their secret Blue with received Orange: Orange+Blue = Brown
6. Both of you now have Brown — the same shared secret.
   The eavesdropper has Yellow, Orange, Green but cannot determine Brown
   because they don't know either secret (Red or Blue).

In actual Diffie-Hellman, colors are replaced by modular exponentiation. The "one-way" function is: g^x mod p — computing this is fast; reversing it (finding x given g^x mod p) is computationally infeasible with sufficiently large values.

WireGuard uses Curve25519, a modern elliptic curve variant of Diffie-Hellman that provides 128-bit security with 256-bit keys — far more efficient than classical DH while offering equivalent security.

Perfect Forward Secrecy: Why Today's Keys Can't Decrypt Yesterday's Traffic

Perfect Forward Secrecy (PFS) means that each VPN session generates a new, ephemeral Diffie-Hellman key exchange. The session key is not derived from a long-term secret. If an attacker:

1. Records all your encrypted VPN traffic for a year
2. Then compromises the VPN server and obtains its private key

With PFS: the recorded traffic cannot be decrypted. Each session's key is gone after the session ends — it was ephemeral and was never stored.

Without PFS: the long-term private key can decrypt all historical traffic that was encrypted with it.

WireGuard implements PFS by default through its handshake protocol. OpenVPN implements it through the --tls-crypt option and the underlying TLS ephemeral key exchange. IPsec implements it through the PFS option in the IKE policy.

Check that your VPN configuration has PFS:

# For OpenVPN: verify tls-crypt is configured
grep -i "tls-crypt\|tls-auth" /etc/openvpn/server/server.conf
 
# For IPsec: verify PFS is enabled in connection config
grep -i "esp.*-sha\|pfs" /etc/ipsec.conf
# Look for something like:
# esp = aes256gcm128-sha256-modp2048-modp3072  # modp2048+ = Diffie-Hellman enabled
 
# For WireGuard: PFS is built in — every handshake generates fresh keys
wg show  # Shows handshake time — new handshake every ~3 minutes means fresh keys

DNS Leaks: The Most Common VPN Failure

A DNS leak is the scenario where your VPN is active and encrypting HTTP/HTTPS traffic, but your DNS queries — the lookups that translate domain names to IP addresses — bypass the VPN tunnel and go directly to your ISP's DNS server.

The result: your ISP still sees every domain you visit. Your traffic content is encrypted, but your destination is plaintext to your ISP through DNS queries.

DNS leaks happen because of:

• Operating system DNS resolver configuration overriding the VPN's DNS settings
• Split DNS configurations that resolve internal names through the corporate DNS and external names through the ISP
• WebRTC's local network discovery (different from DNS but similar leak of real IP)
• IPv6 traffic bypassing an IPv4-only VPN tunnel

Diagnosing DNS Leaks

# Method 1: Check what IP address you appear to have
# Should match your VPN server IP, not your real IP
curl -s https://ifconfig.me
curl -s https://api.ipify.org
 
# Method 2: Check which DNS server is answering your queries
# Should be your VPN server or the VPN provider's DNS, not your ISP
dig +short myip.opendns.com @resolver1.opendns.com
# If this returns your real IP, DNS is leaking
 
# Method 3: Check your configured DNS resolvers
cat /etc/resolv.conf          # Linux/macOS
# Windows: ipconfig /all | findstr "DNS"
 
# Method 4: Check DNS per interface (systemd-resolved systems)
resolvectl status
# Look for wg0 (or your VPN interface) — it should have DNS configured
# If only eth0 has DNS and not wg0, DNS is going out the unencrypted interface
 
# Method 5: Comprehensive test
# Visit dnsleaktest.com or ipleak.net — they show every DNS server
# that resolved their test domains on your behalf
# Should show only VPN server IP or VPN provider's DNS — not your ISP

Fixing DNS Leaks on Linux

# Method 1: WireGuard's DNS option (easiest — handled by wg-quick)
# In your WireGuard client config:
[Interface]
PrivateKey = ...
Address = 10.10.10.2/32
DNS = 10.10.10.1  # Use VPN server as DNS resolver
# wg-quick writes this to /etc/resolv.conf when the VPN starts
 
# Method 2: systemd-resolved configuration
# Set VPN interface as DNS for ALL domains (the ~. means "everything")
resolvectl dns wg0 10.10.10.1
resolvectl domain wg0 "~."
# "~." means: route all DNS queries through this interface's DNS
 
# Verify:
resolvectl status wg0
# Should show: Current DNS Server: 10.10.10.1
#              DNS Domain: ~.
 
# Method 3: NetworkManager with persistent configuration
# In /etc/NetworkManager/conf.d/no-dns-leak.conf:
[main]
dns=none  # Prevent NetworkManager from overwriting /etc/resolv.conf
 
# Then set /etc/resolv.conf manually:
echo "nameserver 10.10.10.1" > /etc/resolv.conf
chattr +i /etc/resolv.conf  # Make file immutable so nothing can overwrite it
 
# Method 4: iptables rule forcing all DNS through VPN
# Any DNS query NOT going to the VPN server is blocked
iptables -A OUTPUT -p udp --dport 53 ! -d VPN-SERVER-IP -j DROP
iptables -A OUTPUT -p tcp --dport 53 ! -d VPN-SERVER-IP -j DROP

WebRTC IP Leak

WebRTC is a browser protocol for real-time communication. It can expose your real IP address even through a VPN by establishing STUN connections that reveal local network interfaces:

// This JavaScript, run in a browser, can reveal real IP addresses
// even when a VPN is active — because WebRTC queries local network interfaces
const pc = new RTCPeerConnection({
    iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});
pc.createDataChannel("");
pc.createOffer().then(offer => pc.setLocalDescription(offer));
pc.onicecandidate = e => {
    if (e.candidate) {
        // This logs your real local IP and potentially your real public IP
        console.log(e.candidate.candidate);
    }
};

Fix: disable WebRTC in Firefox (about:config → media.peerconnection.enabled = false) or use the uBlock Origin extension which includes WebRTC leak blocking. Chrome has no built-in WebRTC disable option — use an extension.

Split Tunneling: The Performance vs. Security Trade-off

Split tunneling controls which traffic routes through the VPN and which goes directly to the internet. Two modes:

Full tunneling (AllowedIPs = 0.0.0.0/0): Everything goes through the VPN — Netflix, YouTube, corporate applications, everything. The VPN server sees all traffic. Performance depends on VPN server location relative to your actual destinations. Latency increases.

Split tunneling: Only corporate traffic (specific subnets) goes through the VPN. Personal internet traffic goes directly. Better performance for non-corporate destinations.

# WireGuard split tunneling example
# Only route corporate network traffic through VPN
[Peer]
PublicKey = SERVER-PUBLIC-KEY
Endpoint = vpn.company.com:51820
 
# Instead of 0.0.0.0/0 (all traffic), specify only corporate subnets
AllowedIPs = 10.0.0.0/8,         # Corporate network
             172.16.0.0/12,       # Other private ranges
             192.168.1.0/24,      # HQ office network
             10.10.10.0/24        # VPN network itself
# Personal internet traffic goes directly, not through VPN

The security problem with split tunneling:

A compromised device with split tunneling has simultaneous access to your corporate network (through the VPN) and the public internet (directly). If malware runs on that device, it can exfiltrate corporate data over the direct internet path while appearing to operate normally through the VPN. The VPN's logging and monitoring only sees the corporate-bound traffic.

Compromised laptop with split tunneling:
Corporate traffic → [VPN] → Corporate network (monitored)
Malware C2 traffic → [Direct internet] → Attacker server (unmonitored)

For high-security corporate environments, disable split tunneling. All traffic must route through the VPN where corporate security monitoring applies.

VPN Kill Switches: Preventing Accidental Exposure

A VPN kill switch blocks all internet traffic if the VPN connection drops. Without a kill switch, a brief VPN reconnection leaves your real IP and traffic exposed to your ISP for the duration. This matters most for privacy-sensitive use cases.

Implementing a Kill Switch with nftables

# /etc/nftables-killswitch.conf
# This ruleset blocks all internet traffic except through the VPN interface
# Only safe to activate AFTER the VPN is connected
 
flush ruleset
 
table inet filter {
    chain output {
        type filter hook output priority 0; policy drop;
 
        # Allow loopback
        oifname "lo" accept
 
        # Allow traffic on the VPN interface
        oifname "wg0" accept
 
        # Allow DHCP (needed to get IP from ISP)
        udp dport 67 accept
 
        # Allow DNS only through VPN
        ip daddr 10.10.10.1 udp dport 53 accept
 
        # Block everything else going out the real interface
        # (eth0, wlan0, etc.) — this is the kill switch
        drop
    }
}

Alternatively, use WireGuard's Table = off option combined with explicit routing to implement the kill switch at the routing level rather than the firewall level — this approach avoids the chicken-and-egg problem of needing to first establish the VPN before applying rules that block non-VPN traffic:

# WireGuard routing-based kill switch
# PostUp creates a "kill switch" routing rule before the VPN comes up
# AllowedIPs = 0.0.0.0/0 ensures all traffic is routed through wg0
# when the VPN is active
 
[Interface]
PrivateKey = CLIENT-PRIVATE-KEY
Address = 10.10.10.2/32
DNS = 10.10.10.1
 
# The kill switch: mark wg0 traffic so it isn't redirected by default routing
# and block anything not going through wg0
PostUp = ip route add default via 10.10.10.1 dev wg0 metric 10
PostUp = ip rule add not fwmark 51820 table main suppress_prefixlength 1
PostUp = ip route add 0.0.0.0/0 dev wg0 table 51820
PostDown = ip route del default via 10.10.10.1 dev wg0
PostDown = ip rule del not fwmark 51820 table main suppress_prefixlength 1
PostDown = ip route del 0.0.0.0/0 dev wg0 table 51820
 
[Peer]
PublicKey = SERVER-PUBLIC-KEY
Endpoint = SERVER-IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

When a VPN Is the Right Tool

Untrusted Networks: The Strongest Use Case

Public Wi-Fi in airports, hotels, and cafes provides minimal protection for your traffic. An attacker on the same network can:

# ARP spoofing — attacker positions themselves as man-in-the-middle
# (Classic attack on unprotected public WiFi)
arpspoof -i wlan0 -t TARGET-IP GATEWAY-IP  # Tell target that attacker is the gateway
arpspoof -i wlan0 -t GATEWAY-IP TARGET-IP  # Tell gateway that attacker is the target
 
# Now all traffic from TARGET passes through the attacker's machine
# Without VPN: attacker sees all plaintext HTTP and can read DNS queries
# With VPN: attacker sees only encrypted traffic to the VPN server — useless

A VPN on public Wi-Fi prevents passive interception of your DNS queries (which reveal every site you visit even over HTTPS) and protects against ARP spoofing attacks that would position an attacker between you and the access point.

Note: HTTPS already encrypts the content of your traffic to websites. What a VPN adds on public WiFi is protecting the metadata — which sites you visit — from the local network and your ISP.

Corporate Remote Access

This is the original and still the most valid use case for VPN technology. Connecting to internal resources (file servers, databases, internal web applications, development environments) that are not and should not be exposed to the internet.

Self-hosted WireGuard for corporate use:

# Self-hosted is always better than commercial for corporate traffic
# Don't route corporate data through a third-party VPN provider
 
# Deploy a WireGuard gateway in your corporate network (or cloud)
# All employee devices connect to this gateway
# Traffic to corporate subnets routes through the VPN
# Traffic to the internet routes directly (split tunneling) or through VPN (full tunnel)
 
# Generate a client config for each employee
# Track configurations in a secure system (Vault, 1Password Teams, etc.)

Privacy from ISP Data Collection

ISPs in the United States (and many other jurisdictions) are permitted to collect and sell browsing data. The 2017 Congressional repeal of FCC broadband privacy rules removed the regulatory protections that existed. ISPs including Verizon, AT&T, and Comcast have documented histories of selling customer data or using it for targeted advertising.

A VPN moves the browsing data visibility from your ISP to the VPN provider. This is an improvement only if:

• The VPN provider's jurisdiction has stronger privacy laws than your ISP's
• The VPN provider has a verified no-log policy
• The VPN provider is financially viable and not itself dependent on data monetization

Providers with independently audited no-log policies and a track record of not producing records when compelled: Mullvad (Sweden) and ProtonVPN (Switzerland) are the consistently recommended choices.

Bypassing Geographic Restrictions

Streaming service geographic restrictions, government content censorship, and regional access controls all use your IP address to determine location. A VPN server in the target country makes you appear to originate there.

Caveat: streaming services have increasingly blocked IP ranges associated with commercial VPN providers. Netflix, Hulu, BBC iPlayer, and Disney+ all maintain blocklists. Success varies by provider, server location, and how recently the VPN provider has rotated its IP addresses.

When a VPN Is Not the Right Tool

You Are Already Logged Into the Site

Google, Facebook, Amazon, and any site where you are authenticated know exactly who you are regardless of your IP address. Your account is the identity. Changing IP addresses does not create anonymity when the site has your name, email, credit card, and browsing history attached to your account.

Protection from Malware

Malware running on your device routes its traffic through the VPN tunnel right alongside your legitimate traffic. The VPN server decrypts it and forwards it to the malware's command and control server. The VPN provides zero protection — the malware uses the encrypted channel as infrastructure.

Anonymity from a Determined Adversary

Commercial VPN providers can be:

• Subpoenaed and forced to produce logs (many claim no-log policies but some have produced records when legally compelled — Loki Network, IPVanish, HideMyAss have all done so historically)
• Hacked and logs exfiltrated (the "no log" claim applies only to what was retained, not to what was captured in memory during an attack)
• Operated by intelligence agencies (this is not paranoia — intelligence agencies operate VPN infrastructure as collection platforms)
• Correlated via traffic analysis even without accessing logs (timing correlation between VPN entry and exit traffic can de-anonymize users)

If your threat model includes nation-state adversaries or law enforcement with legal authority over the VPN provider's jurisdiction, Tor is the appropriate tool — not a commercial VPN. Tor routes traffic through multiple hops controlled by different parties, making traffic correlation attacks substantially harder.

Evaluating Commercial VPN Providers

If you have determined a commercial VPN is appropriate for your threat model:

Jurisdiction

Where is the company legally incorporated? Companies in 14-Eyes countries (United States, United Kingdom, Canada, Australia, New Zealand, and nine EU members) are subject to intelligence-sharing arrangements and compelled disclosure with limited judicial oversight.

Recommended jurisdictions for privacy: Iceland, Switzerland, Panama, Romania. Providers: Mullvad (Sweden — stronger privacy laws than most), ProtonVPN (Switzerland).

Verified No-Log Policy

The claim is universal — every VPN provider claims no logs. The evidence varies dramatically:

• Mullvad: Has received government requests and had server hardware seized in April 2023. Result: zero data handed over, because the hardware contained no user data. The company publishes transparency reports.
• ProtonVPN: Swiss company that required Swiss court orders before any disclosure. Has been ordered to disclose user data in criminal investigations under Swiss law (this happened in 2021 with ProtonMail, the related service) — Swiss law does require compliance with court orders.
• ExpressVPN: A server was seized by Turkish authorities investigating an assassination (2017). The server contained no usage logs. Tested successfully.
• IPVanish: Claimed no logs, then turned over user connection logs to the FBI (2016, before the current ownership). No longer credible as a no-log provider.

The critical distinction: providers that have been legally tested and produced no data are meaningfully different from providers that have never been tested.

Protocol Support

Provider must support WireGuard or IKEv2. Avoid providers offering only OpenVPN (acceptable but outdated), and reject any provider offering only PPTP or L2TP without IPsec.

Kill Switch and DNS Leak Protection

These must be default-on features, not optional toggles. Test them:

# Test kill switch: disconnect VPN interface abruptly and verify traffic stops
# On Linux, simulate a VPN interface going down:
ip link set wg0 down  # Simulate VPN connection drop
curl -m 5 https://ifconfig.me  # Should timeout if kill switch is working
 
# Test DNS leak: with VPN active, check DNS
dig +short myip.opendns.com @resolver1.opendns.com
# Should return VPN server IP, not your real IP

| Provider | Jurisdiction | Audited No-Log | WireGuard | Payment Methods | |---|---|---|---|---| | Mullvad | Sweden | Yes (physically tested 2023) | Yes | Cash, Monero, Credit Card | | ProtonVPN | Switzerland | Yes (independent audit) | Yes | Credit Card, Bitcoin | | IVPN | Gibraltar | Yes (independent audit) | Yes | Cash, Monero, Credit Card | | ExpressVPN | British Virgin Islands | Yes (hardware seizure test 2017) | Yes | Credit Card, Bitcoin | | NordVPN | Panama | Yes (independent audit, 2018 breach) | Via NordLynx | Credit Card, Crypto |

The 2018 NordVPN breach: a threat actor accessed a NordVPN server in Finland. The server contained no user logs, but it did have an expired internal CA certificate that could have been used for MitM attacks. NordVPN's disclosure was delayed. The incident suggests that the server infrastructure itself, not just the logs, can be a threat surface.

Operational Security for VPN Use

# Before activating VPN: check your real IP (establish baseline)
curl -s https://ifconfig.me
# Note: REAL-IP-HERE
 
# Activate VPN
wg-quick up wg0
 
# Verify VPN IP is showing
curl -s https://ifconfig.me
# Note: VPN-SERVER-IP-HERE (should be different)
 
# Verify no DNS leak
dig +short myip.opendns.com @resolver1.opendns.com
# Should return VPN-SERVER-IP-HERE
 
# Check for WebRTC leak in browser
# Visit https://browserleaks.com/webrtc
# Should show no real IP under "Local IP" or "Public IP"
 
# Verify IPv6 is not leaking (if VPN doesn't have IPv6 support)
curl -6 -s https://ifconfig.me 2>/dev/null || echo "No IPv6 leak"
 
# Monitor VPN connection status
watch -n 5 wg show  # Updates every 5 seconds
# "latest handshake" field: should be recent (WireGuard re-handshakes every 3 minutes)
# If handshake is more than 5 minutes old, the connection may be stale

For corporate deployments, implement centralized VPN management:

# WireGuard management at scale using wg-quick + configuration management
# Option 1: Ansible playbook for deploying WireGuard configs to all clients
# Option 2: Headscale (self-hosted Tailscale control plane) — manages
#            WireGuard peer configurations centrally, handles key rotation
# Option 3: Netbird (open-source zero-trust VPN) — adds OIDC authentication
#            to WireGuard, per-resource access policies
 
# Centralized management is critical for:
# - Immediately revoking access when an employee leaves
# - Auditing who connected from where and when
# - Enforcing device compliance before allowing VPN access

The right conclusion about VPNs is not "always use one" or "never use one." It is: a VPN is a specific tool for a specific set of problems. It encrypts traffic on untrusted networks, enables access to private resources, and shifts traffic visibility from your ISP to the VPN provider. Those are its actual capabilities. For those specific use cases, a well-configured WireGuard tunnel with a verified no-log provider or a self-hosted server is a valuable security tool. For everything else, you are paying for a false sense of security.