Beyond the Lock: 5 Essential VPN Security Features You Shouldn't Ignore

Most people shop for a VPN the way they shop for a padlock: they check the brand, glance at the price, and assume the lock works. But a VPN is not a single lock—it's a chain of mechanisms, each with its own failure points. The encryption protocol is important, but it's only one link. In this guide, we focus on five features that often get overlooked in marketing copy but can make or break your privacy posture. We'll explain what each does, how it works under the hood, and where it might not help.

Why These Features Matter More Than Ever

The VPN market has matured quickly. A decade ago, the main selling point was simple: encrypt your traffic so your ISP can't see it. Today, nearly every provider offers AES-256 encryption and OpenVPN or WireGuard. The differentiation has moved to the edges—the features that handle edge cases, failures, and advanced threat models. If you're a journalist, a remote worker handling sensitive data, or someone who simply wants to minimize digital exposure, the basic encryption tunnel is not enough.

Consider a common scenario: you're using a VPN on a public Wi-Fi network at a coffee shop. The VPN connection drops for a second due to interference. Without a kill switch, your device reverts to the unencrypted network, exposing your IP address and any active connections. This is not a theoretical risk—it happens routinely. The kill switch is a feature that blocks all internet traffic until the VPN reconnects. It's a simple idea, but its implementation varies widely. Some kill switches only block certain apps; others block all traffic at the system level. Understanding these nuances is the first step to choosing a VPN that matches your threat model.

Another overlooked feature is split tunneling. Most VPNs route all your traffic through the tunnel by default. That's fine for privacy, but it can break services that require local network access—like a printer on your home network or a banking app that detects IP changes. Split tunneling lets you choose which apps or domains go through the VPN and which use your regular connection. This is not just a convenience feature; it's a security feature when used correctly. For example, you can route your browser through the VPN while keeping a corporate VPN client for work traffic separate. The catch is that misconfigured split tunneling can leak traffic if the rules are not applied consistently.

We also see a rise in multihop (or double VPN) configurations, where traffic passes through two servers in different jurisdictions. This adds a layer of redundancy: if one server is compromised, the other still protects your origin. But it also doubles latency and can complicate troubleshooting. And then there are RAM-only servers—servers that run entirely in memory and leave no data on disk after a reboot. This is a strong defense against physical seizure or remote attacks that try to extract logs. Finally, perfect forward secrecy (PFS) ensures that if an attacker steals your VPN's private key, they cannot decrypt past sessions. Each session uses a unique ephemeral key, so compromising one key doesn't compromise the entire history.

Kill Switch: The Safety Net You Didn't Know You Needed

The kill switch is the most straightforward of the five features, yet it's often implemented poorly. At its core, a kill switch monitors the VPN connection and, if the connection drops, blocks all internet traffic until the VPN reconnects. This prevents your real IP from being exposed during a brief outage. But the devil is in the details.

How It Works Under the Hood

A kill switch typically works by modifying the system's routing table or using a firewall rule. When the VPN is active, the default route points to the VPN interface. If the VPN goes down, the kill switch removes the default route or adds a rule that drops all packets not destined for the VPN server. Some implementations use a persistent tunnel that stays up even if the VPN process crashes, while others rely on a separate daemon that monitors the connection state.

The most common failure mode is a partial kill switch that only blocks certain protocols (like TCP) but leaves UDP open, or one that only works when the VPN is manually disconnected but not when the system sleeps. We've seen cases where a kill switch on a mobile device fails because the OS kills the VPN process to save battery, and the kill switch app doesn't restart in time. The safest implementation is a system-level firewall rule that is applied regardless of the VPN client's state—this is often called a "persistent kill switch."

When It Works and When It Doesn't

A kill switch is essential for anyone who uses a VPN for sensitive activities—like accessing a company network or communicating with sources. But it's not a silver bullet. If the VPN connection drops and the kill switch triggers, you lose connectivity entirely. That can be disruptive if you're in the middle of a download or a video call. Some VPNs offer an "app-specific" kill switch that only blocks certain applications, but this can be bypassed if the app uses a system proxy or DNS leak.

Another edge case: on some operating systems, the kill switch may not block IPv6 traffic if the VPN only tunnels IPv4. If your device has IPv6 enabled and the VPN doesn't handle it, your real IP can leak even with a kill switch. Always verify that your VPN provider blocks IPv6 or routes it through the tunnel. A simple test is to visit an IP leak detection site while the VPN is connected and then simulate a disconnect (by disabling the VPN interface) to see if your real IP appears.

