Course on Privacy and Anonymity Using VMs, VPN, and Tor – Part 2

Course Overview

This course is divided into two parts: a basic and an advanced version. The basic version describes a popular method of using VPN+Tor with Whonix. The advanced version uses nested chains of VPN and Tor, configured with virtual machine routers.

Note: The advanced setup requires careful reading and at least several days of focused work.

Basic Version Architecture

The host machine connects to the internet through a VPN service with firewall rules to prevent leaks. VirtualBox runs on the host, and several Linux work VMs are used for compartmentalization and isolation. Each Linux work VM initially accesses the internet through the host’s VPN service, then connects to the internet via another VPN service or the Tor network. Firewall rules are set up to prevent leaks. For connecting to Tor, the guide uses Whonix, which consists of a Tor gateway VM and a Linux-based (Debian, Ubuntu) workstation VM.

By default, VirtualBox isolates the resources (storage, memory, processing) used by each VM from both the host and other VMs. While the Linux work VMs (and the Whonix gateway VM) use the host’s VPN connection via NAT, VirtualBox does not allow traffic between VMs in this mode. The Linux work VMs (and Whonix workstation VMs) are also isolated from each other online, as they have different IP addresses and network latencies.

Because Whonix separates the workspace and network into different VMs, it resists attacks that compromise or bypass Tor and/or firewall rules. However, a VPN client running in each Linux work VM is vulnerable to such attacks. Even so, the VPN client running on the host is isolated, so any damage is limited.

Advanced Version Architecture

This section presents an advanced setup that provides much greater privacy, anonymity, and freedom compared to the basic setup. It uses compartmentalization and isolation with multiple virtual machines (VMs) accessing the internet through arbitrarily complex nested and branched chains of VPN and Tor.

The advanced setup is generally similar to the basic one. The host machine connects to the internet through a VPN service with firewall rules to prevent leaks. Multiple Linux work environments are used for compartmentalization and isolation, and different work environments independently access the internet through VPN services or the Tor network. Profiling and surveillance can be easily prevented by using multiple pseudonyms in several work VMs with different internet IP addresses. The impact of malware and hacking is limited as long as the VM network services and VPN client are not compromised or bypassed.

However, the advanced setup significantly surpasses the basic one in several key aspects. Instead of using an existing and potentially compromised system (usually Windows or macOS) as the VM host, this configuration uses a fresh Linux system. Since Linux is open source, the risk of backdoors is also lower. Additionally, since most Linux distributions are free, there is no financial trail linking you to a product key or other unique installation information.

In the advanced configuration, all workspaces and network services (VPN and Tor clients) are isolated in separate workspace and gateway VMs (pfSense VPN client VM and Tor client VM). Attacks exploiting vulnerabilities in applications and users cannot reach network services unless they also compromise or bypass the barriers between VMs and the host. And since workspace VMs can only access the internet through gateway VMs, access to remote resources is impossible if the gateway is broken, except in the case of intentional user error.

Moreover, in this system, the placement of gateway VMs and VirtualBox internal networks transparently creates layers of encrypted routing instructions, which then direct packets through specified chains of VPN servers and Tor entry relays. In other words, internet packet routing mirrors the local routing of gateway VMs in VirtualBox. Using the VirtualBox graphical interface, you can create and modify arbitrarily complex nested and branched chains of VPN and Tor connections. You can also automate routing topology changes using the VBoxManage command-line interface (not covered in this guide).

By definition, this is a simple (and static) implementation of onion routing:

Onion routing is a technique for anonymous data transmission over a computer network. Messages are repeatedly encrypted and then sent through several network nodes called onion routers. Like peeling an onion, each router removes a layer of encryption to reveal routing instructions and forwards the message to the next router, where the process repeats. Thus, intermediate nodes cannot know the origin, destination, or content of the message.

Preliminary Privacy Considerations

In short: ideally, local observers should only see that you are using a VPN service and nothing more. If you use multiple VPNs as described below, it’s best to choose one to connect to directly. Consistently using only one VPN service with a direct connection probably attracts less attention than using many VPN services and Tor.

