server reachability case studies

Leak case study 4: Leaks when VPN server can’t be reached

Last updated:

A VPN’s protection of a user’s privacy and security relies on its ability to send all traffic through an encrypted channel to the associated VPN servers. When a VPN application has trouble reaching the server it is connected to, it may fail to properly respond in ways that protect a user’s online activity. This case study from our Digital Security Lab describes what these types of leaks, and how to test for them using the ExpressVPN Leak Testing Tools.

VPN server reachability overview

At times, VPN applications may be unable to reach the VPN server that they are connected to. This can occur for a number of reasons, including:

  • Maintenance work, e.g. for essential software patches
  • Blocking
  • Hardware faults
  • Data center outages
  • Bad routes

When this happens, a user connected to the VPN will lose network connectivity. VPN applications should notice this issue relatively quickly and take action to restore the user’s connection.

These leaks should be considered fairly severe, as there is a high probability of a VPN application being unable to reach a server at some point in time. In the real world, the probability of these issues occuring is relatively high. VPN providers should ensure not only that their applications not leak under these conditions, but also that the user is quickly re-connected to a reachable server. The latter point, however, is a user experience issue and beyond the scope of this leak case study.

Reachability leaks

When the VPN server is unreachable, VPN applications may behave in one of several ways:

  • Fail to notice the issue, leaving the user without a network connection
  • Detect the issue, and disconnect the user from the VPN permanently
  • Detect the issue, and try to connect the user to another VPN server

In each of these scenarios, a VPN application could leak.

Testing for leaks

Manual testing

Manually testing for leaks in this situation is quite difficult. In general you will have no control over the VPN server itself and thus can’t easily simulate a reachability issue.

Generally the best way to simulate a reachability issue is by using firewalls. This can be done either by using firewalls on the test device itself or firewalls on an upstream device, e.g. a router or virtual machine host. We thus consider these steps appropriate only for power users to attempt.

Manipulating Firewalls

We give reproduction steps below which assume that the user is educated in firewall manipulation. In order to manipulate firewalls, we recommend the following tools:

Windows: Netsh Advfirewall

MacOS: Packet Filter

Linux: iptables

Repro Steps

  • Connect your device to the VPN
  • Determine the VPN server’s IP address
  • Initiate packet capture on all interfaces, e.g. using tcpdump
  • Create a firewall rule to block all outgoing traffic to the VPN server IP
  • Wait for the VPN application to notice the block and stabilize to a new state
  • Stop packet capture
  • Remove the firewall rule
  • Disconnect the VPN
  • Check the traffic capture for packets which went unencrypted out of the device

Note: Checking traffic capture can be tricky as there can be noise generated from local IP traffic, ARP and other acceptable traffic.

Testing using the ExpressVPN Leak Testing Tools

The ExpressVPN Leak Testing Tools are an extensible suite of open-source Python tools designed for both manual and automated leak testing of VPN applications. Please see our introduction to the tools for instructions on downloading and setting up the tools.

Once you’ve set up the tools, ensure you are in the tools root directory and execute:

./run_tests.sh -c configs/case_studies/vpn_server_reachability_leaks.py

These tests will perform exactly the manual testing steps described above. They will determine the IP of the VPN server automatically and create firewall rules to block connectivity to the VPN server. This will simulate a reachability failure.

The tests will then monitor leaks for a period of time to see how the VPN server reacts. They check for various types of leaks and report any issues.