A VPN's security depends entirely on how it's configured — the underlying cryptography in WireGuard, OpenVPN, and IPsec/IKEv2 is all well-studied and, used correctly, sound. Nearly every real-world VPN problem, whether it's a genuine weakness or just a connection that mysteriously hangs on large transfers, traces back to a specific configuration choice rather than a flaw in the protocol itself. This is a complete map of that configuration surface: choosing a protocol, setting up each one correctly, the split-tunneling tradeoff, and the MTU arithmetic that determines whether a working tunnel actually performs well. Each section links to a focused guide and a free browser-based tool for the parts that benefit from one.
Why VPN configuration security matters
A misconfigured VPN doesn't usually fail outright — it connects, passes traffic, and looks completely normal to everyone using it. The gap only shows up if something goes wrong: a deprecated cipher that would have taken years to notice, a control channel visible to port scanners because tls-crypt was never set up, or an AllowedIPs mistake that routes far more (or less) traffic through the tunnel than intended. Because all three major protocols here are open, extensively reviewed software, the practical security question for nearly every real deployment isn't "is the cryptography sound" — it almost always is — but "was this specific instance configured the way current guidance actually recommends."
Choosing a protocol
The three protocols covered here solve the same underlying problem with genuinely different tradeoffs, not just different syntax:
WireGuard is the newest of the three (first stable release 2020, merged into the Linux kernel in 2020) and deliberately minimal — one cipher suite, no negotiation, a codebase small enough to be fully audited by a small team. It's the right default for anything new where both ends can run it. OpenVPN has existed since 2001 and remains extremely widely deployed; its main practical advantage today is TCP transport, which can blend in on networks that block or throttle unfamiliar UDP traffic, at the cost of a considerably larger codebase and a menu of configuration options wide enough to include several outdated ones still technically valid. IPsec/IKEv2 is natively supported by iOS, Android, macOS, and Windows without installing any client software at all, which makes it the pragmatic choice for mobile-heavy deployments — at the cost of the densest, least self-explanatory configuration syntax of the three.
WireGuard configuration
A WireGuard .conf file has exactly two section types: one [Interface], describing this side's own private key and address, and one or more [Peer] sections, each describing a remote party by its public key. Every key — private, public, or an optional preshared key — is 32 raw bytes, base64-encoded to exactly 44 characters, generated with wg genkey and wg pubkey rather than typed by hand.
The field most likely to be misunderstood is AllowedIPs, which does two jobs at once: it's the routing entry determining what traffic goes to a given peer, and simultaneously a cryptographic filter — a packet that decrypts successfully but claims a source address outside its peer's AllowedIPs gets dropped anyway, a real security property rather than just a routing convenience. PersistentKeepalive matters specifically for any peer behind NAT, since a stateful NAT mapping expires after a period of silence and needs a small periodic packet to stay alive — its absence is the most common cause of a WireGuard connection that works briefly and then silently stops.
WireGuard Config Validator checks all of this at once — key format, missing or malformed AllowedIPs, duplicate peers, and invalid endpoints. For the full anatomy of every field, see WireGuard Config Explained.
OpenVPN hardening
OpenVPN separates a TLS-based control channel (which authenticates both sides and negotiates session keys) from the data channel that actually encrypts traffic, and hardening advice splits cleanly along that line. On the data channel, an AEAD cipher like AES-256-GCM provides encryption and integrity in one operation — the modern replacement for the older cipher AES-256-CBC paired with a separate auth SHA256 digest, and a clear upgrade from genuinely deprecated choices like BF-CBC or MD5/SHA1 digests still technically accepted without error. On the control channel, tls-crypt (or the older tls-auth) makes the server invisible to unauthenticated port scans by requiring a valid HMAC before any TLS processing happens at all — tls-crypt additionally encrypts the handshake itself, hiding which client certificate is being presented.
Compression deserves specific attention: comp-lzo or compress lzo exposes the connection to the VORACLE attack, which can recover plaintext from compressed, encrypted traffic in certain scenarios — the fix, compress migrate or disabling compression outright, costs nothing on already largely-incompressible modern traffic.
OpenVPN Config Auditor checks an .ovpn file for every one of these issues at once. For the full reasoning, see OpenVPN Security Best Practices.
IPsec/IKEv2
IPsec splits its work into an IKE_SA — the initial authenticated channel, always including a Diffie-Hellman exchange — and one or more Child SAs that actually carry traffic via ESP, negotiated independently and free to use different algorithms than the IKE_SA. A proposal string like aes256-sha256-modp2048 packs encryption, integrity/PRF, and DH group into one hyphen-separated line — readable once you know the shape, easy to get subtly wrong otherwise. The DH group specifically determines Perfect Forward Secrecy: a modp1024 or smaller group, dating to the original 1990s IPsec RFCs, is considered breakable by a well-resourced attacker today; modp2048 is the current practical minimum, with modp3072+ or the elliptic-curve groups (ecp256, ecp384) offering a comfortable margin above it.
IPsec/IKEv2 Proposal Strength Checker breaks down any proposal string and flags weak ciphers, digests, and DH groups. For the full picture of how IKE_SA and Child SA proposals relate, see IPsec/IKEv2 Cipher Suites Explained.
Split tunneling
A VPN doesn't have to route every packet: full tunneling sends everything through it for one consistent security policy; split tunneling sends only specific traffic through the tunnel, letting the rest use the normal network path — useful for reaching internal resources without routing already-fast, already-encrypted traffic through a VPN server unnecessarily. The gotcha that catches almost everyone at least once: split-tunnel routing rules say nothing about DNS resolution by default, which is a separate system-level setting — a client with perfectly correct IP routing can still leak every domain it looks up to its regular, non-VPN resolver unless DNS is explicitly configured to go through the tunnel too.
The specific "route everything except my home network" case needs real computation, not a guess: CIDR notation can't directly express "everything except one subnet," so the equivalent block list has to be built — excluding a single /24 from a full 0.0.0.0/0 tunnel takes exactly 24 separate CIDR blocks. VPN Split-Tunnel CIDR Calculator computes that list directly. For the full tradeoff, see VPN Split-Tunneling Explained.
MTU and performance
Every VPN protocol wraps each packet in its own encapsulation — an outer IP header, a transport header, and the protocol's own framing — which means the interface's MTU has to shrink to compensate, or packets that fit fine on the underlying network arrive too large for the tunnel. The classic symptom of getting this wrong: a VPN that connects fine, handles small requests fine, and hangs specifically on large transfers, because Path MTU Discovery relies on ICMP messages that a firewall somewhere along the path commonly blocks, leaving oversized packets to simply vanish rather than trigger a helpful resize.
WireGuard's overhead is fixed and precisely documented — 32 bytes for its data message header and authentication tag, which is exactly why its own recommended default MTU of 1420 exists (a deliberately conservative number accounting for the worst realistic case, an IPv6 outer transport). OpenVPN's and IPsec's overhead varies by cipher choice, generally smaller for AEAD ciphers than for older CBC-mode ones. VPN MTU / TCP MSS Calculator computes the recommended interface MTU and TCP MSS clamp value from your actual protocol and cipher choice. For the full mechanics of why this breaks the way it does, see VPN MTU and Fragmentation Explained.
Recommended DevTools Hub tools
Every tool referenced throughout this page, in one place:
- WireGuard Config Validator — validate a
.conffile's keys,AllowedIPs, endpoints, and peer uniqueness. - OpenVPN Config Auditor — audit an
.ovpnfile for deprecated ciphers, weak digests, missingtls-crypt, and VORACLE-vulnerable compression. - VPN Split-Tunnel CIDR Calculator — compute the exact
AllowedIPs/route list to send everything through a VPN except specific subnets. - IPsec/IKEv2 Proposal Strength Checker — break down an
ike=/esp=cipher proposal and flag weak ciphers, digests, and DH groups. - VPN MTU / TCP MSS Calculator — compute the recommended interface MTU and MSS clamp for WireGuard, OpenVPN, or IPsec.
Every one of these runs entirely in your browser — nothing you paste is ever sent anywhere.
Explore more: internal linking map
A map of everything on DevTools Hub related to VPNs, organized by what it actually is:
Tools: WireGuard Config Validator · OpenVPN Config Auditor · VPN Split-Tunnel CIDR Calculator · IPsec/IKEv2 Proposal Strength Checker · VPN MTU / TCP MSS Calculator
In-depth articles: WireGuard Config Explained · OpenVPN Security Best Practices · VPN Split-Tunneling Explained · IPsec/IKEv2 Cipher Suites Explained · VPN MTU and Fragmentation Explained
Toolkit hub: VPN Toolkit — all VPN-category tools in one place, with a shared workflow guide.
Related security areas: for the cryptographic building blocks (AES, RSA, SSH keys) VPNs build on, see the Encryption Toolkit; for the network-level basics (CIDR/subnetting) the split-tunnel calculator depends on, see the Network Security Toolkit; for hardening the server a VPN tunnel actually connects to, see Linux Security.
Common mistakes
- Carrying forward an old config's cipher choice unreviewed. A working OpenVPN or IPsec config connects identically whether it's using a modern AEAD cipher or a decade-old deprecated one — nothing about day-to-day use reveals which.
- Reusing a WireGuard key pair across multiple peers. Each peer needs its own identity; a shared key makes individual peers impossible to revoke.
- Assuming split-tunnel routing covers DNS. It doesn't, on any of the three protocols, without separate explicit configuration.
- Leaving the VPN interface at the underlying link's full MTU. The single most common cause of a VPN that connects fine but hangs on large transfers.
- Never revoking a departed team member's key or certificate. The VPN equivalent of an old SSH key left in
authorized_keyslong after it should have been removed.
FAQ
Which VPN protocol should I actually use?
WireGuard for anything new where both ends can run it — it's simpler, faster, and has a much smaller attack surface thanks to its minimal codebase and single cipher suite. OpenVPN remains the right choice when you need TCP-based transport to blend in on restrictive networks, or need to support older clients WireGuard doesn't reach. IPsec/IKEv2 is often the pragmatic choice for mobile devices, since iOS, Android, macOS, and Windows all support it natively without installing a separate client app.
Is a VPN enough to make an untrusted network safe?
A VPN protects the traffic that goes through it from anyone observing the network between you and the VPN server — it doesn't protect against malware already on your device, doesn't verify the destination server itself is trustworthy, and (with split tunneling) may not cover all of your traffic at all. It's one real, meaningful layer, not a complete answer to "is this connection safe."
Do I need a VPN if all my traffic is already HTTPS?
HTTPS already protects the content of your traffic to any HTTPS site — a VPN on top of that mainly adds protection for metadata (which sites you're connecting to, visible via DNS and the destination IP even when the content itself is encrypted) and for the genuinely non-HTTPS traffic that still exists. The most common real reason to run a VPN alongside universal HTTPS is reaching internal, non-public resources — a company network, a home lab — not re-encrypting what's already encrypted.
How often should VPN configs and keys be reviewed?
Whenever a peer or user leaves — a departed employee's or ex-contributor's key should be removed immediately, not left valid indefinitely — and on the same periodic cadence as the rest of your infrastructure's security review. Config drift (a cipher choice that was fine years ago but isn't anymore, a client someone added and forgot about) accumulates quietly, the same way firewall rules and sudoers grants do.
Is running your own VPN server actually more secure than a commercial VPN provider?
It depends what problem you're solving. Self-hosting (WireGuard on a cheap VPS is a common setup) gives you full control over configuration and no third party positioned to see your traffic, at the cost of you being responsible for keeping it patched and correctly configured. A commercial provider trades that control for convenience and a larger, professionally maintained server network — but requires trusting that provider's own logging practices and security. Neither is universally "more secure"; they solve different problems.
Try it yourself
Start with whichever protocol you're actually running — WireGuard Config Validator, OpenVPN Config Auditor, or IPsec/IKEv2 Proposal Strength Checker — or browse the complete set in the VPN Toolkit.