Just how much security does a VPN give you?
What could go wrong with the security you think you’re enjoying, and what potential problems do you need to be aware of?
Last week, in Part 1 of this article, we covered several salient facts about virtual private networks, or VPNs:
Note that VPN software typically presents itself to the operating system as if it were a physical network card that can be managed and configured with the very same tools as real network devices such as Ethernet or Wi-Fi:
Both ends of the VPN link typically end up with what are known as private IP numbers, often referred to as RFC 1918 addresses, which are specially reserved for private use by anyone on their own LAN, and therefore don’t denote any particular network or physical location.
Private IPs are therefore quite literally non-routable outside their own LAN, and every correctly-configured router will dispose of them automatically if they inadvertently get routed onto the public internet.
For IPv4, private IP numbers fall into one of the ranges 10.0.0.0/8
, 172.16.0.0/12
, or 192.168.0.0/16
, where the number after the slash denotes how many of the leftmost bits in the 32-bit IPv4 number are fixed. For IPv6, the private range of what are known as ULAs or unique local addresses, is FC::/7
, with just the first seven bits of the 128-bit IPv6 number locked in. (IPv6 addresses are given in hexadecimal because it’s more compact, while IPv4 addresses use decimal.)
Simply put, connecting your computer to the internet via a VPN network adapter joins you, along with any number of other customers of that VPN, to a virtual LAN that routes your traffic out onto the internet somewhere else, possibly on the other side of the world.
In Part 1, we followed our own traffic from the UK to a web server in the US (in this case, to example.com
) through a regular internet connection via a local ISP, showing the traditional sort of country-to-country network hop you might expect.
The pink hops are computers in the UK; the blue hops are in the US:
Likewise, when we connected to a ‘what-is-my-IP’ server that replies with the network address that our traffic emerged from, we came up with this:
(We disguised the actual IP number here by using one that’s reserved for documentation purposes, but the actual IP of the ISP’s internet-facing router can be geolocated to Oxfordshire in England, which is what the example.com
server saw as our likely physical location.)
However, when we connected via a demo server provided by the open-source VPN software WireGuard, our traffic flow had a very different look:
Although the last three hops (shaded blue) show that our traffic took the same last steps as before to reach example.com
in the US, the rest of the trace gives no hint that our traffic originated in the UK.
The first two hops are non-routable private IP addresses that are part of the VPN’s ‘LAN tunnel’, so they don’t indicate where the VPN endpoints are actually located.
The third hop is the demo.wireguard.com
server, hosted in the US, which is the point at which our traffic emerges from the VPN tunnel and openly joins the internet.
In this case, the example.com
server will see our public IP number as 172.245.26.38
, and therefore ‘detect’ that we are in America:
Note that in this case, we’re using a VPN server that’s there to help you learn about the WireGuard VPN software.
The WireGuard website makes it clear that the service is for educational purposes only; that it isn’t provided to help you disguise your online presence; that you aren’t entitled to use it for improper purposes; and that to prevent abuse, your activity may be logged:
If you’d like to try sending some packets through WireGuard, you may use, for testing purposes only, [this free service we provide]. This will automatically set [up a WireGuard network interface] through a very insecure transport that is only suitable for demonstration purposes. […]
By connecting to this server, you acknowledge that you will not use it for any abusive or illegal purposes and that your traffic may be monitored.
But what if the VPN service you’re using isn’t merely a public demo site for the underlying VPN software you are testing, with clear limitations stated for both privacy and purpose?
As you’ve probably experienced in the ads for commercial VPN products that are widely seen these days, the implicit (and sometimes the explicit) pitch for the service on sale is quite different.
Many consumer VPNs present themselves as increasing your cybersecurity, your personal freedom, and your online safety in a wide range of ways, notably including:
The burning question of course, is, “Just how much can I trust the VPN service?”
The ‘inside-out’ nature of a typical consumer VPN connection means that all you’re doing, loosely speaking, is swapping out your local ISP for a virtual ISP somewhere else in the world.
If you live in the developed world, you might not approve of the amount of commercial tracking or legally-mandated surveillance and logging that internet providers in your country carry out.
Nevertheless, your local ISP and mobile phone provider are probably operating under a regulatory framework that is clearly and publicly documented.
Additionally, your local rules and regulations probably provide you with at least some sort of protection, for example by way of a privacy commissioner, a telecommunications authority, a consumer protection body, or a fair trading office.
But how much do you really know (and how much can you easily find out) about the regulatory framework and the prevailing levels of business ethics in the country or countries where your VPN provider operates?
When they insist that they “keep no logs whatsoever”, how sure can you be that they have both the technical and moral competence to deliver on that promise?
And if they don’t live up to their promise, for example because they kept logs unintentionally and then suffered a data breach due to insider roguery or an external cybersecurity attack, would you ever find out, even if you made formal request for information?
After all, if part of the attraction of the VPN provider is that its legal jurisdiction takes a hands-off approach to internet regulation, the company may have no obligation to report data breaches or cybersecurity blunders, and may be legally entitled simply to deny that they ever happened.
Over the years, more than one US service provider has landed itself in trouble for inadvertently saving plaintext passwords in log files, or for wrongly capturing and storing unencrypted data, due to programming blunders that weren’t spotted, sometimes for years.
But as much as you may be worried by these cybersecurity lapses, it’s worth remembering, in the cases linked to above, not only that the vendors weren’t able to sweep the incidents under the carpet, but also that they reported themselves to the relevant regulator in the first place.
In contrast, VPN providers may not fall under the same legal obligations, even if they know they’ve made a blunder with your data.
More importantly, VPN providers, by design, typically have access to all of your network traffic all of the time, unlike in the Facebook story we linked to above (where the password logging potentially affected your use of Facebook only), or Google’s infamous Wi-Spy case (where packet data from open access points was logged briefly, but only when a Street View vehicle passed by).
Simply put, no matter how much you trust your VPN provider, you need to remember that any unencrypted traffic you send from your computer, and any replies received unencrypted from the other end, are of necessity visible in their entirety to your VPN service, just as they are to the owner of the access point at your local coffee shop, to the sysadmins on your network in the office, or to your own ISP.
The encryption added by the VPN itself only secures your data while it’s inside the VPN tunnel.
The VPN encryption is stripped off by the VPN server at the other end of the tunnel, revealing an exact copy of all your original data so that it can be injected back onto the public internet.
In other words, if you’re concerned about data security, possible surveillance, and industrial espionage anyway, then just using a VPN won’t eliminate those concerns.
A VPN doesn’t provide any end-to-end security between you and the online services you’re ultimately accessing.
More importantly, even if you trust your VPN server to keep no logs and to keep the source of your network packets secret, and even if you very carefully browse only to HTTPS websites, where end-to-end encryption provides a personal layer of anti-snooping and anti-tampering, even by your VPN provider…
…your pseudo-anonymity ends as soon as you share any personally identifying information with any site at the other end of the link, or as soon as you download and open any potentially dangerous files from a remote site.
Also, any personally identifiable information that you share (whether intentionally or inadvertently) via your browser, such as web data, cookies, or authentication tokens retained from a previous session, will give you away to a remote site, no matter how carefully or untraceably your network traffic is sent and received.
If you’re minded to use a VPN because you’re genuinely worried about being tracked – for example, if you’re an activist, or a whistleblower, or currently being tormented by a stalker – then you need to be aware of how you can be tracked even if your low-level network traffic remains anonymous.
The well-known Tor Project, which makes a browser that runs your traffic through what is a form of volunteer-operated, browser-specific VPN, has some a good advice on this topic that is worth reading, even if your need for anonymity doesn’t go as far as protecting yourself from possible physical harm.
Another problem with VPNs in general, and with corporate VPNs in particular if they are implemented to improve control and compliance, is that even a minor misconfiguration could lead to data leaking out even after you have convinced yourself that it can’t and won’t.
As we mentioned earlier, VPN client software typically creates a virtual network card that handles all traffic sent and received via the VPN, and automatically adds its own layer of anti-snooping encryption to any data that it transmits.
But this only protects traffic that your operating system decides to route through the VPN network device.
Given that the VPN itself needs to send its own low-level network packets via a regular network card over an actual internet connection, a configuration blunder at the operating system level could leave the non-VPN network link open for some network destinations, or for some applications.
When you run a network-aware application such as a browser, an auto-update utility, or a cloud data-sharing tool, you are typically aware only that network traffic is being sent and received, but not which network link it is using for the purpose.
This makes it hard to spot that an app you assume has been ‘locked down’ to use the corporate VPN is, in fact, able to sidestep the VPN and communicate directly over the internet instead.
Sometimes, in fact, your sysadmins may decide to have two or more separate network links left open at the same time, creating what’s known in the jargon as a split tunnel, so that you can deliberately access some cloud services directly, without first being ‘teleported’ via the head-office LAN, but access other services only by passing the relevant data through the VPN tunnel.
This can greatly improve efficiency, especially if you are in another country and sometimes need to access local servers.
As we showed above, traffic between a laptop in the UK and a nearby server, also in the UK, took more than six times longer when it was delivered via a VPN server hosted the US instead of being sent directly.
The sixfold slowdown happened because the VPN traffic was first packaged into encrypted form and delivered to the VPN server in the US, crossing the Atlantic ocean once. There, it was decrypted and passed back to the UK, where the true destination server was located, thus crossing the Atlantic for a second time. The reply then went back to the US VPN server, where it was encrypted and returned to its starting point in the UK, for a third and fourth ocean crossing.
The problem with split tunnels, where some traffic is deliberately exempted from the VPN, is that they can lead, either accidentally or by design, to data going where it shouldn’t.
Notably, data that would usually be allowed from your computer onto the internet only after it had gone through some sort of security filtering at head office might nevertheless escape directly and unfiltered, despite the VPN.
In extreme cases (although good VPN software will prevent this from happening if it can), if your computer is remotely hooked up to head office over a VPN and locally open to the internet via your home LAN or the Wi-Fi service at a coffee shop, you might unknowingly turn into an outbound network route that is visible to other computers on the company LAN.
In other words, other devices on the LAN that can reach your computer via the VPN might find a way out onto the internet via the other half of your split tunnel, inadvertently (or perhaps even deliberately) misusing your computer as an unofficial internet-connected company router, instead of going out only via the corporate firewall.
This sort of routing leak can cause catastrophic data breaches by providing an unregulated, unfiltered, unmonitored and unlogged network ‘backdoor exit point’ from what would normally be a carefully-managed corporate LAN.
VPN services aren’t a magic security solution, whether you’re using them ‘outside-in’ to protect your business network, ‘inside-out’ to protect your regular internet usage, or both.
Firstly, VPNs anonymise the source of your traffic because it emerges from the VPN server’s network, not your own, but they can’t and don’t anonymise the data you choose to send over the VPN.
Secondly, VPNs may promise never to keep logs showing where you went or when, but there is no foolproof way of knowing quite how reliable such promises are, or quite how safe the VPN provider’s own network is against intrusion and snooping by third parties.
Thirdly, VPNs can’t force all your network traffic through their servers if your computer or operating system has been configured, either by accident or design, also to let data go out directly from some apps or to some online services.
VPNs need careful choice and cautious management, and should be used in addition to other cybersecurity precautions such as endpoint protection and web filtering, not as a replacement for them.
As we mentioned above, VPNs alone don’t magically make users anonymous, don’t inevitably prevent snoops and criminals from tracking you, and may give a false sense of security if they aren’t configured correctly and kept in a secure configuration.
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Featured image of maze by Susan Q Yin via Unsplash.