VPN Basics Cheat Sheet
Explains VPN protocol options, tunneling modes, and basic WireGuard/OpenVPN configuration for securing remote network access.
2 PagesBeginnerFeb 18, 2026
Common VPN Protocols
Widely used protocols and their tradeoffs.
- OpenVPN- Mature, highly configurable, uses SSL/TLS for key exchange, works over TCP or UDP
- WireGuard- Modern, minimal codebase, fast, uses state-of-the-art crypto (Curve25519, ChaCha20)
- IPsec (IKEv2)- Widely supported natively on OS/mobile, good for site-to-site and roaming clients
- L2TP/IPsec- Legacy combo, weaker than modern alternatives, still found in older setups
- PPTP- Obsolete and insecure; should not be used
WireGuard Basic Config
Minimal server and peer configuration for a WireGuard tunnel.
ini
# /etc/wireguard/wg0.conf (server)[Interface]PrivateKey = <server_private_key>Address = 10.0.0.1/24ListenPort = 51820[Peer]PublicKey = <client_public_key>AllowedIPs = 10.0.0.2/32
WireGuard Commands
Generating keys and managing the interface.
bash
# Generate a private/public key pairwg genkey | tee privatekey | wg pubkey > publickey# Bring the tunnel up/downwg-quick up wg0wg-quick down wg0# Show current connection statuswg show
Tunneling Concepts
Key terminology for how VPN traffic is routed.
- Split tunneling- Only traffic destined for specific networks goes through the VPN; rest uses local internet
- Full tunneling- All client traffic is routed through the VPN, including general internet browsing
- Site-to-site VPN- Connects two networks (e.g. office to cloud VPC) rather than a single client
- Remote access VPN- Connects individual client devices to a private network
OpenVPN Server Configuration
A production-style OpenVPN server config using certificate auth and tunnel hardening.
ini
# /etc/openvpn/server.confport 1194proto udpdev tunca ca.crtcert server.crtkey server.keydh dh2048.pemtls-crypt ta.keycipher AES-256-GCMauth SHA256server 10.8.0.0 255.255.255.0push "redirect-gateway def1 bypass-dhcp"push "dhcp-option DNS 1.1.1.1"keepalive 10 120persist-keypersist-tunuser nobodygroup nogroupexplicit-exit-notify 1
IKEv2 with strongSwan
Site-to-site style IKEv2/IPsec tunnel definition using strongSwan's swanctl configuration.
ini
# /etc/swanctl/conf.d/site-to-site.confconnections { site-a-to-b { local_addrs = 203.0.113.1 remote_addrs = 198.51.100.1 local { auth = pubkey certs = siteA.pem } remote { auth = pubkey id = "C=US, O=Example, CN=siteB" } children { net-net { local_ts = 10.0.0.0/24 remote_ts = 10.1.0.0/24 esp_proposals = aes256gcm16-prfsha384-ecp384 } } version = 2 proposals = aes256-sha384-ecp384 }}
WireGuard: Multiple Peers & Site-to-Site Routing
Extending a WireGuard hub to route traffic between several peers, not just a single client tunnel.
ini
# /etc/wireguard/wg0.conf (hub, routes between two remote LANs)[Interface]PrivateKey = <hub_private_key>Address = 10.0.0.1/24ListenPort = 51820PostUp = sysctl -w net.ipv4.ip_forward=1PostUp = iptables -A FORWARD -i wg0 -j ACCEPT# Roaming laptop peer[Peer]PublicKey = <laptop_public_key>AllowedIPs = 10.0.0.2/32# Branch office peer — AllowedIPs advertises its whole LAN, not just its VPN IP[Peer]PublicKey = <branch_public_key>AllowedIPs = 10.0.0.3/32, 192.168.50.0/24PersistentKeepalive = 25
Advanced VPN Concepts
Terminology and design decisions beyond a basic single-peer tunnel.
- NAT traversal / keepalive- PersistentKeepalive (WireGuard) or NAT-T (IPsec) sends periodic empty packets so home-router/CGNAT NAT mappings don't expire mid-session
- DNS leak- Client resolves hostnames via its default (ISP) DNS instead of the VPN's, revealing browsing activity outside the tunnel
- Kill switch- Firewall rule set that blocks all non-VPN-interface traffic, preventing fallback to the raw internet if the tunnel drops
- MTU/fragmentation- VPN encapsulation overhead shrinks usable packet size; a too-high MTU causes silent fragmentation or blackholed packets
- PSK vs certificate auth- Pre-shared keys are simpler but don't scale/rotate well; certificates support per-peer revocation and are preferred at scale
- Perfect forward secrecy (IPsec)- Each IKE rekey generates fresh Diffie-Hellman material so a compromised long-term key can't decrypt past sessions
- Mesh VPN (e.g. Tailscale/Headscale)- Peers connect directly to each other via a coordination server instead of routing all traffic through one hub
DNS Leak Prevention & Kill Switch (iptables)
Forcing all DNS and general traffic through the VPN interface, dropping everything else if the tunnel is down.
bash
# Only allow DNS queries to leave via the tunnel interfaceiptables -A OUTPUT -o wg0 -p udp --dport 53 -j ACCEPTiptables -A OUTPUT ! -o wg0 -p udp --dport 53 -j DROPiptables -A OUTPUT ! -o wg0 -p tcp --dport 53 -j DROP# Kill switch: drop all outbound traffic that isn't via the VPN interface# or destined for the VPN server's own public IP (needed to establish the tunnel)iptables -A OUTPUT -o lo -j ACCEPTiptables -A OUTPUT -o wg0 -j ACCEPTiptables -A OUTPUT -d <vpn_server_public_ip> -j ACCEPTiptables -A OUTPUT -j DROP
Pro Tip
Prefer full tunneling for remote employees on untrusted Wi-Fi — split tunneling improves performance but leaves the client's general internet traffic (and the device itself) outside your monitoring and DNS filtering controls.
Was this cheat sheet helpful?
Explore Topics
#VPNBasics#VPNBasicsCheatSheet#Cybersecurity#Beginner#CommonVPNProtocols#WireGuardBasicConfig#WireGuardCommands#TunnelingConcepts#Networking#CheatSheet#SkillVeris