Split Tunneling: Control What Goes Through the Tunnel

Split tunneling is often marketed as a convenience feature, but it has real security implications. The idea is simple: you decide which traffic goes through the VPN and which goes directly to the internet. This can be useful for accessing local resources (like a network printer or a NAS drive) while still protecting your browsing traffic. But it can also create a security risk if not configured carefully.

How It Works Under the Hood

Split tunneling works by creating two routing tables or using policy-based routing. Traffic destined for certain IP ranges or applications is routed through the VPN interface; everything else uses the default gateway. Some VPN clients implement this at the application level by intercepting system calls, while others use network namespaces or firewall rules. The most robust implementations use a virtual network adapter and modify the routing table to exclude specific subnets.

The security risk arises when the split tunneling rules are too broad. For example, if you allow all traffic to a specific domain, but that domain loads resources from third-party servers (like CDNs or analytics), those requests may bypass the VPN. Similarly, if you use split tunneling to access a work network while keeping personal traffic outside the VPN, an attacker on the work network could potentially see your real IP if they can force your device to send traffic outside the tunnel. This is known as a "forced browsing" attack.

Composite Scenario: The Remote Worker

Imagine a remote worker who uses a corporate VPN to access internal tools but wants to use a personal VPN for general browsing to avoid ISP tracking. They set up split tunneling: work traffic goes through the corporate VPN, everything else through the personal VPN. But the corporate VPN client might not play well with the personal VPN client—they both try to modify routing tables, leading to conflicts. The result could be that some work traffic leaks out the personal VPN, or vice versa. A better approach is to use a virtual machine or a separate device for work, but that's not always practical.

Another pitfall: DNS leaks. Even if the traffic is routed correctly, DNS queries might still go to the ISP's DNS server if the VPN client doesn't handle DNS properly. Always check that your split tunneling configuration also routes DNS requests through the appropriate tunnel. Some VPNs allow you to specify DNS servers per tunnel, which is a good practice.

Multihop (Double VPN): Adding Layers of Indirection

Multihop, also known as double VPN, routes your traffic through two VPN servers in sequence. The first server encrypts your data and sends it to the second server, which decrypts it and sends it to the destination. This means that neither server alone knows both your IP and the destination—the first server knows your IP but not the destination, and the second server knows the destination but not your IP. This provides an extra layer of privacy if one of the servers is compromised or logs data.

How It Works Under the Hood

In a typical multihop setup, your VPN client establishes a connection to the first server (entry node). That server then establishes a second VPN connection to the second server (exit node). The traffic is encrypted twice: once with the key for the first server, and again with the key for the second server. The first server strips the outer layer and forwards the inner encrypted packet to the second server. The second server decrypts the inner layer and sends the plaintext to the destination. This is similar to the Tor network but with only two hops and typically using the same protocol (e.g., WireGuard over WireGuard).

The downside is latency: each hop adds a round-trip time, so your connection will be noticeably slower. Also, if the VPN provider operates both servers, they could theoretically correlate the two connections if they log metadata. Some providers offer multihop across different jurisdictions to mitigate this—for example, an entry server in Switzerland and an exit server in Iceland. But if the provider is untrustworthy, multihop doesn't help.

When Multihop Makes Sense

Multihop is overkill for most users. It's useful if you have a specific threat model where you want to protect against a compromised VPN server—for example, if you're using a VPN in a country with surveillance and you don't fully trust the provider. It can also help if you want to hide your VPN usage from your ISP (since the first server's IP is visible, but the second server's IP is not). However, for everyday browsing, the performance hit is usually not worth it.

One edge case: some VPNs offer a "multi-hop" mode that actually uses different protocols for each hop (e.g., OpenVPN to the first server, then WireGuard to the second). This can provide additional obfuscation but also increases complexity. If you need this level of protection, consider using Tor instead, which has a similar architecture but with more hops and better anonymity properties.

RAM-Only Servers: No Data Left Behind

RAM-only servers are a relatively new feature that addresses a fundamental problem: if a server is seized or an attacker gains physical access, they can read the hard drive. By running the entire server operating system and VPN software from RAM, with no persistent storage, any data disappears when the server is rebooted. This is a strong defense against forensic analysis and "cold boot" attacks.