If you already use a VPN service, it’s best to use it as your direct-connect VPN if it provides privacy and sufficient performance. Connecting to your current VPN service through a new direct-connect VPN likely makes little sense, as there may be records linking your account to the IP address assigned by your provider.

If you don’t use a VPN service yet, now is the time to choose one for direct connection. For a direct-connect VPN, key characteristics are speed (low latency), unlimited usage (bandwidth), and popularity (so you stand out less).

Choosing between a popular or a small private VPN is not trivial. In a popular public VPN, you easily blend in with other users, who may even be doing the same things as you. But popular services often have speed issues, more intense blocking, and may actively hand over all data upon request. On the other hand, there are non-public or self-hosted VPNs used only by you. In this case, surveillance systems see only one user connecting to a foreign server, which isn’t great. There are many nuances here, which we’ll discuss in more detail later.

Generally, you’ll use only one direct VPN connection, so it’s best to reserve services that allow multiple simultaneous connections and have exit servers in many countries for use as indirect VPNs (which you’ll access through your direct VPN).

If you’re not already using a VPN service and/or Tor, install your chosen direct-connect VPN client on the machine you’re reading this on, following your provider’s instructions.

Using Nested Chains of VPN and Tor to Distribute Trust

It’s important to remember that when using VPN services, you’re simply shifting trust from your ISP and government to the VPN provider (or, if using a self-hosted VPN, to the hosting provider). You can choose a VPN provider that uses multiple hops (Double- & Triple-VPN), promises not to keep logs, carefully separates your account data from its VPN servers, and even claims it will relocate or shut down without violating your privacy. But there’s no reliable way to know if your trust is justified—unless you find out it isn’t.

Therefore, if privacy and pseudonymity are truly important, you shouldn’t rely on just one VPN provider. Instead, you can distribute trust by tunneling one VPN through another, from a different provider. More generally, you can create nested chains of VPN tunnels from multiple providers. To compromise your privacy, an adversary would need to compromise or substitute most (if not all) VPN services in your chain(s).

However, this approach is vulnerable in at least two ways:

• First, internal (in a topological sense) VPN services you access indirectly through other VPNs may have financial trails. The best option is to pay with cryptocurrency.
• Second, some (or all) VPN services in your chain(s) may be vulnerable to compromise or subversion by highly inventive adversaries. To reduce this risk, it’s wise to choose providers operating from weakly interacting geopolitical spheres of influence (SOI). It’s best to avoid providers from the SOI where you reside. For your direct-connect VPN, it’s probably best to choose a provider in a relatively neutral SOI that doesn’t attract much attention. For the terminal/final VPN, choose a provider in a clearly non-cooperating SOI. If you use three or more VPNs, alternate different SOIs with poor interaction for the middle VPNs.

You can also (to some extent) rely on Tor—a very complex implementation of onion routing, where trust is intentionally distributed among many participants with different goals. It provides much greater anonymity than VPNs (even complex nested VPN chains). However, configuring applications to use Tor correctly (without leaks) is non-trivial, and it’s best to use ready-made packages.

Tor Browser includes Tor and an anonymity-optimized version of Firefox from the Tor Project. Despite its ease of installation and use, it’s vulnerable to malware exploits and leaks from user-misconfigured applications.

The Amnesic Incognito Live System (Tails) is a LiveCD (read-only by default) that can also be run as a virtual machine. It comes preconfigured with many applications. However, it’s still vulnerable to malware exploits that bypass Tor. Whonix separates the workspace and network services into separate gateway and workstation VMs. This protects against deanonymization due to user error, misconfigured applications, or malware.

It’s best to place Tor at the end of nested VPN chains. VPN services are popular for P2P file sharing and probably attract less unwanted attention than Tor, except where file sharing and dissent are banned. Access to Tor is blocked in some places. You can bypass blocks by connecting through bridge relays. However, as bridges are discovered and blocked, users must switch to new ones. Given the trial-and-error process of using bridge relays, they don’t reliably hide Tor usage. The safest approach is to use both a VPN and obfuscated bridges that mask Tor traffic.

Some sites don’t accept connections from Tor exit relays. Some block all Tor exits, others only those on various blacklists. A simple solution is to route a VPN service through Tor.

