Does a VPN help with securing traffic? My weekend with IPSec

“Will a VPN help with securing confidential client information?” Was a question my boyfriend asked just a few months ago. His business was hiring someone from Ecuador to run billing and part of her responsibilities would be to charge client credit cards. My boyfriend, whose technical literacy extends to an on/off switch, thought that maybe the internet was less secure in Ecuador, and he wanted to know whether a VPN could help keep client data more secure.

When he asked me, my initial instinct was no, but I couldn’t really explain why. I knew broadly what a VPN was - a proxy that sits in between the client and the server, forwarding requests so the server thinks the request originated from the proxy and not the client, disguising the identity of the user of the proxy. But the protocols and details behind it, I never bothered to learn.

“But none of that matters since HTTPS is encrypted” was my response. “The most important thing she can do is use an up-to-date version of a modern browser, ensure she’s using HTTPS, and maybe avoid working on a public wifi so avoid working in cafes, airports, etc”. Sound advice, and, now, 3 days post binging IPSec documentation, I’d say the advice stands. “But” I warned my boyfriend “like all things nothing is ever 100%, and security is more about mitigating factors than anything else.”

So now that I spent the weekend studying IPSec and the protocols that support VPN, does my answer change? Perhaps slightly.

Before I go into that, I’m unsure why these obvious questions surrounding VPN never popped in my head earlier: If your computer is making a request to “example.com”, but, while using a VPN, the traffic first gets directed to the proxy server to forward, and then finally to “example.com” and yet a packet can only have one destination, how exactly does it get routed to the intermediary destination while preserving the final destination? It’s such an obvious question, and yet it wasn’t until this weekend that I had that ‘AHA’ moment.

If it weren’t obvious by the title of this blog, the answer is … drumroll … IPSec! To be precise, IPSec is a suite of protocols, with the core protocol responsible for this being the Encapsulating Security Payload (ESP). But before I go into it, this isn’t a review of my entire weekend exploration with it. Topics like transport vs tunnel mode and static vs route based aren’t addressed here.

Now back to the question of VPN and whether it could help my boyfriend’s business.

When a VPN is installed, what’s actually installed on the user’s computer is a VPN client software. When enabled, it makes a few very important edits to the operating system’s route table. A normal route table - without a VPN enabled - typically has a default route (0.0.0.0/0) pointing at a gateway with an interface to reach it through. On macOS you can see it with netstat -rn:

Destination        Gateway            Netif
default            192.168.1.1        en0

With the VPN enabled, that table changes:

Destination        Gateway            Netif
0.0.0.0/1          10.8.0.1           utun0
128.0.0.0/1        10.8.0.1           utun0
0.0.0.0/0          192.168.1.1        en0
203.0.113.9/32     192.168.1.1        en0

Two additions. First, 0.0.0.0/1 and 128.0.0.0/1, both pointing at a virtual network interface created by the VPN client (more on this later). It takes two of them because a /1 only covers half the internet - 0.0.0.0/1 is everything from 0.0.0.0 to 127.255.255.255, and 128.0.0.0/1 is everything above that. Together they cover the same ground as the default route.

Second, a /32 host route for the proxy server’s public IP (203.0.113.9 here) pointing back out the physical interface. Without it the encrypted packets heading to the proxy server would themselves match 0.0.0.0/1, get sent into the tunnel, get encrypted a second time, and never actually leave your machine.

So the edits ensure that requests that were once destined for the router now match the more specific routes and get sent towards the virtual network interface instead.

As its name implies, the virtual network interface is not a real physical network interface attached to any hardware. It’s created by the VPN client software, which reads packets from it as the kernel routes them in. Once there, the VPN client software performs the ESP protocol mentioned earlier. Within this protocol several things happen: the packet’s IP header and the layers above it are encrypted and encapsulated inside an ESP packet. The result looks like this:

┌────────────┬──────────┬──────────────────────┐
│ NEW IP hdr │ ESP hdr  │ ENCRYPTED            │
│ dst=proxy  │ SPI      │   orig IP hdr        │
│            │ Seq num  │   dst=example.com    │
│            │          │   TCP hdr + payload  │
└────────────┴──────────┴──────────────────────┘
  plaintext    plaintext

The new IP header on the front is what carries the proxy server’s IP. The ESP header alongside it holds an SPI, which identifies which encryption session the packet belongs to, and a sequence number. So inside the encryption is the original packet with the original destination, and on the outside is the proxy server’s public IP in plaintext. This is how we can technically send two destinations in a single packet, answering the question above. Once the protocol is complete the VPN client software hands the new packet back to the kernel, which routes it like any other packet. This time the route table sees only the outer destination, that matches the /32 host route, so outwards it goes to the physical interface, to the router, and through the public internet to the proxy server.

Once at the proxy server, the server terminates the encryption, strips off the ESP outer layer, revealing the original packet, originally sent by the client before touched by VPN client. So, if the original packet used a secure protocol like HTTPS, then that encryption remains and had an unsecure protocol been used, the complete packet would now be in plaintext. Remember, these encryptions only encrypt the application data, so in both cases the Source/Destination IP and TCP are unencrypted. Now this is important - the only further change the proxy server does is editing the source IP/Ports to its own information, some translation - no further encryption happens here. With those edits it passes that packet unto the internet towards its destination.

The consequences should be clear now. If the packet were initially encrypted then it would remain encrypted both between the client and the proxy server and between the proxy server and the final destination. BUT if the packet were not initially encrypted, then it will be encrypted between the client and the proxy server via the ESP encryption, but it would NOT be encrypted between the proxy server and its final destination.

Which is the whole answer, really. For HTTPS traffic the VPN added no encryption at all. TLS was already doing that job, on both legs, end to end. What the VPN actually changed is who gets to watch. Without it, the local network and the ISP see which sites she’s reaching. With it, they see an encrypted stream to a proxy server, and the VPN provider sees the sites instead. A VPN doesn’t add security so much as it relocates trust.

And that’s where my answer shifts, slightly. Relocating trust can be the entire point. If the local ISP operates with less oversight than you’d like, moving that visibility to a provider in a jurisdiction with stricter laws is a real, defensible reason to run one.

There’s a second thing a VPN genuinely gives you that HTTPS doesn’t, which I hadn’t thought about before this weekend: DNS. VPN clients typically route DNS lookups through the tunnel too, which shuts down local snooping or hijacking of the lookups themselves. That’s real - though DNS-over-HTTPS solves the same problem without any of this.

But for the actual question - would it protect the credit card information? No, and it never needed to. With HTTPS the card number is invisible to the ISP and to the VPN provider. Neither of them can see it. What either can see is metadata: that she connected to a payment processor at 3pm. Which is a very different thing from the card itself.

Which means the advice I gave three months ago holds, I just couldn’t explain it then. Modern browser, HTTPS, be careful on networks you don’t control. It took a weekend of ESP headers and route tables to work out that my instinct was right for reasons I didn’t understand at the time - which, honestly, is the most useful thing I got out of the whole exercise.