How It Works Under the Hood

A RAM-only server boots from a read-only image (often over the network) and loads everything into memory. The root filesystem is a tmpfs (temporary filesystem) that is not written to disk. Any logs, encryption keys, or session data are stored only in RAM. When the server loses power or is rebooted, all data is lost. This makes it impossible for an attacker to retrieve historical logs or session keys from the hard drive, because there is no hard drive with persistent data.

However, RAM is volatile—if the server is frozen or subjected to a cold boot attack, the data can persist for a few seconds. But for most threat models, this is sufficient. The key is that the provider must ensure that no swap space or disk writes occur. Some providers also use encrypted RAM disks to protect against cold boot attacks.

Limitations and Trade-offs

RAM-only servers are not a silver bullet. If the VPN provider logs data elsewhere (like on a separate logging server), the RAM-only nature of the VPN server doesn't help. Also, if an attacker compromises the server while it's running, they can access the data in RAM in real time. The protection is primarily against post-compromise or seizure scenarios. For most users, this feature is a nice-to-have but not essential. It becomes important if you are concerned about government seizure or if the provider operates in a jurisdiction with mandatory data retention laws.

Another consideration: RAM-only servers are more expensive to maintain because they require specialized infrastructure (network boot, centralized configuration). Not all providers offer them, and those that do may charge a premium. If you choose a provider with RAM-only servers, verify that they also have a clear no-logs policy and that the servers are actually configured correctly—some providers claim "RAM-only" but still write logs to a remote syslog server.

Perfect Forward Secrecy: Protecting Past Sessions

Perfect forward secrecy (PFS) is a property of key exchange protocols that ensures that if a long-term private key is compromised, past session keys cannot be derived. In the context of VPNs, this means that if an attacker steals the server's private key (e.g., by seizing the server or exploiting a vulnerability), they cannot decrypt recorded traffic from previous sessions. Each session uses a unique ephemeral key that is derived from the long-term key but is not stored.

How It Works Under the Hood

PFS is achieved through protocols like Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) key exchange. In a typical VPN handshake, the client and server generate temporary key pairs for each session. The session key is derived from these ephemeral keys and the long-term keys, but the ephemeral keys are discarded after the session ends. Even if the long-term private key is later revealed, the attacker cannot reconstruct the ephemeral keys because they were never stored. WireGuard, for example, uses a combination of static and ephemeral keys to provide PFS.

Not all VPN protocols support PFS. OpenVPN can be configured to use PFS by enabling TLS 1.3 or using ECDH ciphers. IPsec with IKEv2 also supports PFS. However, some older protocols like PPTP do not. When choosing a VPN, look for protocols that explicitly mention PFS or use modern key exchange algorithms.

When PFS Matters

PFS is crucial if you are concerned about mass surveillance or if you store encrypted traffic logs. For example, if an intelligence agency records all your VPN traffic today and later obtains the VPN provider's private key (through a court order or hack), they could decrypt all past sessions without PFS. With PFS, they would only be able to decrypt future sessions (if they also have the ephemeral keys, which are not stored). This is a strong argument for using PFS-enabled protocols, even if you trust your VPN provider today.

However, PFS is not a complete privacy solution. It does not protect against traffic analysis (e.g., timing attacks or packet size analysis) or against malware on your device. Also, if the attacker can compromise the client device, they can capture the session key before it is discarded. PFS is one piece of a larger security puzzle.

Putting It All Together: Choosing What Matters for You

No single feature guarantees privacy. The right combination depends on your threat model. For most users, a kill switch and PFS are non-negotiable. Split tunneling is a convenience that can be a security risk if misused. Multihop and RAM-only servers are for specific, high-risk scenarios. We recommend starting with a provider that offers a persistent kill switch, supports WireGuard with PFS, and has a clear no-logs policy. Then, evaluate whether you need split tunneling or multihop based on your use case.

One final piece of advice: test your setup. Use tools like Wireshark or online leak tests to verify that your VPN is not leaking IP, DNS, or WebRTC information. Simulate a disconnect to see if the kill switch works. Check that PFS is actually being used by examining the handshake (some VPN clients show the cipher suite). And remember that a VPN is only one layer—keep your software updated, use a firewall, and practice good opsec. The lock is just the beginning.