The most surprising thing about VPNs is that most of them aren’t actually about privacy at all; they’re about access.
Let’s see what this looks like in the wild. Imagine you’re at a coffee shop, and you need to access your company’s internal file server. Your laptop is on the public Wi-Fi, a network that’s essentially a free-for-all. The file server, however, lives on your company’s private, secure network, and it’s not exposed to the internet. How do you bridge that gap? You use a VPN.
This is where IPSec, SSL (often TLS for VPNs), and WireGuard come into play. They are different protocols, different ways of building that secure, encrypted tunnel between your laptop and the company network.
IPSec is the old guard, a suite of protocols designed to secure IP communications. It’s powerful, flexible, and can operate in two main modes:
- Transport Mode: Encrypts only the payload of the IP packet. The original IP header remains visible. Good for host-to-host communication.
- Tunnel Mode: Encrypts the entire original IP packet and then encapsulates it within a new IP packet. This is what you typically use for network-to-network or remote access VPNs, as it hides the original source and destination IPs from intermediate networks.
IPSec is often configured using IKE (Internet Key Exchange) for key management and negotiation. It’s known for its robustness but can be complex to set up and troubleshoot. You’ll see it commonly used for site-to-site VPNs between corporate firewalls.
SSL/TLS VPNs (often referred to as "SSL VPNs" though technically using TLS) are incredibly common for remote access. Think of accessing your company’s internal web portal or file shares from your home computer. These VPNs leverage the same encryption protocols that secure websites (HTTPS).
- Client-based: Requires installing a VPN client application on the user’s device. This client establishes a secure tunnel to the VPN gateway.
- Clientless: Accessed via a web browser. The user logs into a portal, and applications are accessed through that portal, often via plugins or browser redirects. This is convenient for users who don’t want to install software.
SSL/TLS VPNs are generally easier to deploy and manage than IPSec for remote access, and they often traverse firewalls more easily because they use standard ports (like TCP 443, the same as HTTPS).
WireGuard is the newcomer, designed from the ground up to be simple, fast, and modern. It uses state-of-the-art cryptography (like ChaCha20 and Poly1305) and has a much smaller codebase than IPSec, making it easier to audit and less prone to bugs.
- It’s user-space based, meaning it runs as a regular application rather than a kernel module, simplifying development and deployment.
- It uses UDP for transport, which is generally faster for encrypted traffic than TCP.
- Key management is simpler, often relying on pre-shared public keys.
Let’s look at a simplified WireGuard configuration for a remote worker. On the server side (your company’s gateway), you might have a wg0.conf file:
[Interface]
PrivateKey = <server_private_key>
Address = 10.0.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.2/32
And on the client side (the remote worker’s laptop), their wg0.conf would look like this:
[Interface]
PrivateKey = <client_private_key>
Address = 10.0.0.2/24
[Peer]
PublicKey = <server_public_key>
Endpoint = <server_ip_address>:51820
AllowedIPs = 0.0.0.0/0
When the client connects, AllowedIPs = 0.0.0.0/0 on the client tells WireGuard to send all internet traffic through the tunnel to the server. AllowedIPs = 10.0.0.2/32 on the server tells it to only accept traffic from that specific client IP within the tunnel. The Endpoint specifies where the client should send its packets.
The core difference in how they feel often comes down to performance and complexity. IPSec can be a beast to configure, with many interoperability issues between vendors. SSL/TLS VPNs are generally easier for remote access but can sometimes introduce latency or issues with TCP-over-TCP. WireGuard aims for high throughput and low latency by using modern crypto and a simpler design, making it a strong contender for both remote access and site-to-site VPNs.
Most people don’t realize that the "privacy" a VPN offers is only relative to the network you’re connecting from. If you’re using a VPN to access your company’s internal network, the VPN is primarily ensuring that only authorized individuals can reach those internal resources, not necessarily that your browsing habits are hidden from your employer. The encryption is there to prevent eavesdropping on the path between you and the gateway, but the gateway itself can still see your traffic if it’s not otherwise encrypted (like with HTTPS).
The next step is understanding how these VPNs handle authentication beyond just keys or certificates.