Preventing VPN Leaks

VPN connections are vulnerable to (at least) two types of leaks. One type involves DNS servers. Usually, after the VPN client requests a connection, the server sets up the tunnel and provides the client with necessary information. This includes changes to network routing so all internet traffic uses the VPN tunnel, and DNS servers to use for resolving hostnames to IP addresses.

But if something goes wrong, the client machine may instead query the provider’s DNS servers. This can reveal your identity to those monitoring the VPN exit server. Additionally, the provider can see which domains are accessed. If the provider sees both your traffic at the VPN entry server and queries to its DNS servers, timing analysis can easily show which domains you’re visiting. In other words, the VPN is compromised for that user.

Preventing such DNS leaks can be non-trivial. It may require temporarily hard-coding the VPN’s DNS servers in the client machine’s network configuration and undoing this after closing the VPN connection. This is what a VPN client should do, but sometimes it doesn’t work, especially on rare operating systems with incomplete VPN support.

The other type of leak occurs when traffic bypasses the VPN tunnel and goes directly to the internet. The OS may incorrectly implement the routing changes made by the VPN server to direct all internet traffic through the VPN tunnel. Or the VPN connection may fail in some way. For example, servers may go down, the VPN client software may freeze or crash, perhaps after intermittent network outages. Whatever the reason, it’s crucial that internet access only occurs through the VPN tunnel, even if the VPN connection is misconfigured or fails.

This tutorial uses OpenVPN and WireGuard as the main protocols. While these protocols are blocked in some places, don’t dismiss them immediately. OpenVPN is time-tested and stable, with support built into most OS kernels. WireGuard is modern, fast, and simple. There are also several ways to obfuscate OpenVPN and WireGuard, making them “invisible” to providers. However, that’s a topic for more advanced guides.

OpenVPN technology was originally designed for secure remote network access, not for internet anonymity. By default, OpenVPN sends internet traffic locally to save VPN bandwidth. While it’s not hard to configure VPN tunnels to carry all network traffic, it’s difficult to prevent the client machine’s physical adapter from being used after the VPN client program closes. By default, all routing changes made when connecting to the VPN are undone when disconnecting. This is generally good, as otherwise users might lose internet access (even to reconnect the VPN).

Some VPN providers use proprietary clients that reportedly prevent such failures. But overall, the only reliable protection is network routing and firewall rules that restrict network access to the VPN tunnel.

Using pfSense Virtual Machines as VPN Clients

To safely tunnel one VPN through another without leaks on a single machine, you need network virtual machines (VMs) acting as gateway routers. Moreover, you can create arbitrarily complex nested and branched chains of VPN (and Tor).

pfSense, a secure router/firewall OS based on FreeBSD, is a suitable choice for VPN client VMs. pfSense VMs are small and resource-light. Creating VPN connections and preventing leaks is straightforward in pfSense. The pfSense WebGUI is intuitive and provides nearly all the features needed to create a virtual router with VPN and firewall. Using pfSense VMs as VPN clients will be covered in later sections.

Visualizing Nested VPN Tunnels

Chains of nested VPN tunnels provide better privacy and anonymity when accessing content servers, Tor entry relays, P2P network peers (like BitTorrent, Freenet, and I2P), and other remote servers. Without a VPN, remote servers see your ISP-assigned IP address. Conversely, your ISP and other local observers see the IP addresses of remote servers. If connections aren’t end-to-end encrypted (E2EE), they can eavesdrop and perform man-in-the-middle (MITM) attacks.

• With one VPN: Remote content servers see the VPN exit IP address. Your ISP and other local observers see the VPN entry IP address, and the VPN tunnel is encrypted. However, the VPN provider knows both your ISP-assigned IP and the remote server IPs.
• With two nested VPNs: Remote content servers see the exit IP of the second (inner) VPN. Your ISP and local observers see the entry IP of the first (outer) VPN. Both VPN tunnels are encrypted. Neither VPN provider knows both your ISP-assigned IP and the remote server IPs. The first (outer) VPN provider knows your ISP-assigned IP and the entry IP of the second (inner) VPN. The second (inner) VPN provider knows the remote server IPs and the exit IP of the first (outer) VPN.
• With three or more nested VPNs: Information about your internet activity is even more fragmented and harder to compromise. However, as you increase the depth of VPN tunnels, usability is limited by two factors: each VPN layer adds 50–100 ms of latency and may limit bandwidth; overall reliability (the product of each VPN’s reliability) decreases.

Planning the Initial Setup

Each puzzle piece represents a VPN exit with a static IP address shared by all users. Two VPN services (VPN1 and VPN2) form the backbone. A third VPN service, routed through VPN2, provides several simultaneous exits (VPN3a and VPN3b). A Tor client, also routed through VPN2, provides internet access through a cloud of frequently changing exit IPs used by many other users. Finally, a fourth VPN service (VPN4) is routed through the Tor connection.

Each VPN tunnel in the nested chain provides a certain degree of separation and anonymity. The degree depends on factors like the number of simultaneous users, what the service logs, and the availability of those logs to adversaries. Generally, the highest risk is being linked to the VPN1 exit, less to VPN2, and even less to VPN3a and VPN3b. Tor connections likely provide much greater separation and anonymity, so the risk of association through the Tor exit cloud is much lower than through VPN3 exits.

However, routing VPN4 through Tor weakens anonymity. This is obvious if there are email or financial trails from you to VPN4. But even free VPN services without such links weaken Tor’s anonymity. Tor clients plan and test many circuits with different paths and exit relays. They usually use several parallel circuits to isolate application data streams and frequently change circuits. But after creating a VPN tunnel over a specific circuit, the Tor client can’t move it to another circuit until it disconnects and reconnects. Still, the VPN4 exit is potentially much less associated with the VPN2 exit than the VPN2 exit is with you.

Everyone using a given VPN exit server shares the same IP address. This is good, as crowding increases anonymity. However, using one VPN exit for multiple pseudonyms is somewhat counterproductive, given the shared IP. It’s best to use only one main pseudonym for each pfSense VPN client VM and its corresponding VPN exit and position in the overall nested VPN chain.

Also, each pseudonym should consistently use a specific VPN exit. Changing IP addresses may trigger account verification requests from some services or even lead to blacklisting. With Tor, this is hard to avoid, as clients use several parallel circuits (including exit relays) to isolate application data streams and frequently change them. You can tunnel VPN through Tor, but this reduces anonymity.

When creating and using such setups, remember that the connection between you and various elements—exit IP addresses, as well as pseudonyms and workstations using them—can never be reduced, only increased. For example, consider VPN4 routed through Tor. If you use this connection with a pseudonym or workstation more closely linked to you, that link will likely persist. Or consider a pseudonym created with VPN4. Using that pseudonym without Tor, even through nested VPNs, forever links it to you.

Multiple pseudonyms should never use the same workstation VM, given the risk of cross-correlation through standard tracking, malware, and active attacks. It’s also wise to split information for a given pseudonym among several workstation VMs. One workstation VM can be used for regular internet work. Using a diskless VM with a LiveCD provides some protection when visiting suspicious sites or opening questionable files. Another workstation VM can hold a cryptocurrency wallet client and other financial information. Highly sensitive information can be protected on one or more VMs that are always offline and never share local networks with potentially compromised VMs.

In particular, a workstation should not contain information about the VPN account it connects through. Remote servers see VPN exit IP addresses and may even report them in forum posts or email headers. However, account data like email address and payment method can reveal your real identity (or at least a weaker pseudonym). While information about VPN services purchased to extend the nested VPN chain is less sensitive, it (like other financial info) should be separated from regular network activity.

This is problematic, as configuring and managing pfSense VMs requires workstation VMs to access the pfSense web interface. To configure the VPN client, workstation VMs must have VPN credentials, which may be linked to an email address and payment method. To reduce the risk of compromise and cross-correlation, it’s best to administer each pfSense VPN client VM using a dedicated workstation VM that contains no information about the pseudonyms connecting through that pfSense VM. We’ll show you how to do this.

Onion Market – a free P2P exchange on Telegram.